Genesys Voice Platform interoperability

[GoogleCodeExporter]

GVP client fails to parse RTSP response to DESCRIBE request to
speechrecognizer resource. GVP needs to discover resources first, otherwise
it refuses to use (call) them. The problem is in Transport RTSP header in
response. If the header is omitted, everything goes ok, but may other
clients need it? Maybe the problem can be solved in other way, but I did
not find it. The response should also announce telephone-event support,
generally the response should be generated according to the server
configuration (Issue-19).

Workaround or patch:
Comment out lines 540--543 in mrcp_unirtsp_sdp.c (r1086).

See also http://code.google.com/p/unimrcp/wiki/InteroperabilityGuide

Original issue reported on code.google.com by tomas.valenta@speechtech.cz on 17 Aug 2009 at 2:50

[GoogleCodeExporter]

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.

Original comment by achalo...@gmail.com on 17 Aug 2009 at 4:36

• Changed state: Started
• Added labels: Type-Defect, Priority-Medium, OpSys-All, Component-Server, Component-MRCPv1

[GoogleCodeExporter]

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.

Original comment by tomas.valenta@speechtech.cz on 18 Aug 2009 at 8:12

[GoogleCodeExporter]

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.

Original comment by achalo...@gmail.com on 18 Aug 2009 at 1:25

• Changed state: Fixed

[GoogleCodeExporter]

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

Original comment by tomas.valenta@speechtech.cz on 25 Aug 2009 at 10:08

[GoogleCodeExporter]

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.

Original comment by achalo...@gmail.com on 25 Aug 2009 at 11:41

• Changed state: Verified