congestion

[mistergorgo]

Hello les amis,
me revoilà devant un problème (2 en fait) sur lesquels je planche depuis quelques jours sans succès.

1- pas moyen de passer un appel sortant (pas tout le temps mais régulièrement)
[2013-08-22 10:02:03] VERBOSE[19345] app_dial.c: -- Called SIP/nomado/015305500
[2013-08-22 10:02:04] VERBOSE[19345] app_dial.c: == Everyone is busy/congested at this time (1:0/1/0)
[2013-08-22 10:02:04] VERBOSE[19345] pbx.c: -- Executing [s@macro-dialout-trunk:23] NoOp("SIP/2006-0000061b", "Dial failed for some reason with DIALSTATU
S = CONGESTION and HANGUPCAUSE = 34") in new stack
[2013-08-22 10:02:04] VERBOSE[19345] pbx.c: -- Executing [s@macro-dialout-trunk:24] Goto("SIP/2006-0000061b", "s-CONGESTION,1") in new stack
[2013-08-22 10:02:04] VERBOSE[19345] pbx.c: -- Goto (macro-dialout-trunk,s-CONGESTION,1)

2- (depuis peu et de manière aléatoire) la conversation sortante commence sans problème et puis après un temps aléatoire le son dans les 2 sens se coupe mais la communication ne raccroche pas. aucun message d'erreur dans les logs

dans les deux cas cela n'arrive que sur le trunk fournisseur sip
j'ai contacté le service technique du fournisseur qui ne voit pas le problème

help please

merci

[jean]

congestion: le peer nomado n'est plus joignable et ca déclenche ce message

tu as manifestement un pbm rseau sur ton lien, ce qui explique aussi le 2nd pbm

[mistergorgo]

merci
je vais enquêter par là-bas

[mistergorgo]

hello,
j'avais ouvert ce post il y a un moment déjà et le problème resurgit (en fait il ne doit jamais être parti bien loin, on utilisait juste un autre trunk).
j'imagine bien un problème de nating, mais comment le mettre à jour?
quelles commandes debug ou analyse de logs pourraient m'aider?
nous avons exactement la même configuration à d'autres bureaux sans qu'ils ne rencontrent le probleme, mais chez nous asterisk est sur un serveur virtuel, est-ce une piste?

help me plz

[tanguyd]

Bonjour
Je pense que le mieux est d'activer le debug sip avec la commande "sip set debug" depuis le CLI d'asterisk

[mistergorgo]

bonjour
j'ai réussi à faire une capture d'un sip debug quand il y a perte de son entre les deux correspondants:
j'ai remplacé les ips par des noms corrspondants aux équipements
il y a en rouge une ligne qui m'intrigue
de plus l'appel arrive sur une ligne analogique et semble vouloir être transférer à une ligne sip???
localhost*CLI> sip set debug on
SIP Debugging enabled

<--- SIP read from UDP:192.168.cisco.spa:5061 --->
NOTIFY sip:192.168.free.pbx SIP/2.0
Via: SIP/2.0/UDP 192.168.cisco.spa:5061;branch=z9hG4bK-1a9b7938;rport
From: <sip:192.168.free.pbx>;tag=11068bc8cfc6daa8o1
To: <sip:192.168.free.pbx>
Call-ID: 9e77d948-2b89eb28@192.168.cisco.spa
CSeq: 158901 NOTIFY
Max-Forwards: 70
Event: keep-alive
User-Agent: Linksys/SPA3102-5.1.7(GW)
Content-Length: 0

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

<--- Transmitting (NAT) to 192.168.cisco.spa:5061 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.cisco.spa:5061;branch=z9hG4bK-1a9b7938;received=192.168.cisco.spa;rport=5061
From: <sip:192.168.free.pbx>;tag=11068bc8cfc6daa8o1
To: <sip:192.168.free.pbx>;tag=as2c7bcc68
Call-ID: 9e77d948-2b89eb28@192.168.cisco.spa
CSeq: 158901 NOTIFY
Server: FPBX-2.10.1(10.2.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '9e77d948-2b89eb28@192.168.cisco.spa' in 32000 ms (Method: NOTIFY)
Reliably Transmitting (NAT) to ope.rateur.net.sip:5060:
OPTIONS sip:ope.rateur.net.sip SIP/2.0
Via: SIP/2.0/UDP my.ip.public.net:5060;branch=z9hG4bK284bdd4b;rport
Max-Forwards: 70
From: "Unknown" <sip:sipusername@my.ip.public.net>;tag=as78788b8e
To: <sip:ope.rateur.net.sip>
Contact: <sip:sipusername@my.ip.public.net:5060>
Call-ID: 7922eec34febbae1398567ed4f335e0c@my.ip.public.net: 5060
CSeq: 102 OPTIONS
User-Agent: FPBX-2.10.1(10.2.0)
Date: Tue, 23 Sep 2014 12:34:42 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

[jean]

le scheduling destruction est tout à fait normal, c'est la libération des ressources pour le dialogue Notify/ok - qui correspond pas à un appel mais à des indications sur l'état du téléphone (genre blf, mais plus trop sur).

perso, je suis un grand fan du ngrep (soit apt-get sur debian, soit google pour centos et install du rpm). c'est plus concis, et on peut capturer via -O pour mettre dans wireshark

pour voir ce qui se passe, il faudrait un core set verbose 3 pendant le pbm. je pense aussi que si tu le laisses en permanence à 2, tu verras les enregistrement.

enfin, mets donc un petit qualify=yes sur le trunk nomado - ca enverra régulièrement des OPTIONS, et surtout ça signalera mieux quand le lien est hs - c'est là qu'il faudra débugger

[mistergorgo]

ce qui m'inquiète dans ce cas-ci, c'est que nomado ou autres sip fournisseurs ne sont pas en cause car le client a appelé sur la ligne analogique via le cisco spa!

[jean]

[2013-08-22 10:02:03] VERBOSE[19345] app_dial.c: -- Called SIP/nomado/015305500
[2013-08-22 10:02:04] VERBOSE[19345] app_dial.c: == Everyone is busy/congested at this time (1:0/1/0)

c'est imparable, le trunk défini dans sip.conf par [nomado] est inaccessible - pbm temporaire de routage, ou défaut du fournisseur, mais ce qui est sur, c'est que ca coince entre chez toi et chez eux....

[mistergorgo]

je comprends bien pour l'exemple 1) que tu reprends
cependant dans la 2è capture debug, c'est un lien analogique qui est en cause, une bonne vieille ligne cuivre sur cisco spa
je me demande si le problème ne se situe pas alors dans freepbx ou le fait que freepbx soit virtualisé?
je suis tout seul au bureau aujourd'hui je vais faire des essais de capture et ngrep

[mistergorgo]

j'ai de nouveau pu capturer le cas ce matin et j'ai également installé ngrep
quelle commande de ngrep puis-je utiliser pour tracer le rtp?

[jean]

quand tu dis, dans le 2eme debug, tu parle de ça: http://www.asterisk-france.org/threads/2652-congestion?p=17722&viewfull=1#post17722

mais y'a pas d'appel, là !

donc, lance dans une console shell: ngrep -O appel.pcap port 5060 and host x.y.z.t puis fais un appel
si les traces ne sont pas parlantes, tu peux aller dans wireshark (dispo sous win & linux) et ouvrir le fichier appel.pcap, tu verras, y'a plein d'options

pour ngrep, en fait, c'est surtout pratique pour le sip - vu ton problème, le rtp n'est pas utile à capturer, car ce n'est pas un pbm d'audio mais de sip.
pour info, quand je veux debugger du rtp, ben, je mets un ngrep -O all.pcap host x.y.z.t et après je trie - mais en pratique, je commence par faire un rtp set debug on depuis la console pour voir quelles adresses s'échangent

[mistergorgo]

je parle de la réponse #6 de ce post
un appel est arrivé via la ligne analogique connectée au cisco spa, les correspondants se parlent (toujours +/- 30sec) et ensuite la communication reste ouverte mais plus de son.
vu que la communication n'est pas interrompue, je pense qu'au niveau sip il n'y a pas de problème mais plutôt au niveau flux rtp
j'ai fait un deuxième test hier matin, un debug d'une comm via trunk sip (j'ai pas posté le résultat car c'est long), j'essaie de la lire et de comprendre, toujours interruption du flux audio après +/- 30 sec avec communication qui continue
je vais aujourd'hui tester la commande ngrep et utiliser whireshark (j'ai même vu qu'on peut rejouer la communication audio avec whshrk)
ceci dit (si tu peux m'aider) les captures sont longues à mettre dans un post

merci pour ton soutien

f

[jean]

- sur le post #6, y'a pas d'appel.... (c'est celui dont je parlais aussi)

- si ca coupe au bout de 30 secondes, ce sont effectivement des pbms classiques de nat/firewall
=> au début de comm, fais un rtp set debug on - tu vas voir les @ ou asterisk envoie les paquets - elle ne doivent pas être dans le lan
=> tu peux aussi regarder les invite avec wireshark, le champ contact (de mémoire) et vérifier que les adresses incluses DANS les paquets Invite
=> avec ngrep / wireshark, tu vas aussi voir le paquet répété (avant de couper, * le renvoie plusieurs fois)