Summary:	ASTERISK-23120: ARI/AMI: allow objects created via interfaces to have their unique ID specified by the external application
Reporter:	Matt Jordan (mjordan)	Labels:
Date Opened:	2014-01-08 08:52:16.000-0600	Date Closed:	2014-03-07 12:54:18.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Core/Bridging Core/Channels Core/ManagerInterface Resources/res_ari
Versions:	12.0.0	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Note: There is a long discussion of this issue on the [Asterisk app-dev mailing list|http://lists.digium.com/pipermail/asterisk-app-dev/2013-December/000239.html]. This issue is to allow an external application to specify the ID of the thing being created. This prevents race conditions from occurring where an event is received indicating the object created prior to the external application knowing the success/failure of the operation. With respect to AMI, only the {{Originate}} application will need to change. With ARI, any resource that can be created via an operation should allow for the ID to be specified. Note that in all cases, specifying the ID is optional. A user can choose note to provide an ID and allow Asterisk to create the ID for them. This allows for backwards compatibility with the existing versions of the APIs. This means we only need a minor version bump in the versioning of AMI/ARI. h2. Channels Origination should allow the end user to specify a unique ID for the channel. This unique ID would be assigned to the {{ast_channel}} {{uniqueid}} field. h3. API Changes * AMI {{Originate}} - add a {{ChannelId}} field to the Action. * ARI POST /channels/ - add a {{channel_id}} parameter to the HTTP request h3. LinkedID propagation This is the trickiest part of this change. When a channel is created, its linkedid is set as its uniqueid. When a channel creates another channel via a Dial operation, or when a channel is bridged with another channel, the oldest linkedid is propagated as the linkedid to the other channels. This can currently be done conveniently as the uniqueid is a timestamp; however, this cannot be done with any arbitrary string. In order for this to work, the uniqueid in Asterisk must consist of two parts: * The ID passed in or generated * A timestamp for when the uniqueid was created. For a channel, this is equivalent to its creation time, but must be passed around with the ID. On the {{ast_channel}} struct then, a new struct should be defined: {noformat} struct channel_uniqueid {    char *unique_id;    struct timeval creation_time; }; {noformat} The various linkedid propagation routines can thus be modified to use the time values to propagate the correct ID. Note that some of these routines will probably have to be moved into the internal channel API file. h2. Bridges Bridges already use a UUID. The ARI POST /bridges resource will have to be modified to allow a {{bridge_id}} to be passed as a query parameter. {{bridge_base_init}} should be modified to take in a unique ID and use it instead of generating a new one, if provided. {{bridge_base_new}} should be modified to optionally take in an ID to provide to {{bridge_base_init}}. h2. Playbacks/Recording/Snoop These are technically operations in the ARI /channels resource, but they cause something to be created. Each should allow an optional parameter to be passed that specifies their ID. In the case of playbacks and recordings, this is simply specifying the UUID that is generated by the Stasis application, which should be skipped if present. In the case of Snoop channels, this is the channel_id for the Snoop channel. This should mirror Channel Origination.
Comments:	By: Richard Mudgett (rmudgett) 2014-01-08 10:42:12.878-0600 Bridges created with ARI can be named by the user which could be used until the UUID is available. By: Ben Langfeld (benlangfeld) 2014-01-08 12:50:37.873-0600 That seems inconsistent and error prone, Richard. By: Matt Jordan (mjordan) 2014-01-08 13:38:50.900-0600 While the channel work is a bit large, I'd prefer to just go ahead and do all of these in one fell swoop. That keeps the APIs from having some resources supporting the ID being specified and others not, which would be a bit odd.