Request-id too short

[GoogleCodeExporter]

Hi Arsen,

we came across another issue while testing UniMRCP server with VoiceEnabler
client. VE uses very long request-ids so UniMRCP fails to parse them --
there is probably an overflow. The problem shows when VE sends

SPEAK 1257698432100 MRCP/1.0

and UniMRCP answers with

MRCP/1.0 2147483647 200 IN-PROGRESS

Let us look to specs. MRCPv2
http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-20#section-5.2
says request-id is a 32bit unsigned integer (max 10 digits), but MRCPv1
http://tools.ietf.org/html/rfc4463#section-5.1
does not limit it anyhow.

My notes: Currently request-id is defined as apr_size_t which is defined as
size_t which is not always necessarily 32bit unsigned int. Moreover it is
shorter than request-id sent by some MRCPv1 clients (VoiceEnabler).

Cheers
- Vali

Original issue reported on code.google.com by tomas.valenta@speechtech.cz on 16 Oct 2009 at 10:36

[GoogleCodeExporter]

Hi Vali,

I agree, that size_t is not an appropriate define for request identifier. It'd 
would
be reasonable to define it as apr_uint32_t (32 bit unsigned integer), as MRCPv2
states. From other side, this still will not work with some MRCPv1 clients. 
Honestly
I can't understand why 32 bit should not be enough for an identifier, which is 
scoped
to the MRCP session.
Is there any way to shorten, limit that value from VE config?

Original comment by achalo...@gmail.com on 16 Oct 2009 at 12:57

[GoogleCodeExporter]

Hi Arsen,

unfortunately it is not possible. VE generates request-ids as usual, i.e. 
starting
from zero and increasing, with one exception -- the SPEAK requests. Their id is 
a
kind of hash of what is to be spoken, I guess. Unfortunately the hash is not 
only
32bit integer, which is not forbidden by MRCPv1 spec in fact. But it is silly, 
I agree.

Vali

PS. To answer your question from Issue-46. I think VoiceEnabler is not a part of
WebSphere package, but I could not google it anywhere. Maybe it is a nickname 
our
colleagues use (we do not have VE ourselves, we use another company's one), I 
will
ask about that.

Original comment by tomas.valenta@speechtech.cz on 16 Oct 2009 at 1:35

[GoogleCodeExporter]

Original comment by achalo...@gmail.com on 18 Oct 2009 at 1:35

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

[GoogleCodeExporter]

Hi Arsen,
I can see that change of request id uint32 -> uint64 breaks compatibility, i.e.
server compiled with #define TOO_LONG_MRCP_REQUEST_ID can uderstand plugins 
compiled
the same and vice versa. Anyway, thanks for effort.
Vali

PS. About VE being part of WebSphere -- sorry, I was blind. See the line from 
log:
user-agent: WebSphere-VoiceEnabler 5.1.3

Original comment by tomas.valenta@speechtech.cz on 20 Oct 2009 at 9:19

[GoogleCodeExporter]

Hi Vali,

Sorry, I was a bit tired yesterday and just forgot to add a comment here.
I see you have already caught it!

I decided to support "too long" request identifiers at compile time for now. So 
you
should define TOO_LONG_MRCP_REQUEST_ID for that. Yes, plugins and server must be
compiled the same way. Hopefully it works for you.

P.S.
I suspected that VE should be included in WebSphere. A while ago someone from 
IBM had
contributed WebSphere MRCP package to the project, but I couldn't find VE there.
Anyway, thanks for the info.

Original comment by achalo...@gmail.com on 20 Oct 2009 at 11:52

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for the hot-fix, it works.

Original comment by tomas.valenta@speechtech.cz on 21 Oct 2009 at 3:15

[GoogleCodeExporter]

Original comment by achalo...@gmail.com on 9 Jan 2010 at 6:45

• Changed state: Verified