[Home]

Summary:ASTERISK-27871: Remote URL in playback must end with file extension
Reporter:Caesar (caesar305)Labels:patch
Date Opened:2018-05-21 22:55:56Date Closed:2021-07-28 10:22:17
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_playback Resources/res_http_media_cache
Versions:14.0.0 15.0.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) 0001-res_http_media_cache.c-Parse-media-URLs-to-find-exte.patch
Description:Issue is simple, when using a remote URL if the URL does not end with the extension Asterisk believes it is a file in the local file system. This occurs even after a GET attempt is made to the URL which is strange.


Steps to reproduce:

Dialplan code:
same  =>  n,Playback(http://4.4.4.4:9040/v1/get-audio-file/5b00f1d7f9675d593051c92e.wav?Authorization=abc123123)

Will result in:
[May 21 23:33:02] WARNING[20780][C-00000017]: file.c:774 ast_openstream_full: File http://4.4.4.4:9040/v1/get-audio-file/5b00f1d7f9675d593051c92e.wav?Authorization=abc123123 does not exist in any format
[May 21 23:33:02] WARNING[20780][C-00000017]: file.c:1247 ast_streamfile: Unable to open http://4.4.4.4:9040/v1/get-audio-file/5b00f1d7f9675d593051c92e.wav?Authorization=abc123123 (format (ulaw)): No such file or directory



If we do:
same  =>  n,Playback(http://4.4.4.4:9040/v1/get-audio-file/5b00f1d7f9675d593051c92e.wav)

It works without issue.


Comments:By: Asterisk Team (asteriskteam) 2018-05-21 22:55:57.784-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Richard Mudgett (rmudgett) 2018-05-22 11:26:25.608-0500

Asterisk currently doesn't support URL parameters here.  Technically this is a feature request without a patch but I'll open the issue anyway.
By: Caesar (caesar305) 2018-05-22 11:51:20.676-0500

Hi Richard, I see here: ASTERISK-25654 This was already added in version 14.0. It does work perfect when it ends in ".wav" which leads me to believe it will be a quick fix.

By: Richard Mudgett (rmudgett) 2018-05-22 11:58:55.915-0500

As I said Asterisk currently does not support URL parameters here.  The parameter you are adding is the "?Authorization=abc123123" part of your URL.  That is not a bug but a feature request.  However, since it is a generally useful improvement I was opening the issue anyway.  Normally feature requests without a patch are closed.
By: Caesar (caesar305) 2018-05-22 12:02:04.535-0500

I misunderstood your original response my apologies.
By: dovid (dovid) 2021-06-30 15:19:40.519-0500

I want to contribute and pay someone to fix this. What would be an acceptable fix?
By: Sean Bright (seanbright) 2021-07-02 12:10:12.552-0500

Hi [~dovid], feel free to take the [attached patch|^0001-res_http_media_cache.c-Parse-media-URLs-to-find-exte.patch] for a spin and let us know your results. It should apply cleanly to latest 16.

Your installed version of cURL needs to be at least version 7.62.0 or you need to have the urlparser library installed.
By: Friendly Automation (friendly-automation) 2021-07-16 17:10:43.306-0500

Change 16143 merged by Friendly Automation:
res_http_media_cache.c: Parse media URLs to find extensions.

[https://gerrit.asterisk.org/c/asterisk/+/16143|https://gerrit.asterisk.org/c/asterisk/+/16143]
By: Friendly Automation (friendly-automation) 2021-07-19 06:53:55.062-0500

Change 16164 merged by Joshua Colp:
res_http_media_cache.c: Parse media URLs to find extensions.

[https://gerrit.asterisk.org/c/asterisk/+/16164|https://gerrit.asterisk.org/c/asterisk/+/16164]
By: Friendly Automation (friendly-automation) 2021-07-19 06:54:11.686-0500

Change 16163 merged by Joshua Colp:
res_http_media_cache.c: Parse media URLs to find extensions.

[https://gerrit.asterisk.org/c/asterisk/+/16163|https://gerrit.asterisk.org/c/asterisk/+/16163]
By: Friendly Automation (friendly-automation) 2021-07-19 12:38:27.656-0500

Change 16155 merged by George Joseph:
res_http_media_cache.c: Fix merge errors from 18 -> master

[https://gerrit.asterisk.org/c/asterisk/+/16155|https://gerrit.asterisk.org/c/asterisk/+/16155]
By: Boris P. Korzun (drtr0jan) 2021-09-09 16:35:24.648-0500

Hi [~seanbright],

good patch! Thx!

But I want to know, why do you use {{normalize_content_type_header()}} ?
The function breaks ASTERISK-29275 (strips MIME params for wav16). Especially after ASTERISK-29527 in 19 :(
By: Sean Bright (seanbright) 2021-09-10 08:20:40.445-0500

bq. But I want to know, why do you use {{normalize_content_type_header()}}?

[It was there before my patch, just in a different file.|https://github.com/asterisk/asterisk/blob/c8b6340023baf6ab83da315d6c395315d4a55e48/main/media_cache.c#L127-L143]

I don't see how content type matching with parameters could have ever worked - and even if it did it had to have been fragile and rely on parameter ordering which is not robust at all - but I can take another look.
By: Boris P. Korzun (drtr0jan) 2021-09-10 09:32:30.020-0500

Yep, you are right. It was added in ASTERISK-27286. Sorry for my mistake.

What should I do for solve the problem? Ask in ASTERISK-27286?