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

From: "Pierre Forgues" <[email-masked]>
Date: Wed, 18 May 2005 11:02:23 -0400

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

---

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

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

     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

     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?
     > 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?
     Good catch!

---

From: "Pierre Forgues" <[email-masked]>
Date: Wed, 18 May 2005 11:31:22 -0400

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

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

     

     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

     Good catch!