[asterisk-bugs] [JIRA] (ASTERISK-22814) GROUP broken for attended transfer (Both SIP transfer and features.conf)

[Matt Jordan (JIRA)]

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

Matt Jordan updated ASTERISK-22814:
-----------------------------------

    Reference Notes: 
To reproduce, you will need four SIP phones, numbered 1001,1002,1003 and 1004 and the following dialplan.  1002 plays the role of the transferring agent:

{noformat}
exten => _1XXX,1,NoOp(Dialling phone ${EXTEN})
exten => _1XXX,n,Set(GROUP(${EXTEN})=${EXTEN})
exten => _1XXX,n,GotoIf($[${GROUP_COUNT(${EXTEN})} > 1]?busy,1)
exten => _1XXX,n,Dial(SIP/${EXTEN},,rotTwhk)
exten => _1XXX,n,Hangup

exten => busy,1,Hangup(17)
{noformat}

TO TEST WITH SIP:

Pick up phone 1001 and dial 1002.
Answer phone 1002.
On phone 1002, activate the second line, and dial 1003.
Answer phone 1003.
Complete the transfer on phone 1002, which drops out of the call.

Now use phone 1004 to dial 1002.  This will not cause the phone to ring, in error.

TO TEST WITH FEATURES.CONF:

Make sure atxfer is enabled in features.conf, and restart if necessary.

Pick up phone 1001 and dial 1002.
Answer phone 1002.
On phone 1002, hit *2 (for attended transer) and then 1003.
Answer phone 1003.
Hang up phone 1002.

Now use phone 1004 to dial 1002.  This will not cause the phone to ring, in error.


  was:

To reproduce, you will need four SIP phones, numbered 1001,1002,1003 and 1004 and the following dialplan.  1002 plays the role of the transferring agent:

exten => _1XXX,1,NoOp(Dialling phone ${EXTEN})
exten => _1XXX,n,Set(GROUP(${EXTEN})=${EXTEN})
exten => _1XXX,n,GotoIf($[${GROUP_COUNT(${EXTEN})} > 1]?busy,1)
exten => _1XXX,n,Dial(SIP/${EXTEN},,rotTwhk)
exten => _1XXX,n,Hangup

exten => busy,1,Hangup(17)

TO TEST WITH SIP:

Pick up phone 1001 and dial 1002.
Answer phone 1002.
On phone 1002, activate the second line, and dial 1003.
Answer phone 1003.
Complete the transfer on phone 1002, which drops out of the call.

Now use phone 1004 to dial 1002.  This will not cause the phone to ring, in error.

TO TEST WITH FEATURES.CONF:

Make sure atxfer is enabled in features.conf, and restart if necessary.

Pick up phone 1001 and dial 1002.
Answer phone 1002.
On phone 1002, hit *2 (for attended transer) and then 1003.
Answer phone 1003.
Hang up phone 1002.

Now use phone 1004 to dial 1002.  This will not cause the phone to ring, in error.


    
> GROUP broken for attended transfer (Both SIP transfer and features.conf)
> ------------------------------------------------------------------------
>
>                 Key: ASTERISK-22814
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22814
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Functions/func_groupcount
>    Affects Versions: 1.8.15.0, 11.6.0
>         Environment: Debian linux, SIP.
>            Reporter: Matt King, M.A. Oxon.
>            Assignee: Matt King, M.A. Oxon.
>
> A common use for call centres is to restrict phones to give busy tone if one line is busy on a phone and a further incoming call is placed, while leaving a second line free for outbound calls and attended transfers.  This ensures that the queue will move swiftly on to other agents if the phone is already in use, which is highly desirable.
> The recommended way to handle this in the dialplan is by using the GROUP and GROUPCOUNT functions.
> However, problems arise when an attended transfer is made, using EITHER SIP attended transfer direct from the phone, OR the mechanism specified in features.conf
> Specifically, the Group is NOT cleared when the original phone drops out of the call at the end of the transfer.  Instead, the Group is only cleared when the final party hangs up.
> This leaves the agent unable to take further calls until the transferred call completes.
> See below for steps to reproduce.
> This problem has been found with SIP phones. It is unknown whether other channel types are affected, however this seems highly probable as the Group function is channel type agnostic.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira