[closed] AMI Redirect channel hangs up if created from AMI Originate

Asterisk Asterisk APIs
1

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:

[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

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.

2

I’d suggest filing an issue for this as it appears to be a bug[1].

[1] https://issues.asterisk.org/jira

1 Like
3

OK, thanks for the feedback. I will make a bug report.

4

https://issues.asterisk.org/jira/browse/ASTERISK-26895

5

Richard Mudgett added a comment -
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.
Action: Originate
Channel: PJSIP/88074
Context: my_dialer
Exten: 5000
Priority: 1
ActionID: 12345
[my_dialer]
exten = _XXXX,1,Dial(PJSIP/${EXTEN})
same = n,Hangup()

1 Like
6

At least in earlier versions of Asterisk, the redirect is done by a masquerade process. A new thread is started, on a new channel, set to run the dialplan at the destination address. The technology specific control block is re-linked to the new channel, and the channel name is transferred to the new channel. The original channel is then marked as hungup as a zombie, which causes the Dial or other application to exit, quietly.

There is no reason why this should not work with the thread from Originate, just as well as a PBX thread. It even works when there is no thread, as in the case of a parked call.

I suppose that there could have been radical changes to Asterisk that handle this in a completely different way.