Problème de non détection du raccorché

[guiguizmo]

Hello tous,

J'ai un soucis qui n'apparait pas souvent mais qui est quand même récurrent sur mon trunk.

Pour situer, j'ai un trunk sur lequel est installé Asterisk. Tout fonctionne comme il faut sauf que parfois, lorsque quelqu'un effectue un appel sur mon trunk et qu'il raccroche (peu importe la durée passée en communication), Asterisk ne détecte pas que l'utilisateur à effectivement raccroché et du coup l'appel continue (appel fantôme) jusqu’à atteindre 14400 secondes (limite du trunk) et la il est coupé.

Le fournisseur de mon trunk m'informe que le soucis viendrait de mon IPBX qui n'enverrait pas le BYE.

Est ce que ce problème est déjà arrivé à certain d'entre vous ? Avez vous une idée de la cause du problème ?

Toute aide sera généreusement récompensée d'un grand Merci :wink:

[jean]

il faudrait préciser la config, quand cela implique de l'analogique, ca peut arriver. en tout cas, en positionnant le param rtptimeout:

;rtptimeout=60 ; Terminate call if 60 seconds of no RTP or RTCP activity
; on the audio channel
; when we're not on hold. This is to be able to hangup
; a call in the case of a phone disappearing from the net,
; like a powerloss or grandma tripping over a cable.


J.

[guiguizmo]

Hello et merci pour ta réponse,

Ma config c'est Asterisk 13.3.2 sur un dédié OVH CentOS release 6.6

J'ai déjà le paramètre rtptimeout=60 dans mon sip.conf

Mon trunk provider me dit qu'il peut s'agir d'un problème de configuration d'Asterisk qui n'accepterais pas toutes les terminaisons d'appel ... ça te parle ?

[jean]

ok pour la config, mais comment passes tu un appel ? poste physique, analogique, passerelle, softphone, etc...

si asterisk n'accepte pas quelque chose, il le dit dans la console.... sinon, suivant la fréquence du pbm, je lancerai un ngrep -O cappture.pcap port 5060 and host ipovh
dans un répertoire ou il y a de la place, et quand ca foire, il faut aller voir les traces, à l'oeil ou avec wireshark

en tous cas, rtptimeout doit détecter le silence, et mettre un warinng sur la console

[guiguizmo]

Les appels sont passés depuis des postes physiques (fixes ou mobiles).

J'ai épluché les logs et le problème est que je n'ai rien entre l'heure supposée de fin d'appel et le moment ou la communication est coupée à 14400 secondes, pas un warning m'indiquant qu'il y a un problème.

Quand tu dit "fréquence du pbm" du veux dire du pbx ? Et du quoi qu'est ce que c'est ?

J'ai actuellement 3 appels "fantômes" en cours, penses tu que je puisse lancer ta commande et que ça m'afficherait dans le fichier généré le soucis ?

Merci.

[guiguizmo]

Exemple ce matin d'un appel fantôme. Appel passé à 09:32, l'appel s'est terminé à 09:33 et pourtant le canal est resté occupé jusqu'à 13:32. Dans les logs j'ai ça lors de la fermeture du canal :


<--- SIP read from UDP:XXX.XXX.XXX.XXX:5060 --->
BYE sip:+33XXXXXXXXX@XXX.XXX.XXX.XXX:5060 SIP/2.0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX;rport;branch=XXX
Max-Forwards: 70
From: "+33XXXXXXXXX" <sip:+33XXXXXXXXX@XXX.XXX.XXX.XXX>;tag=XXX
To: <sip:+33XXXXXXXXX@xxx.fr>;tag=XXX
Call-ID: xxx.gwin
CSeq: 96064411 BYE
User-Agent: xxx
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, NOTIFY
Supported: path, replaces
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
Content-Length: 0

<------------->
[2016-09-02 13:32:34] VERBOSE[7674] chan_sip.c: --- (12 headers 0 lines) ---
[2016-09-02 13:32:34] VERBOSE[7674][C-xxx] chan_sip.c: Sending to XXX.XXX.XXX.XXX:5060 (NAT)
[2016-09-02 13:32:34] VERBOSE[7674][C-xxx] chan_sip.c: Scheduling destruction of SIP dialog 'xxx.gwin' in 32000 ms (Method: BYE)
[2016-09-02 13:32:34] VERBOSE[7674][C-xxx] chan_sip.c:
<--- Transmitting (NAT) to XXX.XXX.XXX.XXX:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX;branch=XXX;received=XXX.XXX.XXX.XX X;rport=5060
From: "+33XXXXXXXXX" <sip:+33XXXXXXXXX@XXX.XXX.XXX.XXX>;tag=XXX
To: <sip:+33XXXXXXXXX@xxx.fr>;tag=XXX
Call-ID: xxx.gwin
CSeq: 96064411 BYE
Server: Asterisk PBX 13.3.2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

Donc tout à l'air de se passer comme si l'appel avait réellement duré 14400 seconds sauf que ce n'est pas le cas, et entre la fin réelle de l'appel et la fermeture du canal, rien dans les logs se rapportant à cet appel ...

[jean]

c'est pas ultra clair avec l'anonymisation.... je comprends !

si le bye est émis par ton asterisk, c'est que le raccroché ne lui était pas parvenu du poste. et qu'il est enfin arrivé => analyser entre le poste et asterisk

sinon, si c"est ovh qui envoie le bye, essaie de retrouver si ton asterisk a bien envoyé le bye auparavant, et s'il a été acquitté

[guiguizmo]

Est ce que le paramètre hanguponpolarityswitch pourrait aider dans mon cas ?