[asterisk-dev] Asterisk 14 - Remote URI Playback

[Joshua Colp]

Matthew Jordan wrote:

<snip>

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

<snip>

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

Cheers,

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org