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

[Gaurav Khurana]

Thanks! I figured that a couple of days ago and tried it out yesterday. With Cache-control and max-age it works fine.

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: asterisk-dev-bounces at lists.digium.com <asterisk-dev-bounces at lists.digium.com> on behalf of Matthew Jordan <mjordan at digium.com>
Sent: Friday, March 9, 2018 12:27:59 PM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Asterisk 14 doesn't cache media, really



On Thu, Feb 22, 2018 at 12:06 PM, Joshua Colp <jcolp at digium.com<mailto: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/20180310/7a8959da/attachment.html>