| Summary: | ASTERISK-24134: ARI: GET /channels/{channel_id}/variable for channel in dialplan returns 409 conflict | ||
| Reporter: | Matt Jordan (mjordan) | Labels: | |
| Date Opened: | 2014-07-30 10:47:32 | Date Closed: | 2014-08-11 13:33:58 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Resources/res_ari |
| Versions: | 12.4.0 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ||
| 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. | ||
| Comments: | |||