[asterisk-app-dev] Originate/Channel Creation as a two step process

David M. Lee dlee at digium.com
Wed Dec 4 14:56:46 CST 2013


On Dec 4, 2013, at 1:59 PM, Matthew Jordan <mjordan at digium.com> wrote:

> Ideally, you would create the channel and receive a response indicating what channel you just created. Once you've done that, you'd initiate another request to start running the channel. This is really the only way to keep events from showing up until after you've received the handle to the channel.
> 
> Something like:
> 
> POST /channels?endpoint=PJSIP/matt&app=hello-world
>   => Returns 200 OK with channel 12345
> POST /channels/12345/run

I don’t really care for this approach.

You’re adding an additional round-trip for origination. Adding an extra call in order to avoid an asynchronous ordering issue feels wrong. Remote API’s should be kept course-grained; this is moving in the wrong direction.

You’re also exposing a new state for channels that one has to contend with in the API. These anticipatory channels may only be run (or deleted, I guess, if they change their minds about originating). And those are the only channels that may be run. I’d almost want to call it a different sort of resource (a protochannel?) since the available operations for it are very different from what you can do on a normal channel.

What if we use the app and appArgs that can be passed into the origination? When the channel is created for origination, it is already subscribed to the given app. When it is answered, a StasisStart event is generated for the given application, with the given arguments (just as if it had hit Stasis(app,appArgs) in the dialplan).

Let’s be consistent and create a ChannelOriginated event. We can guarantee that this will be the first event for originated channels. It will have the appArgs and channel information, similar to the StasisStart event. The application can put a unique identifier in the application’s arguments in order to associate the originated channel with a request.

Another option would be to allow the user to specify the unique id of the channel. This seems a bit frightening, but might be worth pursuing.
-- 
David M. Lee
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org

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


More information about the asterisk-app-dev mailing list