<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 22, 2018 at 12:06 PM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Feb 21, 2018, at 7:42 PM, Gaurav Khurana wrote:<br>
> Does anyone know about how caching of media actually happens in Asterisk<br>
> 14? What I observe is that in the case of a media uri being presented to<br>
> Asterisk to play to the caller, Asterisk fetches the media, stores it<br>
> in /tmp and plays it back. Now, when the same media uri is presented to<br>
> Asterisk again whether in the same Call (SIP session with a given<br>
> caller) or a new call, Asterisk makes a web request to fetch the media<br>
> file again and replaces the existing file under /tmp  with the new one.<br>
> This is kinda fine but what doesn't seem right is that when Media server<br>
> serving the media files is down, Asterisk fails to play it instead of<br>
> using the cached media file.<br>
<br>
</span>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.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Well.... sort of.</div><div><br></div><div>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:</div><div><br></div><div>- 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.</div><div>- 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.</div><div>- 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.</div><div><br></div><div>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.</div><div> </div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Matthew Jordan<br>Digium, Inc. | CTO<br>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div></div>