Re: WebSocket Stasis Control Best Practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Mon, Jul 14, 2014 at 5:54 PM, Krandon <krandon.bruse@xxxxxxxxx> 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

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

asterisk-app-dev mailing list

[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux