Affichage des résultats 1 à 8 sur 8

Discussion: Problème de non détection du raccorché

  1. #1
    Membre
    Date d'inscription
    juin 2015
    Messages
    41
    Downloads
    0
    Uploads
    0

    Exclamation Problème de non détection du raccorché

    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

  2. #2
    Membre Senior
    Date d'inscription
    septembre 2010
    Localisation
    Where the sun shines
    Messages
    1 418
    Downloads
    0
    Uploads
    0
    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.

  3. #3
    Membre
    Date d'inscription
    juin 2015
    Messages
    41
    Downloads
    0
    Uploads
    0
    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 ?

  4. #4
    Membre Senior
    Date d'inscription
    septembre 2010
    Localisation
    Where the sun shines
    Messages
    1 418
    Downloads
    0
    Uploads
    0
    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

  5. #5
    Membre
    Date d'inscription
    juin 2015
    Messages
    41
    Downloads
    0
    Uploads
    0
    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.

  6. #6
    Membre
    Date d'inscription
    juin 2015
    Messages
    41
    Downloads
    0
    Uploads
    0
    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 :

    Code:
    <--- 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.XXX;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 ...

  7. #7
    Membre Senior
    Date d'inscription
    septembre 2010
    Localisation
    Where the sun shines
    Messages
    1 418
    Downloads
    0
    Uploads
    0
    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é

  8. #8
    Membre
    Date d'inscription
    juin 2015
    Messages
    41
    Downloads
    0
    Uploads
    0
    Est ce que le paramètre hanguponpolarityswitch pourrait aider dans mon cas ?

Les tags pour cette discussion

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •