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

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Wed, 18 May 2005 09:05:33 -0700

On Security/TLS I would wait to hear what Dave/Eric have to say.

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.

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: "David R. Oran" <[email-masked]>
Date: Wed, 18 May 2005 13:06:07 -0400

> 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.

> when working across a NAT. My understanding was that that's why SIP
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).