Play Media using URL mp3 file

[FASTDEVICE]

When I play media using the URL option http://mydomain.com/file.mp3 and replace the file with a new recording of the same name, the recording 'may' not change. In many cases, after say five minutes, the recoding changes but in just as many cases the system plays an older version of the file that appears to be cached.

Is there a way to flush the media cache before updating the recording?   

[mc_]

If you change the MP3 at mydomain.com/file.mp3, there is nothing to tell Kazoo that the media changed. I don't think FreeSWITCH will do HEAD requests or use HTTP headers to determine whether to download again.

You can upload the media file to Kazoo instead; if you replace the attached MP3 it should cause the media to be flushed from the underlying systems.

I can't think of a programmatic way to flush the URL though...

[FASTDEVICE]

Are there any size limitations to what can be uploaded?   

Edited August 23, 2018 by FASTDEVICE (see edit history)

[Logicwrath]

I believe the size limit is right around 5 MB.

[FASTDEVICE]

Does that hold the same for files stored on my server where the play media module is referencing a URL? It appears that when using this method Kazoo uploads the file anyway and caches it. I may want to put a rather large file out on my server. I'm thinking isn't that the purpose of having the file elsewhere?

[Logicwrath]

I am not sure.  I was actually excited about the possibility of using URL to get around the file size limit.  I am wondering how the "streamable" property affects media at this point.

[FASTDEVICE]

We use the streaming property with our streaming music-on-hold. It has huge advantages and some disadvantages that I hope 2600hz will correct in the future. When used with MoH there is no fail-back capability and if a stream is not available (even for a short time, say server reboot or stream server fail-over) there is a possibility your calls will fail. We have also found that the call Park feature can break. When used in a callflow you can simply add a TTS or other media file after the streamable media. This way if the stream is ever unavailable, it will drop to the next element in the callflow which can be an error message or substitute media and the callflow exits without issue.       

[mc_]

Certainly we need to know these use cases that are failing for you so Kazoo can be more robust in the face of the errors. Mind filing tickets for each of these so we can investigate and get some fixes in?

I don't think there's a limit on URL-based files; just that you will see a delay on calls that hit a FreeSWITCH server with a cold cache. Shoutcast streams are a nice alternative as I believe FreeSWITCH will just stream bytes as needed during the call vs fetching the file in full before playing, but providing the stream is a different experience vs providing a file.

This is good feedback and I hope we'll see some tickets come in where we can coordinate this work! Thanks

[FASTDEVICE]

in lieu of a fix, which was discussed, this message was added to warn about streaming media. 

If your team is willing to undertake changing the functionality with MoH to eliminate any risks, that would be much appreciated.  

As for the call park issue, I submitted ticket number #KAZOO-5797 on 24/Dec/17