We have:
Some ASR ENGINE (nuance compatible)
Some SLM models (TAG TAG1)
And Unimrcp.
Own grammar format to switch between SLM

We returned nlsml like this:

<?xml version="1.0"?>
<result>
<interpretation grammar="simple.gram" confidence = "100">
<input mode="speech">????? ?? ?????</input>
<instance>
<SWI_literal>????? ?? ?????</SWI_literal>
<TAG confidence="100">????? ?? ?????</TAG>
<TAG1 confidence="100">empty</TAG1>
<SWI_grammarName>simple.gram</SWI_grammarName>
<SWI_meaning>{TAG:????? ?? ????? TAG1:empty}</SWI_meaning>
</instance>
</interpretation>
</result>

The question is that the Cyrillic in the values are not transmitted in Data\PromtCollect\ETC.
If the tag contains Cyrillic it is set as the UNDEFINED. If the tag specified in any other language (except Chinese) it comes correctly.
Is there any way to solve this problem?

AAEP 7.1
AAOD 7.1
TOCAT 8.X
JDK 1.8

What do you mean by "not transmitted"? The way it works is that the voice brower gives the ASR the link to the grammar file, and the ASR process the grammar file. So you need to make sure the grammar file is intact encoded correctly on the app server. Then it is the ASR to process it and return the result. You can check the voice browser log on mpp and ASR logs to see if there is any indicating error.

The grammar file is encoded utf8. Answer files are transferred from unimrcp to mpp is utf8 encoding. By "not transmitted" I mean the fact that the presence of Cyrillic characters in the slots\coumnname vlues get the result as undefined, or if there is (say) the number we will get a number with no character.

while in the log server encoding mpp <SWI_literal> is displayed normally, TAG looks like �� . However, I am sure that the characters are encoded in UTF8. We have just made a change results from an external file to check. Perhaps for transmission nlsml use other codepage?

Just looks result in mpp log. TAG looks corectly. But in AAOD or trace.log we have TAG=undefined.

Can you post the log files that you are looking at?

nlsml reslut parsed by JavaScript in com.avaya.sce.runtime.vxml (scert-07.01.08.04.jar) We suspect that the error here.

Technically, Javascript does not do parsing. It's is just some logic running in the voice browser to get values from variables. It's the voice browser's job to parse anything back from ASR and store them as values in vxml variables. Also Javascript does not have any encoding capability.

Do you have the OD trace.log that shows the undefined value that you are talking about?

21/06/2016 22:21:53:909 INFO - 33F3D52BCFD194DCEE5BF6222564A355:/XXXXXXXXXX_Testing : Storing :PRC_TestingGram___model_chat to complex: PRC_TestingGram:model_chat as [undefined]
21/06/2016 22:21:53:909 INFO - 33F3D52BCFD194DCEE5BF6222564A355:/XXXXXXXXXX_Testing : Storing :PRC_TestingGram___model_date to complex: PRC_TestingGram:model_date as [21.01]


model_chat : undefined
model_date : 21.01

Do you have experience with older EP version? We wonder if something breaks in the 7.1 version. Did you mean it works with other multi-byte language other than Chinese? I am having our Voice Browser expert to take a look as well.

After our platform folks reviewing the logs, they noticed that the slot information on model_chat is missing at end of the following json data. They are requesting to get all the ASR, TTS, MRCP, session manager, SIP, wireshark traces turned on and sent to see what exactly ASR is sending.

haveUtterance: 0
utteranceDuration: 2860
utterancePath: ""
rslt: [
inputMode: 1
result 0
{
grammarName: session:1
confidence: 0.99
rawInput: ?? ??????
interpretation 0
{
simpleResult: {model_chat:?? ?????? model_date:21.01}
slot result 0
{
confidence: 0.99
key: model_date
value: 21.01
}
}
}
]
}

WilsonYu wrote:Do you have experience with older EP version? We wonder if something breaks in the 7.1 version. Did you mean it works with other multi-byte language other than Chinese? I am having our Voice Browser expert to take a look as well.

Yes. exactly the same problem in version 5.1 SP3

I sent the logs to our platform folks to take a look. But they came back and said it'd be easier to take a look at the 7.1 logs instead. Can you post the same set of logs for EP 7.1?

Of course.

Our platform folk seems to have a solution. Please contact support@avaya.com to get this resolved.

Can I get a ticket or Id number of the request with which to contact the support service