Subject: [Speechsc] Questions about MRCPv2 transport protocols

From: "Pierre Forgues" <[email-masked]>
Date: Wed, 18 May 2005 09:38:59 -0400

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

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.

   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

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 18 May 2005 10:46:28 -0400

On May 18, 2005, at 9:38 AM, Pierre Forgues wrote:

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