RTP unidirectional only

[GoogleCodeExporter]

Hi Arsen,

as we are testing UniMRCP with VoiceEnabler we found another issue. It
appears when opening resources when needed (not in advance). The newly open
resource overrides the RTP stream including direction. Suppose following
two scenarios and remember that VoiceEnabler share the same session ID
among resources (e.g. SETUP recognizer without session header, ID returned
in response, then SETUP synthesizer with the same ID):

1. ASR TTS ASR
SETUP recognizer (without SDP)
(media is recvonly -- OK, might be)
DEFINE-GRAMMAR...
RECOGNIZE
RECOGNITION-COMPLETE
SETUP synthesizer (with SDP without a=sendrecv)
(media is sendonly -- should be sendrecv anyway)
SPEAK
SPEAK-COMPLETE
DEFINE-GRAMMAR
RECOGNIZE
(media still sendonly -- problem)

2. TTS ASR TTS (VE first defines grammars, then prompts)
SETUP recognizer (without SDP)
(media is recvonly -- OK, might be)
DEFINE-GRAMMAR
SETUP synthesizer (with SDP without a=sendrecv)
(media is sendonly -- should be sendrecv)
SPEAK
SPEAK-COMPLETE
RECOGNIZE
(media still sendonly -- problem)

I attached logs illustrating the scenarios. They are not exactly the same
as the scenarios, but I thing everything is clear. I also attached
WireShark packet captures from the same machine to show that the packets
really flow.

Cheers
- Vali

Original issue reported on code.google.com by tomas.valenta@speechtech.cz on 21 Oct 2009 at 3:59

Attachments:

• RTP_unidir.zip

[GoogleCodeExporter]

To be more specific, IMO the media direction should remain open until it is torn
down. But afaik SDP spec says it is sendrecv anyway if not specified 
explicitely.

Original comment by tomas.valenta@speechtech.cz on 21 Oct 2009 at 4:07

[GoogleCodeExporter]

Hi Vali,

I've just looked through the logs and both (OK and BAD) look bad to me. The VE
behavior seems to be quite reasonable at this time. However, I don't know why 
the
second RTSP OK don't contain sendrecv media stream. Something is going wrong
somewhere in session management layer. Honestly now I don't like the idea of an
abstract MRCP session. RTSP/MRCPv1 and SIP/MRCPv2 sessions are quite different, 
most
probably I'll split them in a day, but not tomorrow ...

Original comment by achalo...@gmail.com on 21 Oct 2009 at 5:20

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

[GoogleCodeExporter]

but will try to address this issue during the days.

Original comment by achalo...@gmail.com on 21 Oct 2009 at 5:21

[GoogleCodeExporter]

Hi Vali,

I assume, this issue should be fixed in r1211. However I have neither VE nor 
GVP to
test against. Please retest this and related scenarios and let me know the 
results.

Original comment by achalo...@gmail.com on 22 Oct 2009 at 6:11

• Changed state: Fixed

[GoogleCodeExporter]

Great! Thank you, we will give it a try.

Original comment by tomas.valenta@speechtech.cz on 23 Oct 2009 at 7:44

[GoogleCodeExporter]

Hi Arsen,

the patch seems to work. Thank you.

Vali

PS. I hope you enjoyed your vacation. You have deserved it like noone else.

Original comment by tomas.valenta@speechtech.cz on 1 Nov 2009 at 10:10

[GoogleCodeExporter]

Hi Vali,

I'm glad it works for you. Nevertheless most probably I'll rework/split session
management layer, when an appropriate time can be found.

P.S. Thanks, I indeed enjoyed it.

Original comment by achalo...@gmail.com on 2 Nov 2009 at 9:14

[GoogleCodeExporter]

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

• Changed state: Verified