[asterisk-bugs] [JIRA] (ASTERISK-26681) chan_local: Local Channels Not Optimizing

[Richard Mudgett (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234427#comment-234427 ] 

Richard Mudgett commented on ASTERISK-26681:
--------------------------------------------

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


> chan_local: Local Channels Not Optimizing
> -----------------------------------------
>
>                 Key: ASTERISK-26681
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26681
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_local
>    Affects Versions: 13.13.1
>         Environment: OpenSuSE 42.1, Intel i5, 8gigs RAM, SSD
>            Reporter: Michael Cargile
>         Attachments: cli_output.txt.txt
>
>
> 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 at 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)