It is a Loquendo. Does this still apply? If so, is this a Nuance/Loquendo setting, an EPMS setting or a OD setting?

We have reduced the number of nodes in the grammar, and split it into two different grammars and we don't get that specific error anymore, however, the system does take a long time (>10secs) loading the grammars.

Right now they are dynamic grammars, would this process be faster if they were static?

We are not making expensive queries every time we need the grammars, just retrieving an object from the context and parsing through it to make the actual grammar rules. Should we use static grammars?

Hi.

We have an app with a dynamic grammar. The grammar works well when the database has few entries (we tested it with 1800 records that each generated 3 entries on the grammar, so about 5400 entries), however, when the database grows (we are working with about 5000 records, 15000 entries, now) and we receive an error.unsupportedformat on the part of the voice browser. Is there a limit/recommendation for the maximum size of a grammar? Is there a maximum size for the generated grxml? If so, is it standard related? Can it be configured?

Thanks in advance

Upon further review, and to simplify the process, the missing word (DE) is the same as spelling the letter D, this new version uses that fact to reduce the size and scope of the change. It also includes the .properties file needed for the system not to complain about the language not being installed.

Is there any ill effect that can come from the fact that this es-la.jar is not signed like the original one?

I am going to go ahead and answer my own question. I dug around and it turns out that this logic is in a jar file inside each app's WEB-INF/lib directory that nicely enough, has the source code included. The steps I had to take where:

Create a new audio called std_de on the std_es_la phraseset.

Create add the STD_DE constant on IPhraseDefs

Modify the currencyFormat1, currencyFormat2 and currencyFormat3 methods

Attached the source code for the modifications.

Hi.

We have been working with DD/OD localized using es-la 3.1.6 for a while now and had until now missed a problem:

When saying a currency that is an exact number of millions, in spanish you have to say "de" between the number and the currency.

For instance, AR$1.000.000 should read as "un millón de pesos" but reads "un millón pesos". This only happens with exact numbers, that is:
1.000.0001 says, correctly, "un millón un pesos". Is there a way to fix this, other than the obvious rebuilding of prompts to say them as integers, and the optionally adding the "de" word?

From checking the forum on https://devconnect.avaya.com/public/forum/d_forum_3.jsp?t=11440&f=6 it is stated that "1. If using SIP, you can use VXML transfer and its AAI property for transferring UUI. If using H323, you need to use AES connector to transfer UUI."
How does this work? Is this a valid replacement?

If CTI does not work with SIP then what is the option there?

Could you please send that email to jpmoralesATingenian.com
Thanks

On the EPMS, when I click on the pencil icon I see a form where I can fill the parameters I set on OD, and change them for my EP application. How could I emulate this for a CCXML app?

So, If I wanted to have a form, just like the one that appears on VXML forms, I'd need to develop it by hand? If I were to do that, how could I integrate that with the app? Is that possible?

I am talkin about the VP/EP parameters that a VXML app has. I can change those on the app when I click on the "pencil" icon in the applications tab on the EPMS. CCXML seems not to have that.

Hi. I have a VXML application that has a lot of VP parameters.

I want to add some management of calls and holds that requires for me to create a CCXML app that will call my VXML app. This means that the URL I will put on VP is a CCXML one. How can I configure the CCXML app so that It has the same parameters as the VXML one? How can I pass the information from CCXML app to VXML app?

After a lot of pain we finally discovered that this was due to a problem when the WAS resolved a name. That is, the WAS had a misconfigured /etc/hosts file and when it looked up the name it got stuck. We fixed the /etc/hosts and the problem went away.

We analyzed it further and it turned out that wget was answering, but it was taking too long. (23 seconds). We increased the timeout on the AVB, while looking for a solution to the underlying efficiency problem. This made the app work.