On Wed, Dec 4, 2013 at 2:56 PM, David M. Lee <dlee at digium.com> wrote: > > 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. > We already run into this problem with media operations ongoing on a channel and other operations not being allowed (such as being added to a bridge). The fact that a channel may be in a staged state doesn't seem like a good enough reason to invalidate the idea. I'd argue that having state for an unknown resource being returned before you've been given the handle back to the resource is a bigger problem then a protochannel. The idea of using another resource would be analogous to specifying the channel ID during the origination. > 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. > This is basically what we have today, where you specify a UUID through a channel variable and then look for that identifier in subsequent events. This feels like a hack, not a solution. > > 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. > > This is the other option that actually feels like a solution. The danger there is that logic internal to Asterisk relies on the fact that the unique ID of a channel is the system name (if specified) + the timestamp. Not following that schema will break linkedid propagation through bridges. Allowing users to specify it means they would have follow that schema to some extent, which means it probably isn't an option. -- 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/20131204/be322e87/attachment.html>
