[asterisk-bugs] [JIRA] (ASTERISK-26895) AMI Redirect'd channel hangs up if created from AMI Originate
Richard Mudgett (JIRA)
noreply at issues.asterisk.org
Thu Mar 23 17:19:09 CDT 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-26895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236099#comment-236099 ]
Richard Mudgett commented on ASTERISK-26895:
--------------------------------------------
This isn't really a bug. You should not be originating a call that way. The originated PJSIP/88074 channel executes the Dial application directly instead of by a PBX (i.e. a dialplan execution loop). Thus when you redirect the channel out of the Dial application it has no PBX to execute dialplan and hangs up. You should instead send the PJSIP/88074 to a location in your dialplan to execute the Dial.
{noformat}
Action: Originate
Channel: PJSIP/88074
Context: my_dialer
Exten: 5000
Priority: 1
ActionID: 12345
{noformat}
{noformat}
[my_dialer]
exten = _XXXX,1,Dial(PJSIP/${EXTEN})
same = n,Hangup()
{noformat}
> AMI Redirect'd channel hangs up if created from AMI Originate
> -------------------------------------------------------------
>
> Key: ASTERISK-26895
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-26895
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Resources/res_pjsip
> Affects Versions: 13.9.1, 14.3.0
> Environment: Centos Linux 2.6.32-729.el6.x86_64
> Reporter: Bruce McIntosh
>
> Using Asterisk 14.3
> I use AMI Originate to create a call between two PJSIP endpoints:
> Action: Originate
> Channel: PJSIP/88074
> Application: Dial
> Data: PJSIP/5000
> ActionID: 12345
> then, when I use AMI to Redirect the channel, it hangs up instead of entering the dial plan and calling the specified extension:
> Action: Redirect
> ActionID: 12346
> Channel: PJSIP/88074-00000009
> Context: DHFCS
> Priority: 1
> Exten: 227000
> The log follows:
> {code:title=Log|borderStyle=solid}
> [Mar 23 05:33:38] DEBUG[19126] manager.c: Running action 'Redirect'
> [Mar 23 05:33:38] DEBUG[19126] channel.c: Soft-Hanging (0x02) up channel 'PJSIP/88074-00000009'
> [Mar 23 05:33:38] DEBUG[19303] bridge_channel.c: Setting 0x7f177c0cd6a8(PJSIP/88074-00000009) state from:0 to:1
> [Mar 23 05:33:38] DEBUG[19303] bridge_channel.c: Bridge 4233b7a0-b405-44cc-a2c3-cb0091cda63f: pulling 0x7f177c0cd6a8(PJSIP/88074-00000009)
> [Mar 23 05:33:38] VERBOSE[19303] bridge_channel.c: Channel PJSIP/88074-00000009 left 'native_rtp' basic-bridge <4233b7a0-b405-44cc-a2c3-cb0091cda63f>
> [Mar 23 05:33:38] DEBUG[19303] bridge_channel.c: Bridge 4233b7a0-b405-44cc-a2c3-cb0091cda63f: 0x7f177c0cd6a8(PJSIP/88074-00000009) is leaving native_rtp technology
> [Mar 23 05:33:38] DEBUG[19303] bridge_native_rtp.c: Discontinued RTP bridging of 'PJSIP/88074-00000009' and 'PJSIP/5000-0000000a' - media will flow through Asterisk core
> [Mar 23 05:33:38] DEBUG[19303] bridge.c: Bridge 4233b7a0-b405-44cc-a2c3-cb0091cda63f: dissolving bridge with cause 16(Normal Clearing)
> [Mar 23 05:33:38] DEBUG[19303] bridge_channel.c: Setting 0x7f177c048b08(PJSIP/5000-0000000a) state from:0 to:2
> [Mar 23 05:33:38] DEBUG[19303] bridge.c: Bridge 4233b7a0-b405-44cc-a2c3-cb0091cda63f: queueing action type:13 sub:1001
> [Mar 23 05:33:38] DEBUG[19303] bridge_channel.c: Channel PJSIP/88074-00000009 will survive this bridge; clearing outgoing (dialed) flag
> [Mar 23 05:33:38] DEBUG[19303] bridge.c: Bridge 4233b7a0-b405-44cc-a2c3-cb0091cda63f is dissolved, not performing smart bridge operation.
> [Mar 23 05:33:38] DEBUG[19303] app_dial.c: Exiting with DIALSTATUS=ANSWER.
> [Mar 23 05:33:38] DEBUG[19303] channel.c: Hanging up channel 'PJSIP/88074-00000009'
> [Mar 23 05:33:38] DEBUG[19303] chan_pjsip.c: AST hangup cause 16 (no match found in PJSIP)
> [Mar 23 05:33:38] DEBUG[19073] manager.c: Mansession: 0x7f1768001308 refcount now 2
> [Mar 23 05:33:38] DEBUG[19056] threadpool.c: Increasing threadpool stasis-core's size by 1
> [Mar 23 05:33:38] DEBUG[19056] threadpool.c: Increasing threadpool stasis-core's size by 1
> [Mar 23 05:33:38] DEBUG[19298] res_pjsip_session.c: Method is BYE
> {code}
> If I repeat the test but instead create the call using a VOIP phone to dial from 88074 to 5000 (not using AMI at all), then the AMI Redirect works fine.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list