Genesys Voice Platform interoperability about unimrcp HOT 5 CLOSED

Thanks for the detailed description, Vali.

1. RTSP Transport
Actually RTSP Transport header can be specified only in RTSP SETUP requests/responses.
http://tools.ietf.org/html/rfc2326#page-58

So I'll just remove Transport header generation from the responses sent to RTSP
DESCRIBE requests.

2. Announcement of telephone-event support.
For now, I'm going to add telephone-event next to other hard-coded codecs which
construct the response to the resource discovery request.
Finally, actual resource discovery will be implemented in the scope of Issue-19.

Thanks, GVP works fine now. I hope it did not break compatibility with other products
somehow.

By the way, we experienced another problem with GVP: NLSML result cannot contain any
white-space at the end of the message. Our ASR engine returns \r\n at the end so I
treated it in our plugin. This is just a note for those dealing with GVP, I would not
recommend to fix it in UniMRCP in general. It is definitely bug of GVP, because XML
specification allows white-space at the end of the document.

Well, actually it should not break anything, as I stated RTSP Trasnport header should
be present on in RTP SETUP. Yesterday I also checked the message flow with other MRCP
servers involved. Anyway, It'll be preferable if MRCPv1 specification (RFC4463)
contains at least one usage example, but it doesn't.

Thanks for sharing with us the NLSML issue you observed. I indeed see nothing, which
should be fixed in UniMRCP, at least other GVP users will be aware not to put any
additional white-spaces at the end of the doc.

So this issue is fixed. I remember about hard-coded capabilities and will address
them in the scope of Issue-19, when possible.

Hi Arsen,

I am responding to the Issues to verify challenge. Well, I think you can mark this
issue as verified. The DESCRIBE request now works fine (the rest is under Issue-19),
the thing with white-space in the end of NLSML is put here so that plugin developers
can find it and be aware of it.

The interoperability with GVP is still being tested so we might find another issue,
but I believe it would be problem of GVP so no patch to UniMRCP should be done and
the issue would be rather put on wiki.

But still I recall one minor issue observed with GVP. When we raise
RECOGNITION-COMPLETE event with completion cause
RECOGNIZER_COMPLETION_CAUSE_NO_MATCH_MAXTIME, GVP reports error and stops processing
the dialog. Because RECOGNIZER_COMPLETION_CAUSE_NO_MATCH_MAXTIME is introduced in
MRCPv2 spec, but GVP uses MRCPv1 (and RTSP). Shouldn't UniMRCP be aware of checking
such situations? In my opinion r1076 is adequate solution.

Vali

Hi Vali,

Thanks for the response.
You can continue the interoperability with GVP and report new issues if anything found.

I agree that sending MRCPv2 completion cause in the scope of MRCPv1 session is not
entirely correct. It should be easy to add an appropriate checking in the core to
allow only v1 causes. More over, it's possible to map additional causes introduced
in
v2 to v1. However, that causes are not fully backward compatible. I assume, the best
place to distinguish and construct appropriate messages is plugin itself. Therefore,
I added that ability in r1076 according to your suggestion. The rest is up to plugin
developers.