On Thu, Nov 6, 2014 at 6:46 PM, Joshua Colp <[email protected]> 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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
