Re: [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-boun...@lists.digium.com 
<asterisk-dev-boun...@lists.digium.com> on behalf of Matthew Jordan 
<mjor...@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 
<jc...@digium.com<mailto: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

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

[Matthew Jordan]

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

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

[Joshua Colp]

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.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.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

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

[Gaurav Khurana]

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.

gke-daniel-smartline-us--voip-cluster-c0456898-lg29*CLI> media cache show all
URI
Local File
---
https://media-service-vip.smartline.svc.cluster.local/media/v1/media-service/SecondMessage
/tmp/bucket-xkLK8U.wav
https://media-service-vip.smartline.svc.cluster.local/media/v1/media-service/FirstMessage
/tmp/bucket-81YBXw.wav
https://media-service-vip.smartline.svc.cluster.local/media/v1/media-service/Goodbye
/tmp/bucket-Krr4gc.wav
https://media-service-vip.smartline.svc.cluster.local/media/v1/media-service/GDIntro
/tmp/bucket-bMieY6.wav
[Feb 13 00:38:50] WARNING[408][C-0007]: res_http_media_cache.c:238 
execute_curl_instance: Failed connect to 
media-service-vip.smartline.svc.cluster.local:443; Connection refused
[Feb 13 00:38:50] WARNING[408][C-0007]: res_http_media_cache.c:238 
execute_curl_instance: Failed connect to 
media-service-vip.smartline.svc.cluster.local:443; Connection refused
[Feb 13 00:38:50] WARNING[408][C-0007]: res_http_media_cache.c:284 
bucket_file_run_curl: Failed to retrieve URL 
'https://media-service-vip.smartline.svc.cluster.local/media/v1/media-service/Goodbye':
 server returned -1
[Feb 13 00:38:50] WARNING[408][C-0007]: res_http_media_cache.c:238 
execute_curl_instance: Failed connect to 
media-service-vip.smartline.svc.cluster.local:443; Connection refused
[Feb 13 00:38:50] WARNING[408][C-0007]: res_http_media_cache.c:284 
bucket_file_run_curl: Failed to retrieve URL 
'https://media-service-vip.smartline.svc.cluster.local/media/v1/media-service/Goodbye':
 server returned -1
[Feb 13 00:38:50] WARNING[408][C-0007]: file.c:790 ast_openstream_full: 
File 
https://media-service-vip.smartline.svc.cluster.local/media/v1/media-service/Goodbye
 does not exist in any format
[Feb 13 00:38:50] WARNING[408][C-0007]: file.c:1263 ast_streamfile: Unable 
to open 
https://media-service-vip.smartline.svc.cluster.local/media/v1/media-service/Goodbye
 (format (ulaw)): No such file or directory
[Feb 13 00:38:50] WARNING[408][C-0007]: res_stasis_playback.c:277 
playback_final_update: 1518482313.8: Playback failed for 
sound:https://media-service-vip.smartline.svc.cluster.local/media/v1/media-service/Goodbye

Has anyone seen the same thing? And, have any comments on how to get it to 
behave right? My last resort is to patch Asterisk but wanted to find out how 
others are doing before I start fixing it myself.

Thanks,
Gaurav
-- 
_
-- 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