<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 6, 2013 at 10:08 AM, Ben Langfeld <span dir="ltr"><<a href="mailto:ben@langfeld.me" target="_blank">ben@langfeld.me</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 dir="ltr"><div class="im">>On Thu, Dec 5, 2013 at 10:57 AM, Ben Langfeld <ben at <a href="http://langfeld.me" target="_blank">langfeld.me</a>> wrote:<br>
</div></div></blockquote><div><br></div><div><snip><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="im">
</div><div><br></div><div>Thankfully in Asterisk 12 the rename issue is gone, so we can now simplify this and more quickly dispatch events to their appropriate threads. The exception to this is in channel origination; here we specify a channel variable of `punchblock_call_id`, containing the same UUID we use on FreeSWITCH. We then have to maintain the registry on the basis of the channel name requested and do fuzzy matches until we receive a VarSet event in order to grab the actual channel name (in Asterisk 12 UniqueID) of the channel and update the registry. This leaves us open to incorrect matches in the meantime (you can't concurrently originate calls to the same channel name or we'll get them mixed up).</div>
<br></div></blockquote><div><br></div><div>Driving home last night I thought about this some more. I was initially more in the camp of going with a two-step creation process, but that runs into the complications David Lee and Matt DiMeo pointed out - (1) you end up with proto-states on objects, which is a bit cumbersome; (2) you need to do it with everything, as all operations can conceivably run into this problem. If channels were the only object that required a two-step creation process I think it would be liveable; requiring it of every resource feels about as ugly as requiring the end user to supply their own custom ID on top of the ID returned back by Asterisk.<br>
<br></div><div></div><div>With everything but channels, having an external actor provide the UUID for the resource being created shouldn't be a problem. Going down the list:<br></div><div> * Bridges - currently have a UUID assigned during creation by the Bridging Framework. We'd have to add a new creation function that allows for the UUID to be passed in, but that's probably about it.<br>
</div><div> * Endpoints - currently can't be created.<br></div><div> * Devicestates - creating a new device state controlled by ARI is done by supplying the name, which acts as its ID. This should be fine as is.<br></div>
<div> * Playbacks - created as a result of a /play operation, also has a UUID created for it when it is created. Ostensibly this could be passed in.<br></div><div> * Recordings - has the same UUID creation as Playbacks.<br>
</div><div> * Sounds - can't be created.<br></div><div><br></div><div>So the big one appears to be channels. There are a few problems with channels:<br><br></div><div>(1) Linkedid propagation: this can be solved by using the channel creation time instead of depending on the unique ID to be a time-based value. We would still propagate the linkedid correctly.<br>
</div><div>(2) People relying on undefined behavior: people "know" that a unique ID is a time-based value. We can "solve" this in two fashions:<br></div><div> (a) If you don't supply a unique ID via an interface, Asterisk generates it in the current manner. That mitigates most of the upgrade pain.<br>
</div><div> (b) If you do supply one, you're on your own - but at least you *know* that you didn't provide a time based ID. If you were depending on that behavior, you broke it. We can document that the unique ID is not guaranteed to be time based.<br>
</div><div>(3) Schema changes for things that stored unique IDs. Currently, unique IDs can max out at 150 characters:<br>#define AST_MAX_UNIQUEID 150 /*!< Max length of a channel uniqueid */<br> /* 150 = 127 (max systemname) + "-" + 10 (epoch<br>
* timestamp) + "." + 10 (monotonically incrementing<br> * integer) + NULL. Note that if this value is ever<br> * changed, MAX_CHANNEL_ID should be updated in<br>
* rtp_engine.h */<br></div><div>We can validate input based on that value; libraries generating RFC 4122 compliant UUIDs should have no problem fitting in that.<br><br></div><div>So I think we can accommodate channels - there's just some things to work though here and there.<br>
<br></div><div>The major point that makes me feel "okay" with allowing external systems provide the unique ID for channels is that we don't break anyone who isn't doing it. As long as Asterisk continues to generate its current scheme if no one is using an interface *and* aren't supply their own IDs, then people relying on that behaviour aren't affected.<br>
</div> <br></div><br>-- <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>