Summary:ASTERISK-24552: ARI: Allow associating a channel as an initiator of an Origination for record keeping purposes
Reporter:Matt Jordan (mjordan)Labels:
Date Opened:2014-11-24 10:47:02.000-0600Date Closed:2014-12-09 09:45:30.000-0600
Status:Closed/CompleteComponents:Resources/res_ari Resources/res_ari_channels
Versions:Frequency of
Description:Currently, ARI does not have the ability to initiate a "Dial", in the same fashion as {{app_dial}}. This is a good thing, as the {{Dial}} application does far more than ARI would want (bridging, early media, etc. is better handled in other ways).

One aspect of {{Dial}} that is needed, however, is {{linkedid}} propagation. Consider the following:
* {{linkedid}} propagation is entirely an internal construct in Asterisk, and is not exposed (either through variables or the {{CHANNEL}} function)
* Propagation occurs either when a dial operation occurs (either through {{Queue}}, {{Dial}}, or other internal 'dials') or when two or more channels are bridged.
* Of the aforementioned mechanisms, {{linkedid}} propagation does occur in bridges created through ARI. The propagation that occurs during dialling, however, cannot - as there is no dial operation.

There are a few options for fixing this:
# Allow a user to specify a {{linkedid}} on channel origination.
# Allow a user to modify the {{linkedid}} at any point in time.
# Allow a user to specify a channel that caused the origination, and handle the {{linkedid}} propagation internally as per normal.

There are issues with the first two approaches, for the following reasons:
* Because propagation rules happen automatically, providing the ability to set {{linkedid}} is not necessarily advisable. For example, if a user sets a {{linkedid}} on a channel, there is no guarantee that the {{linkedid}} will persist or not be overwritten. Since Asterisk does the propagation automatically (and doesn't always tell the user, as a {{linkedid}} is more of a {{CEL}} field and not an {{ARI}}/{{AMI}} field), this could be unexpected.
* Setting the {{linkedid}} after channel creation would result in some {{CEL}} entries with the old {{linkedid}}, and would result in additional {{CEL}} processing. Users of {{CEL}} already have to piece together "calls" from multiple {{linkedids}}; requiring them to do even more work is not necessarily nice.

Thus, this issue is advocating that a user provide a channel that 'caused' the origination (optionally, of course). If provided, the {{linkedid}} from the provided channel will be propagated over to the originated channel. This would simply be an optional field on the {{/channels}} operation, and would take a channel {{uniqueid}} as its value.

POST /channels?endpoint=PJSIP/alice&initiator=123874.87&app=Hello+world