-
Délai après Hangup
Bonjour,
Je me permet de poster ici car je rencontre un problème étrange.
Je bosse sur un script perl dont le but est de couper à la demande des appels entrants, passés depuis un téléphone portable, qui sont dans un Chanspy.
Mon problème est le suivant : lorsque je demande le hangup, via AMI, le channel est raccroché (je n'entend plus rien dans mes téléphones), mais les téléphones ne raccrochent que 35 secondes (précisément) plus tard.
J'avais déjà rencontré ce problème, sans pouvoir le résoudre, avec des téléphones fixes. Le délai était alors (et est toujours) d'une minute précise.
Ce problème est d'autant plus étrange que jusqu'à la semaine dernière, j'avais un autre script qui faisait le même genre de chose, et qui fonctionnait parfaitement. Aujourd'hui, pour en avoir le coeur net, j'ai testé à nouveau ce script, et j'ai le même souci.
Afin de trouver la cause, j'ai effectué quelques tests :
- envoi d'un hangup via AMI : délai de 35 secondes.
- envoi d'un hangup via le CLI : délai de 35 secondes.
- appel vers le scénario de test suivant : délai de 35 secondes.
Code:
[test]
exten => _X.,1,Answer
exten => _X.,2,Wait(10)
exten => _X.,3,Hangup()
- appel du scénario de prod suivant, puis raccrochage du channel espionné : raccrochage immédiat !!!
Code:
[listenchannel2]
exten => _X.,1,Answer
exten => _X.,n(RelitDtmf),Read(sDTMF,,1,,,3)
exten => _X.,n,GotoIF($["${sDTMF}" = "*"]?:RelitDtmf)
exten => _X.,n,Read(ukey,,7)
exten => _X.,n,ChanSpy(,qg(${ukey})E)
exten => _X.,n,Hangup()
Jusque la, j'étais prêt à incriminer l'opérateur, vu que je n'ai rien touché à ma config... Mais du coup, si c'est l'opérateur, pourquoi le dernier cas fonctionne bien ?
Si je ne me trompe pas, lorsque l'appel espionné est coupé, on passe direct à la ligne suivante, à savoir le Hangup, donc on est exactement dans la même situation que pour le test juste au dessus...
Est ce que quelqu'un ici à une idée ? Je suis en train de m'arracher les cheveux la :confused:
Merci d'avance
Joris
-
idée de réflexion, et pas certitudes absolues.... quand c'est le dialplan qui fait le hangup, les deux channels (qui sont bridgés) sont raccrochés. quand c'est via ami ou cli, tu n'en raccroches qu'un (tu spécifie explicitement quel channel tu raccroche, alors que ce n'est pas spécifié dans le dialplan).
essaie de voir si un core show channels verbose après le hangup cli montre que l'autre channel de l'appel est toujours là... si c'est le cas, il faut peut être explicitement raccrocher les deux
-
Et bien en fait, je ne peux pas faire ainsi, car je ne veux couper que les "espions", la communication espionnée ne doit pas être interrompue.
Du coup, je n'ai qu'un seul channel sur lequel agir.
En tout cas, même si je ne m'explique pas la raison pour laquelle ça fonctionne mieux quand tout est coupé, je ne m'explique pas non plus pourquoi tout ça fonctionnait bien (avec les mobiles) la semaine dernière.
Avant de commencer à écrire mon script, j'ai fait des test "manuels" via un telnet sur l'interface AMI, et ça marchait super bien...
Et puis il y a mon autre script qui raccroche depuis des mois des conférence ConfBridge en temps réel, et qui se trouve affligé du même problème aujourd'hui...
Pensez vous que cela puisse venir de l'opérateur ?
Joris
