[asterisk-bugs] [JIRA] (ASTERISK-24134) ARI: GET /channels/{channel_id}/variable for channel in dialplan returns 409 conflict
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Wed Jul 30 10:48:58 CDT 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-24134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Jordan updated ASTERISK-24134:
-----------------------------------
Description:
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.
was:
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.
> 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)
More information about the asterisk-bugs
mailing list