Platform Limitations

When designing an application for eventual deployment as a 'live' app, you will want to be aware of the platform limitations on the Staging/Production network, so that you don't get hosed upon commercial launch. The limitations listed below are not subject to change, so while you can still ask, we reserve the right to say 'no'.

Maximum grammar filesize

As mentioned previously, the maximum filesize for a GSL or grXML grammar is right around 1 megabyte. However, we certainly do not recommend using a grammar over half this size, as fetch issues and recognition accuracy are bound to suffer unless some Nbest post processing are used, (and even then, other performance issues can crop up with a grammar this large....caveat emptor).

Maximum document filesize

The maximum allowable filesize for an XML document on the platforms is 100 kilobytes. This limitation is in no way negotiable, as increasing the document size can conceivably affect performance on a network-wide scale.

Maximum querystring size (VXML tokens)

The max allowable size for a token querystring is 100 kilobyes; do keep in mind, you cannot pass through variables with a dash ("-") in the variable name. There is no HTTP standard solidifying the dash as a valid querystring variable name character (in fact, several sever-side languages, such as ColdFusion, do not even support variables with dashes in the name). All such variables are converted to the underscore ("_") for now. This behavior may change in the future (again, conversion only takes place when using the "large URL" subroutines -- if the submitted URL is less than 400 bytes in length, it will be passed through normally).

For example, the data in this ficticious querystring:

var1=value1&var2=value2&my-special-variable=SuperSpecialValue

.....would be translated through as:

var1=value1&var2=value2&my_special_variable=SuperSpecialValue

Script limitations

There is an existing limitation on how many characters the VoicenXML browsers will allow within the <script> element. Currently, Voxeo engineers have determined that this limitation is somewhere around 3500 characters.

HTTPS support

HTTPS is supported when the developer has a Tier 1 certification from a known vendor, such as Verisign . Not sure if you have a certificate that will work? Bring up the url in a web browser; if you see a dialog box, then you will be out of luck, and will need to look into purchasing a valid certificate.

Transfer Encoding

It is strongly advised that you make certain that your HTTP transfer encoding headers so that they do NOT contain the 'chunked' value, as this can cause severe performance issues, especially with ASP and .NET documents. Note that the default setting for IIS has this set to 'chunked' so it is in your best interests to send across a 'blank' value for this to alleviate any potential performance issues.

ANNOTATIONS: EXISTING POSTS

bpcamac

8/16/2006 1:36 PM (EDT)

To disable HTTP-chunking in Tomcat 4 one could use allowChunking="false" in the Connector tag. However, Tomcat5 appears to no longer support this nor offer any replacement.

I am aware that this isn't a Tomcat discussion group, but I figure that quite a few developers might be using Tomcat (ie. JSPs, servlets) in their Voxeo applications so this would be of interest to them.

My research on the internet has failed to locate any method for instructing Tomcat5 to not send chunked HTTP. Has anyone found a way?

I've already seen this phenomenon cause an unexpected end of file compilation error in our voxeo application (fetching a document which was well formed on the webserver). So I know this isn't just an academic problem.

Anyone have any practical ideas on the subject?

vuidesign

| TOC

| B: Debugging Techniques