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

[Michael Cargile (JIRA)]

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

Michael Cargile commented on ASTERISK-26681:
--------------------------------------------

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?

> 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)