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

[Matthew Jordan]

On Tue, Jun 17, 2014 at 12:16 AM, Krandon <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
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140618/66832982/attachment.html>