[asterisk-dev] Asterisk 14 doesn't cache media, really

[Matthew Jordan]

On Thu, Feb 22, 2018 at 12:06 PM, Joshua Colp <jcolp at digium.com> wrote:

> On Wed, Feb 21, 2018, at 7:42 PM, Gaurav Khurana wrote:
> > Does anyone know about how caching of media actually happens in Asterisk
> > 14? What I observe is that in the case of a media uri being presented to
> > Asterisk to play to the caller, Asterisk fetches the media, stores it
> > in /tmp and plays it back. Now, when the same media uri is presented to
> > Asterisk again whether in the same Call (SIP session with a given
> > caller) or a new call, Asterisk makes a web request to fetch the media
> > file again and replaces the existing file under /tmp  with the new one.
> > This is kinda fine but what doesn't seem right is that when Media server
> > serving the media files is down, Asterisk fails to play it instead of
> > using the cached media file.
>
> I don't think that scenario was targeted for the support when it was
> written. It may have just been written to not download the file if it
> hasn't changed which would explain the behavior you are seeing. I think
> it'd be reasonable to add support for the scenario and shouldn't be too bad
> depending on the code.
>
>
Well.... sort of.

It caches it *if* the HTTP response from the upstream provider indicates
that it *can* be cached. That's a complex topic, but it boils down to a few
things:

- Does it have an ETag? If so, we store that in the metadata in the media
cache layer. If the ETag changes (which we check with a HEAD request), we
have to get a new version.
- Does it have a 'cache-control' header? If so, does it tell us to not
cache it? If so, we get a new version of the file each time.
- Is there an expiration time? (cache-control header value of max-age or
s-maxage, or an expires header value). If it expired, we get a new version
of the file.

So - you'll need to check the HTTP responses from your server to determine
why we would get a new version each time. Having an expiration value, no
ETag, or cache-control values that indicate that we shouldn't cache the
file would explain why we get it each time.


-- 
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20180309/6a42ffda/attachment.html>