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-0600	Date Closed:	2014-12-09 09:45:30.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_ari Resources/res_ari_channels
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
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. {noformat} POST /channels?endpoint=PJSIP/alice&initiator=123874.87&app=Hello+world {noformat}
Comments: