[asterisk-bugs] [JIRA] (ASTERISK-21146) Semi attended transfer causes queue member not to respect wrapuptime

[Eelco Brolman (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-21146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eelco Brolman updated ASTERISK-21146:
-------------------------------------

    Description: 
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)
* M 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).



  was:
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).



    
> 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)
> * M 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