Asterix ne raccroche pas !

[ferdykkm]

Bonjour à Tous!
Je suis nouveau sur le forum et quand je parcours, j'adore ce vous faite.

J'ai un problème!
J'utilise Asterix pour faire mes appels à international via un fournisseur VOIP.
J'ai un TRUNK qui se connecte a mon compte chez mon fournisseur.
Lorsque je passe un appel en utilisant une extension '1002', Asterix établit bien une liaison avec mon TRUNK et je passe mon appel sans aucun soucis. Mais lorsque je raccroche, Asterix de coupe pas la liaison entre l'extension et mon TRUNK; du coup aucun autre appel n'est possible et je suis obligé de redémarrer mon serveur.

SVP pourrais-je savoir ou se trouve le problème????????

[tanguyd]

Bonjour

Vois tu quelque chose dans les logs quand tu raccroches ? As tu essayé d'activer le debug sip "sip set debug" depuis le CLI asterisk ?

[ferdykkm]

Merci pour votre reponse rapide.
Quand je fais un

sip debug peer 2001

<--- SIP read from UDP:62.225.51.220:5062 --->
ACK sip:23795282032@46.105.44.139:5060 SIP/2.0
Via: SIP/2.0/UDP 62.225.51.220:5062;branch=z9hG4bK354346904
From: "CENTRALE*MAERSK" <sip:2001@46.105.44.139>;tag=548383655
To: <sip:23795282032@46.105.44.139>;tag=as7df85776
Call-ID: 1697675030@192.168.254.2
CSeq: 2 ACK
Contact: <sip:2001@62.225.51.220:5062>
Max-Forwards: 70
User-Agent: Yealink SIP-T20P 9.60.0.110
Content-Length: 0

<------------->
--- (10 headers 0 lines) ---
    -- SIP/voipinfocenter-00000024 is making progress passing it to SIP/2001-00000023

<--- SIP read from UDP:62.225.51.220:5062 --->
ACK sip:23795282032@46.105.44.139:5060 SIP/2.0
Via: SIP/2.0/UDP 62.225.51.220:5062;branch=z9hG4bK2124364413
From: "CENTRALE*MAERSK" <sip:2001@46.105.44.139>;tag=548383655
To: <sip:23795282032@46.105.44.139>
Call-ID: 1697675030@192.168.254.2
CSeq: 2 ACK
Contact: <sip:2001@62.225.51.220:5062>
Max-Forwards: 70
User-Agent: Yealink SIP-T20P 9.60.0.110
Content-Length: 0

<------------->
--- (10 headers 0 lines) ---

<--- SIP read from UDP:62.225.51.220:5062 --->
ACK sip:23795282032@46.105.44.139:5060 SIP/2.0
Via: SIP/2.0/UDP 62.225.51.220:5062;branch=z9hG4bK354346904
From: "CENTRALE*MAERSK" <sip:2001@46.105.44.139>;tag=548383655
To: <sip:23795282032@46.105.44.139>;tag=as7df85776
Call-ID: 1697675030@192.168.254.2
CSeq: 2 ACK
Contact: <sip:2001@62.225.51.220:5062>
Max-Forwards: 70
User-Agent: Yealink SIP-T20P 9.60.0.110
Content-Length: 0

<------------->
--- (10 headers 0 lines) ---

<--- SIP read from UDP:62.225.51.220:5062 --->
ACK sip:23795282032@46.105.44.139:5060 SIP/2.0
Via: SIP/2.0/UDP 62.225.51.220:5062;branch=z9hG4bK354346904
From: "CENTRALE*MAERSK" <sip:2001@46.105.44.139>;tag=548383655
To: <sip:23795282032@46.105.44.139>;tag=as7df85776
Call-ID: 1697675030@192.168.254.2
CSeq: 2 ACK
Contact: <sip:2001@62.225.51.220:5062>
Max-Forwards: 70
User-Agent: Yealink SIP-T20P 9.60.0.110
Content-Length: 0

<------------->
--- (10 headers 0 lines) ---
    -- SIP/voipinfocenter-00000024 answered SIP/2001-00000023
