Subject: [MMUSIC] RTSP 2.0: Allowing pipelining for the session creation phase

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Oct 2007 18:27:29 +0200

3GPP already has defined a way to allow for pipelining at session
creation. I think the method works fine and proposes that we actually
adopt it for RTSP 2.0. Because of this I have written it up for the
draft. Here is the major additions in text that I am proposing.

I think the major difference of this definition compared to what is in
section 5.5.3 of 3GPP TS 26.234
http://www.3gpp.org/ftp/Specs/archive/26_series/26.234/26234-740.zip
is that I changed to ABNF to allow white spaces around the ":" the same
way as all the other headers in this spec. This allow the 3GPP defined
header to be valid within our spec, but that something following the
IETF spec may be invalid according the 3GPP spec.

So please review and comment

5.  General Header Fields

   See [H4.5], except that the Pragma, Trailer, Transfer-Encoding,
   Upgrade, and Warning headers are not defined.  RTSP further defines
   the CSeq, Pipelined-Requests, Proxy-Supported and Timestamp headers.
   The general headers are listed in Table 1:

                +--------------------+--------------------+
                | Header Name        | Defined in Section |
                +--------------------+--------------------+
                | Cache-Control      | Section 15.10      |
                |                    |                    |
                | Connection         | Section 15.11      |
                |                    |                    |
                | CSeq               | Section 15.19      |
                |                    |                    |
                | Date               | Section 15.20      |
                |                    |                    |
                | Pipelined-Requests | Section 15.29      |
                |                    |                    |
                | Proxy-Supported    | Section 15.33      |
                |                    |                    |
                | Supported          | Section 15.44      |
                |                    |                    |
                | Timestamp          | Section 15.45      |
                |                    |                    |
                | Via                | Section 15.50      |
                +--------------------+--------------------+

                 Table 1: The general headers used in RTSP

11.  Pipelining Support

   Pipelining is a general method to improve performance of request
   response protocols by allowing the requesting entity to have more
   than one request outstanding and send them over the same persistent
   connection.  For RTSP where the relative order of requests will
   matter it is important to maintain the order of the requests.
   Because of this the the responding entity SHALL process the incoming
   requests in their sending order.  The sending order can be determined
   by the CSeq header and its sequence number.  For TCP the delivery
   order will be the same as the sending order.  The processing of the
   request SHALL also have been finished before processing the next
   request from the same entity.  The responses MUST be sent in the
   order the requests was processed.

   RTSP 2.0 has extended support for pipelining compared to RTSP 1.0.
   The major improvement is to allow all requests to setup and initiate
   media playback to be pipelined after each other.  This is
   accomplished by the utilization of the Pipelined-Requests header (See
   Section 15.29).  This header allows a client to request that two or
   more requests is to be processed in the same RTSP session context
   which the first request creates.  In other words a client can request
   that two or more media streams are set-up and then played without
   needing to wait for a single response.  This speeds up the initial
   startup time for an RTSP session with at least one RTT.

   When pipelining requests care must be taken.  If a pipelined request
   builds on the succesful completion of one or more prior requests the
   requestor must verify that all requests was executed as expected.  O
   common example will be two SETUP requests and a PLAY request.  In
   case one of the SETUP fails unexpectedly, the PLAY request can still
   be succesfully executed.  However, not as expected by the requesting
   client as only a single media instead of two will be played.  In this
   case the client can send a PAUSE request, correct the failing SETUP
   request and then request it to be played.

     Table 9: Overview of RTSP header fields (A-L) related to methods
           DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.

   +------------+-------+------+----+-----+-------+------+-------+-----+
   | Header     | Where | Prox | DE | OPT | SETUP | PLAY | PAUSE | TRD |
   |            |       | y    | S  |     |       |      |       |     |
   +------------+-------+------+----+-----+-------+------+-------+-----+
   | Pipelined- |       | amdr | -  | o   | o     | o    | o     | o   |
   | Requests   |       |      |    |     |       |      |       |     |
   |            |       |      |    |     |       |      |       |     |

     Table 10: Overview of RTSP header fields (P-W) related to methods
           DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.

      +------------------------+---------+-------+-----+-----+-----+
      | Header                 | Where   | Proxy | GPR | SPR | RDR |
      +------------------------+---------+-------+-----+-----+-----+

      | Pipelined-Requests     |         | amdr  | o   | o   | o   |

