| Summary: | ASTERISK-24338: ARI live recording operations cause 500 Internal Server error during initial "beep" | ||
| Reporter: | Mark Michelson (mmichelson) | Labels: | |
| Date Opened: | 2014-09-17 13:28:53 | Date Closed: | |
| Priority: | Major | Regression? | No |
| Status: | Open/New | Components: | Resources/res_ari Resources/res_ari_bridges Resources/res_ari_channels |
| Versions: | SVN 12.5.0 13.0.0-beta1 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | The channel and bridge resources in ARI provide a "record" operation for recording media. One of the options that can be specified is "beep=true" to play a beep sound at the start of recording. While the initial beep is playing, if any operations to try to manipulate the live recording are attempted, they result in a 500 Internal Server error.
The reason for this is that the playing of the beep is not a built-in part of recording. The playing of the beep runs in the typical waitstream context of reacting to specific control frames. Not included in these control frames are the various AST_CONTROL_RECORD_XXX frames used for controlling live recordings. When the waitstream core reads a control frame it is not expecting, it fails the operation (in this case, playing the beep), and this failure is propagated all the way back to ARI. ARI responds in kind with a 500. | ||
| Comments: | |||