[asterisk-bugs] [JIRA] (ASTERISK-24134) ARI: GET /channels/{channel_id}/variable for channel in dialplan returns 409 conflict

[Matt Jordan (JIRA)]

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

Matt Jordan updated ASTERISK-24134:
-----------------------------------

           Affects Version/s: 12.4.0
    Target Release Version/s:     (was: 12.5.0)

> ARI: GET /channels/{channel_id}/variable for channel in dialplan returns 409 conflict
> -------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-24134
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24134
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_ari
>    Affects Versions: 12.4.0
>            Reporter: Matt Jordan
>
> If an ARI application executes a {{GET /channels/{channel_id}/variable}} on a channel that is currently in dialplan, i.e., not in a {{Stasis}} dialplan application, it will get a {{409 conflict}} response.
> This is probably too restrictive, for a few reasons:
> # We already allow a user to retrieve a channel's information using {{GET /channels/{channel_id}/}}. From the perspective of a user, not letting them access a subsequent property on a channel in a read-only fashion is odd.
> # For certain channels in the dialplan, you will need to use {{GET /channels/{channel_id}/variable}} in order to know how to take actions within an ARI application. For example, it is useful to know the {{REDIRECTING}} reason for a channel you are watching that just executed a {{Dial}}, or you may want to get {{CONNECTEDLINE}} information from a channel.
> Issuing a 409 on channel variable retrieval is too restrictive.
> *Note:* I'm sure this was originally done intentionally, as we were/are quite paranoid about not letting ARI crash a channel owned by another application. In this case, however, retrieving channel variables is a relatively benign operation, and should be free from side effects.



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