[asterisk-bugs] [JIRA] (ASTERISK-24043) ARI /continue fails to actually continue into the dialplan

Jonathan Rose (JIRA) noreply at issues.asterisk.org
Tue Aug 19 11:39:31 CDT 2014


     [ https://issues.asterisk.org/jira/browse/ASTERISK-24043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Rose closed ASTERISK-24043.
------------------------------------


> ARI /continue fails to actually continue into the dialplan
> ----------------------------------------------------------
>
>                 Key: ASTERISK-24043
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24043
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_ari
>    Affects Versions: 12.4.0
>         Environment: Linux 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:08:14 UTC 2014 i686 i686 i686 GNU/Linux
>            Reporter: Krandon Bruse
>            Assignee: Jonathan Rose
>         Attachments: asterisk_console.log, dialplan_show_default.txt, stasis-continue.diff, stasis.log
>
>
> When using /continue (https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Channels+REST+API#Asterisk12ChannelsRESTAPI-continueInDialplan) the channel immediately hangs up/is destroyed.
> Sample case #1 (working):
> Call is originated with a POST to /channels with reference ID chanA and endpoint defined as a SIP call to a number (SIP/vendor/12565551323). Defined is the dialplan to drop the call into - default,1,1
> In extensions.conf - default 1,1 is Stasis(app, args). Once the Stasis app issues the command /continue, Stasis receives a StasisEnd event - and the call resumes through the dialplan, as expected.
> Sample case #2 (broken/not implemented):
> Call is originated with a POST to /channels with reference ID chanB and endpoint defined as a SIP call to a number (SIP/vendor/12565551323). A context, priority and extension is NOT defined - instead the (Stasis)App and AppArgs are defined. The call gets dropped into the Stasis app as expected, as well as channeldestroyed events in the case that the initial outbound call fails (which does not happen in Case #1, as it never reaches dialplan, also to be expected but worth noting).
> Stasis app then calls /continue with query arguments context=default&priority=1&exten=1. Asterisk immediately hangs up the call and the channeldestroyed and stasisend events are received instead of the expected "redirect" behavior.
> This prohibits the ability of Stasis apps to throw calls into other extensions to be resumed by other stasis apps/any other use case.
> Attached are full logs of the Asterisk output (with verbose 10 and debug 10) as well as the full Stasis dump (json decoded into little arrays)



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



More information about the asterisk-bugs mailing list