[asterisk-dev] Asterisk 14 - Remote URI Playback

[Matthew Jordan]

On Thu, Nov 6, 2014 at 6:46 PM, Joshua Colp <jcolp at digium.com> wrote:
>>
>> I think this is the way to do this in the long run. There's some major
>> technical hurdles to overcome with this, however:
>>
>> (1) A remote file stream doesn't have the ability to do a 'parallel
>> fetch' the way it is proposed on the wiki page. For video streams,
>> that means Asterisk would (finally) have to understand media container
>> formats, which is a *very* large project.
>> (2) There are the obvious technical issues dealing with buffering,
>> overrun of the network download, and other off nominal kinds of
>> things. I think those are reasonably well understood, or at least can
>> be thought through.
>> (3) The largest concern I have is that I can't envision the API for
>> this. Currently, Asterisk channels support two file streams - one for
>> audio, one for video. Those streams are opaque objects managed by the
>> file API (file.h). If this fits behind that API, then there are some
>> serious things to work through with how that API works. If it is a
>> separate type of stream and a different object, then we can't take
>> advantage of the remote stream in all of the existing applications,
>> which would be unfortunate.
>>
>> I think - for the purposes of this project only - I'd go with the
>> following philosophy: Make the media cache/HTTP playback blocking for
>> now, but put the hooks in for an asynchronous access to the retrieved
>> bytes for future expansion. That way the larger questions above can be
>> dealt with separately, but the information is available for what that
>> occurs.
>
>
> I hesitate to even say put the asynchronous hooks in because without scoping
> out how the core would look and behave chances are (speaking from
> experience) that what you do will be inadequate or just end up being thrown
> out.

I don't think I'd go too crazy here, as the call to perform a
'streaming' playback from a remote source should block - that's what
the dialplan applications (and other APIs, for that matter) expect.
The "asynchronous"-ish part is being able to take data returned from
the cURL request, convert them to frames, and put them on the channel
during execution of curl_exec. That's actually pretty easy, since
curl_exec periodically calls a callback function with the data
retrieved. Something could insert itself into the callback, take the
data, and - instead of saving it to a file - turn that data into
frames (buffering the remaining), and queue it up on the channel.

That's about the extent that I was thinking.

>
>>
>> To do this correctly, I think we'll need a sorcery wizard that accepts
>> push configuration/objects. We had previously talked about this with
>> respect to a push configuration model for PJSIP, but this actually
>> takes it one step further with a push wizard for buckets. Since
>> buckets sits on top of sorcery, it feels like this is theoretically
>> possible... but I'm not sure yet how it would play out completely.
>> Josh may want to comment on this part.
>
>
> It's all such a thin layer that you can do whatever you want. No matter
> whether it is sorcery or bucket, the implementation is only called into when
> the resource is requested - and ultimately the caller doesn't care where it
> comes from. This being said there's nothing in the sorcery core acting as a
> cache or place for this stuff - that's up to the wizards. As well in bucket
> what wizard is used is determined based on the URI scheme - and there can be
> only one impl for each scheme.
>

Yup. I'm not entirely sure how this would work yet - I think I have to
think about it some more. Ideally, we would have:
 * ARI resources that receive HTTP requests with data, e.g., /sounds
could have a PUT operation that, as BJ pointed out, pushes some JSON
metadata + a sound file to the server.
 * An API in the media cache that allows for updating item in the
cache. The ARI resources can then call this to push data to the cache
and add/update items manually.

As I write this, I think sorcery wizards may end up playing a smaller
role here than I originally thought. The actual sorcery wizard
implementation would still hide behind the media cache API - there's
really no reason for ARI (which provides the HTTP API for clients) to
use anything else.

I'll think about this some more and update the wiki page. I think
getting a prototype put together for the media cache would go a long
way, as it will start to flesh out these ideas.

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org