Re: Basic questions about Stasis, ari-py

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

 






On Mon, Jun 30, 2014 at 10:22 AM, Nick Horelik <nhorelik@xxxxxxx> wrote:
Thank you so much for your help.  I think I mostly understand now, I just want to confirm that I'm thinking of this properly.  Basically, in the dialplan you can pass an arbitrary string to Stasis, which serves as the application name and handle by which a websocket client refers to that application.  I need to dial that extension to get a channel into it from a phone or e.g. something like,

client.channels.originate(endpoint="Local/hello-world@default", extension="hello-world", context="default")

using ari-py from anywhere if I have the extension you mentioned.  I also noticed that I need an active websocket at /ari/events?app=<appname>&api_key=<user:password> in order for the channel to remain open (for example, leaving open the wscat example in the getting started guide), otherwise it hangs up immediately.

Correct - if there is no websocket connection (or rather, if a websocket connection was never established for the application - it's a bit more forgiving if a disconnect happens) then the Stasis application bounces the channel out. The channel isn't hung up, but it certainly isn't handed off for control to your ARI application. If Asterisk can't inform you about what a channel is doing - for example, if a channel hangs up - it isn't very safe to control it from your ARI app.
 

I think one thing that led me astray before was that when I ran originate_example.py I got the no-json error indicated in this air-py github issue [1] and immediately assumed that I was just doing something wrong.  In fact, that example shouldn't raise an exception regardless of the appname - it just won't do anything until a phone dials an extension that triggers a Stasis command with that appname.

Does all this sound correct?  If so it sounds like I should try to debug ari-py or look into other abstraction layers.

Thanks again,

Nick

Yeah, unfortunately that is still an issue. From the limited amount of debugging I've been able to do on it, I *think* the problem is actually in the swagger-py library [1], but I could be mistaken.

We have a feature freeze in Asterisk coming up in a few weeks, and that's kept most of us from debugging what changed in requests to break the websocket. Hopefully when we get past that date, we can refocus and fix swagger-py/ari-py.

[1] https://github.com/digium/swagger-py


--
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
_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

[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