Subject: RE: [Speechsc] Questions about MRCPv2 transport protocols

From: "Pierre Forgues" <[email-masked]>
Date: Wed, 18 May 2005 13:37:05 -0400

Agreed on the security swamp.  We will assume standard SIP channels with
no extra security.

You also make excellent points for favoring TCP.  Anyway, if we are not
going to restrict it to TCP at the MRCP specification level, then it
will leave interpretation to either TCP or UDP.  I will follow-up with
implementers to see if we really need to support (and test
interoperability) for both UDP and TCP.

Pierre

-----Original Message-----
From: David R. Oran [mailto:[email-masked]] 
Sent: Wednesday, May 18, 2005 1:06 PM
To: Shanmugham, Saravanan
Cc: Pierre Forgues; IETF SPEECHSC (E-mail)
Subject: Re: [Speechsc] Questions about MRCPv2 transport protocols

On May 18, 2005, at 12:05 PM, Shanmugham, Saravanan wrote:

> On Security/TLS I would wait to hear what Dave/Eric have to say.
>
I think we should not wade into the swamp of what security properties  
much be selected for other protocols unless there is an MRCP-specific  
vulnerability introduced. At the moment I can't think of one with  
SIP. In the case of RTP however, there are specific vulnerabilities  
and I think we cover those.

> I think UDP would be the scalable one. But I am thinking TCP might  
> help
> when working across a NAT. My understanding was that that's why SIP
> clients implement TCP.
>
There are a number of reasons for SIP clients implementing TCP.  
Fragmentation is one, congestion control is another, NAT traversal is  
a third (although STUN can and should be used with SIP over UDP to  
solve that - TCP still doesn't help with the outside-to-inside  
session initiation problem SIP has), and security is a fourth (unless  
DTLS is used, which there is as yet no SIP specification for how to  
use).

