[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