On Thu, Feb 22, 2018 at 12:06 PM, Joshua Colp <jc...@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
-- _____________________________________________________________________ -- 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