ARI: Fix implicit answer when playback is initiated on unanswered channel
authorMatthew Jordan <mjordan@digium.com>
Thu, 21 Aug 2014 15:25:25 +0000 (15:25 +0000)
committerMatthew Jordan <mjordan@digium.com>
Thu, 21 Aug 2014 15:25:25 +0000 (15:25 +0000)
commitf3a525e9a6241c3c345bceae09903d46acff52b7
tree37febe74cab7c517533b1e25997e3b15612bebab
parent085d5a2629a39135d7feed8d6e3cdb8dbcbbfae1
ARI: Fix implicit answer when playback is initiated on unanswered channel

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
........

Merged revisions 421695 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 421696 from http://svn.asterisk.org/svn/asterisk/branches/13

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421699 65c4cc65-6c06-0410-ace0-fbb531ad65f3
UPGRADE-13.txt
main/app.c