Subject: [Speechsc] MRCPv2 Transport questions

From: Alex Lee <[email-masked]>
Date: Tue, 17 Feb 2004 14:39:55 -0500

Hi,

    For MRCPv2, it mentions that it will use SIP as the protocol to
establish the session, and lists RFC2543 as the reference.  However,
there is a newer version of the SIP protocol which is RFC3261.  Which
one of these RFCs should MRCPv2 work with?  This question follows from
the question of whether MRCPv2 should work with SIP over UDP or TCP, or
both.  In RFC2543, it lists TCP as an optional transport, while RFC3261
specifies that all SIP elements must support both UDP and TCP.  Which of
these must an MRCPv2 client and server to support?  TCP or UDP or both?

    Another question for the transport is that the spec says the client
will establish a control TCP channel where the MRCP control messages are
sent.  I want to ask what is the expected behaviour on the client and
server when the socket is broken?

    Should the server assume that all the sessions on this TCP
connections are lost, and if not, then how much information is lost?
For example, if the server is in the middle of processing a RECOGNIZE
message, does the server terminate the RECOGNIZE operation, but keep the
grammar info that was defined on this session so that when the client
re-establishes a TCP control connection and send another request on the
same SessionID the server will be able to resume the previous sessions.

    What about the client?  Should the client assume that all the
sessions on the MRCP server are lost, and if not, then how much
information is lost?

    Should either the client or the server be able to specify a
"keep-alive" timeout on how long the server will keep the session info
if there are no activities on a session?

    Thanks!

Alex...

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 17 Feb 2004 16:28:45 -0500

Good point.

I would offer that MRCPv2 has to work with RFC3261.

What do implementers feel about behavior on the loss of the MRCPv2 control channel?  Does it have some sort of "keep alive keep alive" beyond the TCP socket lifetime, or does it assume "lost control channel = gone".

I can see arguments both ways.  Denial of service is a big one for not having "keep alive keep alive".

> -----Original Message-----
> From: Alex Lee [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 2:40 PM
> To: [email-masked]
> Subject: [Speechsc] MRCPv2 Transport questions
> 
> 
> Hi,
>