> Sarvi
>
>      -----Original Message-----
>      From: Pierre Forgues [mailto:[email-masked]]
>      Sent: Wednesday, May 18, 2005 8:31 AM
>      To: Shanmugham, Saravanan; David R. Oran
>      Cc: IETF SPEECHSC (E-mail)
>      Subject: RE: [Speechsc] Questions about MRCPv2 transport  
> protocols
>
>      I personally don't see the need for securing the SIP
>      channel as the only information going across are addition
>      and removal of resources.  My preference would be to stay
>      as standard as possible.  The MRCP channel is the one
>      bearing sensitive information.
>
>      Regarding TCP versus UDP for SIP, I guess I will have to
>      ask various client-side implementers individually.  Even
>      though the SIP spec allows both, I wonder if we should
>      simplify implementations by selecting one method in
>      particular.  This would greatly reduce interoperability
>      combinations across vendors.  If the consensus by everyone
>      is to allow both, then no problem - it's more
>      interoperability work.
>
>      Pierre
>
>
>
>      -----Original Message-----
>      From: Shanmugham, Saravanan [mailto:[email-masked]]
>      Sent: Wednesday, May 18, 2005 11:24 AM
>      To: Pierre Forgues; David R. Oran
>      Cc: IETF SPEECHSC (E-mail)
>      Subject: RE: [Speechsc] Questions about MRCPv2 transport  
> protocols
>
>      The SIP client associated with the MRCP server should be a
>      fully compliant SIP client and we are not adding/removing
>      anything from that spec.
>
>      Infact, when I think about it we might have to add
>      additionally that the SIP client associated with MRCP must
>      also implement TLS if we are to meet security
>      considerations for Speaker Verification and Idenitifcation.
>
>      Sarvi
>
>           -----Original Message-----
>           From: [email-masked]
>           [mailto:[email-masked]] On Behalf Of Pierre  
> Forgues
>           Sent: Wednesday, May 18, 2005 8:02 AM
>           To: David R. Oran
>           Cc: IETF SPEECHSC (E-mail)
>           Subject: RE: [Speechsc] Questions about MRCPv2
>      transport protocols
>
>           Hi David, my question was for SIP messages specifically.
>           I understand the MRCP channel is a reliable TCP connection.
>
>           So my question as a developer of an MRCPv2 server is that
>           we will receive SIP Invite messages and respond likewise
>           with capabilities.
>           These SIP exchanges can occur over TCP or UDP.  So my
>           question is do we need to support BOTH TCP and UDP?  I am
>           guessing the specification is very "general" and therefore
>           would require that implementations need to support both
>           because this is what the SIP RFC suggest.
>
>           However, practically I was wondering whether implementers
>           would bother with both TCP and UDP.  I noticed all of the
>           examples in the spec seem to use TCP only
>
>           " Via: SIP/2.0/TCP client.atlanta.example.com"
>
>           Pierre
>
>           -----Original Message-----
>           From: David R. Oran [mailto:[email-masked]]
>           Sent: Wednesday, May 18, 2005 10:46 AM
>           To: Pierre Forgues
>           Cc: IETF SPEECHSC (E-mail)
>           Subject: Re: [Speechsc] Questions about MRCPv2
>      transport protocols
>
>
>           On May 18, 2005, at 9:38 AM, Pierre Forgues wrote:
>
>
>> Hi, I have 2 questions about the latest MRCPv2
>>
>      specification.
>
>>
>>
>>
>> Question-1: The examples in the MRCPv2 specification
>>
>           always show
>
>> TCP as the transport protocol for SIP messages.  Do
>>
>           implementers
>
>> have to support both TCP and UDP?
>>
>           For SIP, right? MRCP of course only runs on a
>      reliable transport,
>           with TCP/TLS being mandatory to implement. This
>      requirement is
>           completely independent of what transport SIP is running
>           over. Am I
>           missing something in your question?
>
>> Note that the large majority of SIP implementations
>>
>           currently use
>
>> UDP.  I guess a related question is that if both
>>
>      need to be
>
>> supported, which mode will actually be used by client
>>
>           implementations?
>           Yes, and all MSRP implementations use TCP. MRCP is as
>           independent of
>           the the transport SIP runs on as is MSRP, or any other
>           media session
>           established through SIP. Am I missing something?
>
>>
>>
>> Question-2: I think the examples in the MRCPv2
>>
>           specification do not
>
>> conform to RFC 3264 which states that new m-lines in an
>>
>           SDP should
>
>> always be added at the end of the existing list.
>>
>      Here is the
>
>> relevant text (note the text in section 8.1 or RFC 3264):
>>
>>
>>
>> 8. Modifying the Session
>>
>>    At any point during the session, either participant
>>
>           MAY issue a new
>
>>    offer to modify characteristics of the session.  It is
>> fundamental to
>>    the operation of the offer/answer model that the
>>
>      exact same
>
>>    offer/answer procedure defined above is used for
>>
>      modifying
>
>> parameters
>>    of an existing session.
>>
>>    The offer MAY be identical to the last SDP provided
>>
>           to the other
>
>>    party (which may have been provided in an offer or an
>>
>           answer),
>
>> or it
>>    MAY be different.  We refer to the last SDP
>>
>      provided as the
>
>> "previous
>>    SDP".  If the offer is the same, the answer MAY be
>>
>           the same as the
>
>>    previous SDP from the answerer, or it MAY be
>>
>           different.  If the
>
>>    offered SDP is different from the previous SDP, some
>>
>           constraints
>
>> are
>>    placed on its construction, discussed below.
>>
>>    Nearly all aspects of the session can be modified.
>>
>           New streams can
>
>>    be added, existing streams can be deleted, and
>>
>      parameters of
>
>> existing
>>    streams can change.  When issuing an offer that
>>
>      modifies the
>
>> session,
>>    the "o=" line of the new SDP MUST be identical
>>
>      to that in the
>
>>    previous SDP, except that the version in the
>>
>      origin field MUST
>
>>    increment by one from the previous SDP.  If the
>>
>           version in the
>
>> origin
>>    line does not increment, the SDP MUST be identical to
>>
>           the SDP with
>
>>    that version number.  The answerer MUST be prepared
>>
>           to receive an
>
>>    offer that contains SDP with a version that has
>>
>      not changed;
>
>> this is
>>    effectively a no-op.  However, the answerer MUST
>>
>           generate a valid
>
>>    answer (which MAY be the same as the previous
>>
>      SDP from the
>
>> answerer,
>>    or MAY be different), according to the
>>
>      procedures defined in
>
>> Section
>>    6.
>>
>>    If an SDP is offered, which is different from the
>>
>           previous SDP, the
>
>>    new SDP MUST have a matching media stream for each
>>
>           media stream in
>
>>    the previous SDP.  In other words, if the previous
>>
>           SDP had N "m="
>
>>    lines, the new SDP MUST have at least N "m=" lines.
>>
>           The i-th media
>
>>    stream in the previous SDP, counting from the top,
>>
>           matches the i-th
>
>>    media stream in the new SDP, counting from the
>>
>      top.  This
>
>> matching is
>>    necessary in order for the answerer to determine
>>
>           which stream in
>
>> the
>>    new SDP corresponds to a stream in the previous SDP.
>>
>           Because of
>
>>    these requirements, the number of "m=" lines in
>>
>      a stream never
>
>>    decreases, but either stays the same or increases.
>>
>           Deleted media
>
>>    streams from a previous SDP MUST NOT be removed
>>
>      in a new SDP;
>
>>    however, attributes for these streams need not
>>
>      be present.
>
>>
>> 8.1 Adding a Media Stream
>>
>>    New media streams are created by new additional media
>>
>           descriptions
>
>>    below the existing ones, or by reusing the "slot"
>>
>           used by an old
>
>>    media stream which had been disabled by setting its
>>
>           port to zero.
>
>>
>>    Reusing its slot means that the new media description
>>
>           replaces the
>
>>    old one, but retains its positioning relative to
>>
>      other media
>
>>    descriptions in  the SDP.  New media descriptions
>>
>           MUST appear below
>
>>    any existing media sections.  The rules for
>>
>           formatting these media
>
>>    descriptions are identical to those described in
>>
>      Section 5.
>
>>
>>    When the answerer receives an SDP with more media
>>
>           descriptions than
>
>>    the previous SDP from the offerer, or it receives an
>>
>           SDP with a
>
>> media
>>    stream in a slot where the port was previously zero,
>>
>           the answerer
>
>>    knows that new media streams are being added.
>>
>      These can be
>
>> rejected
>>    or accepted by placing an appropriately
>>
>      structured media
>
>> description
>>    in the answer.  The procedures for constructing
>>
>      the new media
>
>>    description in the answer are described in Section 6.
>>
>>
>>
>>
>>
>>
>>
>> If you look at the examples 1, 2 and 3 at the beginning
>>
>           of the MRCP
>
>> specification, a speech recognizer is added to the
>>
>           session but the
>
>> m-line for this resource shows up at the beginning of
>>
>           the list.
>
>> This should be appended at the end.
>>
>>
>>
>           Good catch!
>
>
>>    C->S:            INVITE
>>
>      sip:[email-masked] SIP/
>
>> 2.0            Via: SIP/2.0/TCP client.atlanta.example.com:
>> 5060;                branch=z9hG4bK74bf9
>>
>           Max-Forwards:
>
>> 6            To: MediaServer
>> <sip:[email-masked]>            From: sarvi
>> <sip:[email-masked]>;tag=1928301774  Call-ID:
>> a84b4c76e66710            CSeq: 314163 INVITE
>>
>           Contact:
>
>> <sip:[email-masked]>            Content-Type: application/
>> sdp            Content-Length: ...
>>
>
>
>> v=0            o=sarvi 2890844526 2890842809 IN IP4
>> 126.16.64.4            s=-           c=IN IP4
>>
>           224.2.17.12
>
>> m=application 9 TCP/MRCPv2
>>
>      a=setup:active
>
>> a=connection:existing           a=resource:speechrecog
>>
>
>
>> a=cmid:1           m=application 9 TCP/MRCPv2
>> a=setup:active           a=connection:existing
>> a=resource:speechsynth           a=cmid:1
>>
>           m=audio 49170
>
>> RTP/AVP 0 96            a=rtpmap:0 pcmu/8000
>>
>           a=rtpmap:96 telephone-
>
>> event/8000            a=fmtp:96 0-15
>> a=sendrecv            a=mid:1
>>
>>
>>
>>
>>
>>
>> Pierre
>>
>>
>>
>>
>>
>> _______________________________________________
>> Speechsc mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/speechsc
>>
>>
>
>
>
>
>
>           _______________________________________________
>           Speechsc mailing list
>           [email-masked]
>           https://www1.ietf.org/mailman/listinfo/speechsc
>
>
>
>
>
>

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

---

From: Brett Gavagni <[email-masked]>
Date: Wed, 18 May 2005 13:52:24 -0400

Hi,

I would vote to not add convolution to the MRCPv2 specification with 
transport specifics for the session control, but rather leverage the 
referenced specification for these specific details (in this particular 
case RFC 3261). 

Thanks,

Brett Gavagni 
WebSphere Voice Server Development 
http://www-306.ibm.com/software/pervasive/voice_server/
(561) 862-2097 T/L (975) 
[email-masked]

"Pierre Forgues" <[email-masked]> 
Sent by: [email-masked]
05/18/2005 01:37 PM

To
"David R. Oran" <[email-masked]>, "Shanmugham, Saravanan" 
<[email-masked]>
cc
"IETF SPEECHSC \(E-mail\)" <[email-masked]>
Subject
RE: [Speechsc] Questions about MRCPv2 transport protocols

Pierre