Voir la version complète : Asterix ne raccroche pas !
ferdykkm
18/12/2013, 12h07
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????????
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
18/12/2013, 15h27
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:506 0
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:506 0
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:50 60' Method: OPTIONS
-- Remote UNIX connection
-- Remote UNIX connection disconnected
-- Remote UNIX connection
-- Remote UNIX connection
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
18/12/2013, 20h57
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
18/12/2013, 23h37
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
19/12/2013, 10h22
Mon serveur est sur OVH, et cela marche depuis 3mois jusqua Lundi!
Merci pour l'astuce, mais :gratgrat: je crois pas que le probleme vient de la!
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.
Bonjour et bienvenue.
fait voir ton sip.conf et extention.conf (sans les ip et mdp.)
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.
benoitd54
19/12/2013, 20h40
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.
Tout à fait d'accord ! A cause de ça, j'ai quelque fois des trunks qui n'arrivent pas à se reconnecter (UNREACHABLE)... et quand je désactive le SIP ALG, tout redeviens à la normale...
il est sur un serveur OVH, y'a pas de modem avec de l'alg...
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. Tous droits réservés