[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
INTERNET DRAFT                                             12 July 2000


Expires: 12 January 2001

                                                            Sean Sheedy
                                                      nCUBE Corporation



                             RTSP Extensions:
            Additional Transports and Performance Enhancements


                   draft-sheedy-mmusic-rtsp-ext-01.txt



                           Status of this memo

          This document is an Internet-Draft and is in full
          conformance with all provisions of Section 10 of
          RFC2026.

          Internet-Drafts are working documents of the
          Internet Engineering Task Force (IETF), its areas,
          and its working groups.  Note that other groups may
          also distribute working documents as Internet-
          Drafts.

          Internet-Drafts are draft documents valid for a
          maximum of six months and may be updated, replaced,
          or obsoleted by other documents at any time.  It is
          inappropriate to use Internet-Drafts as reference
          material or to cite them other than as "work in
          progress."

          The list of current Internet-Drafts can be accessed
          at http://www.ietf.org/ietf/1id-abstracts.txt

          The list of Internet-Draft Shadow Directories can
          be accessed at http://www.ietf.org/shadow.html.



                                 Abstract

          This document proposes enhancements to the RTSP
          protocol for broadcast quality non-IP based video-
          on-demand applications.  Additional transports for
          non-IP delivery of media streams are proposed,
          along with control extensions to reduce latency.
          These proposals are based on nCUBE Corporation's
          and Oracle Corporation's experience with their
          existing media servers.


Sheedy                                                         [Page 1]


INTERNET DRAFT                                             12 July 2000




1  Introduction

   nCUBE Corporation has developed a media server using the RTSP
   standard [1] for its video-on-demand (VOD) platform, the MediaCUBE
   4.  The platform is designed for large-scale deployments of
   broadcast quality interactive video.  It is being used currently in
   several commercial deployments worldwide, with many more deployments
   scheduled in the near future.

   nCUBE's experience to date with the RTSP protocol has been positive.
   The basic protocol is flexible enough to work in a large-scale,
   high-bandwidth environment.  The HTTP-like syntax has proven easy
   for client developers to implement.  The flexibility provided by the
   syntax and the facilities for extensions have proven invaluable in
   deploying RTSP in an environment somewhat different from that for
   which it was originally designed.

   A typical broadcast quality environment differs from the Internet
   environment in several ways:

      - Transports and lower transports

        Although IP protocols are often used for control connections,
        broadcast quality video-on-demand installations often do not
        use IP protocols (such as UDP and RTP) for the actual delivery
        of a presentation (which is usually an aggregation of media
        streams).  Typically, MPEG-2 transport streams are carried on a
        lower transport that natively supports MPEG-2, such as AAL5
        (over ATM) or QAM.

      - Multiplexing RTSP clients

        Supporting non-RTSP clients (e.g., many currently available set
        top boxes) requires a bridging server that speaks the client's
        native protocol and, in turn, acts as an RTSP client of the
        media server.  Such bridging servers typically make transport
        address and bandwidth assignments for the clients, and often
        need to coordinate these decisions with external hardware
        devices such as QAM modulators and up converters.

      - Limited capability clients

        Video-on-demand clients in the home (such as specialized set
        top boxes) are under tremendous price pressures.  Consequently,
        their capabilities are often much more limited than even low-
        end general-purpose computers.  Memory is typically very
        limited (on the order of 8 megabytes), and the media streams
        are discarded immediately once they have been decoded.  Many
        hardware decoders are sensitive to timing jitter and
        discontinuities in video or audio elementary streams.


Sheedy                                                         [Page 2]


INTERNET DRAFT                                             12 July 2000


      - Latency

        Low latency, particularly for stream control requests such as
        pause or fast forward, is critical to the satisfaction of many
        home users of video-on-demand services.  End users of a home
        VOD service are a cross section of cable television customers,
        and are often not computer savvy.  Their standard of comparison
        for the responsiveness of a media server is their VCR or DVD
        player, not a computer web browser accessing the Internet.

   nCUBE Corporation has added some extensions to the RTSP standard,
   which address the requirements of this different environment [2].
   These enhancements were developed in collaboration with Oracle
   Corporation, who has also incorporated similar features in their
   RTSP server [3].  The remainder of this document proposes a set of
   enhancements to the RTSP standard based on both of these
   implementations.

   This document does not address extensions to the SDP standard [4]
   that may also be required.

2  Transports and Lower Transports

   Other media delivery mechanisms besides RTP are used in many
   commercial video-on-demand deployments.  To support this, new
   transports and lower transports in addition to the current standard
   RTP and UDP are needed.

   The names and address syntax for these transports and lower
   transports are intended to match those in proposed extensions to SDP
   syntax [5].

2.1  Transports

   MPEG-2 is used extensively for high bandwidth video [6].  An
   enhancement to the "transport-protocol" field in the "Transport"
   header to support this is:

        MP2T   MPEG-2 Transport

   The new syntax of "transport-protocol" would then be:

       transport-protocol = "RTP" | "MP2T"

2.2  Lower Transports

   Similarly, TCP or UDP are not always used as lower transports.
   Enhancements to the "lower-transport" field are:

        AAL5   ATM Adaptation Layer 5




Sheedy                                                         [Page 3]


INTERNET DRAFT                                             12 July 2000


        ASI    DVB Asynchronous Serial Interface

        QAM    Quadrature Amplitude Modulation

   The new syntax of "lower-transport" would then be:

       lower-transport = "TCP" | "UDP" | "AAL5" | "ASI" | "QAM"

   (Note that end user RTSP clients typically don't request a DVB-ASI
   lower transport.  This is primarily used by bridging servers that
   are also controlling external hardware such as QAM modulators.)

2.3  Destinations

   To handle the additional lower transport types, the syntax of the
   "destination" transport parameter needs to be enhanced.  In
   particular, many lower transports described in section 2.2 use
   addresses that are not globally unique, but are unique only within a
   particular physical channel.  The destination "address" field should
   contain an optional identifier string at the beginning to allow
   sufficiently intelligent clients (such as bridging servers) to
   disambiguate between physical channels.

   The formal syntax for the expanded "destination" addresses is:

       address      = [ id-string ":" ] type-address

       type-address = host
                    | atm-address
                    | qam-address

       id-string    = 1*( ALPHA | DIGIT | "_" )

   (Note that QAM and DVB-ASI addressing are identical, and both are
   covered by the "qam-address" rule.)

   The AVP profile is used with all of these lower transports.  The
   behavior specified by the AVP profile is defined by existing
   standards, and depends upon the lower transport type:

        AAL5   The ITU H.222.1 standard for MPEG delivery over
               ATM [7]

        ASI    The Digital Video Broadcasting - Cable standard
        QAM    [8]

2.3.1  ATM Address

   The destination address for ATM may be either an ATM permanent
   virtual circuit address or an ATM switched virtual circuit address:




Sheedy                                                         [Page 4]


INTERNET DRAFT                                             12 July 2000


       atm-address = atm-pvc-address
                   | atm-svc-address


2.3.1.1 ATM PVC Address

   The destination address for an ATM permanent virtual circuit is the
   VPI and VCI of the client, and the port number on the server of the
   physical trunk that connects to the client.  Numbers may be
   specified in either decimal or hexadecimal (preceded by "0x"):

       atm-pvc-address = atm-port "/" vpi "/" vci

       atm-port        = 1*5(DIGIT)
                       | "0x" 1*4(HEX)
       vpi             = 1*5(DIGIT)
                       | "0x" 1*4(HEX)
       vci             = 1*5(DIGIT)
                       | "0x" 1*4(HEX)

   For example, to use ATM permanent virtual circuits a client may
   specify a Transport header like the following:

       Transport: MP2T/AVP/AAL5;unicast;destination=0/0/40

2.3.1.2 ATM SVC Address

   The destination address for an ATM switched virtual circuit is the
   20-byte network service access point (NSAP) address, specified as 40
   hex characters without a "0x" prefix.  Optionally, dots may be
   included after 16-bit fields, with the first dot following an 8-bit
   field:

       atm-svc-address = 20*20(HEX)
                       | 2*2(HEX) 9*9( "." 4*4(HEX) ) "." 2*2(HEX)

   For example, to use ATM switched virtual circuits a client may
   specify a Transport header like the following:

       Transport: MP2T/AVP/AAL5;unicast;
                  destination=47000580ffe1000000f21a360b00204821490f01

2.3.2  QAM and DVB-ASI Addresses

   The destination address for QAM or DVB-ASI is a server-specific
   channel number (note that this is not the RF channel number) and
   MPEG-2 program number specified in decimal:

       qam-address    = channel-number "." program-number

       channel-number = 1*3(DIGIT)
       program-number = 1*5(DIGIT)


Sheedy                                                         [Page 5]


INTERNET DRAFT                                             12 July 2000


   For example, to use QAM a client may specify a Transport header like
   the following:

       Transport: MP2T/AVP/QAM;unicast;destination=cim00:0.75

   For example, to use DVB-ASI a client may specify a Transport header
   like the following:

       Transport: MP2T/AVP/ASI;unicast;destination=dac00:0.75

2.4  Client Identification

   For most video-on-demand environments, clients cannot be allowed to
   specify a transport destination address.  In non-IP delivery
   environments, they typically do not have sufficient knowledge of the
   network topology to properly specify an address.  In all
   environments, allowing clients to choose an address presents
   security problems.  Further, in many non-IP delivery environments
   (such as cable systems using QAM and DOCSIS), valid transport
   addresses cannot be derived from the IP address of the client.

   To resolve these problems, the client must be able to identify
   itself to the media server.  This can be accomplished by adding a
   new Transport parameter, "client".  The argument to "client" is a
   deployment-specific string that uniquely identifies a client.
   Identity information included in the string may be, for example, a
   smart card ID for a set top box and the optical node to which the
   set top box is connected.

   The formal syntax for the "client" parameter is:

       client    = "client" "=" client-id
       client-id = token

3  Reuse of Transports

   In some environments, such as commercial ATM or QAM deployments,
   transport properties do not change from presentation to
   presentation, and setting up sessions is expensive, in terms of both
   server loading and client perceived latency.  The Web browsing model
   of creating a transport for each presentation works well in many
   Internet delivery environments.  In a non-IP delivery environment
   with dedicated media delivery bandwidth, however, using a single
   transport for several sequential presentations provides a better end
   user experience.

   Allowing a single transport to handle multiple sequential
   presentations requires extensions in the following areas:

      - Presentation URI's

      - Transport parameters


Sheedy                                                         [Page 6]


INTERNET DRAFT                                             12 July 2000


3.1  Presentation URI Enhancements

   Reusing an existing transport for different presentations requires a
   mechanism to change the presentation URI, and URI wildcarding to
   allow clients to control playout in cases when the currently active
   presentation on the server is not known precisely.

3.1.1  Changing Presentation URI

   To play a different presentation on an existing transport, the
   client may specify a different presentation URI on a PLAY method
   request than was used in the initial SETUP request.  If a PLAY is
   requested with a different presentation URI than that most recently
   used in the session, the presentation specified by the new URI will
   be played over the existing session's transport.

   For a PLAY request with a new presentation URI to succeed,
   sufficient bandwidth must already be available in the existing
   transport.  This can be reserved with an extension transport
   parameter on the initial SETUP of the session ("bandwidth",
   described in section 3.2), or can be allocated with a new SETUP
   request.

   Changing a presentation URI is only allowed if the server supports
   aggregate control of both the current presentation and the new
   presentation.  If this is not the case, the server must respond with
   error 459, "Aggregate Operation Not Allowed".

   If the new URI requested by a client is not a presentation URI, the
   server must respond with error 460, "Only Aggregate Operation
   Allowed".

3.1.2  Wildcard Presentation URI

   If a client uses queued PLAY requests with different URI's, it may
   not be able to determine which presentation is active at any
   particular time.  To handle this case, an asterisk (*) for the URI
   matches whatever presentation URI, if any, is currently active.
   Such a wild card asterisk is legal only for the following methods:

       PLAY
       PAUSE
       TEARDOWN
       GET_PARAMETER
       SET_PARAMETER

   Wildcard URI's may not be used with SETUP requests.  If a client
   uses a wildcard URI in a SETUP request, the server must respond with
   an error 404, "Not Found".





Sheedy                                                         [Page 7]


INTERNET DRAFT                                             12 July 2000


3.1.2.1 URI Response Header

   In a response to a request containing a wildcard URI, the server
   must include a URI header its response to indicate the actual
   presentation URI affected by the request.  The syntax of the URI
   response header is:

       URI-Response = "URI" ":" absolute_URI

3.2  bandwidth Transport Parameter

   A client may use the "bandwidth" Transport parameter to reserve
   bandwidth for a transport.  Its argument is a decimal number
   specifying the bandwidth to reserve in bits per second.  If no
   bandwidth parameter is given, it implies that the media server will
   use the bit rate of the presentation specified in the SETUP
   request's URI for the bandwidth of the transport.

   The formal syntax for the "bandwidth" parameter is:

       bandwidth = "bandwidth" "=" 1*DIGIT

4  PLAY Queue Enhancements

   Requiring all new PLAY requests to be queued when another PLAY
   request is active makes low-latency implementation of fast forward
   and rewind difficult; it requires multiple requests to the media
   server to stop the current PLAY and start the new one.  Further, it
   makes seamless transitions between normal and scaled play
   impossible, since the current PLAY must be stopped, resulting in a
   gap in the media delivery, before the new PLAY can be started.

   Similarly, requiring all PAUSE requests to flush the queue of PLAY
   requests is awkward.  This forces a client to remember and reissue
   all previously queued PLAY requests when it restarts a stream after
   a PAUSE.

   These problems can be resolved by allowing clients to specify the
   type of queuing behavior they desire on each request.  The proposed
   mechanism uses a new header "Queue-Control" with two options for
   specifying queueing behavior.  The syntax is:

       Queue-Control   = "Queue-Control" ":" queue-directive
                         *(";" queue-directive)
       queue-directive = "play-now"
                       | "no-flush"

4.1  play-now Directive

   A client may use the play-now directive with either a SETUP or PLAY
   method.



Sheedy                                                         [Page 8]


INTERNET DRAFT                                             12 July 2000


4.1.1  play-now with PLAY

   When used in a PLAY request, the play-now directive indicates that
   the PLAY operation should be performed immediately rather than
   queuing it.  Using play-now in a PLAY request causes any queued PLAY
   requests to be discarded unless the no-flush directive is also
   included.

4.1.2  play-now with SETUP

   When added to a SETUP request, the play-now directive indicates that
   the client wants streaming to begin immediately (i.e., possibly even
   before the SETUP response is sent to the client). This allows the
   client to avoid waiting for the response from SETUP and then issuing
   a PLAY command, but has some practical limitations.

   The play-now directive with SETUP is not useful in those
   environments where the client requires information contained in the
   SETUP response before it can start decoding the media stream.  For
   example, if a set top box needs the SETUP response to know which
   channel to tune to, it will typically need to issue a separate PLAY
   command after it has tuned to the proper channel.

   If the play-now directive is included in a SETUP request, Range,
   Scale and Speed headers may also be included.

4.2  no-flush Directive

   A client may use the no-flush directive with either a PAUSE or PLAY
   method.  When added to either request, it prevents queued PLAY
   requests from being discarded.

5  Server State Changes

   Most clients need to track the state of the media server while the
   server is streaming.  The most critical state change to clients
   occurs when the media server encounters the end of a presentation
   (or the beginning when rewinding), and stops streaming.  There are
   currently no standard mechanisms for detecting this in the RTSP
   specification.  Problems clients encounter in the current
   architecture include:

      - Polling for the current media server state wastes network
        bandwidth, and introduces unacceptable latencies in detecting
        state transitions.

      - In non-IP delivery environments, the transport typically
        remains allocated even if no media is being delivered.  This
        means that a client cannot watch for the server to close the
        transport to signal the end of media delivery.




Sheedy                                                         [Page 9]


INTERNET DRAFT                                             12 July 2000


      - Watching for the incoming media to stop is unreliable.  Short
        timeouts can trigger a false end of media detection if the
        media flow is temporarily delayed.  Long timeouts introduce
        unacceptable latencies.  Clients are unable to distinguish
        between a normal end of media and an error condition that
        resulted in the media delivery stopping.

   These problems can be remedied by a client callback mechanism.  The
   proposed mechanism uses the ANNOUNCE method sent from the server to
   the client, along with a new header which contains the details of
   media server state transitions.

5.1  ANNOUNCE Callbacks

   If desired by the client, an ANNOUNCE request can be sent
   asynchronously from the server to the client to notify it of any
   changes in a session state.  ANNOUNCE requests are only sent to a
   client if the client used the May-Notify header in its SETUP request
   for the session (section 5.2).  The nature and time of the event
   causing the stream state change are contained in the Notice header
   (section 5.3).

   An ANNOUNCE request will only be sent if the session is currently
   associated with an open persistent connection to the client.  If the
   session is not associated with a connection to the client, the state
   change notification will be returned in the next GET_PARAMETER
   response for the session.

5.2  May-Notify Header

   The May-Notify header may be included in a SETUP request.

   If a client includes the May-Notify header in a SETUP request, the
   server will notify the client asynchronously of any stream state
   changes by sending it an ANNOUNCE request (section 5.1).   If this
   header is not included, state changes are returned to the client as
   part of a GET_PARAMETER response.  In both cases, the state change
   is reported with a Notice header (section 5.3).

5.3  Notice Header

   The Notice header contains media server state change information for
   a session, such as errors encountered during play or reaching the
   end of the stream.  It may only originate from a media server, and
   is not recognized in client requests.  The Notice header is sent
   from the server to a client via either an ANNOUNCE request or a
   GET_PARAMETER response (section 5.1).

   The formal syntax for the Notice header is:

       Notice       = "Notice" ":" notify *("," notify)



Sheedy                                                        [Page 10]


INTERNET DRAFT                                             12 July 2000


       notify       = event-code SP """ event-phrase """ SP
                      "event-date" "=" utc-time

       event-code   = 4DIGIT

       event-phrase = *<TEXT, excluding CR, LF, ">

   Event codes and phrases which may be returned by the server are:

        Code   Message

        1103   Stream Stalled

        1104   Stream Resumed

        2101   End-of-Stream Reached

        2103   Transition

        2104   Start-of-Stream Reached

        2306   Continuous Feed Terminated

        4401   Error Reading Media Data

        5201   Server Resources Unavailable

        5401   Stream Failure

        5402   Session Terminated by Server

        5403   Server Shutting Down

        5501   Internal Server Error

6  Miscellaneous

6.1  Reason Header

   A client may wish to inform the server why it has chosen to tear
   down a session.  This is often useful in diagnosing server or
   network problems.  This is accomplished with the Reason header.  The
   Reason header is only valid in TEARDOWN requests.

   How much of the Reason header message is saved by the media server,
   or whether the message is saved at all, is up to the discretion of
   the media server.  Implementers of media servers should place limits
   on the message length and message frequency to prevent the Reason
   header from being used in denial-of-service attacks.

   The formal syntax of the Reason header is:



Sheedy                                                        [Page 11]


INTERNET DRAFT                                             12 July 2000


       Reason        = "Reason" ":" reason-phrase
       reason-phrase = *<TEXT, excluding CR, LF, ">

6.2  Looping Ranges

   Continuous looping play of a presentation is a frequent requirement
   in commercial environments.  This is typically used for movie
   trailers, etc.

   To support this, the Range header can be enhanced to allow clients
   to ask the media server to continuously loop a presentation.  The
   formal syntax of the extended Range header is:

       Range        = "Range" ":" 1\#ranges-specifier *(range-option)
       range-option = ";" "time" "=" utc-time
                    | ";" "loop" [ "=" loop-count ]
       loop-count   = 1*DIGIT

   Adding the "loop" option to a Range header causes the specified
   range within the media to loop for "loop-count" iterations, or
   forever if no "loop-count" is specified.

   A PAUSE request or another PLAY request for the session will stop
   the looping.  A PAUSE request will terminate the loop immediately.
   A queued PLAY request (without the play-now directive, section 4.1)
   will terminate the loop at the end of the current iteration.  A PLAY
   request with the play-now directive will terminate the loop
   immediately.

6.3  Additional Status Codes

   The following two standard status codes should be added:

        Code   Message

        463    Destination Required

        464    Unable to Visual Scan

   Code 463 indicates that the media server was unable to select an
   appropriate transport destination address for the client, and that
   the client must supply one explicitly.  It may only be returned in
   SETUP responses.

   Code 464 may only be returned in response to a PLAY request, which
   includes a scale other than 1.  It indicates that the server is
   unable to stream the media at a rate other than normal speed
   forward.  This may be a temporary condition caused, for example, by
   unusually heavy loading on the media server.  It may also be a
   permanent condition due, for example, to media encoding limitations
   or media server policy.



Sheedy                                                        [Page 12]


INTERNET DRAFT                                             12 July 2000


6.4  Stream Parameters

   Standard parameters need to be defined for the GET_PARAMETER method
   to be generally useful.  Proposed standard parameters are:

        state      The current server protocol state.  Possible
                   returned values are:

                        playing
                        ready

        position   The current stream position. The position is
                   the number of seconds from the beginning of
                   the media, in npt format.

        scale      The current stream scale.

Appendix A: Author's Address

   Sean Sheedy
   nCUBE Corporation
   1825 NW 167th Place
   Beaverton, OR  97006
   USA

   E-mail: seans@ncube.com

References

1. Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
   Protocol (RTSP)", RFC 2326, April 1998.

2. nCUBE Corporation, "nCUBE RTSP Implementation and Extensions",
   January 2000.

3. Oracle Corporation, "Custom Video Client Developer's Guide, Release
   3.2", September 1999.

4. Handley, M., and V. Jacobson, "SDP: Session Description Protocol",
   RFC 2327, April 1998.

5. Kumar, R. and M. Mostafa, "Conventions for the use of the Session
   Description Protocol (SDP) for ATM Bearer Connections", draft-
   rajeshkumar-mmusic-sdp-atm-02.txt, July 2000.

6. International Telecommunication Union, "Generic Coding of Moving
   Pictures and Associated Audio Information: Systems", H.222.0, July
   1995.

7. International Telecommunication Union, "Multimedia Multiplex and
   Synchronization for Audiovisual Communication in ATM Environments",
   H.222.1, March 1996.


Sheedy                                                        [Page 13]


INTERNET DRAFT                                             12 July 2000


8. European Telecommunications Standards Institute, "Digital Video
   Broadcasting: Framing Structure, Channel Coding and Modulation For
   Cable Systems", EN 300 429, October 1997.



















































Sheedy                                                        [Page 14]