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

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan updated ASTERISK-24552:
-----------------------------------

    Status: Open  (was: Triage)

> 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)