Really destroying SIP dialog '149919920@192.168.254.2' Method: BYE
Reliably Transmitting (NAT) to 62.225.51.220:5062:
OPTIONS sip:2001@62.225.51.220:5062 SIP/2.0
Via: SIP/2.0/UDP 46.105.44.139:5060;branch=z9hG4bK29df8d3b;rport
Max-Forwards: 70
From: "Unknown" <sip:Unknown@46.105.44.139>;tag=as77e62ce0
To: <sip:2001@62.225.51.220:5062>
Contact: <sip:Unknown@46.105.44.139:5060>
Call-ID: 190783951cfed4bb7ee01838780707d9@46.105.44.139:5060
CSeq: 102 OPTIONS
User-Agent: (Very nice Sip Registrar/Proxy Server)
Date: Wed, 18 Dec 2013 13:09:52 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


---

<--- SIP read from UDP:62.225.51.220:5062 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 46.105.44.139:5060;branch=z9hG4bK29df8d3b;rport
From: "Unknown" <sip:Unknown@46.105.44.139>;tag=as77e62ce0
To: <sip:2001@62.225.51.220:5062>;tag=2113377934
Call-ID: 190783951cfed4bb7ee01838780707d9@46.105.44.139:5060
CSeq: 102 OPTIONS
User-Agent: Yealink SIP-T20P 9.60.0.110
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---
Really destroying SIP dialog '190783951cfed4bb7ee01838780707d9@46.105.44.139:5060' Method: OPTIONS
    -- Remote UNIX connection
    -- Remote UNIX connection disconnected
    -- Remote UNIX connection
    -- Remote UNIX connection

[tanguyd]

J'avoue ne rien voir de spécial dans cette log

Que donne un "sip show channelstats" après avoir raccroché ?

As tu ce genre de logs quand tu racroche

Spawn extension (macro-hangupcall, s, 3) exited non-zero on 'SIP/6407-00008597' in macro 'hangupcall'

[ferdykkm]

elastix*CLI> sip show channelstats
Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
77.72.174.129    1ef8e148473  03:45:45 0000037622  0000000000 ( 0.00%) 0.0000 0000037189  0000000000 ( 0.00%) 0.0004
62.225.51.220    1388768768@  03:45:45 0000038921  0000000423 ( 1.08%) 0.0000 0000039392  0000000000 ( 0.00%) 0.0054
2 active SIP channels

77.72.174.129 : Represente l'adresse IP de mon fournisseur
62.225.51.220 : Represente l'adresse IP du client connecté.

[benoitd54]

Bonjour,

Un truc con, tu utilises quel modem pour te connecter à Internet ?

C'est peut etre qu'une piste : essai de changer ton modem ou alors (si possible) de virer le support du SIP ALG sur le modem.

Benoit.

[ferdykkm]

Mon serveur est sur OVH, et cela marche depuis 3mois jusqua Lundi!
Merci pour l'astuce, mais je crois pas que le probleme vient de la!

[tanguyd]

As tu d'autres téléphones sur le même serveur ? Ou as tu essayé avec un softphone pour voir si ça fait la même chose

Si oui, raccrochent t'ils lors d'un appel interne ?

As tu activé iptables sur le serveur ? Y'a t'il des paquets bloqués ? Par exemple moi j'ai déjà eu des soucis avec le module nf_conntrack_sip qui le bloquait du traffic alors qu'une ip avait été autorisée.

Sinon, pour le sip alg, même si ce n'est peut être pas ça, c'est souvent une source de problèmes car son implémentation est souvent mauvaise dans les routeurs grand publique.

[_AK_]

Bonjour et bienvenue.

fait voir ton sip.conf et extention.conf (sans les ip et mdp.)

[jean]

Perso, je suis très fan du ngrep (à installer si besoin est)

ngrep -t port 5060 and host ipdudistant

lancer la commande dans une session à part, établir l'appel, attendre une 20aine de secondes, et raccrocher

=> ca permettra de voir si un bye est envoyé par le distant.