Summary:	ASTERISK-25249: Features code not working for called party when Local channels are involved
Reporter:	Etienne Lessard (hexanol)	Labels:
Date Opened:	2015-07-14 10:33:23	Date Closed:	2015-07-17 07:13:53
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Features
Versions:	13.4.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) extensions.conf ( 1) features.conf ( 2) full.log ( 3) sip.conf
Description:	In Asterisk 13, features that are activated through DTMF codes are not working for the called party when Local channels are involved. Given I have the following extensions.conf: {noformat} [internal] exten = 102,1,Dial(SIP/bob) exten = 112,1,Dial(SIP/bob,,ht) exten = 122,1,Dial(Local/102@internal,,ht) exten = 132,1,Dial(Local/102@internal/n,,ht) exten = 142,1,Dial(Local/112@internal) {noformat} And I have the following sip.conf: {noformat} [general] directmedia = no dtmfmode = rfc2833 language = fr_FR [alice] host = dynamic context = internal callerid = "Alice" <101> secret = S2BFNK type = friend setvar = TRANSFER_CONTEXT=internal [bob] host = dynamic context = internal callerid = "Bob" <102> secret = 82NWM0 type = friend setvar = TRANSFER_CONTEXT=internal {noformat} And I have the following features.conf: {noformat} [general] [featuremap] disconnect = *0 blindxfer = *1 atxfer = *2 automon = *3 {noformat} When Alice dials 122 And Bob answers And Bob press *0 Then the calls it not hung up (expected: the call is hung up) See full.log for the associated asterisk log output. This is a changed in behaviour from asterisk 11. I've taken a look at some other option to make feature codes work when Local channel are involved: * it  you add the /n modifier for the Local channel (extension 132 in my example), then feature code for the called party "works", but if you try an attended transfer for example, then the pbx-transfer sound will be played in language "en" instead of "fr_FR", and the TRANSFER_CONTEXT variable used is not the TRANSFER_CONTEXT of the called party but the TRANSFER_CONTEXT of the calling party. * if you put the "ht" option in the Dial executed by the Local channel (extension 142 in my example), then feature code for the called party works, but this is not a practical solution in more complex dialplan In my example, I've used the Dial application, but it also affects other applications, like the Queue application for example.
Comments:	By: Asterisk Team (asteriskteam) 2015-07-14 10:33:24.474-0500 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: Rusty Newton (rnewton) 2015-07-14 12:55:34.136-0500 This is expected behavior. [~rmudgett] tells me that the previous behavior, where features were inherited between the channels, was a side-effect of [masquerades|https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project#Asterisk12BridgingProject-WhatisaMasquerade]. The current behavior is that the features are associated with the channel, which is evidenced by what you have seen so far. Additionally if a local channel optimizes out (/n) then any state it had will be lost. If your application of Asterisk requires different behavior then you will want to develop an improvement patch or bring the issue up on the [Asterisk development mailing list|http://lists.digium.com/mailman/listinfo/asterisk-dev] to see if someone else wants to take it on. By: Etienne Lessard (hexanol) 2015-07-14 13:19:28.195-0500 I feel like the previous behavior was more "functionally" intuitive; whatever interface (SIP, IAX, Local, ...) you Dial'ed, you could pass the "ht" options there, and when you were bridged with the callee, the feature codes would work. With the new behavior, depending on the type of channel that is Dial'ed, you end up that the option might or might not have an effect. I understand that there's technical reason behind, but I still feel the previous behavior was more intuitive/interesting. By: Rusty Newton (rnewton) 2015-07-16 15:35:47.125-0500 I tend to agree, however since we have determined this is not a bug and don't have a patch to consider here I'll go ahead and close this out. As mentioned you are welcome to bring the topic up in the community forums or development mailing list. Thanks Etienne! By: Etienne Lessard (hexanol) 2015-07-17 07:08:13.791-0500 Alright, fine with me. Thank you. By: Asterisk Team (asteriskteam) 2015-07-17 07:08:14.229-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.