15.29.  Pipelined-Requests

   The Pipelined-Requests general header is used to indicate that a
   request is to be executed in the context created by previous
   requests.  The primary usage of this header is to allow pipelining of
   SETUP requests so that any additional SETUP request after the first
   one doesn't need to wait for the session ID to be sent back to the
   requesting entity.  The header contains a unique identifier that is
   scoped by thepersistent connection used to send the requests.

   Upon receiving a request with the Pipelined-Requests the responding
   entity SHALL look up if there exist a binding between this Pipelined-
   Requests identifier for the current persistent connection and an RTSP
   session ID.  If that exist then the received request is processed the
   same way as if it did contain the Session header with the looked up
   session ID.  If there doesn't exist a mapping and no Session header
   is included in the request, the responding entity SHALL create a
   binding upon the succesful completion of a session creating request,
   i.e.  SETUP.  If the request failed to create an RTSP session no
   binding SHALL be created.  In case the request contains both a
   Session header and the Pipelined-Requests header the Pipelined-
   Requests SHALL be ignored.

   Note: Based on the above definition at least the first request
   containing a new unique Pipelined-Requests will be required to be a
   SETUP request (unless the protocol is extended with new methods of
   creating a session).  After that first one, additional SETUP requests
   or request of any type using the RTSP session context may includ the
   Pipelined-Requests header.

   For all responses to request that contained the Pipelined-Requests,
   the Session header and the Pipelined-Requests SHALL both be included,
   assuming that it is allowed for that response and that the binding
   between the header values exist.  Pipelined-Requests SHOULD NOT be
   used in requests after that the client has received the RTSP Session
   ID.  This as using the real session ID allows the request to be used
   also in cases the persistent connection has been terminated and a new
   connection is needed.

   It is the sender of the request that is responsible for using a
   previously unused identifier within this transport connection scope
   when a new RTSP session is to be cretated with this method.  A server
   side binding SHALL be deleted upon the termination of the related
   RTSP session.  Note: Although this definition would allow for reusing
   previously used pipelining identifiers, this is NOT RECOMMENDED to
   allow for better error handling and logging.

   RTSP Proxies may need to translate Pipelined-Requests identifier
   values from incoming request to outgoing to allow for aggregation of
   requests onto a persistent connection.

18.2.  Media on Demand using Pipelining

   This example is basically the example above ( Section 18.1) but now
   utilizing pipelining to speed up the setup.  Into requiring only two
   round trip times until media starts flowing.  First getting the
   session description to determine what media resources need to be
   setup.  In the second one send the necessary SETUP requests and the
   PLAY request to initiate media delivery.

   Client C requests a presentation from media server M. The movie is
   stored in a container file.  The client has obtained an RTSP URI to
   the container file.

   C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
         CSeq: 1
         User-Agent: PhonyClient/1.2

   M->C: RTSP/2.0 200 OK

Schulzrinne, et al.      Expires April 28, 2008               [Page 124]

Internet-Draft   Real Time Streaming Protocol 2.0 (RTSP)    October 2007

         CSeq: 1
         Server: PhonyServer/1.0
         Date: 23 Jan 1997 15:35:06 GMT
         Content-Type: application/sdp
         Content-Length: 257
         Content-Base: rtsp://example.com/twister.3gp/
         Expires: 24 Jan 1997 15:35:06 GMT

         v=0
         o=- 2890844256 2890842807 IN IP4 192.0.2.5
         s=RTSP Session
         i=An Example of RTSP Session Usage
         e=[email-masked]
         a=control: *
         a=range: npt=0-0:10:34.10
         t=0 0
         m=audio 0 RTP/AVP 0
         a=control: trackID=1
         m=video 0 RTP/AVP 26
         a=control: trackID=4

   C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
         CSeq: 2
         User-Agent: PhonyClient/1.2
         Require: play.basic
         Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
         Accept-Ranges: NPT, SMPTE, UTC
         Pipelined-Requests: 7654

   C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
         CSeq: 3
         User-Agent: PhonyClient/1.2
         Require: play.basic
         Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
         Accept-Ranges: NPT, SMPTE, UTC
         Pipelined-Requests: 7654

   C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
         CSeq: 4
         User-Agent: PhonyClient/1.2
         Range: npt=0-10, npt=30-
         Session: 12345678
         Pipelined-Requests: 7654

   M->C: RTSP/2.0 200 OK
         CSeq: 2
         Server: PhonyServer/1.0
         Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001;

Schulzrinne, et al.      Expires April 28, 2008               [Page 125]

Internet-Draft   Real Time Streaming Protocol 2.0 (RTSP)    October 2007

                    src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
                    ssrc=93CB001E
         Session: 12345678
         Expires: 24 Jan 1997 15:35:12 GMT
         Date: 23 Jan 1997 15:35:12 GMT
         Accept-Ranges: NPT
         Pipelined-Requests: 7654

   M->C: RTSP/2.0 200 OK
         CSeq: 3
         Server: PhonyServer/1.0
         Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003;
                    src_addr="192.0.2.5:9002"/"192.0.2.5:9003";
                    ssrc=A813FC13
         Session: 12345678
         Expires: 24 Jan 1997 15:35:13 GMT
         Date: 23 Jan 1997 15:35:13 GMT
         Accept-Range: NPT
         Pipelined-Requests: 7654

   M->C: RTSP/2.0 200 OK
         CSeq: 4
         Server: PhonyServer/1.0
         Date: 23 Jan 1997 15:35:14 GMT
         Session: 12345678
         Range: npt=0-10, npt=30-623.10
         RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
            ssrc=0D12F123:seq=12345;rtptime=3450012,
           url="rtsp://example.com/twister.3gp/trackID=1";
            ssrc=4F312DD8:seq=54321;rtptime=2876889
         Pipelined-Requests: 7654

20.2.2 Message Syntax

  general-header  =  Cache-Control
                   /  Connection
                   /  CSeq
                   /  Date
                   /  Pipelined-Requests
                   /  Proxy-Supported
                   /  Supported
                   /  Timestamp
                   /  Via
                   /  extension-header

20.2.3 Header Syntax

Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id
 startup-id  = 1*8DIGIT

Appendix H. Changes

   o  RTSP message handling has been changed in the following way:

      *  RTSP messages now uses URIs rather then URLs.

      *  It has been clarified that a 4xx message due to missing CSeq
         header shall be returned without a CSeq header.

      *  Rules for how to handle timing out RTSP messages has been
         added.

      *  Extended Pipelining rules allowing for quick session
         startup.

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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