[asterisk-app-dev] WebSocket Stasis Control Best Practice

[Matthew Jordan]

On Mon, Jul 14, 2014 at 5:54 PM, Krandon <krandon.bruse at gmail.com> wrote:
> I am getting StasisEnd (which is to be expected when using the /continue
> with the query arguments of context default, priority 1 and exten amdme) -
> then getting a ChannelDialplan event with the application AppDial2 (not sure
> how exactly) - followed immediately by a channel destruction. In the
> ChannelDestroyed event, it even shows the right area of the dial plan:
>
>                 (
>                     [context] => default
>                     [priority] => 1
>                     [exten] => amdme
>                 )
>
> However, it never reaches amdme. It's difficult to track down what is
> happening from the Asterisk console as well. Even with verbose 10 and debug
> 10 it just shows:
>
>    -- Called vendor/12565551323
>
>     -- SIP/vendor-00000007 is making progress
>     -- SIP/flowroute-00000007 answered
>     > Launching Stasis(vb,{"Lots of json arguments":"woo"}) on
> SIP/vendor-00000007
>
> It doesn't show the call being hung up/any errors. A little help please!
>

That actually looks like a legitimate bug. I don't think we are
starting up a pbx stack on channels that were originated into Stasis
directly (as opposed to first going into the dialplan).

It shouldn't be a terribly hard fix - mind opening an issue for it? A
log illustrating it would be helpful, just to make sure we aren't
crazy.

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org