<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 4, 2013 at 2:56 PM, David M. Lee <span dir="ltr"><<a href="mailto:dlee@digium.com" target="_blank">dlee@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div class="im"><br><div><div>On Dec 4, 2013, at 1:59 PM, Matthew Jordan <<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>> wrote:</div>
<br><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
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.<br>
<br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
Something like:<br><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
POST /channels?endpoint=PJSIP/matt&app=hello-world<br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
  => Returns 200 OK with channel 12345<br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
POST /channels/12345/run</div></blockquote><br></div></div><div>I don’t really care for this approach.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
</div></blockquote><div><br></div><div>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.<br>
<br></div><div>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.<br></div><div><br>The idea of using another resource would be analogous to specifying the channel ID during the origination.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>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).</div>
<div><br></div><div>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.</div>
</div></blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">
<div><br></div><div>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.</div><br clear="all"></div></blockquote><div><br></div><div>
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.<br>
<br><br></div></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div></div>