Summary:	ASTERISK-26681: chan_local: Local Channels Not Optimizing
Reporter:	Michael Cargile (mcargile)	Labels:
Date Opened:	2016-12-28 09:32:23.000-0600	Date Closed:	2017-01-09 20:29:41.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_local
Versions:	13.13.1	Frequency of Occurrence
Related Issues:	is related to ASTERISK-17239 Local channel: variables do not propagate on masquerade until Wait()
Environment:	OpenSuSE 42.1, Intel i5, 8gigs RAM, SSD	Attachments:	( 0) cli_output.txt.txt
Description:	Local Channels created with an AMI Originate are not optimizing when connected, even with 30 seconds of Wait. In Asterisk 11 they usually did this within 200ms. Here is the relevant dialplan: {noformat} exten => _91NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log) exten => _91NXXNXXXXXX,2,Dial(SIP/office-server/${EXTEN:1},,To) exten => _91NXXNXXXXXX,3,Hangup exten => 8368,1,Playback(sip-silence) exten => 8368,n,Wait(30) exten => 8368,n,DumpChan() exten => 8368,n,AGI(agi://127.0.0.1:4577/call_log) exten => 8368,n,AGI(agi-VDAD_ALL_outbound.agi,NORMAL-----LB) exten => 8368,n,AGI(agi-VDAD_ALL_outbound.agi,NORMAL-----LB) exten => 8368,n,Hangup() exten => h,1,AGI(agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME}) {noformat} Here is the SIP entry: {noformat} [office-server] type=peer context=international usecallerid=yes trustrpid=yes sendrpid=yes host=192.168.198.1 qualify=yes insecure=port,invite disallow=all allow=gsm allow=ulaw dtmfmode=RFC2833 {noformat} Here is the Originate action: {noformat} Action: Originate Exten: 8368 Context: default Channel: Local/917275777470@default Priority: 1 Callerid: "V2281648150000060018" <0000000000> Timeout: 60000 {noformat} Here is the CLI output: [Edit by Rusty - Removed as per guidelines. Attaching as cli_output.txt] In Asterisk 11 and earlier Local channel optimization was triggered during audio processing. I am not sure if that is still the case now that it has been moved into the Core, but I have confirmed that there is audio on these calls. It would actually be great if the LocalOptimizeAway actually triggered an optimization rather than just clearing the 'n' flag from the channel. Either that or there was a dialplan application that would force an optimization of a Local Channel.
Comments:	By: Asterisk Team (asteriskteam) 2016-12-28 09:32:24.226-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: Michael Cargile (mcargile) 2016-12-28 16:12:49.346-0600 So upon further testing it appears the if the Exten specified in the Originate is an extension that actually rings a phone instead of routing to an AGI script the Local Channel will optimize away. However this is a complete change from Asterisk 11 and earlier where Local channels would optimize as soon as they were answered by the called party and audio had begun to flow. By: Rusty Newton (rnewton) 2016-12-29 08:15:26.853-0600 Michael I'm attaching your CLI output as cli_output.txt Please read through the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] and do not paste more than several lines of debug into the Description or Comment fields. You should use the "More > Attach Files" option to attach debug as text files with a .txt extension. Thanks! By: Michael Cargile (mcargile) 2016-12-29 10:57:45.328-0600 Will do. Terribly sorry about that. By: Richard Mudgett (rmudgett) 2017-01-03 18:03:47.666-0600 This is not a bug.  However, you do point out that there is a deficiency in the documentation of local channels.  Local channel optimization works differently since Asterisk v12 and not because it was pulled into the core. Asterisk v12 introduced major architectural changes to Asterisk.  As part of the bridging overhaul [1][2][3][4], local channel optimization [5] had to be completely redone [6].  Local channels now optimize themselves out when both ends are in a bridge and the bridge allows optimization.  The scenario you are showing does not have both ends of the local channel in a bridge so optimization will not happen. [1] https://wiki.asterisk.org/wiki/display/AST/Bridges [2] http://blogs.asterisk.org/2016/10/05/asterisk-architecture-the-bridging-framework-part-i/ [3] http://blogs.digium.com/2014/10/07/asterisk-13-core-changes-bridging-framework/ Low level details and reasons for the architecture change. [4] https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project [5] https://wiki.asterisk.org/wiki/display/AST/Local+Channel+Optimization [6] https://wiki.asterisk.org/wiki/display/AST/AMI+v2+Specification#AMIv2Specification-LocalChannelOptimization By: Michael Cargile (mcargile) 2017-01-03 20:43:19.947-0600 That's what I was afraid you would say. Our software was written at a time when Asterisk was downloaded via CVS checkouts. At the time if you tried to transfer a Local Channel from one extension to another using the AMI it could on occasion cause a crash if the local channel optimized at just the right moment. We push upwards of 100,000+ calls through an Asterisk server in a single day so that occasion would happen frequently. As such our entire software application will only route a call if the Local Channel has optimized away. From pre-1.0 through Asterisk 11 the behavior of Local Channels was the same. Looking through the information you provided it makes sense for the change, but for those of us who only work with your Long Term Support releases I must say this is a shock. Considering how drastic this change is to the well established behavior, I am actually surprised that there wasn't a dialplan application added that would allow a Local Channel to optimize before dialplan execution continued. To change our software to be able to handle Local Channels during routing and then deal with them optimizing after the route will be a massive undertaking. It will also means that there will be considerably more channels in use by our application as the Local Channels will stick around through the routing which can take several seconds, up to several minutes. This adds load and reduces capacity. The simplest solution for us is to try to find a way to optimize the Local Channel before routing it and do so as quickly as possible. Any suggestions on how to do so would be greatly appreciated. I am tempted to route the Local Channel to a conference with no one in it till it optimizes then transfer it to our normal routing via the AMI but that sounds to be less than optimal. If this is a topic for IRC or the mailing list I understand, but I am currently trying to wrap my head around the volume of work ahead of me. By: Richard Mudgett (rmudgett) 2017-01-03 22:33:20.490-0600 Simply putting a channel into a bridge to allow optimization won't really work either.  The currently available bridges you would be able to use won't allow the optimization for various reasons. * BridgeWait [1] will not allow local channels in it to optimize out because the channel cannot timeout back to the dialplan where it went into dialplan.  This application should be modifiable with a little effort to allow optimizations if the S() option was disabled when the named holding bridge was created. * ConfBridge will not allow local channels in it to optimize out because of the channel state associated with conferencing and the expectation of a channel leaving the bridge returning to the same place in the dialplan.  It was written long before the bridging framework was used by the rest of the system and hides its usage of the bridge framework too well.  Merging two ConfBridges linked by a local channel pair adds even more difficulties.  I really tried to get ConfBridge to play nice with the rest of the system to allow merging/optimization but was unsuccessful. * Stasis [2] application bridges do not allow local channels to optimize because the stasis application has no control over the channel being swapped in.  However, you might want to investigate writing your own stasis application because you may not even need to use local channels at all. The AMI Redirect action [3] might be of use once you find the "real" channel on the far end of the local channel. I was thinking earlier that the channel origination methods (AMI Originate action, call-files, and the Originate application) would need pre-dial handler [4] support added to better handle your situation.  The pre-dial handler would setup the channel so you may not need to use local channels at all. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Application_BridgeWait [2] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Application_Stasis [3] https://wiki.asterisk.org/wiki/display/AST/ManagerAction_Redirect [4] https://wiki.asterisk.org/wiki/display/AST/Pre-Dial+Handlers By: Michael Cargile (mcargile) 2017-01-04 09:51:17.251-0600 The issue I see with Pre-Dial Handlers is that they require a level of Asterisk knowledge far above our end customers. Hell it is above my knowledge at the moment. Most have a hard time setting up the most basic outbound calling dialplan. As for doing an AMI Redirect on the "real" channel that would probably be much easier. We use a unique CallerIDName / ConnectedLineName for keeping track of calls. As such the Local Channel and the "real" channel should have the same CallerIDName / ConnectedLineName. It is just a matter of finding the "real" channel with that name and redirecting it. Probably can get that from the AMI when the channel is created. That said, I am just curious what would happen to the Local Channel after the redirect. Does it just hang up / go away, or would it stick around till the "real" channel fully bridged? By: Richard Mudgett (rmudgett) 2017-01-04 11:04:06.427-0600 Once the redirect happens the local channel that the "real" channel is bridged with would hangup.  Redirect has the ability to redirect two channels at the same time because if you needed to redirect both channels in a bridge you would have to redirect them at the same time. By: Michael Cargile (mcargile) 2017-01-05 13:59:48.101-0600 Well proof of concept is working for Redirecting the 'real' channel. Hopefully there are no issues at high volume. Thank you for your help. By: Rusty Newton (rnewton) 2017-01-06 08:39:35.248-0600 [~mcargile] I'm always looking for ways to improve Asterisk documentation. I'm interested in any ideas you have on how we could improve the documentation within Asterisk or on the wiki to help others that run into the same situation that you have. By: Michael Cargile (mcargile) 2017-01-06 09:59:48.264-0600 I will review the documentation as soon as I have our application working properly on Asterisk 13 and give feed back. Overall this just shows that I need to stay on top of Asterisk trunk development and provide feedback when things are changing that sound like they will effect how we are using Asterisk. I also probably need to start working on support for new versions of Asterisk when you put out initial release candidates and not when an LTS version is beginning to head towards end of life. If I had before Asterisk 12 was fully release I might have been able to suggest adding a dialplan application for forcing Local Channel optimizations (still might look into developing one for Asterisk 15 or 16). By: Michael Cargile (mcargile) 2017-01-06 14:22:40.614-0600 So not sure if this is a bug or if this is the way it is supposed to be. DialBegin AMI events for the ;1 local channel are missing a bunch of fields. For the ;2 event all the fields seem to be there. http://pastebin.com/jrQCma2P By: Richard Mudgett (rmudgett) 2017-01-06 14:48:09.301-0600 Depending on how the call was initiated there may not be a caller channel that initiated the dial.  For example a call file doesn't have a caller channel. By: Michael Cargile (mcargile) 2017-01-06 15:22:20.455-0600 I understand that in certain instances those fields would not have a value because there isn't one. I just figured that the AMI would still send the field header with a blank value. The AccountCode does not have a value and the header for it is still sent. The output that I was expecting to see was something like this: http://pastebin.com/TdSUNpHi By: Rusty Newton (rnewton) 2017-01-09 20:29:41.477-0600 Closing this out since the original issue appears to not be a bug. Please feel free to file a new issue for any documentation improvement that you can suggest, or for other new issues that you run into. Don't hesitate to post on community.asterisk.org or on the asterisk-users list (I'm sure you do already) for issues if you are unsure whether it is a bug or not.