[Voiceglue] Fwd: Propagating HTTP session to <audio> tag requests

[Robby Dermody]

Regarding using querystrings in <audio> tags in general, we had spoke to Doug and he had identified that this may be an issue with the current way its implemented in voiceglue. Here's the text of our findings if it helps:

Say we have a tag like <audio src="http://127.0.0.1:9070/accessPlaylist?returnType=.mp3">. We can get wget to save this correctly to the disk, at least after we messed with the voiceglue code a small bit (under /var/lib/asterisk/sounds/voiceglue/url/127.0.0.1:9070/accessPlaylist?returnType=.mp3). Note that we don't need this "returnType=.mp3" part, but we tack it on so that the file ends in .mp3 ...kind of a hack (given that we also set the Content-Type to audio/mpeg in the result headers). Note also that we have Asterisk's format_mp3 installed.

Then, with agi debug on, we see in Asterisk:

STREAM FILE voiceglue/url/127.0.0.1:9070/accessPlaylist?returnType=.mp3
WARNING[19582]: file.c:602 ast_openstream_full: File voiceglue/url/127.0.0.1:9070/accessPlaylist?returnType=.mp3 does not exist in any format

And from what we were told, STREAM FILE does not support filenames like that. So we figured Astierisk doesn't like the ? and = characters in there, so we tried URLencoding them out...i.e.:
<audio src="http://127.0.0.1:9070/accessPlaylist%3FreturnType%3D.mp3">

However with this, openVXI now throws a fit (parse error). So no go there.

So it looks like to add this support for dynamic URIs in <audio> there are a few options:

-We can use Content-Disposition in the response header, along with the --content-disposition flag to wget ...but then voiceglue/phoneglue would need to know about this as well, so I don't favor that approach personally. Plus, --content-disposition is kind of betaish with wget.

-A small patch can be made to voiceglue to detect if the fetch source is a query string (e.g. contains ?, & or = characters), and if so, to change, escape or otherwise sanitize these out of the filename before, during or after being written to disk (that, or maybe we can escape them in what we pass to STREAM FILE)... not totally sure here.

One very important thing is that we shouldn't really be caching these files, as they are the results to dynamic queries... Really for our needs, we *could* cache to disk, because the final querystring we use will specify the entity ID we want, and the data returned for the same query string will be the same in this case every time. However, this assumption can't really be made everywhere as you know with this kind of stuff...

Robby
----- Original Message -----
From: "Alarcón Carlos" <carlos.alarcon at tyven.com>
To: "General discussion about voiceglue" <voiceglue at voiceglue.org>
Sent: Friday, February 6, 2009 2:53:33 PM GMT -05:00 US/Canada Eastern
Subject: Re: [Voiceglue] Fwd: Propagating HTTP session to <audio> tag requests


Probably it is not what you need but .. 
wget <url> -O <filename> 


this command saves the requested <url> as the given <filename> 




Regards 





El 06/02/2009, a las 20:28, Archie Cobbs escribió: 


Resending due to previous email delivery problems... 

-Archie 


---------- Forwarded message ---------- 
From: Archie Cobbs < archie at dellroad.org > 
Date: Thu, Feb 5, 2009 at 11:10 AM 
Subject: Propagating HTTP session to <audio> tag requests 
To: General discussion about voiceglue < voiceglue at voiceglue.org > 


When voiceglue downloads an audio file on behalf of an <audio> tag, which is done via wget, it does not propagate any cookies associated with the containing VXML document's HTTP session. 

With wget, cookies can be configured easily using the --load-cookies command line flag. So one half of solving this problem is easy. However, I haven't looked into how to extract the cookies from whatever "web browser" voiceglue is using to download the VXML files. 

This matters to us because we are dynamically generating audio files at runtime (pulling them from a a database), and we need to associate these requests with the same HTTP session that is getting the VXML documents for security reasons. 

Because of the lack of cookie propagation, we are using URL-rewriting so end up with tags like this in our VXML: 

<audio src="/ivr/audio.jsp;jsessionid=KjJDSJjdj2Jd?msgid=123456"> 

This almost works :-) The problem now is that when wget saves the file, the name of the file has the jsessionid part stripped out (in the above example, the filename ends up being " audio.jsp?msgid=123456"). I assume this is a "feature" of wget. But the result is that voiceglue cannot find the file because of the name change, so the audio doesn't play. 

So consider this a two-part bug report: 


    1. (Short term) A workaround is needed for wget's stripping of the jsessionid from the audio URL 
    2. (Long term) Propagate cookies associated with the session to wget when downloading audio files 

Thanks, 
-Archie 

-- 
Archie L. Cobbs 




-- 
Archie L. Cobbs 


_______________________________________________ 
Voiceglue mailing list 
Voiceglue at voiceglue.org 
http://www.voiceglue.org/mailman/listinfo/voiceglue 

_______________________________________________
Voiceglue mailing list
Voiceglue at voiceglue.org
http://www.voiceglue.org/mailman/listinfo/voiceglue