[asterisk-bugs] [JIRA] (ASTERISK-23120) ARI/AMI: allow objects created via interfaces to have their unique ID specified by the external application

[Richard Mudgett (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-23120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=213766#comment-213766 ] 

Richard Mudgett commented on ASTERISK-23120:
--------------------------------------------

Bridges created with ARI can be named by the user which could be used until the UUID is available.
                
> ARI/AMI: allow objects created via interfaces to have their unique ID specified by the external application
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-23120
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23120
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Core/Bridging, Core/Channels, Core/ManagerInterface, Resources/res_ari
>    Affects Versions: 12.0.0
>            Reporter: Matt Jordan
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira