On Fri, Dec 6, 2013 at 10:08 AM, Ben Langfeld <ben at langfeld.me> wrote:
> >On Thu, Dec 5, 2013 at 10:57 AM, Ben Langfeld <ben at langfeld.me> wrote:
>
<snip>
>
> 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).
>
>
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.
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:
* 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.
* Endpoints - currently can't be created.
* 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.
* 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.
* Recordings - has the same UUID creation as Playbacks.
* Sounds - can't be created.
So the big one appears to be channels. There are a few problems with
channels:
(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.
(2) People relying on undefined behavior: people "know" that a unique ID is
a time-based value. We can "solve" this in two fashions:
(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.
(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.
(3) Schema changes for things that stored unique IDs. Currently, unique IDs
can max out at 150 characters:
#define AST_MAX_UNIQUEID 150 /*!< Max length of a channel uniqueid */
/* 150 = 127 (max systemname) + "-" +
10 (epoch
* timestamp) + "." + 10
(monotonically incrementing
* integer) + NULL. Note that if this
value is ever
* changed, MAX_CHANNEL_ID should be
updated in
* rtp_engine.h */
We can validate input based on that value; libraries generating RFC 4122
compliant UUIDs should have no problem fitting in that.
So I think we can accommodate channels - there's just some things to work
though here and there.
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.
--
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/20131206/a70e1046/attachment.html>
