Showing results for 
Search instead for 
Did you mean: 

Handling ambiguous Nuance results

We are having an interesting issue with how the CVP handles an "ambiguous result" from Nuance. This is in Spanish for a prompt that asks the caller to input an eight character alpha-numeric account number.

In Spanish the names for the letters "V" and "B" are both pronounced "be" (using Nuance markups). Native speakers often get around this by saying "B larga" and "V corta" (long b, short v). Oddly, Nuance doesn't include those so we added them to the lexicon.

But our problem comes when callers just say "be". Then Nuance produces what is called an ambiguous result. In the Nuance log it looks like this. Notice that the result has two values v2226444 and b2226444.

RSLT={value:v2226444}#{value:b2226444}|RAWT=v dos dos dos seis cuatro cuatro cuatro#b dos dos dos seis cuatro cuatro cuatro|SPOK=v dos dos dos seis cuatro cuatro cuatro#b dos dos dos seis cuatro cuatro cuatro|GRMR=GURI0#GURI0|KEYS=<value conf="71">v2226444</value><SWI_confidence conf="0">0</SWI_confidence>|CONF=71|RAWS=-4015.408447

But here is what shows up in the CVP activity log for this. It takes the interpretation for one value and the utterance for the other. (And it's not consistent which letter shows up in which spot.)

... ,interaction,utterance,v dos dos dos seis cuatro cuatro cuatro

... ,interaction,interpretation,b2226444

This is not a grammar issue. The grammar tags V with V and B with B, not vice-versa!

We use the interpretation as the account number. But that would be invalid if it really starts with V. It would be easy enough to write a little code that tries both values. But there are account numbers than contain two or three instances of B or V which increases the number of possible permutations.

Nuance wouldn't be returning values like this if there weren't systems built to handle that kind of result. So does anyone know if there is a fix for this in the CVP?

Rising star

Re: Handling ambiguous Nuance results

What if you set maxNBest to 2? Do you get back the other result into



Re: Handling ambiguous Nuance results

We have nBest set to 10.  That doesn't help, though.  If there is a return like in my example above with v2226444/b2226444 as an ambiguous result  (and CVP seeing V2226444 in the utterance and B2226444 in the interpretation) then Nuance doesn't return another nBest result with the same values. 

From the perspective of Nuance the ambiguous result has already taken care of both possibilities. The Nuance log shows one entry for RSLT={value:v2226444}#{value:b2226444}. So Nuance is not going to return another nBest with either of those same values in it.

Rising star

Re: Handling ambiguous Nuance results

My hunch is that you're going to have to write a custom voice element if you want both embiguous results returned to VXML Server. I haven't seen any documentation at Cisco regarding handling ambiguities.

You should turn on MRCP logging and determine exactly what data and format the cisco voice browser receives the info from Nuance.

Can you disable 'ambiguitiies' in the Nuance config?

Or, if it's always the case that v and b are considered ambiguous, perhaps it'll be easiest to do the various lookups of all combinations of v and b at your end.


Re: Handling ambiguous Nuance results

The end solution was to add some prompting to the error prompts instructing callers to say "b larga" or "v corta" if their number contains one of those letters. 

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards