Retrieving audio files

[jit]

I'm using the XML-RPC interface (via python) to retrieve the URL of an audio file for a given call ID. That works fine. The problem is that when I try to retrieve the audio file (using cURL) for local playback I simply get a message "Illegal file access: user is missing the correct grant".

How can I pull these audio files for playback? Do I need to pass my username/password somehow in the URL requesting the audio file? Thanks.

[QueueMetrics]

You can either re-map them to the local file system, or you should have a logged-on user in order to access them through QM.

[jit]

I'm trying to retrieve the files to a machine that is remote from the Asterisk/QM machine - I don't have access to the filesystem.

There's no way to retrieve the audio files using the URL? Then what's the point of being able to retrieve the URL through the API? I'd even settle for popping open a browser window to play the file, but don't see any method to do that either.

[QueueMetrics]

To me, the easiest way around would be remapping the file returned by the URL (you should see the absolute path as a parameter) to a local mount of the remote files. This is easy  to do.

The problem lies in the statelessness of your requests - it would be a huge security problem for QM if users could retrieve any file just by asking for it.

[jit]

The problem lies in the statelessness of your requests - it would be a huge security problem for QM if users could retrieve any file just by asking for it.

Of course- I wouldn't expect you to be able to retrieve audio files with no security consideration. I'm just surprised there is no secure way to retrieve the audio file either 1) with some kind of token from the API, or 2)user name & password passed in the URL, 3) via an XML-RPC call, returning the binary file, or 4) a URL that could be pushed to a browser that would authenticate the user first before presenting the audio. I'd construct a URL based on the existing system when you click-through from the list of calls, but it seems to rely on the number of the item in the list rather than the actual call ID. The solution of mounting the remote storage, if I can even get my vendor to assist me with that, seems far less secure and creates a whole raft of additional problems. Is that how others are using this function of the API?

[QueueMetrics]

I am sorry - can you give me an example of an URL that is returned to you?

[jit]

I am sorry - can you give me an example of an URL that is returned to you?

here's one:

Code: [Select]

qm_popup_streamAudio.do?/var/spool/asterisk/monitor/q400-20100408-055427-1270731259.187308.WAV

[QueueMetrics]

No there is no easy way - the only thing it to get the path yourself.
 

[jit]

No there is no easy way - the only thing it to get the path yourself.
 

So not even a way to reformat that URL into one that I can push to a browser window for authentication before playback (in the browser window?). Ugh, that's really really frustrating. I can't be the only person who's ever looked at your API and thought "QM.findAudio" meant that after I found the audio that I could actually do something with it.

I guess it is what it is. I hope that you consider adding some kind of access to the audio files - either remote retrieval of the file through the API or at least a way to open a specific call in a browser window - in a future version.

[QueueMetrics]

Yes we have already made the changes for direct access and authorization, so that you can click on a URL and you will be prompted to log-on. so it should not be impossible.

I am adding a feature request for this - we track this as #1063

Thanks