When issuing a POST /channels/{channel_id}/play on a channel that is not
yet answered, ARI is supposed to:
* Queue up an AST_CONTROL_PROGRESS on the channel
* Start up the playback of the media
Instead, we sneak an answer on the channel right before starting playing media.
This is due to ARI's usage of control_streamfile. This function implicitly
answers the channel (and doesn't give ARI the option to stop it). The answering
of the channel here is probably unnecessary:
* app_voicemail, by far the biggest consumer of this function, always answers
the channels anyway
* control stream file (in res_agi) and ControlPlayback probably shouldn't be
implicitly answering the channel. Answering should not be tied directly to
playing back media.
As it turns out, the answering of the channel here is pretty old:
356042 twilson if (ast_channel_state(chan) != AST_STATE_UP) {
3087 anthm res = ast_answer(chan);
180259 tilghman }
(As in, ancient?)
Note that others ran into this problem and commented about it on various
mailing lists.
Review: https://reviewboard.asterisk.org/r/3907/
ASTERISK-24229 #close
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@421695
65c4cc65-6c06-0410-ace0-
fbb531ad65f3
===
===========================================================
+From 12.5.0 to 12.6.0:
+
+ControlPlayback:
+ - The ControlPlayback and 'control stream file' AGI command will no longer
+ implicitly answer the channel. If you do not answer the channel prior to
+ using either this application or AGI command, you must send Progress
+ first.
+
From 12.4.0 to 12.5.0:
ARI:
strcat(breaks, restart);
}
}
- if (ast_channel_state(chan) != AST_STATE_UP) {
- res = ast_answer(chan);
- }
if ((end = strchr(file, ':'))) {
if (!strcasecmp(end, ":end")) {