[asterisk-dev] Asterisk 14 - Remote URI Playback

Matthew Jordan mjordan at digium.com
Thu Nov 6 14:40:51 CST 2014


On Wed, Nov 5, 2014 at 3:58 AM, Johan Wilfer <lists at jttech.se> wrote:
> Den 2014-11-05 08:45, BJ Weschke skrev:
>>
>>
>>   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
>>
>
> +1 This was my thought as well. We should stick to the HTTP standard, and
> not have our own way of doing caching. In HTTP you have two models:
>  1. Timestamps (header "Expires")
>  2. E-tag for validation of the resource (header "If-None-Match").

Yup, E-tag is the way to go here. I'll punt on my suggestions that I
have on the wiki and re-write it to note that. Thanks!

> I would also like to add that we really should have a way of using & in an
> url. Wouldn't this be a much more common use-case than to play in parallel?
> Maybe the parallel payback can be enabled/disabled by a extra flag in the
> dialplan? This way you would lose the ability to have an amp in the url if
> you would like to do parallel playback but not otherwise. I think that would
> be acceptable...

Consider a sound resource named "stuff&things". This is technically a
valid resource name, so long as the "&" is URI encoded:

http://myserver.com/sounds/stuff%26things

If this was a query of some sorts, then my URI my look something like this:

http://myserver.com/sounds?media=yes&file=stuff%26things

This is where things break down in Asterisk dialplan (keeping in mind
that for ARI, you could put all of this into a JSON blob and not
care.) If we allowed '&' to be URI encoded in the Playback dialplan
application, this would look like:

same => n,Playback(http://myserver.com/sounds?media=yes%26file=stuff%26things)

And when Asterisk decoded the URI, it would turn this into:

http://myserver.com/sounds?media=yes&file=stuff&things

Which is very, very wrong.

This has nothing to do with playing sounds in parallel, but with
Asterisk's nomenclature for delineating sequential sounds to playback
(that is, playlists). The '&' is already a reserved keyword for that,
so we have to escape it in some fashion before passing it to the
dialplan applications.

Now, as BJ pointed out, we could escape things in *different* ways -
but I'm concerned that doing that would make things more complicated
and prone to breaking. As an API usage, it also makes it hard to know
how to pass data to Asterisk - the more custom things are, the harder
it is to know what to do. URI escaping is common; custom Asterisk-y
escaping is ... not.

All of this is a long way of saying that I'd be happy if we supported
'&' in a URI, but only at the expense of *not* supporting a URI
escaped '&' in a resource in that URI.

>
> Overall I must say that this is very simple and cool idea and a nice way to
> do scalability. Thank you! :-)

Well, keep in mind this is just a proposal. It's no promise that it
will happen. We'll need assistance to have this feature actually show
up in Asterisk 14!

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



More information about the asterisk-dev mailing list