[asterisk-dev] [Code Review] 3907: ARI: Fix implicit answer of channel when playback is initiated on unanswered channels

[Matt Jordan]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3907/
-----------------------------------------------------------

(Updated Aug. 21, 2014, 10:22 a.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
-------

Committed in revision 421695


Bugs: ASTERISK-24229
    https://issues.asterisk.org/jira/browse/ASTERISK-24229


Repository: Asterisk


Description
-------

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.

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?)

This patch goes with simply removing the ast_answer. If we're okay with this, I'll note in the UPGRADE.txt notes that ControlPlayback and control stream file no longer implicitly answer the channel.


Diffs
-----

  /branches/12/main/app.c 420978 

Diff: https://reviewboard.asterisk.org/r/3907/diff/


Testing
-------

With this patch, ARI can now playback media to a channel without having it be answered. My early howler monkeys were pleased.


Thanks,

Matt Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140821/8bad715b/attachment-0001.html>