| Considerations when using VoiceXML Insert elements under OSB |
| Categories: Audium 3.2.x |
| Article ID: | 21 |
| Last updated: | November 02, 2006 |
| User Opinions |
|
No users have voted.
|
|
Thank you for rating this answer.
|
SUMMARY
This article explains considerations for how the caching of the Audium-specified root document for use in VoiceXML Insert elements works with the OSB voice browser.
SYMPTOMS
The Java application server access logs indicate that for each VoiceXML page used within an Audium VoiceXML Insert element, a separate request is made for the Audium-specified root document (it is not cached). While the application is able to run, repeatedly serving the root document adds some overhead to the performance of the application.
RESOLUTION
The OSB 1.1 voice browser does not perform any caching on any VoiceXML pages referred to in an application unless the appropriate HTTP caching headers are used (by default caching is off). When caching is turned on, the OSB 1.1 browser caches VoiceXML pages based on the full URL used to access the page (including any HTTP GET parameters). This is not normally an issue for the VoiceXML pages that the Audium Server dynamically generates as they are not supposed to be cached anyway.
The Audium Server produces the appropriate caching HTTP headers to avoid any problems with the dynamically-generated VoiceXML pages. VoiceXML Insert elements, however, require the developer producing either static VoiceXML pages, or VoiceXML pages containing business logic (by using JSPs, ASPs, PHP, etc.). These pages are not produced by the Audium Server, so do not include the caching HTTP headers. Additionally, the root document for VoiceXML Insert elements, while it is produced by the Audium Server, does not return the appropriate caching HTTP headers.
As a result, the root document will not be cached and will be requested anew for each VoiceXML page in the VoiceXML Insert element. The reason the Audium Server does not return the VoiceXML Insert element root document with the appropriate caching HTTP headers is related to the fact that the OSB 1.1 browser caches based on URL. Had the Audium Server included these headers, the root document would then be cached for all VoiceXML Insert elements in the application and all calls made to that application.
This would cause problems with Audium logging, hotlinks, and any custom variables the developer choose to place in the root document. The only way to prevent this would be to make the root document URL unique for each VoiceXML Insert element in the application. This would involve adding, say, the session ID of the call along with a unique identifier for the Insert element. This would mean that all VoiceXML pages in an Insert element would have to be dynamically generated by using a technology like JSP or ASP to add the dynamic content to the URL. Since the ability to use static VoiceXML for VoiceXML Insert elements is a major bonus, Audium chose not to include the HTTP headers for the VoiceXML Insert root documents.
|
| Visitor Comments |
|
No visitor comments posted. Post a comment
|
| Attachments |
|
No attachments were found.
|
Search the Knowledgebase
Jump to ID
Browse by Category
Print this page
Post a comment