[asterisk-bugs] [JIRA] (ASTERISK-21146) Semi attended transfer causes queue member not to respect wrapuptime
Eelco Brolman (JIRA)
noreply at issues.asterisk.org
Thu Feb 21 12:15:18 CST 2013
Eelco Brolman created ASTERISK-21146:
----------------------------------------
Summary: Semi attended transfer causes queue member not to respect wrapuptime
Key: ASTERISK-21146
URL: https://issues.asterisk.org/jira/browse/ASTERISK-21146
Project: Asterisk
Issue Type: Bug
Security Level: None
Components: Applications/app_queue
Affects Versions: 1.8.20.1
Reporter: Eelco Brolman
Attachments: semi_attended_transfer_queue_member_status.patch
h2. Situation
Considering the following situation:
* 1 queue Q (900) with a wrapuptime of 30 seconds
* 1 member M (Local/800 at from-internal)
* a local phone 700
* queue members can do a *2 DTMF for atxfer
h2. Call sequence
* Call A to queue 900
* M is called and answers
* Call B to queue 900 (so we have a waiting call)
* A presses *2, dials 700#
* 700 is ringing, but DOES NOT answer
* M hangs up, making the atxfer a semi blindxfer (if that is a word)
h3. Expected
At this points, I expect M to get another call after 30 seconds (wrap up time).
h3. Problem
BUT: M get the new call B immediately.
h2. Analyse
This is due to the fact that when M hangs up while 700 is still in ringing state, no channel masquerade is done, since there is nothing to masquerade yet. app_queue does not get notified at this point yet, but DOES get notified that a channel (in this case Local/800) has changed the state to AST_DEVICE_NOTINUSE. So it makes the agent available, and he get a new call immediate.
h2. Fix
I have attached a patch, which hooks to the device-state notification code, and sets the member->lastcall timestamp to "now" in the case the device was previously in the AST_DEVICE_INUSE state.
This fixes the wrapuptime issues, but does not take care of the queue_log entry and the QueuememberState event which occur late (i.e. when 700 really answer the call and a masquerade can be done).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list