[asterisk-bugs] [JIRA] (ASTERISK-24552) ARI: Allow associating a channel as an initiator of an Origination for record keeping purposes

[Matt Jordan (JIRA)]

Matt Jordan created ASTERISK-24552:
--------------------------------------

             Summary: ARI: Allow associating a channel as an initiator of an Origination for record keeping purposes
                 Key: ASTERISK-24552
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24552
             Project: Asterisk
          Issue Type: Improvement
      Security Level: None
          Components: Resources/res_ari, Resources/res_ari_channels
            Reporter: Matt Jordan


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.

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



--
This message was sent by Atlassian JIRA
(v6.2#6252)