[asterisk-dev] Asterisk 14 - Remote URI Playback

[BJ Weschke]

On 11/6/14, 4:04 PM, Matthew Jordan wrote:
>
>>   eg -
>> Playback(http://myserver.com/monkeys.wav&http://myserver.com/can.wav&http://myserver.com/act.wav&http://myserver.com/like.wav&http://myserver.com/weasels.wav)
>> <--- On an empty HTTP Media cache, the previous app invocation would
>> probably sound pretty bad to the first caller going through this workflow.
>> :-)
>>
>>   Also, I think the inability to use & in a URI for playback really limits
>> the usefulness of this change. I totally understand why the typical URI
>> decode doesn't work, but perhaps a combination of a URI encoded & with an
>> HTML entity representation is a suitable alternative?  eg - (%26amp; == & in
>> a URI in Playback and do that pattern replacement in the URI before any
>> other URI decoding/encoding operations. Ya, I know, it's a hack, but not
>> allowing multiple parameters in a loaded queryString URL is way too
>> restricting IMHO).
> So I just replied to this part on Johan's e-mail - do you think we can
> skip supporting an '&' in a resource? (How many media files are going
> to be named tt-monkeys&weasels anyway?)
>
> <snip>

  Yes. I think that's perfectly reasonable.

>   Well, kind of. I think you're still envisioning using CURL behind the
> scenes using the input provided in the JSON body of the PUT to /media_cache
> to go and grab the resource from the remote server. If you go that way, I
> think not only should we handle custom headers, but it's probably also not
> unreasonable to provide a way to do basic/digest authentication for the GET
> call as well. However, instead of that, I had envisioned being able to do a
> PUT to /media_cache as a multipart MIME request where one part is the JSON
> descriptor and the second part is the binary resource itself you're looking
> to place into HTTP Media cache. The advantage of doing things this way is
> that if you're running call control via some sort of API, that API will know
> for certain when files/resources are ready to be played back and you don't
> run the risk of the awkward blocking silence scenario that you have above.
> However, when you do it this way, the URI description/parameter itself
> doesn't make too much sense because it's not really where the resource came
> from. I guess there's also a question as to whether or not we follow the
> true REST practice with using POST for a brand new resource and PUT for
> updates to existing resources.
> I'd prefer that approach actually. Pushing media to the server is
> preferable to having Asterisk attempt to pull it.
>
> 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.
  I look forward to his commentary. :-)

>>   As for the timestamps for deciding whether the local cache is dirty, I
>> don't think we should try to reinvent the wheel here. We should stick what's
>> already well established for stuff like this and use the entity tag (Etag)
>> response header stored and then use the "If-None-Match" request header
>> approach. Google does a much better job of explaining it than I can here:
>> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching
>>
> Agreed, as commented on Johan's e-mail. E-Tags for the win!
>
> I'll update the wiki from the conversation here shortly.
>