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=as78788b8 e
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