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

[Krandon]

On Wednesday, June 18, 2014 at 9:05 AM, Matthew Jordan wrote:
> 
> 
> 
> On Tue, Jun 17, 2014 at 12:16 AM, Krandon <krandon.bruse at gmail.com (mailto:krandon.bruse at gmail.com)> 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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140618/3bf2380e/attachment-0001.html>