MRCPRecogPrompt needs to handle full range of RECOG_COMPLETION_CAUSE values

[Jared-Prime]

Presently only three RECOG_COMPLETION_CAUSE values are recognized by Punchblock. UniMRCP sends up to 18 values for the channel variable. This causes Adhearsion-ASR to crash.

[benlangfeld]

Only those three are documented. Are you sure the others can actually make it into the channel variable? Could I see an example trace log of this happening?

[Jared-Prime]

No problem; grabbing that trace log for you @benlangfeld

Forgot to cc @runningferret @sfgeorge

[Jared-Prime]

Here is an example from yesterday. You can see that, when within the expected parameters of the ASR engine, the result is one of the documented 3 completion causes. At the end of the gist and linked above is an unexpected completion cause of 015 which corresponds with the undocumented RECOGNIZER_COMPLETION_CAUSE_NO_MATCH_MAXTIME.

You're completely correct in that this is undocumented behavior. It appears, however, that it's consistent with the MRCPv2 protocol. Lumenvox very recently began implementing more completion cause events.

[Jared-Prime]

The codes themselves were not easy to find. They're in RFC4463 (MRCPv1) and RFC6787 (MRCPv2).

[benlangfeld]

I understand that it would more closely match MRCPv2 if UniMRCP were to emit this extended set of completion causes, I was just not aware it was capable of doing so and believed it to normalise to the set of three we currently have.

The Rayo specification allows for the three we have (:match, :nomatch and :noinput) or one of the global reasons. If you have suggestions for including further reasons in Rayo, please open a ticket against the spec.

For the time being we should normalise all MRCP codes to what's available in the Rayo spec today. @Jared-Prime would you be willing/able to submit a PR for that?

[runningferret]

That would basically mean interpreting the 015 code (and any other non 000,
001, 002 code)
as a :nomatch, for purposes of what Rayo is trying to do, correct?
On Jun 13, 2014 12:28 PM, "Ben Langfeld" [email protected] wrote:

I understand that it would more closely match MRCPv2 if UniMRCP were to
emit this extended set of completion causes, I was just not aware it was
capable of doing so and believed it to normalise to the set of three we
currently have.

The Rayo specification allows for the three we have
http://xmpp.org/extensions/xep-0327.html#session-component-execution-input-completion
(:match, :nomatch and :noinput) or one of the global reasons
http://xmpp.org/extensions/xep-0327.html#def-components-complete-reason.
If you have suggestions for including further reasons in Rayo, please open
a ticket against the spec https://github.com/rayo/xmpp/issues/new.

For the time being we should normalise all MRCP codes to what's available
in the Rayo spec today. @Jared-Prime https://github.com/Jared-Prime
would you be willing/able to submit a PR for that?

—
Reply to this email directly or view it on GitHub
#224 (comment)
.

[benlangfeld]

Not quite that simple; for example 005 - Grammar Compilation Failure should be mapped to a Rayo error reason with an appropriate textual description.

[Jared-Prime]

That's a good suggestion, however, I'd be reluctant to map those completion codes into generic completion reasons. It'd be more beneficial to us to have the more detailed data when doing more idiosyncratic ASR engine tuning.

How about we hold off on merging in the larger set of completion codes until Rayo includes them in its spec. I do not know if Rayo needs those codes right now, so I'll defer on that decision. I'd be more than happy to submit the patch as a PR if and when the broader Punchblock community needs it.

Thank you very much for your help!

[benlangfeld]

Leaving this open because it is not resolved - you've stated that the component is not appropriately completed if one of these causes is encountered, and that's a legitimate bug.

I disagree that there is not value in handling these codes in an abstracted manor - this is precisely what VoiceXML does. The argument over whether Rayo belongs at the same abstraction as VoiceXML or MRCP is one to be had in a ticket against the spec, and I encourage you to start that discussion if you feel the status-quo is insufficient.

In the meantime, we should properly comply with the Rayo spec as it stands today, since the current state of Punchblock is buggy. If and when Rayo changes in the future, we will have further changes to make to fully comply.