Summary:ASTERISK-06236: Hangup event occurs when the agent answers the call - [queue related problem]
Reporter:Blaz Ziherl (bziherl)Labels:
Date Opened:2006-02-02 05:04:56.000-0600Date Closed:2006-05-09 10:06:25
Versions:Frequency of
Environment:Attachments:( 0) Configs.txt
( 1) Events.txt
( 2) Verbose.txt
Description:A hangup event occurs, when agent answers the call from the queue, eventhough the call is still active and the agent and client can communicate normally. The result of that is that if you're using Monitor() application in the extensions where the agents are reachable, the call that reached the agent will not get recorded, as the hangup event will occur just a few milliseconds after the call has been answered by the agent.


I have attached attached the Verbose CTI, where you can see the problematic line 17. That is the hangup event right after the agent's answer.
Comments:By: Blaz Ziherl (bziherl) 2006-02-02 05:08:09.000-0600

I have also added the list of events received from the Asterisk Manager API (see line 35 for the problematic HangUp event) when a call is placed into the queue, answered by the agent and then truly ended. The call in fact really terminated a minute later when the real HangUp event was raised (see line 38).

Also see my current configuration in the Configs.txt file.

By: Serge Vecher (serge-v) 2006-05-01 14:25:49

Is this still an issue with v. Has anybody else experienced this?


By: Blaz Ziherl (bziherl) 2006-05-01 14:56:13

I haven't tried yet, but it does persist in 1.2.6.

By: Serge Vecher (serge-v) 2006-05-09 10:02:17

bziherl: please update to the most recent code in 1.2 branch and attach a verbise log showing the problem. Since you have a sip client, please turn sip debug on also.


By: BJ Weschke (bweschke) 2006-05-09 10:06:25

Unfortunately, this is normal behavior when you're using callback agents. The hangup event you're seeing is the Local channel stepping out of the way for a native bridge once the call gets setup with the intended "real" channel for the Agent callback. It's not ideal behavior, but this is how it's been and will be for 1.2 and 1.4. The alternative is to use the Monitor functionality built in to 1.2 and the Monitor/MixMonitor functionality built into /trunk (1.4 to be).