Re: WebSocket Stasis Control Best Practice

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


Created -


On Monday, July 14, 2014 at 6:35 PM, Krandon wrote:

No problem! On it


On Monday, July 14, 2014 at 6:23 PM, Matthew Jordan wrote:

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

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

asterisk-app-dev mailing list

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