ARI: Add the ability to play multiple media URIs in a single operation
authorMatt Jordan <mjordan@digium.com>
Mon, 18 Apr 2016 23:17:08 +0000 (18:17 -0500)
committerJoshua Colp <jcolp@digium.com>
Tue, 17 May 2016 17:01:22 +0000 (14:01 -0300)
commit03d88b56565301d0552676ceb72f059b9267bca7
treeb2dbce242a7c8323c8fd5110539fd6308af2bcb6
parent040522100b3332af877e496ab8316993f6f02b4e
ARI: Add the ability to play multiple media URIs in a single operation

Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.

Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.

In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.

It's important to note the following:
 - If an offset is provided to the 'play' operations, it only applies to the
   first media URI, as it would be weird to skip n seconds forward in every
   media resource.
 - Operations that control the position of the media only affect the current
   media being played. For example, once a media resource in the list
   completes, a 'reverse' operation on a subsequent media resource will not
   start a previously completed media resource at the appropiate offset.
 - This patch does not add any new operations to control the list. Hopefully,
   user feedback and/or future patches would add that if people want it.

ASTERISK-26022 #close

Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f
15 files changed:
CHANGES
include/asterisk/stasis_app_playback.h
res/ari/ari_model_validators.c
res/ari/ari_model_validators.h
res/ari/resource_bridges.c
res/ari/resource_bridges.h
res/ari/resource_channels.c
res/ari/resource_channels.h
res/res_ari_bridges.c
res/res_ari_channels.c
res/res_stasis_playback.c
rest-api/api-docs/bridges.json
rest-api/api-docs/channels.json
rest-api/api-docs/events.json
rest-api/api-docs/playbacks.json