Summary:	ASTERISK-27673: Attended SIP Transfer via func local_attended_transfer does not call TRANSFER_CONTEXT
Reporter:	Peter Katzmann (pk16208)	Labels:
Date Opened:	2018-02-13 02:03:36.000-0600	Date Closed:	2018-03-12 10:14:23
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:	11.25.3 13.17.2	Frequency of Occurrence	Constant
Related Issues:
Environment:	ubuntu lts 14.x, 16.x	Attachments:
Description:	During tests of transfer scenarios we figured out that under some circumstances the defined TRANSFER_CONTEXT is not called. We nailed it down to Attended Transfers via SIP REFER inside a single pbx. Further debugging showed that inside chan_sip.c the handle_request_refer asterisk calls  local_attended_transfer. If these function succeeded asterisk returns (13.x series) or jumps to cleanup (11.x series) without calling any ast_async_goto for the TRANSFER_CONTEXT variable.
Comments:	By: Asterisk Team (asteriskteam) 2018-02-13 02:03:36.697-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Asterisk Team (asteriskteam) 2018-02-13 02:03:37.288-0600 The module you are reporting the issue against is no longer supported as a core module but your issue is in the queue. Your patience is appreciated as a community developer may work the issue when time and resources become available. Asterisk is an open source project and community members work the issues on a voluntary basis. You are welcome to develop your own patches and submit them to the project.[1] If you are not a programmer and you are in a hurry to see a patch provided then you might try rallying support on the Asterisk users mailing list or forums.[2] Another alternative is offering a bug bounty on the asterisk-dev mailing list.[3] Often a little incentive can go a long way. [1]: https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process [2]: http://www.asterisk.org/community/discuss [3]: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties By: Joshua C. Colp (jcolp) 2018-02-13 05:14:08.173-0600 An attended transfer doesn't result in any dialplan executing so TRANSFER_CONTEXT wouldn't be applicable. It results in one channel taking the place of another, wherever it may be. The dialplan variable is only used for blind transfers as in that case you are specifically telling a channel to go back into the dialplan. By: Peter Katzmann (pk16208) 2018-02-13 05:58:00.892-0600 Well why does Attended Transfer via DTMF in main/features.c -> builtin_atxfer trigger an goto to TRANSFER_CONTEXT , when this variable is only for BlindTransfer and not applicable for attended_transfer ? By: Joshua C. Colp (jcolp) 2018-02-13 06:02:18.894-0600 DTMF based attended transfer goes through Asterisk so it knows that it will end with an attended transfer and thus TRANSFER_CONTEXT can be used for the initial call. With a SIP protocol level attended transfer we have NO idea that a call is going to end up as an attended transfer until the transfer is completed, which is after the dialplan has been executed. By: Peter Katzmann (pk16208) 2018-02-13 06:44:39.194-0600 Still not get into this. Why can we play attended_transfer_complete sound for sip refer if we don't have the knowledge of a completed transfer ? So we have this sequence in local_attended_transfer <code>       /* Transfer succeeded! */        const char *xfersound = pbx_builtin_getvar_helper(target.chan1, "ATTENDED_TRANSFER_COMPLETE_SOUND");                /* target.chan1 was locked in get_sip_pvt_byid_locked, do not unlock target.chan1 before this */                ast_cel_report_event(target.chan1, AST_CEL_ATTENDEDTRANSFER, NULL, transferer_linkedid, target.chan2);                /* Tell transferer that we're done. */                transmit_notify_with_sipfrag(transferer, seqno, "200 OK", TRUE); </code> So for me it looks like we are still in control of the flow and it should be possible to trigger the dialplan. By: Joshua C. Colp (jcolp) 2018-02-13 06:50:49.296-0600 When the attended transfer is COMPLETED you know it is an attended transfer and can play a sound to the transferer for example. However an attended transfer is not "send this call into the dialplan at extension 1000 context test". It's "this channel is taking my place". It may go into a bridge with another channel, for example. It's not going into the dialplan in that case and TRANSFER_CONTEXT wouldn't do anything. What would you expect the dialplan variable to do with a SIP initiated attended transfer? By: Peter Katzmann (pk16208) 2018-02-13 09:25:55.152-0600 At DTMF XFER the dialplan call occurs after everything is set up and shortly before the channels are masqueraded. This could also be achieved for SIP REFER, i played around a little bit and got it working as expected, but this was only proof of concept. If this is working it gives me the possibility to keep track about the call flow that there was an attended transfer. Currently this scenario is an blind spot for me and i loose information which are crucial for our users. By: Joshua C. Colp (jcolp) 2018-03-12 08:02:44.745-0500 Are you planning to provide this change as a new feature? By: Peter Katzmann (pk16208) 2018-03-12 10:13:46.427-0500 Sorry no, i'm not so deep in asterisk development to provide an acceptable patch. This was more something like a proof of concept. By: Joshua C. Colp (jcolp) 2018-03-12 10:14:23.386-0500 As that would be a new feature we don't accept new feature requests without a patch. As a result I am suspending this issue.