Re: WebSocket Stasis Control Best Practice

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

 



On Wednesday, June 18, 2014 at 9:05 AM, Matthew Jordan wrote:



On Tue, Jun 17, 2014 at 12:16 AM, Krandon <krandon.bruse@xxxxxxxxx> wrote:
I also wanted to add that I am now attempting to just throw channel variables in as a way to pass arguments since I cannot pass them directly to Stasis. When I attempt to originate a new call with /channels/ and then right after I get the ID, I try to /channels/{channelID}/variable?appargs=blah but get the error Channel not in Stasis application. I can see that it's sent from /res/ari/resource_channels.c in find_control (from ast_ari_channels_set_channel_var). I understand that, at that point in time, while executing other Asterisk Apps, Stasis does not "own" the channel (if I understand that correctly) - but shouldn't it still be possible to set channel variables regardless of who owns the channel at the time the variable is attempting to be set? 

-- 
KB


A few things there:

(1) You can now originate a channel through ARI and provide your own ID - which makes it a bit easier to manage and track channels since you don't have to wait on the response to the request to know the handle.

(2) The body parameters of the originate POST request allow you to pass channel variables to the channel on creation. ARI will set those on the channel immediately after its creation.

(3) It is a little odd, but when you originate a channel, ARI does not necessarily own the created channel. If you spin it off into the dialplan, for example, it starts running dialplan - and isn't in a Stasis application. If you do originate it to a Stasis application, than I would expect you to be able to manipulate the channel once you get the StasisStart event for the channel.


--
Matthew Jordan

Matt - that makes total sense. I can see now in resource_channels that ARI only owns the channel when Stasis is being used. I see you guys did that to avoid a whole bunch of issues, one of which is lock on the channel itself! That's really interesting. I'll go implement variable passing through the POST request's body. I didn't notice it in the documentation, my apologies!

Using my own internal unique ID is also _very_ cool, as I used to do this with action ids in manager. 

Thanks for the overview. Just being able to pass in application logic/variables overcomes a lot of barriers! I'll report back with the rest of the in-depth testing later. So far, so good!

-- 
KB

 

_______________________________________________
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