Internet Engineering Task Force                                MMUSIC WG
Internet Draft                                H. Schulzrinne
                                                             Columbia Schulzrinne/Columbia U.
draft-ietf-mmusic-rfc2326bis-06.txt                         A. Rao
                                                                   Cisco Rao/Cisco
February 16, 2004                               R. Lanphier
                                                            RealNetworks
                                                           M. Westerlund
                                                                Ericsson
                                                           A. Narasimhan
                                                                     Sun
draft-ietf-mmusic-rfc2326bis-05.txt
October 27, 2003 Lanphier/RealNetworks
Expires: April, August, 2004                             M. Westerlund/Ericsson
                                                       A. Narasimhan/Sun

                  Real Time Streaming Protocol (RTSP)

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

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

Abstract

   This memorandum is a revision of RFC 2326, which is currently a
   Proposed Standard.

   The Real Time Streaming Protocol, or RTSP, is an application-level
   protocol for control over the delivery of data with real-time
   properties. RTSP provides an extensible framework to enable
   controlled, on-demand delivery of real-time data, such as audio and
   video. Sources of data can include both live data feeds and stored
   clips. This protocol is intended to control multiple data delivery
   sessions, provide a means for choosing delivery channels such as UDP,
   multicast UDP and TCP, and provide a means for choosing delivery
   mechanisms based upon RTP (RFC 3550).

                           Table of Contents

   1          Introduction ........................................    8
   1.1        The Update of the RTSP Specification

   This is the draft to an update of RTSP which is currently a proposed
   standard defined in RFC 2326  [21]. Many flaws have been found in ................    8
   1.2        Purpose .............................................    9
   1.3        Notational Conventions ..............................   11
   1.4        Terminology .........................................   11
   1.5        Protocol Properties .................................   14
   1.6        Extending RTSP since it was published. While this draft tries to address the
   flaws, not all known issues have been resolved.

   The goal of the current work on ......................................   16
   1.7        Overall Operation ...................................   17
   1.8        RTSP is to progress it to draft
   standard status. Whether this is possible without first publishing States .........................................   18
   1.9        Relationship with Other Protocols ...................   19
   2          RTSP as a proposed standard depends on the changes necessary to make
   the protocol work. The list of changes in chapter F indicates the
   issues that have already been addressed. The currently open issues
   are listed in chapter E.

   There is also a list of reported bugs available at
   "http://rtspspec.sourceforge.net". These bugs should be taken into
   account when reading this specification. While a lot of these bugs
   are addressed, not all are yet accounted for in this specification.
   Input on the unresolved bugs and other issues can be sent via e-mail
   to the MMUSIC WG's mailing list mmusic@ietf.org and the authors.

   Take special notice of the following:

        o The example section  15 has not yet been revised since the
          changes to protocol have not been completed.

        o The BNF chapter  16 has not been compiled completely.

        o Not all of the contents of RFC 2326 are part of this draft.
          In an attempt to prevent the draft from exploding in size, the
          specification has been reduced and split. The content Use Cases ......................................   19
   2.1        On-demand Playback of this
          draft is the core specification Stored Content ................   20
   2.2        Unicast distribution of the protocol. It contains
          the general idea behind Live Content ................   20
   2.3        Inviting RTSP and the basic functionality
          necessary to establish an on-demand play-back session. It also
          contains the mechanisms for extending the protocol. Any other
          functionality will be published as extension documents. Two
          proposals exist at this time:

        o NAT and FW traversal mechanisms for RTSP are described in servers into a
          document called "How to make Real-Time Streaming multicast
              group ...............................................   20
   2.4        On-demand Playback using Multicast ..................   20
   3          Protocol
          (RTSP) traverse Network Address Translators (NAT) and interact
          with Firewalls." [33].

        o The MUTE extension [34] contains a proposal on adding
          functionality to mute and unmute media streams in an
          aggregated media session without affecting the time-line of
          the playback.

   There have also been discussions about the following extensions to
   RTSP:

        o Transport security for Parameters .................................   20
   3.1        RTSP messages (rtsps).

        o Unreliable transport of Version ........................................   20
   3.2        RTSP messages (rtspu).

        o The Record functionality.

        o A text body type with suitable syntax for basic parameters to
          be used in SET_PARAMETER, and GET_PARAMETER. Including IANA
          registry within the defined name space.

        o A URL ............................................   20
   3.3        Session Identifiers .................................   22
   3.4        SMPTE Relative Timestamps ...........................   22
   3.5        Normal Play Time ....................................   22
   3.6        Absolute Time .......................................   23
   3.7        Feature-tags ........................................   23
   4          RTSP MIB.

   However, so far, they have not become concrete proposals.

1.2 Purpose

   The Real-Time Streaming Protocol (RTSP) establishes Message ........................................   24
   4.1        Message Types .......................................   24
   4.2        Message Headers .....................................   24
   4.3        Message Body ........................................   25
   4.4        Message Length ......................................   25
   5          General Header Fields ...............................   25
   6          Request .............................................   25
   6.1        Request Line ........................................   26
   6.2        Request Header Fields ...............................   27
   7          Response ............................................   27
   7.1        Status-Line .........................................   28
   7.1.1      Status Code and controls
   single or several time-synchronized streams of continuous media such
   as audio Reason Phrase .......................   28
   7.1.2      Response Header Fields ..............................   29
   8          Entity ..............................................   30
   8.1        Entity Header Fields ................................   32
   8.2        Entity Body .........................................   32
   9          Connections .........................................   32
   9.1        Pipelining ..........................................   33
   9.2        Reliability and video. Put simply, RTSP acts as a "network remote
   control" for multimedia servers.

   There is no notion of a RTSP connection in the protocol. Instead, a    |
   RTSP server maintains a session labelled by an identifier to           |
   associate groups Acknowledgements ....................   33
   9.3        Unreliable Transport ................................   34
   9.4        The usage of media streams and their states. A RTSP session is  |
   not tied to a transport-level connection such as a TCP connection.     |
   During a session, a client may open and close many reliable transport  | connections to the server to issue RTSP requests for that session.

   This memorandum describes the use of RTSP over a reliable connection
   based transport level protocol such as TCP. RTSP may be implemented
   over an unreliable connectionless transport protocol such as UDP.
   While nothing in ............................   34
   9.5        Timing Out RTSP precludes this, additional definition of this
   problem area must be handled as an extension to the core
   specification.

        The mechanisms of RTSP's operation over UDP were left out
        of this spec. because they were poorly defined in RFC 2336
        [21] and the tradeoff in size and complexity messages ............................   36
   9.6        Use of this spec.
        for a small gain IPv6 .........................................   36
   10         Capability Handling .................................   37
   11         Method Definitions ..................................   38
   11.1       OPTIONS .............................................   39
   11.2       DESCRIBE ............................................   40
   11.3       SETUP ...............................................   42
   11.4       PLAY ................................................   44
   11.5       PAUSE ...............................................   48
   11.6       TEARDOWN ............................................   51
   11.7       GET_PARAMETER .......................................   52
   11.8       SET_PARAMETER .......................................   53
   11.9       REDIRECT ............................................   55
   11.10      PING ................................................   56
   12         Embedded (Interleaved) Binary Data ..................   57
   13         Status Code Definitions .............................   59
   13.1       Success 1xx .........................................   59
   13.1.1     100 Continue ........................................   59
   13.2       Success 2xx .........................................   59
   13.3       Redirection 3xx .....................................   59
   13.3.1     TBW .................................................   60
   13.3.2     301 Moved Permanently ...............................   60
   13.3.3     302 Found ...........................................   60
   13.3.4     303 See Other .......................................   60
   13.3.5     304 Not Modified ....................................   60
   13.3.6     305 Use Proxy .......................................   61
   13.4       Client Error 4xx ....................................   61
   13.4.1     400 Bad Request .....................................   61
   13.4.2     405 Method Not Allowed ..............................   61
   13.4.3     451 Parameter Not Understood ........................   61
   13.4.4     452 reserved ........................................   61
   13.4.5     453 Not Enough Bandwidth ............................   61
   13.4.6     454 Session Not Found ...............................   62
   13.4.7     455 Method Not Valid in a targeted problem space was not deemed
        justifiable.

   The set of streams to be controlled is defined by a presentation
   description. This memorandum does not define a format for the
   presentation description. The streams controlled by RTSP may use RTP
   [1] State ..................   62
   13.4.8     456 Header Field Not Valid for their data transport, but the operation of RTSP does not
   depend on the transport mechanism used to carry continuous media. The
   protocol is intentionally similar in syntax and operation to HTTP/1.1
   [26] so that extension mechanisms to HTTP can in most cases also be
   added to RTSP.  However, RTSP differs in a number of important
   aspects from HTTP:

        o RTSP introduces a number Resource .............   62
   13.4.9     457 Invalid Range ...................................   62
   13.4.10    458 Parameter Is Read-Only ..........................   62
   13.4.11    459 Aggregate Operation Not Allowed .................   62
   13.4.12    460 Only Aggregate Operation Allowed ................   62
   13.4.13    461 Unsupported Transport ...........................   62
   13.4.14    462 Destination Unreachable .........................   63
   13.5       Server Error 5xx ....................................   63
   13.5.1     551 Option not supported ............................   63
   14         Header Field Definitions ............................   63
   14.1       Accept ..............................................   65
   14.2       Accept-Encoding .....................................   65
   14.3       Accept-Language .....................................   66
   14.4       Accept-Ranges .......................................   66
   14.5       Allow ...............................................   66
   14.6       Authorization .......................................   66
   14.7       Bandwidth ...........................................   66
   14.8       Blocksize ...........................................   68
   14.9       Cache-Control .......................................   70
   14.10      Connection ..........................................   72
   14.11      Content-Base ........................................   73
   14.12      Content-Encoding ....................................   73
   14.13      Content-Language ....................................   73
   14.14      Content-Length ......................................   73
   14.15      Content-Location ....................................   73
   14.16      Content-Type ........................................   73
   14.17      CSeq ................................................   73
   14.18      Date ................................................   74
   14.19      Expires .............................................   74
   14.20      From ................................................   75
   14.21      Host ................................................   75
   14.22      If-Match ............................................   75
   14.23      If-Modified-Since ...................................   75
   14.24      Last-Modified .......................................   76
   14.25      Location ............................................   76
   14.26      Proxy-Authenticate ..................................   76
   14.27      Proxy-Require .......................................   76
   14.28      Public ..............................................   77
   14.29      Range ...............................................   77
   14.30      Referer .............................................   79
   14.31      Retry-After .........................................   79
   14.32      Require .............................................   79
   14.33      RTP-Info ............................................   80
   14.34      Scale ...............................................   82
   14.35      Speed ...............................................   82
   14.36      Server ..............................................   83
   14.37      Session .............................................   83
   14.38      Supported ...........................................   85
   14.39      Timestamp ...........................................   86
   14.40      Transport ...........................................   86
   14.41      Unsupported .........................................   92
   14.42      User-Agent ..........................................   92
   14.43      Vary ................................................   93
   14.44      Via .................................................   93
   14.45      WWW-Authenticate ....................................   93
   15         Caching .............................................   93
   16         Examples ............................................   94
   16.1       Media on Demand (Unicast) ...........................   94
   16.2       Streaming of new methods and has a different
          protocol identifier.

        o Container file .......................   97
   16.3       Single Stream Container Files .......................  100
   16.4       Live Media Presentation Using Multicast .............  101
   16.5       Capability Negotiation ..............................  103
   17         Syntax ..............................................  104
   17.1       Base Syntax .........................................  104
   17.2       RTSP has the notion of a session built into the protocol.

        o Protocol Definition ............................  105
   17.2.1     Generic Protocol elements ...........................  105
   17.2.2     Message Syntax ......................................  106
   17.2.3     Header Syntax .......................................  110
   18         Security Considerations .............................  112
   19         IANA Considerations .................................  115
   19.1       Feature-tags ........................................  115
   19.1.1     Description .........................................  115
   19.1.2     Registering New Feature-tags with IANA ..............  116
   19.1.3     Registered entries ..................................  116
   19.2       RTSP Methods ........................................  116
   19.2.1     Description .........................................  116
   19.2.2     Registering New Methods with IANA ...................  116
   19.2.3     Registered Entries ..................................  117
   19.3       RTSP Status Codes ...................................  117
   19.3.1     Description .........................................  117
   19.3.2     Registering New Status Codes with IANA ..............  117
   19.3.3     Registered Entries ..................................  117
   19.4       RTSP Headers ........................................  117
   19.4.1     Description .........................................  117
   19.4.2     Registering New Headers with IANA ...................  118
   19.4.3     Registered entries ..................................  118
   19.5       Transport Header registries .........................  118
   19.5.1     Transport Protocols .................................  119
   19.5.2     Profile .............................................  119
   19.5.3     Lower Transport .....................................  119
   19.5.4     Transport modes .....................................  120
   19.6       Cache Directive Extensions ..........................  120
   19.7       SDP attributes ......................................  121
   A          RTSP server needs to maintain state by default Protocol State Machine .........................  122
   A.1        States ..............................................  122
   A.2        State variables .....................................  122
   A.3        Abbreviations .......................................  122
   A.4        State Tables ........................................  123
   B          Media Transport Alternatives ........................  125
   B.1        RTP .................................................  126
   B.1.1      AVP .................................................  126
   B.1.2      AVP/UDP .............................................  127
   B.1.3      AVP/TCP .............................................  128
   B.1.4      Handling NPT Jumps in almost all
          cases, as opposed to the stateless nature of HTTP.

        o Both a RTP Media Layer ...........  129
   B.1.5      Handling RTP Timestamps after PAUSE .................  131
   B.1.6      RTSP server and client can issue requests.

        o Data is usually carried out-of-band by a different protocol.
          Session descriptions returned in a DESCRIBE response (see
          Section 11.2) and interleaving of / RTP Integration ..............................  133
   B.1.7      Scaling with RTSP over TCP are
          exceptions to this rule (see Section 11.11).

        o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO
          8859-1, consistent RTP ....................................  133
   B.1.8      Maintaining NPT synchronization with current HTML internationalization
          efforts [3].

        o RTP
              timesatmps ..........................................  133
   B.1.9      Continuous Audio ....................................  134
   B.1.10     Multiple Sources in an RTP Session ..................  134
   B.1.11     Usage of SSRCs and the RTCP BYE Message During a
              RTSP Session ........................................  134
   B.2        Future Additions ....................................  134
   C          Use of SDP for RTSP Session Descriptions ............  135
   C.1        Definitions .........................................  135
   C.1.1      Control URL .........................................  135
   C.1.2      Media Streams .......................................  136
   C.1.3      Payload Type(s) .....................................  137
   C.1.4      Format-Specific Parameters ..........................  137
   C.1.5      Range of Presentation ...............................  137
   C.1.6      Time of Availability ................................  138
   C.1.7      Connection Information ..............................  138
   C.1.8      Entity Tag ..........................................  139
   C.2        Aggregate Control Not Available .....................  139
   C.3        Aggregate Control Available .........................  140
   C.4        RTSP external SDP delivery ..........................  141
   D          Minimal RTSP implementation .........................  141
   D.1        Client ..............................................  141
   D.1.1      Basic Playback ......................................  142
   D.1.2      Authentication-enabled ..............................  142
   D.2        Server ..............................................  143
   D.2.1      Basic Playback ......................................  143
   D.2.2      Authentication-enabled ..............................  144
   E          Open Issues .........................................  144
   F          Changes .............................................  145
   G          Author Addresses ....................................  151
   H          Contributors ........................................  152
   I          Acknowledgements ....................................  152
   J          Normative References ................................  152
   K          Informative References ..............................  154

1 Introduction

1.1 The Request-URI always contains Update of the absolute URI. Because RTSP Specification

   This is the draft to an update of
          backward compatibility with RTSP which is currently a historical blunder, HTTP/1.1
          [26] carries only the absolute path proposed   |
   standard defined in RFC 2326  [1]. Many flaws have been found in RTSP  |
   since it was published. While this draft tries to address the request and puts
          the host name flaws,   |
   not all known issues have been resolved. However in this version only  |
   a separate header field.

             This makes "virtual hosting" easier, where a single
             host with one IP address hosts several document trees. few remains, please see Open Issues in section  E.

   The protocol supports the following operations:

        Retrieval goal of media from media server: The client can request a
             presentation description via HTTP or some other method. If the presentation current work on RTSP is being multicast, the presentation
             description contains to progress it to draft
   standard status. Whether this is possible without first republishing
   RTSP as a proposed standard depends on the multicast addresses and ports changes necessary to
             be used for make
   the continuous media.  If protocol work. The list of changes in appendix  F indicates the presentation
   issues that have already been addressed. The currently open issues
   are listed in appendix E.

   There is
             to also a list of reported bugs available at
   "http://rtspspec.sourceforge.net". These bugs should be taken into
   account when reading this specification. While a lot of these bugs
   are addressed, not all are yet accounted for in this specification.
   Input on the unresolved bugs and other issues can be sent only via e-mail
   to the client via unicast, MMUSIC WG's mailing list mmusic@ietf.org and the client
             provides authors.

   Not all of the destination for security reasons.

        Invitation contents of a media server to a conference: A media server can
             be "invited" to join RFC 2326 are part of this draft. In an existing conference      |
   attempt to play back
             media into prevent the presentation. This mode is useful for
             distributed teaching applications. Several parties draft from exploding in size, the
             conference may take turns "pushing               |
   specification has been reduced and split. The content of this draft    |
   is the remote control
             buttons".

        Addition core specification of media the protocol. It contains the general     |
   idea behind RTSP and the basic functionality necessary to establish    |
   an existing presentation: Particularly for
             live presentations, it is useful if on-demand play-back session. It also contains the server can tell mechanisms for    |
   extending the
             client about additional media becoming available.

   RTSP requests may protocol. Any other functionality will be handled by proxies, tunnels and caches published as in
   HTTP/1.1 [26].

1.3 Requirements   |
   extension documents. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", Working group currently is working on:        |

        o NAT and "OPTIONAL" FW traversal mechanisms for RTSP are described in this a     |
          document are called "How to make Real-Time Streaming Protocol       |
          (RTSP) traverse Network Address Translators (NAT) and interact  |
          with Firewalls." [20].                                          |

   There have also been discussion or proposals about the following       |
   extensions to RTSP:                                                    |

        o Mute and Unmute Extension [21].                                 |

        o RTSP Stream Switching [22].                                     |

        o Live Streaming Relays [23].                                     |

        o Transport security for RTSP messages (rtsps).                   |
        o Unreliable transport of RTSP messages (rtspu).                  |

        o The Record functionality.                                       |

        o A text body type with suitable syntax for basic parameters to   |
          be interpreted as described used in RFC 2119 [4].

1.4 Terminology

   Some of SET_PARAMETER, and GET_PARAMETER. Including IANA     |
          registry within the terminology has been adopted from HTTP/1.1 [26]. Terms
   not listed here are defined as in HTTP/1.1.

        Aggregate control: The concept of controlling multiple streams
             using a single timeline, generally maintained by the
             server. name space.                         |

        o A client, for example, uses aggregate control when
             it issues a RTSP MIB.                                                     |

1.2 Purpose

   The Real-Time Streaming Protocol (RTSP) establishes and controls
   single play or pause message to simultaneously
             control both the several time-synchronized streams of continuous media such
   as audio and video in video. Put simply, RTSP acts as a movie.

        Aggregate control URI: The URI used in "network remote
   control" for multimedia servers.

   There is no notion of a RTSP request to refer
             to and control an aggregated session. It normally, but not
             always, corresponds to the presentation URI specified connection in the session description. See Section  11.3 for more
             information.

        Conference: protocol. Instead, a multiparty, multimedia presentation, where "multi"
             implies greater than or equal
   RTSP server maintains a session labelled by an identifier to one.

        Client: The client requests media service from the media server.

        Connection: A transport layer virtual circuit established
             between two programs for the purpose
   associate groups of communication.

        Container file: A file which may contain multiple media streams
             which often comprise a presentation when played together. and their states. A RTSP servers may offer aggregate control on these files,
             though the concept of a container file session is
   not embedded in
             the protocol.

        Continuous media: Data where there is tied to a timing relationship
             between source transport-level connection such as a TCP connection.
   During a session, a client may open and sink; that is, the sink must reproduce close many reliable transport
   connections to the timing relationship server to issue RTSP requests for that existed at session.

   This memorandum describes the source. The
             most common examples use of continuous media are audio and
             motion video. Continuous media can be real-time
             (interactive), where there is RTSP over a "tight" timing relationship
             between source and sink, or streaming (playback), where the
             relationship is less strict.

        Entity: The information transferred reliable connection
   based transport level protocol such as TCP. RTSP may be implemented
   over an unreliable connectionless transport protocol such as UDP.
   While nothing in RTSP precludes this, additional definition of this
   problem area must be handled as an extension to the payload core
   specification.

        The mechanisms of a request
             or response. An entity consists RTSP's operation over UDP were left out
        of meta-information this spec. because they were poorly defined in the
             form of entity-header fields RFC 2326
        [1] and content in the form tradeoff in size and complexity of an
             entity-body, as described this spec.
        for a small gain in Section 8.

        Feature-tag: A tag representing a certain targeted problem space was not deemed
        justifiable.

   The set of functionality,
             i.e. streams to be controlled is defined by a feature.

        Media initialization: Datatype/codec specific initialization. presentation       |
   description. This includes such things as clockrates, color tables, etc.
             Any transport-independent information which memorandum does not define a format for the          |
   presentation description. However appendix  C defines how SDP [2] is required   |
   used for this purpose. The streams controlled by
             a client RTSP may use RTP [3]  |
   for playback of a media stream occurs in their data transport, but the media
             initialization phase operation of stream setup.

        Media parameter: Parameter specific RTSP does not depend    |
   on the transport mechanism used to a media type carry continuous media. The         |
   protocol is intentionally similar in syntax and operation to HTTP/1.1  |
   [4] so that may extension mechanisms to HTTP can in most cases also be
             changed before or during stream playback.

        Media server: The server providing playback services for one or
             more media streams. Different media streams within     |
   added to RTSP. However, RTSP differs in a
             presentation may originate number of important aspects  |
   from HTTP:

        o RTSP introduces a number of new methods and has a different media servers. A
             media server may reside on
          protocol identifier.

        o RTSP has the same or notion of a different host as session built into the web protocol.

        o A RTSP server needs to maintain state by default in almost all
          cases, as opposed to the presentation is invoked from.

        Media server indirection: Redirection stateless nature of HTTP.

        o Both a media RTSP server and client to can issue requests.

        o Data is usually carried out-of-band by a different media server.

        (Media) stream: A single media instance, e.g., an audio stream
             or a video stream as well as a single whiteboard or shared
             application group. When using RTP, protocol.
          Session descriptions returned in a stream consists of all
             RTP DESCRIBE response (see
          Section 11.2) and RTCP packets created by a source within an interleaving of RTP
             session. This with RTSP over TCP are
          exceptions to this rule (see Section 12).                       |

        o RTSP is equivalent defined to the definition of a DSM-CC
             stream([5]).

        Message: use ISO 10646 (UTF-8) rather than ISO        |
          8859-1, consistent with HTML internationalization efforts       |
          [24].

        o The basic unit of RTSP communication, consisting Request-URL always contains the absolute URL. Because of
          backward compatibility with a
             structured sequence of octets matching historical blunder, HTTP/1.1 [4]
          carries only the syntax defined absolute path in Section 16 the request and transmitted via puts the
          host name in a connection or a
             connectionless protocol.

        Non-Aggregated Control: Control of separate header field.

             This makes "virtual hosting" easier, where a single media stream.  Only
             possible in RTSP sessions
             host with a single media.

        Participant: Member of a conference. A participant may be a
             machine, e.g., a playback server.

        Presentation: A set of one or more streams presented to IP address hosts several document trees.

   The protocol supports the
             client as a complete following operations:

        Retrieval of media feed, using from media server: The client can either       |
             request a presentation description as defined below. In most cases in the via RTSP
             context, this implies aggregate control of those streams,
             but does not have to.

        Presentation description: A DESCRIBE, HTTP   |
             or some other method. If the presentation is being           |
             multicast, the presentation description contains
             information about one or more media streams within a
             presentation, such as the set of encodings, network         |
             multicast addresses and information about the content. Other IETF
             protocols such as SDP (RFC 2327 [24]) use the term
             "session" for a live presentation. The presentation
             description may take several different formats, including
             but not limited ports to be used for the session description format SDP.

        Response: A RTSP response. If an HTTP response is meant, that is
             indicated explicitly.

        Request: A RTSP request. continuous  |
             media. If an HTTP request is meant, that is
             indicated explicitly.

        RTSP session: A stateful abstraction upon which the main control
             methods of RTSP operate. A RTSP session is a server entity;
             it presentation is created, maintained and destroyed by to be sent only to the server. It
             is established by a RTSP server upon client  |
             via unicast, the completion client provides the destination for         |
             security reasons.

        Invitation of a
             successful SETUP request (when 200 OK response is sent) and
             is labelled by a session identifier at that time. The
             session exists until timed out by the media server or explicitly
             removed by to a TEARDOWN request. conference: A RTSP session is also a
             stateful entity; a RTSP media server maintains can
             be "invited" to join an explicit
             session state machine (see Appendix  A) where most state
             transitions are triggered by client requests. The existence
             of a session implies existing conference to play back
             media into the existence of state about presentation. This mode is useful for
             distributed teaching applications. Several parties in the
             session's media streams and their respective transport
             mechanisms. A given session can have zero or more media
             streams associated with it. A RTSP server uses
             conference may take turns "pushing the session
             to aggregate remote control over multiple media streams.

        Transport initialization: The negotiation
             buttons".

   RTSP requests may be handled by proxies, tunnels and caches as in
   HTTP/1.1 [4].

1.3 Notational Conventions                                                |

   Since many of transport
             information (e.g., port numbers, transport protocols)
             between the client definitions and syntax are identical to HTTP/1.1,    |
   this specification only points to the server.

1.5 Protocol Properties

   RTSP has the following properties:

        Extendable: New methods and parameters can section where they are defined   |
   rather than copying it. For brevity, [HX.Y] is to be easily added taken to
             RTSP.

        Easy refer    |
   to parse: RTSP can be parsed by standard HTTP or MIME
             parsers.

        Secure: RTSP re-uses web security mechanisms, either at the
             transport level (TLS, RFC 2246 [27]) or within Section X.Y of the protocol
             itself. All HTTP authentication mechanisms such as basic current HTTP/1.1 specification (RFC 2616 [26]) and digest authentication (RFC 2069 [6]) [4]).   |

   All the mechanisms specified in this document are directly applicable.

        Transport-independent: RTSP does not preclude described in both    |
   prose and the augmented Backus-Naur form (BNF) described in detail in  |
   RFC 2234 [5].                                                          |

   In this specification, we use indented and smaller-type paragraphs to  |
   provide background and motivation. This is intended to give readers    |
   who were not involved with the formulation of the specification an
             unreliable datagram protocol (UDP) (RFC 768 [7]), a
             reliable datagram protocol (RDP,     |
   understanding of why things are the way that they are in RTSP.         |

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",    |
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   |
   document are to be interpreted as described in RFC 1151, not widely used
             [8]) 2119 [6].           |

   This specification uses the word "Unspecified" to indicate             |
   functionality or a reliable stream protocol features that are not defined in this specification,  |
   and therefore can't be used. Any such functionality or feature can in  |
   the future be evaluated and if technical sound be defined in           |
   specification extending RTSP.

1.4 Terminology

   Some of the terminology has been adopted from HTTP/1.1 [4]. Terms not
   listed here are defined as TCP (RFC 793
             [9]) as it implements application-level reliability. in HTTP/1.1.

        Aggregate control: The
             use concept of controlling multiple streams
             using a connectionless datagram protocol such as UDP single timeline, generally maintained by the
             server. A client, for example, uses aggregate control when
             it issues a single play or
             RDP requires additional definition that may be provided as
             extensions pause message to simultaneously
             control both the core RTSP specification.

        Multi-server capable: Each media stream within audio and video in a movie.

        Aggregate control URL: The URL used in a RTSP request to refer    |
             to and control an aggregated session. It normally, but not   |
             always, corresponds to the presentation
             can reside on URL specified in     |
             the session description. See Section  11.3 for more          |
             information.

        Conference: a different server. multiparty, multimedia presentation, where "multi"
             implies greater than or equal to one.

        Client: The client automatically
             establishes several concurrent control sessions with the
             different requests media servers.  Media synchronization is
             performed at service from the media server.

        Connection: A transport level.

        Separation layer virtual circuit established
             between two programs for the purpose of stream control and conference initiation: Stream
             control is divorced from inviting a communication.

        Container file: A file which may contain multiple media server to streams
             which often comprise a
             conference. In particular, SIP [10] or H.323 [28] presentation when played together.
             RTSP servers may be
             used to invite a server to offer aggregate control on these files,
             though the concept of a conference.

        Suitable for professional applications: RTSP supports frame-
             level accuracy through SMPTE time stamps to allow remote
             digital editing.

        Presentation description neutral: The protocol does container file is not impose embedded in
             the protocol.

        Continuous media: Data where there is a
             particular presentation description or metafile format timing relationship
             between source and
             can convey the type of format to be used. However, sink; that is, the
             presentation description sink must contain reproduce
             the timing relationship that existed at least one RTSP
             URI.

        Proxy and firewall friendly: the source. The protocol should be readily
             handled by both application and transport-layer (SOCKS
             [11]) firewalls. A firewall may need to understand the
             SETUP method to open a "hole" for the UDP media stream.

        HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so
             that the existing infrastructure can be reused. This
             infrastructure includes PICS (Platform for Internet Content
             Selection [12,13]) for associating labels with content.
             However, RTSP does not just add methods to HTTP since the
             controlling
             most common examples of continuous media requires server state in most
             cases.

        Appropriate server control: If a client are audio and
             motion video. Continuous media can start a stream, it
             must be able to stop real-time
             (interactive), where there is a stream. Servers should not start "tight" timing relationship
             between source and sink, or streaming to clients in such a way that clients cannot stop (playback), where the stream.

        Transport negotiation:
             relationship is less strict.

        Entity: The client can negotiate information transferred as the transport
             method prior to actually needing to process payload of a continuous
             media stream.

        Capability negotiation: If basic features are disabled, there
             must be some clean mechanism for the client to determine
             which methods are not going to be implemented. This allows
             clients to present request
             or response. An entity consists of meta-information in the appropriate user interface. For
             example, if seeking is not allowed,
             form of entity-header fields and content in the user interface must
             be able form of an
             entity-body, as described in Section 8.

        Feature-tag: A tag representing a certain set of functionality,
             i.e. a feature.

        Live: Normally used to disallow moving describe a sliding position indicator.

        An earlier requirement presentation or session with    |
             media coming from ongoing event. This generally results in RTSP was multi-client capability.
        However, it was determined   |
             that the session has a better approach was to
        make sure unbound or only loosely defined       |
             duration, and that the protocol no seek operations are possible.

        Media initialization: Datatype/codec specific initialization.
             This includes such things as clockrates, color tables, etc.
             Any transport-independent information which is easily extensible to the
        multi-client scenario. Stream identifiers can be used required by
        several control streams, so that "passing
             a client for playback of a media stream occurs in the remote" would
        be possible. The protocol would not address how several
        clients negotiate access; this is left media
             initialization phase of stream setup.

        Media parameter: Parameter specific to either a "social
        protocol" media type that may be
             changed before or some other floor control mechanism.

1.6 Extending RTSP

   Since not all during stream playback.

        Media server: The server providing playback services for one or
             more media servers have the same functionality, streams. Different media
   servers by necessity will support streams within a
             presentation may originate from different sets of requests. For
   example:

        o media servers. A
             media server may not be capable of seeking (absolute positioning)
          if it is to support live events only.

        o Some servers may not support setting stream parameters and
          thus not support GET_PARAMETER and SET_PARAMETER.

   A reside on the same or a different host as
             the web server SHOULD implement all header fields described in Section 13.

   It is up to the creators of presentation descriptions not to ask the
   impossible is invoked from.

        Media server indirection: Redirection of a server. This situation is similar in HTTP/1.1 [26],
   where the methods described in [H19.5] are not likely media client to be supported
   across all servers.

   RTSP can be extended in three ways, listed here in order of the
   magnitude of changes supported:

        o Existing methods can be extended with new parameters, a
             different media server.

        (Media) stream: A single media instance, e.g., an audio stream
             or a video stream as long well as these parameters can be safely ignored by the recipient.
          (This is equivalent to adding new parameters to an HTML tag.)
          If the client needs negative acknowledgement when a method
          extension is not supported, single whiteboard or shared
             application group. When using RTP, a tag corresponding to the
          extension may be added in the Require:  field (see Section
          13.32).

        o New methods can be added. If the recipient stream consists of the message does
          not understand the request, it responds with error code 501
          (Not Implemented) all
             RTP and the sender should not attempt to use
          this method again.  A client may also use the OPTIONS method
          to inquire about methods supported RTCP packets created by a source within an RTP
             session. This is equivalent to the server. The server
          SHOULD list the methods it supports using the Public response
          header.

        o A new version of the protocol can be defined, allowing almost
          all aspects (except the position definition of the protocol version
          number) to change. a DSM-CC
             stream([25]).

        Message: The basic capability discovery mechanism can be used to both discover
   support for unit of RTSP communication, consisting of a certain feature
             structured sequence of octets matching the syntax defined
             in Section 17 and to ensure that transmitted via a feature is
   available when performing connection or a request. For detailed explanation
             connectionless protocol.

        Non-Aggregated Control: Control of this
   see chapter  10.

1.7 Overall Operation

   Each presentation and a single media stream stream.  Only
             possible in RTSP sessions with a single media.

        Participant: Member of a conference. A participant may be identified by a RTSP URL.
   The overall presentation and the properties
             machine, e.g., a playback server.

        Presentation: A set of one or more streams presented to the
             client as a complete media the
   presentation is made up of are defined by feed, using a presentation
             description
   file, the format of which is outside the scope of this specification.
   The presentation description file may be obtained by the client using
   HTTP or other means such as email and may not necessarily be stored
   on the media server.

   For defined below. In most cases in the purposes of RTSP
             context, this specification, a implies aggregate control of those streams,
             but does not have to.

        Presentation description: A presentation description is
   assumed to describe contains
             information about one or more presentations, each of which
   maintains media streams within a common time axis. For simplicity
             presentation, such as the set of exposition encodings, network
             addresses and
   without loss of generality, it is assumed that information about the presentation
   description contains exactly one content. Other IETF
             protocols such as SDP (RFC 2327 [2]) use the term "session"
             for a presentation. A presentation
   may contain several media streams. The presentation description file contains a description of the media
   streams making up the presentation, may take
             several different formats, including their encodings,
   language, and other parameters that enable the client but not limited to choose the
   most appropriate combination of media. In this presentation
   description, each media stream that is individually controllable by
             session description format SDP.

        Response: A RTSP is identified by a RTSP URL, which points to the media server
   handling response. If an HTTP response is meant, that particular media stream and names the stream stored on is
             indicated explicitly.

        Request: A RTSP request. If an HTTP request is meant, that server. Several media streams can be located on different
   servers; for example, audio and video streams can be split across
   servers for load sharing. The description also enumerates which
   transport methods the server is capable of.

   Besides the media parameters, the network destination address and
   port need to be determined. Several modes of operation can be
   distinguished:

        Unicast:
             indicated explicitly.

        Request URL: The media is transmitted URL used in a request to indicate the source of resource   |
             which the request shall be performed on.

        RTSP
             request, with the port number chosen by the client.
             Alternatively, the media is transmitted on the same
             reliable stream as RTSP.

        Multicast, server chooses address: The media server picks session: A stateful abstraction upon which the
             multicast address and port. This main control
             methods of RTSP operate. A RTSP session is the typical case for a
             live or near-media-on-demand transmission.

        Multicast, client chooses address: If the server entity;
             it is to
             participate in an existing multicast conference, the
             multicast address, port created, maintained and encryption key are given destroyed by the
             conference description, server. It
             is established by means outside the
             scope of this specification.

1.8 RTSP States

   RTSP controls a stream which may be sent via a separate protocol,
   independent of the control channel. For example, RTSP control may
   occur on a TCP connection while server upon the data flows via UDP. Thus, data
   delivery continues even if no RTSP requests are received completion of a
             successful SETUP request (when 200 OK response is sent) and
             is labelled by the media
   server. Also, during its lifetime, a single media stream may be
   controlled session identifier at that time. The
             session exists until timed out by RTSP requests issued sequentially on different TCP
   connections. Therefore, the server needs to maintain "session state"
   to be able to correlate or explicitly
             removed by a TEARDOWN request. A RTSP requests with session is also a stream. The
             stateful entity; a RTSP server maintains an explicit
             session state machine (see Appendix  A) where most state
             transitions are described in Appendix A.

   Many methods in RTSP do not contribute to state. However, the
   following play triggered by client requests. The existence
             of a central role in defining session implies the allocation and usage existence of
   stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, PING
   and TEARDOWN.

        SETUP: Causes state about the server to allocate resources for a stream
             session's media streams and
             create a RTSP session.

        PLAY: Starts data transmission on a stream allocated via SETUP.

        PAUSE: Temporarily halts a stream without freeing server
             resources.

        REDIRECT: Indicates that the session should be moved to new
             server / location

        PING: Prevents the identified their respective transport
             mechanisms. A given session from being timed out.

        TEARDOWN: Frees resources can have zero or more media
             streams associated with the stream.  The it. A RTSP server uses the session ceases
             to exist on aggregate control over multiple media streams.

        Transport initialization: The negotiation of transport
             information (e.g., port numbers, transport protocols)
             between the client and the server.

        URI: Universal Resource Identifier, see RFC 2396 [12]. In RTSP methods that contribute to state use    |
             the Session header field
   (Section 13.37) to identify used URIs are as general rule in fact URL's as they      |
             gives an location for the resource. Therefore although RTSP session whose state  |
             URLs are a subset of URIs, they will be refered as URLs.     |

        URL: Universal Resource Locator, is being
   manipulated. The server generates session identifiers in response to
   SETUP requests (Section 11.3).

1.9 Relationship with Other Protocols

   RTSP has an URI which identifies the   |
             resource through its primary access mechanism, rather than   |
             identifying the resource by name or by some overlap in functionality with HTTP. It also may
   interact with HTTP in other            |
             attribute(s) of that resource.

1.5 Protocol Properties

   RTSP has the initial contact with streaming content
   is often to following properties:

        Extendable: New methods and parameters can be made through a web page. The current protocol
   specification aims easily added to allow different hand-off points between a web
   server and the media server implementing
             RTSP. For example, the
   presentation description

        Easy to parse: RTSP can be retrieved using parsed by standard HTTP or RTSP, which
   reduces roundtrips in web-browser-based scenarios, yet also allows
   for standalone MIME
             parsers.

        Secure: RTSP servers and clients which do not rely on HTTP re-uses web security mechanisms, either at
   all. However, RTSP differs fundamentally from HTTP in that most data
   delivery takes place out-of-band in a different protocol. HTTP is an
   asymmetric protocol where the client issues requests and the server
   responds. In RTSP, both
             transport level (TLS, RFC 2246 [26]) or within the media client protocol
             itself. All HTTP authentication mechanisms such as basic
             (RFC 2616 [4]) and media server can issue
   requests. RTSP requests digest authentication (RFC 2617 [7]) are also stateful; they may set parameters
   and continue
             directly applicable.

        Transport-independent: RTSP does not preclude the use of an       |
             unreliable datagram protocol (UDP) (RFC 768 [8]), a          |
             reliable datagram protocol (RDP, RFC 1151, not widely used   |
             [27]) as it would be possible to control implement application-      |
             level reliability. The use of a media stream long after connectionless datagram      |
             protocol such as UDP or RDP requires additional definition   |
             that may be provided as extensions to the request has
   been acknowledged.

        Re-using HTTP functionality has advantages in at least two
        areas, namely security and proxies. core RTSP          |
             specification. The requirements are
        very similar, so having usage of the ability to adopt HTTP work on
        caches, proxies and authentication reliable stream protocol     |
             TCP (RFC 793 [9]) is valuable.

   RTSP assumes the existence what is currently defined as transport  |
             protocol of RTSP messages.

        Multi-server capable: Each media stream within a presentation description format that
             can express both static and temporal properties of reside on a presentation
   containing different server. The client automatically
             establishes several concurrent control sessions with the
             different media streams. Session Description Protocol (SDP)
   [24] servers.  Media synchronization is generally
             performed at the format transport level.

        Separation of choice; however, RTSP stream control and conference initiation:  Stream
             control is not bound to
   it. For data delivery, most real-time media will use RTP as divorced from inviting a
   transport protocol. While RTSP works well with RTP, it is not tied media server to
   RTP.

2 Notational Conventions

   Since many of the definitions and syntax are identical a
             conference. In particular, SIP [28] or H.323 [29] may be
             used to HTTP/1.1,
   this specification only points to the section where they are defined
   rather than copying it. For brevity, [HX.Y] is to be taken to refer
   to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [26]).

   All the mechanisms specified in this document are described in both
   prose and an augmented Backus-Naur form (BNF) similar invite a server to that used in
   [H2.1]. It is described in detail in RFC 2234 [14], with the
   difference that this RTSP specification maintains the "#" notation a conference.

        Suitable for comma-separated lists from [H2.1].

   In this draft, we use indented and smaller-type paragraphs to provide
   background and motivation. This is intended professional applications: RTSP supports frame-
             level accuracy through SMPTE time stamps to give readers who were allow remote
             digital editing.

        Presentation description neutral: The protocol does not involved with the formulation of impose a
             particular presentation description or metafile format and
             can convey the specification an
   understanding type of why things are format to be used. However, the way that they are in RTSP.

3 Protocol Parameters

3.1 RTSP Version

   HTTP Specification Section [H3.1] applies, with HTTP replaced by
   RTSP. This specification defines version 1.0 of RTSP.

3.2
             presentation description must contain at least one RTSP URL
             URL.

        Proxy and firewall friendly: The "rtsp", "rtsps" protocol should be readily       |
             handled by both application and "rtspu" schemes are used transport-layer (SOCKS       |
             [30]) firewalls. A firewall may need to refer understand the       |
             SETUP method to network
   resources via open a "hole" for the media stream.

        HTTP-friendly: Where sensible, RTSP protocol. This section defines reuses HTTP concepts, so
             that the scheme-
   specific syntax and semantics existing infrastructure can be reused. This
             infrastructure includes PICS (Platform for Internet Content
             Selection [31,32]) for associating labels with content.
             However, RTSP URLs. The RTSP URL is case
   sensitive.

   rtsp_URL  =  ( "rtsp:" / "rtspu:" / "rtsps:" )
                "//" host [ ":" port ] [ abs_path [ "?" query ]]
   host      =  As defined by RFC 2732 [30]
   abs_path  =  As defined by RFC 2396 [22]
   port      =  *DIGIT
   query     =  As defined by RFC 2396 [22]
        Note that fragment and query identifiers do does not have a
        well-defined meaning at this time, with the interpretation
        left just add methods to HTTP since the RTSP server.

   The scheme rtsp
             controlling continuous media requires that commands are issued via server state in most
             cases.

        Appropriate server control: If a reliable
   protocol (within the Internet, TCP), while the scheme rtspu
   identifies an unreliable protocol (within the Internet, UDP). The
   scheme rtsps identifies client can start a reliable transport using secure transport,
   perhaps TLS [27]. The rtspu and rtsps is stream, it
             must be able to stop a stream. Servers should not defined start
             streaming to clients in this
   specification, and such a way that clients cannot stop
             the stream.

        Transport negotiation: The client can negotiate the transport
             method prior to actually needing to process a continuous
             media stream.

        Capability negotiation: If basic features are disabled, there
             must be some clean mechanism for future extensions of the protocol client to
   define.

   If determine
             which methods are not going to be implemented. This allows
             clients to present the port appropriate user interface. For
             example, if seeking is empty or not given, port 554 SHALL be assumed. The
   semantics are that allowed, the identified resource can be controlled by RTSP
   at the server listening for TCP (scheme "rtsp") connections or UDP
   (scheme "rtspu") packets on that port of host, and the Request-URI
   for the resource is rtsp_URL.

   The use of IP addresses in URLs SHOULD user interface must
             be avoided whenever possible
   (see RFC 1924 [16]). Note: Using qualified domain names in any URL is
   one able to disallow moving a sliding position indicator.

        An earlier requirement for making it possible for RFC 2326 implementations
   of in RTSP was multi-client capability.
        However, it was determined that a better approach was to use IPv6. This specification
        make sure that the protocol is updated easily extensible to allow for
   literal IPv6 addresses in RTSP URLs using the host specification in
   RFC 2732 [30].

   A presentation or a stream is identified
        multi-client scenario. Stream identifiers can be used by
        several control streams, so that "passing the remote" would
        be possible. The protocol would not address how several
        clients negotiate access; this is left to either a textual "social
        protocol" or some other floor control mechanism.

1.6 Extending RTSP

   Since not all media
   identifier, using servers have the character set and escape conventions [H3.2] same functionality, media
   servers by necessity will support different sets of
   URLs (RFC 2396 [22]). URLs requests. For
   example:

        o A server may refer not be capable of seeking (absolute positioning)
          if it is to a support live events only.

        o Some servers may not support setting stream or an aggregate of
   streams, i.e., a presentation. Accordingly, requests parameters and
          thus not support GET_PARAMETER and SET_PARAMETER.

   A server SHOULD implement all header fields described in Section 11 can apply 14.

   It is up to either the whole creators of presentation or an
   individual stream within descriptions not to ask the
   impossible of a server. This situation is similar in HTTP/1.1 [4],
   where the presentation. Note that some request methods can only be applied to streams, described in [H19.5] are not presentations and vice
   versa.

   For example, the likely to be supported
   across all servers.

   RTSP URL:

     rtsp://media.example.com:554/twister/audiotrack

   identifies the audio stream within can be extended in three ways, listed here in order of the presentation "twister", which
   magnitude of changes supported:

        o Existing methods can be controlled via RTSP requests issued over a TCP connection extended with new parameters, e.g.      |
          headers, as long as these parameters can be safely ignored by   |
          the recipient. (This is equivalent to
   port 554 of host media.example.com

   Also, adding new parameters to  |
          an HTML tag.) If the RTSP URL:

     rtsp://media.example.com:554/twister
   identifies client needs negative acknowledgement      |
          when a method extension is not supported, a tag corresponding   |
          to the presentation "twister", which extension may be composed added in the Require: field (see        |
          Section 14.32).

        o New methods can be added. If the recipient of audio
   and video streams.

        This the message does
          not imply a standard way to reference streams in
        URLs. The presentation description defines the hierarchical
        relationships in understand the presentation request, it responds with error code 501
          (Not Implemented) and the URLs for the
        individual streams. sender should not attempt to use
          this method again.  A presentation description client may name a
        stream "a.mov" and the whole presentation "b.mov".

   The path components of also use the RTSP URL are opaque OPTIONS method
          to the client and do
   not imply any particular file system structure for inquire about methods supported by the server.

        This decoupling also allows presentation descriptions to be
        used with non-RTSP media control protocols simply by
        replacing the scheme in The server
          SHOULD list the URL.

3.3 Session Identifiers

   Session identifiers are strings of any arbitrary length. A session
   identifier MUST be chosen randomly and MUST be at least eight
   characters long to make guessing methods it more difficult. (See Section 17.)

   session-id  =  8*( ALPHA / DIGIT / safe )

3.4 SMPTE Relative Timestamps

   A SMPTE relative timestamp expresses time relative to supports using the start Public response
          header.

        o A new version of the clip. Relative timestamps are expressed as SMPTE time codes for
   frame-level access accuracy. The time code has the format
                  hours:minutes:seconds:frames.subframes,
   with the origin at protocol can be defined, allowing almost
          all aspects (except the start position of the clip. protocol version
          number) to change.

   The default smpte format
   is"SMPTE 30 drop" format, with frame rate is 29.97 frames per second.
   Other SMPTE codes MAY basic capability discovery mechanism can be supported (such as "SMPTE 25") through the
   use of alternative use of "smpte time". used to both discover
   support for a certain feature and to ensure that a feature is
   available when performing a request. For the "frames" field in the
   time value can assume the values 0 through 29. The difference between
   30 detailed explanation of this
   see chapter  10.

1.7 Overall Operation

   Each presentation and 29.97 frames per second media stream is handled identified by dropping the first two
   frame indices (values 00 an RTSP URL.  The
   overall presentation and 01) the properties of every minute, except every tenth
   minute. If the frame value media the presentation
   is zero, it may be omitted. Subframes are
   measured in one-hundredth made up of are defined by a frame.

   smpte-range       =  smpte-type "=" smpte-range-spec
   smpte-range-spec  =  ( smpte-time "-" [ smpte-time ] )
                     /  ( "-" smpte-time )
   smpte-type        =  "smpte" / "smpte-30-drop" / "smpte-25"
                        ; other timecodes may be added
   smpte-time        =  1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT
                        [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ]

   Examples:

     smpte=10:12:33:20-
     smpte=10:07:33-
     smpte=10:07:00-10:07:33:05.01
     smpte-25=10:07:00-10:07:33:05.01

3.5 Normal Play Time

   Normal play time (NPT) indicates the stream absolute position
   relative to presentation description file, the beginning
   format of which is outside the presentation, not to be confused
   with the Network Time Protocol (NTP). The timestamp consists scope of a
   decimal fraction. this specification. The part left of the decimal
   presentation description file may be expressed in
   either seconds obtained by the client using
   HTTP or hours, minutes, other means such as email and seconds. The part right of may not necessarily be stored
   on the
   decimal point measures fractions of a second.

   The beginning media server.

   For the purposes of this specification, a presentation corresponds to 0.0 seconds.  Negative
   values are not defined. The special constant now description is defined as the
   current instant
   assumed to describe one or more presentations, each of which
   maintains a live event. It MAY only be used for live events, common time axis. For simplicity of exposition and SHALL NOT be used for on-demand content.

   NPT is defined as in DSM-CC: "Intuitively, NPT
   without loss of generality, it is assumed that the clock the
   viewer associates with a program. It is often digitally displayed on
   a VCR. NPT advances normally when in normal play mode (scale = 1),
   advances at presentation
   description contains exactly one such presentation. A presentation
   may contain several media streams.

   The presentation description file contains a faster rate when in fast scan forward (high positive
   scale ratio), decrements when in scan reverse (high negative scale
   ratio) description of the media
   streams making up the presentation, including their encodings,
   language, and other parameters that enable the client to choose the
   most appropriate combination of media. In this presentation
   description, each media stream that is fixed in pause mode. NPT individually controllable by
   RTSP is (logically) equivalent identified by a RTSP URL, which points to
   SMPTE time codes." [5]

   npt-range       =  ["npt" "="] npt-range-spec
                      ; implementations SHOULD use npt= prefix, but SHOULD
                      ; the media server
   handling that particular media stream and names the stream stored on
   that server. Several media streams can be prepared to interoperate with RFC 2326
                      ; implementations which don't use it
   npt-range-spec  =  ( npt-time "-" [ npt-time ] ) / ( "-" npt-time )
   npt-time        =  "now" / npt-sec / npt-hhmmss
   npt-sec         =  1*DIGIT [ "." *DIGIT ]
   npt-hhmmss      =  npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
   npt-hh          =  1*DIGIT ; any positive number
   npt-mm          =  1*2DIGIT ; 0-59
   npt-ss          =  1*2DIGIT ; 0-59

   Examples:

     npt=123.45-125
     npt=12:05:35.3-
     npt=now- located on different
   servers; for example, audio and video streams can be split across
   servers for load sharing. The syntax conforms description also enumerates which
   transport methods the server is capable of.

   Besides the media parameters, the network destination address and
   port need to ISO 8601. be determined. Several modes of operation can be
   distinguished:

        Unicast: The npt-sec notation media is
        optimized for automatic generation, transmitted to the ntp-hhmmss notation
        for consumption source of the RTSP
             request, with the port number chosen by human readers. The "now" constant allows
        clients to request to receive the live feed rather than client.
             Alternatively, the
        stored or time-delayed version. This is needed since
        neither absolute time nor zero time are appropriate for
        this case.

3.6 Absolute Time

   Absolute time media is expressed transmitted on the same
             reliable stream as ISO 8601 timestamps, using UTC (GMT).
   Fractions of a second may be indicated.

   utc-range       =  "clock" "=" utc-range-spec
   utc-range-spec  =  ( utc-time "-" [ utc-time ] ) / ( "-" utc-time )
   utc-time        =  utc-date "T" utc-time "Z"
   utc-date        =  8DIGIT ; < YYYYMMDD >
   utc-time        =  6DIGIT [ "." fraction ] ; < HHMMSS.fraction >
   fraction        =  1*DIGIT

   Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
   UTC:

     19961108T143720.25Z

3.7 Feature-tags

   Feature-tags are unique identifiers used to designate features in RTSP. These tags are used in Require (Section 13.32), Proxy-Require
   (Section 13.27), Unsupported (Section 13.41), and Supported (Section
   13.38) header fields.

   Syntax:

   feature-tag  =  token

   Feature tag needs to indicate if they apply to servers only, proxies   |
   only, or both

        Multicast, server and proxies. chooses address: The creator of a new RTSP feature-tag should either prefix media server picks the
   feature-tag with a reverse domain name (e.g., "com.foo.mynewfeature"
             multicast address and port. This is an apt name the typical case for a feature whose inventor can be reached at
   "foo.com"),
             live or register the new feature-tag with near-media-on-demand transmission.

        Multicast, client chooses address: If the Internet
   Assigned Numbers Authority (IANA), see IANA Section  18.

4 RTSP Message

   RTSP server is a text-based protocol and uses the ISO 10646 character set in
   UTF-8 encoding (RFC 2279 [18]). Lines are terminated by CRLF, but
   receivers should be prepared to also interpret CR and LF by
   themselves as line terminators.

        Text-based protocols make it easier to add optional
        parameters
             participate in a self-describing manner. Since an existing multicast conference, the number of
        parameters
             multicast address, port and encryption key are given by the frequency
             conference description, established by means outside the
             scope of commands is low, processing
        efficiency is not this specification.

1.8 RTSP States

   RTSP controls a concern. Text-based protocols, if done
        carefully, also allow easy implementation stream which may be sent via a separate protocol,
   independent of research
        prototypes in scripting languages such as Tcl, Visual Basic
        and Perl.

   The 10646 character set avoids tricky character set switching, but is
   invisible to the application as long as US-ASCII is being used.  This
   is also the encoding used for RTCP. ISO 8859-1 translates directly
   into Unicode with control channel. For example, RTSP control may
   occur on a high-order octet of zero. ISO 8859-1 characters
   with TCP connection while the most-significant bit set are represented as 1100001x
   10xxxxxx. (See RFC 2279 [18]) data flows via UDP. Thus, data
   delivery continues even if no RTSP messages can requests are received by the media
   server. Also, during its lifetime, a single media stream may be carried over any lower-layer transport protocol
   that is 8-bit clean.
   controlled by RTSP messages are vulnerable requests issued sequentially on different TCP
   connections. Therefore, the server needs to bit errors and
   SHOULD NOT be subjected maintain "session state"
   to them.

   Requests contain methods, the object the method is operating upon and
   parameters be able to further describe the method. Methods are idempotent,
   unless otherwise noted. Methods correlate RTSP requests with a stream. The state
   transitions are also designed described in Appendix A.

   Many methods in RTSP do not contribute to require little
   or no state maintenance at state. However, the media server.

4.1 Message Types

   See [H4.1].

4.2 Message Headers

   See [H4.2].

4.3 Message Body

   See [H4.3]

4.4 Message Length

   When a message body is included with
   following play a message, central role in defining the length of that
   body is determined by one allocation and usage of
   stream resources on the following (in order of precedence):

        1.   Any response message which MUST NOT include a message body
             (such as server: SETUP, PLAY, PAUSE, REDIRECT, PING
   and TEARDOWN.

        SETUP: Causes the 1xx, 204, server to allocate resources for a stream and 304 responses) is always
             terminated by
             create a RTSP session.

        PLAY: Starts data transmission on a stream allocated via SETUP.

        PAUSE: Temporarily halts a stream without freeing server
             resources.

        REDIRECT: Indicates that the first empty line after session should be moved to new
             server / location

        PING: Prevents the header fields,
             regardless of identified session from being timed out.

        TEARDOWN: Frees resources associated with the entity-header fields present in stream.  The RTSP
             session ceases to exist on the
             message. (Note: An empty line consists of only CRLF.)

        2.   If a Content-Length server.

   RTSP methods that contribute to state use the Session header field (section 13.14)
   (Section 14.37) to identify the RTSP session whose state is
             present, its value being
   manipulated. The server generates session identifiers in bytes represents the length of response to
   SETUP requests (Section 11.3).

1.9 Relationship with Other Protocols

   RTSP has some overlap in functionality with HTTP. It also may
   interact with HTTP in that the
             message-body. If this header field initial contact with streaming content
   is not present, often to be made through a value
             of zero is assumed.

   Note that web page. The current protocol
   specification aims to allow different hand-off points between a web
   server and the media server implementing RTSP. For example, the
   presentation description can be retrieved using HTTP or RTSP, which
   reduces roundtrips in web-browser-based scenarios, yet also allows
   for standalone RTSP does servers and clients which do not (at present) support rely on HTTP at
   all. However, RTSP differs fundamentally from HTTP in that most data
   delivery takes place out-of-band in a different protocol. HTTP is an
   asymmetric protocol where the HTTP/1.1 "chunked"
   transfer coding(see [H3.6.1]) client issues requests and requires the presence of the
   Content-Length header field.

        Given the moderate length of presentation descriptions
        returned, server
   responds. In RTSP, both the media client and media server should always be able can issue
   requests. RTSP requests are also stateful; they may set parameters
   and continue to determine its
        length, even if it is generated dynamically, making control a media stream long after the
        chunked transfer encoding unnecessary.

5 General Header Fields

   See [H4.5], except that Pragma, Trailer, Transfer-Encoding, Upgrade, request has
   been acknowledged.

        Re-using HTTP functionality has advantages in at least two
        areas, namely security and Warning headers proxies. The requirements are not defined.
        very similar, so having the ability to adopt HTTP work on
        caches, proxies and authentication is valuable.

   RTSP further defines assumes the CSeq, existence of a presentation description format that
   can express both static and Timestamp:

   general-header  =  Cache-Control  ; Section 13.9
                   /  Connection     ; Section 13.10
                   /  CSeq           ; Section 13.17
                   /  Date           ; Section 13.18
                   /  Timestamp      ; Section 13.39
                   /  Via            ; Section 13.44

6 Request

   A request message from temporal properties of a client presentation
   containing several media streams. Session Description Protocol (SDP)
   [2] is generally the format of choice; however, RTSP is not bound to
   it. For data delivery, most real-time media will use RTP as a server or vice versa includes,
   within
   transport protocol. While RTSP works well with RTP, it is not tied to
   RTP.

2 RTSP Use Cases
   This section describes some of the first line use cases RTSP can be used for.     |
   They are listed in descending order of importance in regards to        |
   ensuring that message, all necessary functionality is present.                  |

   TODO: Fill this headings with descriptions of the method use cases.           |

2.1 On-demand Playback of Stored Content                                  |

2.2 Unicast distribution of Live Content                                  |

2.3 Inviting RTSP on-demand servers into a multicast group                |

2.4 On-demand Playback using Multicast                                    |

3 Protocol Parameters

3.1 RTSP Version

   HTTP Specification Section [H3.1] applies, with HTTP replaced by
   RTSP. This specification defines version 1.0 of RTSP.

3.2 RTSP URL

   The "rtsp", "rtsps" and "rtspu" schemes are used to be applied refer to network
   resources via the resource, the identifier of RTSP protocol. This section defines the resource, scheme-
   specific syntax and semantics for RTSP URLs. The RTSP URL is case
   sensitive.

   Informative RTSP URL syntax:

   rtsp[u|s]://host[:port]/abspath[?query]#fragment

   See section  17.2.1 for the protocol
   version in use.

   Request  =   Request-Line      ; Section 6.1
            *(  general-header    ; Section 5
            /   request-header    ; Section 6.2
            /   entity-header )   ; Section 8.1
                CRLF
                [ message-body ]  ; Section 4.3

6.1 Request Line

   Request-Line  =  Method SP Request-URI SP RTSP-Version CRLF

   Method  =  "DESCRIBE"        ; Section 11.2
           /  "GET_PARAMETER"   ; Section 11.7
           /  "OPTIONS"         ; Section 11.1
           /  "PAUSE"           ; Section 11.5
           /  "PLAY"            ; Section 11.4
           /  "PING"            ; Section 11.10
           /  "REDIRECT"        ; Section 11.9
           /  "SETUP"           ; Section 11.3
           /  "SET_PARAMETER"   ; Section 11.8
           /  "TEARDOWN"        ; Section 11.6
           /  extension-method

   extension-method  =  token
   Request-URI       =  "*" / absolute_URI
   RTSP-Version      =  "RTSP" "/" 1*DIGIT "." 1*DIGIT

6.2 Request Header Fields
   request-header  =  Accept             ; Section 13.1
                   /  Accept-Encoding    ; Section 13.2
                   /  Accept-Language    ; Section 13.3
                   /  Authorization      ; Section 13.6
                   /  Bandwidth          ; Section 13.7
                   /  Blocksize          ; Section 13.8
                   /  From               ; Section 13.20
                   /  If-Modified-Since  ; Section 13.23
                   /  Proxy-Require      ; Section 13.27
                   /  Range              ; Section 13.29
                   /  Referer            ; Section 13.30
                   /  Require            ; Section 13.32
                   /  Scale              ; Section 13.34
                   /  Session            ; Section 13.37
                   /  Speed              ; Section 13.35
                   /  Supported          ; Section 13.38
                   /  Transport          ; Section 13.40
                   /  User-Agent         ; Section 13.42

   Note that in contrast to HTTP/1.1 [26], RTSP requests always contain formal definition of the absolute RTSP URL (that is, including the scheme, host syntax.

        Note that fragment and port)
   rather than just query identifiers do not have a
        well-defined meaning at this time, i.e. their usage is
        unspecified, with the absolute path.

        HTTP/1.1 requires servers interpretation left to understand the absolute URL,
        but clients RTSP
        server.

   The URL scheme rtsp requires that commands are supposed issued via a reliable
   protocol (within the Internet, TCP), while the scheme rtspu is
   intended to use identify RTSP over an unreliable protocol (within the Host request header.
        This
   Internet, UDP). The scheme rtsps is purely needed for backward-compatibility with
        HTTP/1.0 servers, a consideration that does not apply intended to
        RTSP. identify a reliable
   transport using secure transport, perhaps TLS [26]. The asterisk "*" rtspu and
   rtsps is not defined in this specification, and are for future
   extensions of the Request-URI means that the request does not
   apply protocol to a particular resource, but define how to use.

   If the server or proxy itself,
   and port is only allowed when the method used does empty or not necessarily apply
   to a resource.

   One example would given, port 554 SHALL be as follows:

     OPTIONS * RTSP/1.0

   An OPTIONS in this form will determine assumed. The      |
   semantics are that the capabilities of identified resource can be controlled by RTSP   |
   at the server listening for TCP (scheme "rtsp") connections or the proxy UDP     |
   (scheme "rtspu") packets on that first receives port of host, and the request. If one needs to address Request-URL     |
   for the server explicitly, then one should use an absolute URL with resource is rtsp_URL. For the
   server's address.

     OPTIONS rtsp://example.com RTSP/1.0

7 Response

   [H6] applies except that HTTP-Version scheme rtsps the TCP and UDP     |
   port 322 is replaced by RTSP-Version.
   Also, RTSP defines additional status codes registered and does not define some
   HTTP codes. SHALL be assumed.

   The valid response codes and the methods they can use of IP addresses in URLs SHOULD be used
   with are defined avoided whenever possible
   (see RFC 1924 [10]). Note: Using qualified domain names in Table 1.

   After receiving and interpreting a request message, the recipient
   responds with an RTSP response message.

   Response  =   Status-Line       ; Section 7.1
             *(  general-header    ; Section 5
             /   response-header   ; Section 7.1.2
             /   entity-header )   ; Section 8.1
                 CRLF
                 [ message-body ]  ; Section 4.3

7.1 Status-Line

   The first line of a Response message any URL is the Status-Line, consisting
   one requirement for making it possible for RFC 2326 implementations
   of RTSP to use IPv6. This specification is updated to allow for
   literal IPv6 addresses in RTSP URLs using the protocol version followed host specification in
   RFC 2732 [11].

   A presentation or a stream is identified by a numeric status code, and the textual phrase associated with media
   identifier, using the status code, with each element
   separated by SP characters. No CR character set and escape conventions [H3.2] of
   URLs (RFC 2396 [12]). URLs may refer to a stream or LF is allowed except an aggregate of
   streams, i.e., a presentation. Accordingly, requests described in
   Section 11 can apply to either the
   final CRLF sequence.

   Status-Line  =  RTSP-Version SP Status-Code SP Reason-Phrase CRLF

7.1.1 Status Code whole presentation or an
   individual stream within the presentation. Note that some request
   methods can only be applied to streams, not presentations and Reason Phrase

   The Status-Code element is vice
   versa.

   For example, the RTSP URL:

     rtsp://media.example.com:554/twister/audiotrack

   identifies the audio stream within the presentation "twister", which
   can be controlled via RTSP requests issued over a 3-digit integer result code TCP connection to
   port 554 of host media.example.com

   Also, the
   attempt to understand and satisfy RTSP URL:

     rtsp://media.example.com:554/twister

   identifies the request. These codes are fully
   defined presentation "twister", which may be composed of audio
   and video streams.

        This does not imply a standard way to reference streams in Section 12.
        URLs. The Reason-Phrase is intended to give a short
   textual presentation description of defines the Status-Code. The Status-Code is intended
   for use by automata hierarchical
        relationships in the presentation and the Reason-Phrase is intended URLs for the human
   user. The client is not required to examine or display
        individual streams. A presentation description may name a
        stream "a.mov" and the Reason-
   Phrase. whole presentation "b.mov".

   The first digit path components of the Status-Code defines RTSP URL are opaque to the class of response. The
   last two digits client and do
   not have imply any categorization role.  There are 5
   values particular file system structure for the first digit:

        o 1xx: Informational - Request received, continuing process

        o 2xx: Success - The action was successfully received,
          understood, and accepted

        o 3rr: Redirection - Further action must server.

        This decoupling also allows presentation descriptions to be taken
        used with non-RTSP media control protocols simply by
        replacing the scheme in order to
          complete the request

        o 4xx: Client Error - The request contains bad syntax or cannot URL.

3.3 Session Identifiers

   Session identifiers are strings of any arbitrary length. A session
   identifier MUST be fulfilled

        o 5xx: Server Error - The server failed chosen randomly and MUST be at least eight
   characters long to fulfill an apparently
          valid request

   The individual values make guessing it more difficult. (See Section 18.)

3.4 SMPTE Relative Timestamps

   A SMPTE relative timestamp expresses time relative to the start of
   the numeric status clip. Relative timestamps are expressed as SMPTE time codes defined for
   RTSP/1.0, and an example set of corresponding Reason-Phrase's, are
   presented below.
   frame-level access accuracy. The reason phrases listed here are only recommended
   -- they may be replaced by local equivalents without affecting time code has the
   protocol. Note that RTSP adopts most HTTP/1.1 [26] status codes and
   adds RTSP-specific status codes starting format
                  hours:minutes:seconds:frames.subframes,
   with the origin at x50 to avoid conflicts the start of the clip. The default smpte format
   is"SMPTE 30 drop" format, with newly defined HTTP status codes.

        Status-Code  =  "100" ; Continue
                     /  "200" ; OK
                     /  "201" ; Created
                     /  "250" ; Low on Storage Space
                     /  "300" ; Multiple Choices
                     /  "301" ; Moved Permanently
                     /  "302" ; Moved Temporarily
                     /  "303" ; See frame rate is 29.97 frames per second.
   Other
                     /  "304" ; Not Modified
                     /  "305" ; Use Proxy
                     /  "350" ; Going Away
                     /  "351" ; Load Balancing
                     /  "400" ; Bad Request
                     /  "401" ; Unauthorized
                     /  "402" ; Payment Required
                     /  "403" ; Forbidden
                     /  "404" ; Not Found
                     /  "405" ; Method Not Allowed
                     /  "406" ; Not Acceptable
                     /  "407" ; Proxy Authentication Required
                     /  "408" ; Request Time-out
                     /  "410" ; Gone
                     /  "411" ; Length Required
                     /  "412" ; Precondition Failed
                     /  "413" ; Request Entity Too Large
                     /  "414" ; Request-URI Too Large
                     /  "415" ; Unsupported Media Type
                     /  "451" ; Parameter Not Understood
                     /  "452" ; reserved
                     /  "453" ; Not Enough Bandwidth
                     /  "454" ; Session Not Found
                     /  "455" ; Method Not Valid in This State
                     /  "456" ; Header Field Not Valid for Resource
                     /  "457" ; Invalid Range
                     /  "458" ; Parameter Is Read-Only
                     /  "459" ; Aggregate operation not allowed
                     /  "460" ; Only aggregate operation allowed
                     /  "461" ; Unsupported transport
                     /  "462" ; Destination unreachable

                        /  "500"                     ; Internal Server Error
                        /  "501"                     ; Not Implemented
                        /  "502"                     ; Bad Gateway
                        /  "503"                     ; Service Unavailable
                        /  "504"                     ; Gateway Time-out
                        /  "505"                     ; RTSP Version not supported
                        /  "551"                     ; Option not supported
                        /  extension-code
        extension-code  =  3DIGIT
        Reason-Phrase   =  *<TEXT, excluding CR, LF>

   RTSP status SMPTE codes are extensible. RTSP applications are not required
   to understand MAY be supported (such as "SMPTE 25") through the meaning
   use of all registered status codes, though such
   understanding is obviously desirable. However, applications MUST
   understand the class alternative use of any status code, as indicated by "smpte time". For the first
   digit, and treat any unrecognized response as being equivalent to "frames" field in the
   x00 status code of that class, with
   time value can assume the exception that an
   unrecognized response MUST NOT be cached. For example, if an
   unrecognized status code of 431 values 0 through 29. The difference between
   30 and 29.97 frames per second is received handled by dropping the client, it can
   safely assume that there was something wrong with its request first two
   frame indices (values 00 and
   treat 01) of every minute, except every tenth
   minute. If the response as if frame value is zero, it had received may be omitted. Subframes are
   measured in one-hundredth of a 400 status code. In such
   cases, user agents SHOULD present to the user the entity returned
   with the response, since that entity is likely to include human-
   readable information which will explain the unusual status.

7.1.2 Response Header Fields

   The response-header fields allow frame.

   Examples:

     smpte=10:12:33:20-
     smpte=10:07:33-
     smpte=10:07:00-10:07:33:05.01
     smpte-25=10:07:00-10:07:33:05.01

3.5 Normal Play Time

   Normal play time (NPT) indicates the request recipient stream absolute position
   relative to pass
   additional information about the response which cannot be placed in the Status-Line. These header fields give information about beginning of the
   server and about further access presentation, not to the resource identified by the
   Request-URI.

   response-header  =  Accept-Ranges       ; Section
   13.4
                    /  Location            ; Section 13.25
                    /  Proxy-Authenticate  ; Section 13.26
                    /  Public              ; Section 13.28
                    /  Range               ; Section 13.29
                    /  Retry-After         ; Section 13.31
                    /  RTP-Info            ; Section 13.33
                    /  Scale               ; Section 13.34
                    /  Session             ; Section 13.37
                    /  Server              ; Section 13.36
                    /  Speed               ; Section 13.35
                    /  Transport           ; Section 13.40
                    /  Unsupported         ; Section 13.41
                    /  Vary                ; Section 13.43
                    /  WWW-Authenticate    ; Section 13.45

   Response-header field names can be extended reliably only in
   combination confused
   with the Network Time Protocol (NTP). The timestamp consists of a change in
   decimal fraction. The part left of the protocol version. However, new or
   experimental header fields MAY decimal may be given the semantics of response-
   header fields if all parties expressed in
   either seconds or hours, minutes, and seconds. The part right of the communication recognize them
   decimal point measures fractions of a second.

   The beginning of a presentation corresponds to
   be response-header fields. Unrecognized header fields 0.0 seconds.  Negative
   values are treated as
   entity-header fields.

8 Entity

   Request and Response messages MAY transfer an entity if not otherwise
   restricted by defined. The special constant now is defined as the request method or response status code. An entity
   consists
   current instant of entity-header fields and an entity-body, although some
   responses will a live type event. It MAY only include the entity-headers.

   In this section, both sender be used for live
   type events, and recipient refer to either SHALL NOT be used for on-demand content.

   NPT is defined as in DSM-CC: "Intuitively, NPT is the client
   or clock the server, depending
   viewer associates with a program. It is often digitally displayed on who sends
   a VCR. NPT advances normally when in normal play mode (scale = 1),
   advances at a faster rate when in fast scan forward (high positive
   scale ratio), decrements when in scan reverse (high negative scale
   ratio) and who receives the entity.

8.1 Entity Header Fields

   Entity-header fields define optional meta-information about the
   entity-body or, if no body is present, about fixed in pause mode. NPT is (logically) equivalent to
   SMPTE time codes." [25]

   Examples:

     npt=123.45-125
     npt=12:05:35.3-
     npt=now-

        The syntax conforms to ISO 8601. The npt-sec notation is
        optimized for automatic generation, the resource identified ntp-hhmmss notation
        for consumption by human readers. The "now" constant allows
        clients to request to receive the request.

   entity-header     =  Allow             ; Section 13.5
          Code  Reason                            Method
          _______________________________________________________
          100   Continue                          all

_______________________________________________________
          200   OK                                all
          201   Created                           RECORD
          250   Low on Storage Space              RECORD
          _______________________________________________________
          300   Multiple Choices                  all
          301   Moved Permanently                 all
          302   Found                             all
          303   See Other                         all
          305   Use Proxy                         all
          350   Going Away                        all
          351   Load Balancing                    all

_______________________________________________________
          400   Bad Request                       all
          401   Unauthorized                      all
          402   Payment Required                  all
          403   Forbidden                         all
          404   Not Found                         all
          405   Method Not Allowed                all
          406   Not Acceptable                    all
          407   Proxy Authentication Required     all
          408   Request Timeout                   all
          410   Gone                              all
          411   Length Required                   all
          412   Precondition Failed               DESCRIBE, SETUP
          413   Request Entity Too Large          all
          414   Request-URI Too Long              all
          415   Unsupported Media Type            all
          451   Parameter Not Understood          SET_PARAMETER
          452   reserved                          n/a
          453   Not Enough Bandwidth              SETUP
          454   Session Not Found                 all
          455   Method Not Valid In live feed rather than the
        stored or time-delayed version. This State    all
          456   Header Field Not Valid            all
          457   Invalid Range                     PLAY, PAUSE
          458   Parameter Is Read-Only            SET_PARAMETER
          459   Aggregate Operation Not Allowed   all
          460   Only Aggregate Operation Allowed  all
          461 is needed since
        neither absolute time nor zero time are appropriate for
        this case.

3.6 Absolute Time

   Absolute time is expressed as ISO 8601 timestamps, using UTC (GMT).
   Fractions of a second may be indicated.

   Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
   UTC:

     19961108T143720.25Z

3.7 Feature-tags

   Feature-tags are unique identifiers used to designate features in
   RTSP. These tags are used in Require (Section 14.32), Proxy-Require
   (Section 14.27), Unsupported Transport             all
          462   Destination Unreachable           all
          _______________________________________________________
          500   Internal Server Error             all
          501   Not Implemented                   all
          502   Bad Gateway                       all
          503   Service Unavailable               all
          504   Gateway Timeout                   all
          505   RTSP Version Not Supported        all
   Table 1: Status codes (Section 14.41), and their usage with RTSP methods

                     /  Content-Base      ; Section 13.11
                     /  Content-Encoding  ; Section 13.12
                     /  Content-Language  ; Section 13.13
                     /  Content-Length    ; Section 13.14
                     /  Content-Location  ; Section 13.15
                     /  Content-Type      ; Section 13.16
                     /  Expires           ; Section 13.19
                     /  Last-Modified     ; Section 13.24
                     /  extension-header
   extension-header  =  message-header

   The extension-header mechanism allows additional entity-header fields Supported (Section
   14.38) header fields.

   Feature tag needs to be defined without changing the protocol, but these fields cannot
   be assumed indicate if they apply to be recognizable by the recipient. Unrecognized header
   fields SHOULD be ignored by the recipient servers only, proxies
   only, or both server and forwarded by proxies.

8.2 Entity Body

   See [H7.2] with the addition that

   The creator of a new RTSP message feature-tag should either prefix the         |
   feature-tag with a reverse domain name (e.g.,                          |
   "com.example.mynewfeature" is an entity body
   MUST include apt name for a Content-Type header.

9 Connections

   RTSP requests feature whose          |
   inventor can be transmitted in several different ways:

        o persistent transport connections used for several request-
          response transactions;

        o one connection per request/response transaction;

        o connectionless mode.

   The type of transport connection is defined by the RTSP URI (Section
   3.2). For reached at "example.com"), or register the scheme "rtsp", a connection is assumed, while new         |
   feature-tag with the
   scheme "rtspu" calls for Internet Assigned Numbers Authority (IANA), see   |
   IANA Section  19.

4 RTSP requests to be sent without setting up
   a connection.

   Unlike HTTP, Message

   RTSP allows is a text-based protocol and uses the media server to send requests ISO 10646 character set in
   UTF-8 encoding (RFC 2279 [13]). Lines are terminated by CRLF, but
   receivers should be prepared to the
   media client. However, this is only supported for persistent
   connections, also interpret CR and LF by
   themselves as line terminators.

        Text-based protocols make it easier to add optional
        parameters in a self-describing manner. Since the media server otherwise has no reliable way number of
   reaching the client.  Also, this is
        parameters and the only way that requests from
   media server to client are likely to traverse firewalls.

9.1 Pipelining
   A client that supports persistent connections or connectionless mode
   MAY "pipeline" its requests (i.e., send multiple requests without
   waiting for each response). A server MUST send its responses to those
   requests frequency of commands is low, processing
        efficiency is not a concern. Text-based protocols, if done
        carefully, also allow easy implementation of research
        prototypes in the same order that the requests were received.

9.2 Reliability scripting languages such as Tcl, Visual Basic
        and Acknowledgements                                      | Perl.

   The transmission of RTSP over UDP was optionally 10646 character set avoids tricky character set switching, but is
   invisible to implement and      |
   specified in RFC 2326. However that definition was not satisfactory    | the application as long as US-ASCII is being used.  This
   is also the encoding used for interoperable implementations. Due to lack RTCP. ISO 8859-1 translates directly
   into Unicode with a high-order octet of interest, this       |
   specification does not specify how RTSP over UDP shall be              |
   implemented. However to maintain backwards compatibility in zero. ISO 8859-1 characters
   with the        |
   message format certain RTSP headers must be maintained.  These         |
   mechanism are described below. The next section Unreliable Transport   |
   (section  9.3) provides documentation of certain features that most-significant bit set are     |
   necessary for transport protocols like UDP.                            |

   Any RTSP request according to this specification SHALL NOT be sent to  |
   a multicast address. Any represented as 1100001x
   10xxxxxx. (See RFC 2279 [13])

   RTSP request SHALL messages can be acknowledged. If a      |
   reliable carried over any lower-layer transport protocol
   that is used 8-bit clean. RTSP messages are vulnerable to carry RTSP, requests MUST bit errors and
   SHOULD NOT   | be retransmitted; subjected to them.

   Requests contain methods, the RTSP application MUST instead rely on object the        |
   underlying transport method is operating upon and
   parameters to provide reliability.                           |

        If both further describe the underlying reliable transport such as TCP and    | method. Methods are idempotent,
   unless otherwise noted. Methods are also designed to require little
   or no state maintenance at the RTSP application retransmit requests, it media server.

4.1 Message Types

   See [H4.1].

4.2 Message Headers
   See [H4.2].

4.3 Message Body

   See [H4.3]

4.4 Message Length

   When a message body is possible     | included with a message, the length of that each packet loss results in two retransmissions. The    |
        receiver cannot typically take advantage
   body is determined by one of the              |
        application-layer retransmission since the transport stack   |
        will not deliver following (in order of precedence):

        1.   Any response message which MUST NOT include a message body
             (such as the application-layer retransmission        |
        before 1xx, 204, and 304 responses) is always
             terminated by the first attempt has reached empty line after the receiver. If header fields,
             regardless of the    |
        packet loss is caused by congestion, multiple                |
        retransmissions at different layers will exacerbate entity-header fields present in the      |
        congestion.                                                  |

   Each request carries
             message. (Note: An empty line consists of only CRLF.)

        2.   If a sequence number Content-Length header field (section 14.14) is
             present, its value in bytes represents the CSeq header (Section     |
   13.17), which MUST be incremented by one for each distinct request     |
   transmitted to length of the destination end-point.  The initial sequence        |
   number MAY be chosen arbitrary, but is RECOMMENDED to begin with 0.    |
             message-body. If a request this header field is repeated because not present, a value
             of lack zero is assumed.

   Note that RTSP does not (at present) support the HTTP/1.1 "chunked"
   transfer coding(see [H3.6.1]) and requires the presence of acknowledgement, the       |
   request MUST carry
   Content-Length header field.

        Given the original sequence number (i.e., moderate length of presentation descriptions
        returned, the sequence    |
   number server should always be able to determine its
        length, even if it is generated dynamically, making the
        chunked transfer encoding unnecessary.

5 General Header Fields

   See [H4.5], except that Pragma, Trailer, Transfer-Encoding, Upgrade,
   and Warning headers are not incremented).                                            |

9.3 Unreliable Transport                                                  |

   This section provides some information to future specification of      | defined. RTSP over unreliable transport.                                        |
   Requests are acknowledged by further defines the receiver unless they CSeq,
   and Timestamp. The general headers are sent listed in table 1:

6 Request

   A request message from a client to a server or vice versa includes,    |
   multicast group. If there is no acknowledgement,
   within the sender may first line (Request Line) of that message, the method to    |
   resend
   be applied to the same message after a timeout resource, the identifier of one round-trip time (RTT). the resource, and the    |
   The round-trip time is estimated as
   protocol version in TCP (RFC 1123) [15], with an use. Then follows zero or more headers that can    |
   initial round-trip value
   be of 500 ms. An implementation MAY cache the general (Section 5), request (Section 6.2), or entity (Section   |
   last RTT measurement as
   8.1) type. Then an empty line, i.e. a line with only the initial value for future connections. two           |

   If RTSP is used over a small-RTT LAN, standard procedures for
   characters Carriage Return (CR) and Line Feed (LF), indicates the end  |
   optimizing initial TCP round trip estimates, such as those
                     Header Name    Comment
                     _________________________________
                     Cache-Control  See section 14.9
                     Connection     See section 14.10
                     CSeq           See section 14.17
                     Date           See section 14.18
                     Supported      See section 14.38
                     Timestamp      See section 14.39
                     Via            See section 14.44

   Table 1: The General headers used in     |
   T/TCP (RFC 1644) [19], can be beneficial.                              |

   The Timestamp RTSP.

   of the header (Section 13.39) is used part. Optionally a message body (entity) follows to avoid the              |
   retransmission ambiguity problem [20] and obviates the need for        |
   Karn's algorithm.  |

   If a request is repeated because
   end of lack the message. The length of acknowledgement, the message body is indicated        |
   request must carry the original sequence number (i.e.,
   through the sequence entity headers.                                            |
   number is not incremented).

6.1 Request Line                                                          |

   A number of RTSP packets destined for

   The request line, provides the most important things about the same control end point may   |
   be packed into a single lower-layer PDU or encapsulated into a TCP         |
   stream. RTSP data MAY be interleaved with RTP
   request: What method, on what resources and RTCP packets. using which RTSP version.  |
   The default port for the RTSP server methods that is 554 for UDP.

9.4 defined by this specification can be seen in       |
   Table  6.1. The usage of connections

   Systems implementing RTSP MUST support carrying resource is identified through an absolute RTSP over TCP.  The URL    |
   default port for
   (see section 3.2.

   <Method> SP <Request-URL> SP <RTSP-Version> CRLF

   Please note: The request line's syntax can't be changed in future
   versions of RTSP, as this line indicates the RTSP server is 554 for TCP. A number version of RTSP      |
   packets destined for the same control end point may be encapsulated    |
   into a TCP stream. RTSP data MAY be interleaved with RTP and RTCP      |
   packets. Unlike HTTP, an RTSP message MUST contain a Content-Length    |
   header field whenever that message contains a payload (entity).        |
   Otherwise, an RTSP packet is terminated with an empty line             |
   immediately following the last message header.

   TCP can be used for both persistent connections and for one message
   exchange per connection, as presented above. This section gives
   further rules messages
   and recommendations on how need to handle these connections
   so maximum interoperability and flexibility can be achieved.

   A server SHALL handle both persistent connections and one
   request/response transaction per connection. A persistent connection
   MAY be used for all transactions between the server and client,
   including messages parsable also by older versions.

   Note that in contrast to multiple HTTP/1.1 [4], RTSP sessions. However requests always contain
   the persistent
   connection MAY also be closed after a few message exchanges, e.g. absolute URL (that is, including the
   initial setup scheme, host and play command in a session. Later when port)
   rather than just the client
   wishes absolute path.

        HTTP/1.1 requires servers to send a new request, e.g.  pause, understand the absolute URL,
        but clients are supposed to use the session a new
   connection is opened. Host request header.
        This connection may either be for a single
   message exchange or can be kept open for several messages, i.e.
   persistent.

   A major motivation for allowing non-persistent connections are that
   they ensure fault tolerance. A second one is to allow purely needed for application
   layer mobility. A server and client supporting non-persistent
   connection can survive a loss of a TCP connection, e.g. due to backward-compatibility with
        HTTP/1.0 servers, a NAT
   timeout. When the client has discovered consideration that the TCP connection has
   been lost, it can set up a new one when there is need does not apply to communicate.
        RTSP.

   The client MAY close asterisk "*" in the connection at any time when no outstanding
   request/response transactions exist. The server SHOULD NOT close Request-URL means that the
   connection unless at least one RTSP session timeout period has passed
   without data traffic. A server MUST NOT initiate a close of a
   connection directly after responding request does not
   apply to a TEARDOWN request for particular resource, but to the
   whole session. A server MUST NOT close or proxy itself,
   and is only allowed when the connection as a result of
   responding method used does not necessarily apply
                     Method         Defined In Section
                     _________________________________
                     DESCRIBE       Section 11.2
                     GET_PARAMETER  Section 11.7
                     OPTIONS        Section 11.1
                     PAUSE          Section 11.5
                     PLAY           Section 11.4
                     PING           Section 11.10
                     REDIRECT       Section 11.9
                     SETUP          Section 11.3
                     SET_PARAMETER  Section 11.8
                     TEARDOWN       Section 11.6

   Table 2: The RTSP Methods

   to a request with an error code. Doing this resource.

   One example would prevent
   or result be as follows:

     OPTIONS * RTSP/1.0

   An OPTIONS in extra overhead for this form will determine the client when testing advanced or
   special types capabilities of requests.

   The client SHOULD NOT have more than one connection to the server at
   any given point. If a client
   or the proxy handles multiple RTSP sessions
   on that first receives the same server, it is RECOMMENDED to use only a single
   connection.

   Older services which was implemented according request. If one needs to RFC 2326 sometimes
   requires the client to use persistent connection. The client closing
   the connection may result in that address
   the server removes the session. To
   achieve interoperability with old servers any client is strongly
   RECOMMENDED to use persistent connections.

   A Client is also strongly RECOMMENDED to explicitly, then one should use persistent connections
   as it allows the server to send request to the client.  In cases
   where no connection exist between the server and the client, this may
   cause the server to be forced to drop an absolute URL with the
   server's address.

     OPTIONS rtsp://example.com RTSP/1.0

6.2 Request Header Fields

   The RTSP session without
   notifying the client why,due to the lack of signalling channel. An
   example of such a case is when the server desires to send headers in Table  6.2 can be included in a REDIRECT request for a RTSP session to with the client.

   A server implemented according
   purpose to this specification MUST respond
   that it supports give further define how the "play.basic" feature-tag above. request should be fulfilled. A client MAY
   send a
   request including the Supported header in a request to
   determine support of non-persistent connections. A server supporting
   non-persistent connections will return the "play.basic" feature-tag
   in its response. If the client receives the feature-tag in the
   response, it can MAY also be certain that the server handles non-persistent
   connections.

9.5 Use of IPv6

   This specification has been updated so that it supports IPv6.
   However this support was not present in RFC 2326 therefore some
   interoperability issues exist. A RFC 2326 implementation can support
   IPv6 as long as no explicit IPv6 addresses are used within RTSP
   messages. This require response header, see section  7.1.2.

7 Response

   [H6] applies except that any HTTP-Version is replaced by RTSP-Version.     |
   Also, RTSP URL pointing at a IPv6 host must
   use fully qualified domain name defines additional status codes and does not a IPv6 address.  Further the
   Transport header must not use the parameters source and destination.

   Implementations according to this specification MUST understand IPv6
   addresses define some    |
                   Header             Defined in URLs, Section
                   _____________________________________
                   Accept             Section 14.1
                   Accept-Encoding    Section 14.2
                   Accept-Language    Section 14.3
                   Authorization      Section 14.6
                   Bandwidth          Section 14.7
                   Blocksize          Section 14.8
                   From               Section 14.20
                   If-Match           Section 14.22
                   If-Modified-Since  Section 14.23
                   Proxy-Require      Section 14.27
                   Range              Section 14.29
                   Referer            Section 14.30
                   Require            Section 14.32
                   Scale              Section 14.34
                   Session            Section 14.37
                   Speed              Section 14.35
                   Supported          Section 14.38
                   Transport          Section 14.40
                   User-Agent         Section 14.42

   Table 3: The RTSP request headers

   HTTP codes. The valid response codes and headers. By this requirement the feature-tag
   "play.basic" methods they can be used to determine that  |
   with are defined in Table 4.                                           |

   After receiving and interpreting a server or client is
   capable of handling IPv6 within RTSP.

10 Capability Handling

   This chapter describes request message, the capability handling mechanism available in
   RTSP which allows recipient      |
   responds with an RTSP to be extended. Extensions to this version of
   the protocol are basically done in two ways. First, new headers can
   be added. Secondly, new methods can be added. response message.                                |

7.1 Status-Line                                                           |

   The capability handling
   mechanism is designed to handle these two cases.

   When first line of a method Response message is added the involved parties can use Status-Line, consisting    |
   of the OPTIONS
   method to discover if it is supported. This is done protocol version followed by issuing a
   OPTIONS request to the other party. Depending on numeric status code, and the URL it will
   either apply in regards to a certain media resource,     |
   textual phrase associated with the whole server
   in general, status code, with each element      |
   separated by SP characters. No CR or simply LF is allowed except in the next hop.       |
   final CRLF sequence.                                                   |

   <RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF                |

7.1.1 Status Code and Reason Phrase                                       |

   The OPTIONS response will contain Status-Code element is a Public header which declares all methods supported for 3-digit integer result code of the
   indicated resource.

   It is not necessary        |
   attempt to use OPTIONS understand and satisfy the request. These codes are fully   |
   defined in Section 13. The Reason-Phrase is intended to discover support of give a method, short   |
   the client could simply try the method. If the receiver
   textual description of the Status-Code. The Status-Code is intended    |
   request does not support the method it will respond with an error      |
   code indicating
   for use by automata and the Reason-Phrase is intended for the method human    |
   user. The client is either not implemented (501) required to examine or      |
   does not apply for display the resource (405). Reason-     |
   Phrase.                                                                |

   The choice between first digit of the two      |
   discovery methods depends on Status-Code defines the requirements class of the service.

   To handle functionality additions that are response. The  |
   last two digits do not new methods feature-
   tags have any categorization role.  There are defined. Each feature-tag represents a certain block of
   functionality. The amount of functionality that a feature-tag
   represents can vary significantly. A simple feature-tag can simple
   represent the functionality a single header gives. Another feature-
   tag is "play.basic" which represents the minimal playback
   implementation according to 5      |
   values for the updated specification. first digit:                                            |

        o 1xx: Informational - Request received, continuing process       |

        o 2xx: Success - The feature-tags are then used action was successfully received,            |
          understood, and accepted                                        |

        o 3rr: Redirection - Further action must be taken in order to determine if     |
          complete the client, server request                                            |

        o 4xx: Client Error - The request contains bad syntax or
   proxy supports the functionality that is necessary to achieve the
   desired service. To determine support of a feature-tag several
   different headers can cannot   |
          be used, each explained below:

        Supported: fulfilled                                                    |

        o 5xx: Server Error - The supported header is used server failed to determine fulfill an apparently  |
          valid request                                                   |

   The individual values of the
             complete numeric status codes defined for          |
   RTSP/1.0, and an example set of functionality that both client and server
             has. corresponding Reason-Phrase's, are     |
   presented in table  4. The intended usage is to determine before one needs to
             use a functionality that it is supported. If can reason phrases listed here are only         |
   recommended they may be used in
             any method however OPTIONS is replaced by local equivalents without          |
   affecting the protocol. Note that RTSP adopts most suitable as one HTTP/1.1 [4]        |
   status codes and adds RTSP-specific status codes starting at
             the same time determines all methods that x50 to    |
   avoid conflicts with newly defined HTTP status codes.                  |

   RTSP status codes are implemented.
             When sending a request extensible. RTSP applications are not required   |
   to understand the requestor declares all its
             capabilities by including meaning of all supported feature-tags. The
             results in that the receiver learns registered status codes, though such  |
   understanding is obviously desirable. However, applications MUST       |
   understand the requestors feature
             support. The receiver then includes its set class of features in any status code, as indicated by the response.

        Require: The Require header can be included in first     |
   digit, and treat any request where unrecognized response as being equivalent to the end point, i.e.  |
   x00 status code of that class, with the client or server, exception that an              |
   unrecognized response MUST NOT be cached. For example, if an           |
   unrecognized status code of 431 is required to
             understand the feature to correctly perform received by the request.
             This client, it can for example be a SETUP      |
   safely assume that there was something wrong with its request where and      |
   treat the server
             must understand response as if it had received a certain parameter to be able 400 status code. In such    |
   cases, user agents SHOULD present to set up the media delivery correctly. Ignoring this parameter would
             not have user the desired effect and is not acceptable.
             Therefore entity returned      |
   with the end-point receiving a request containing a
             Require must negatively acknowledge any feature response, since that it
             does not understand and not perform entity is likely to include human-       |
   readable information which will explain the request. unusual status.            |

7.1.2 Response Header Fields                                              |
   The
             response in cases where features are not understood are 551
             (Option Not Supported). Also response-header fields allow the features that are not
             understood are given in request recipient to pass         |
   additional information about the Unsupported header response which cannot be placed in    |
   the
             response.

        Proxy-Require: This method has Status-Line. These header fields give information about the same purpose        |
   server and workings as
             Require except that it only applies about further access to proxies and not the
             end point. Features that needs to be supported resource identified by both
             proxies and end-point needs to be included in both the
             Require and Proxy-Require header.

        Unsupported: This header is used in 551 error      |
   Request-URL. All headers currently being classified as response to tell
             which feature(s) that was not supported. Such a        |
   headers are listed in table  7.1.2.

                  Header              Defined in Section
                  ______________________________________
                  Accept-Ranges       Section  14.4
                  Location            Section  14.25
                  Proxy-Authenticate  Section  14.26
                  Public              Section  14.28
                  Range               Section  14.29
                  Retry-After         Section  14.31
                  RTP-Info            Section  14.33
                  Scale               Section  14.34
                  Session             Section  14.37
                  Server              Section  14.36
                  Speed               Section  14.35
                  Transport           Section  14.40
                  Unsupported         Section  14.41
                  Vary                Section  14.43
                  WWW-Authenticate    Section  14.45

   Table 5: The RTSP response is headers

   Response-header field names can be extended reliably only in
   combination with a change in the result of protocol version. However, new or
   experimental header fields MAY be given the usage semantics of the Require and/or Proxy-
             Require response-
   header where one or more feature where not
             supported. This information allows fields if all parties in the requestor communication recognize them to make
             the best of situations
   be response-header fields. Unrecognized header fields are treated as it knows which features that was
   entity-header fields.

8 Entity

   Request and Response messages MAY transfer an entity if not supported.

11 Method Definitions

   The method token indicates otherwise  |
   restricted by the request method to be performed on the resource
   identified by or response status code. An entity    |
   consists of entity-header fields and an entity-body, although some     |
   responses will only include the Request-URI case-sensitive. New methods may be
   defined in the future. Method names may not start with a $ character
   (decimal 24) entity-headers.                        |

   The SET_PARAMETER, and must be a token as defined by the ABNF. Methods are
   summarized in Table 2.

    method         direction       object  Server req.    Client req.
    ___________________________________________________________________
    DESCRIBE       C -> S          P,S     recommended    recommended GET_PARAMETER  C -> S, S -> C  P,S     optional       optional
    OPTIONS        C -> S, S -> C  P,S     R=Req, Sd=Opt  Sd=Req, R=Opt
    PAUSE          C -> S          P,S     recommended    recommended
    PING           C -> S, S -> C  P,S     recommended    optional
    PLAY           C -> S          P,S     required       required
    REDIRECT       S -> C          P,S     optional       optional
    SETUP          C -> S          S       required       required
    SET_PARAMETER  C -> S, S -> C  P,S     optional       optional
    TEARDOWN       C -> S          P,S     required       required

   Table 2: Overview of RTSP methods, their direction, request and what  objects
   (P: presentation, S: stream) they operate on. Legend:  R=Responde to,
   Sd=Send, Opt: Optional, Req: Required, Rec:  Recommended

   Notes response, and         |
   DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY    |
   also have an entity.                                                   |
          Code  Reason                            Method
          _______________________________________________________
          100   Continue                          all

_______________________________________________________
          200   OK                                all
          201   Created                           RECORD
          250   Low on Table 2: Storage Space              RECORD
          _______________________________________________________
          300   Multiple Choices                  all
          301   Moved Permanently                 all
          302   Found                             all
          303   See Other                         all
          305   Use Proxy                         all
          350   Going Away                        all
          351   Load Balancing                    all

_______________________________________________________
          400   Bad Request                       all
          401   Unauthorized                      all
          402   Payment Required                  all
          403   Forbidden                         all
          404   Not Found                         all
          405   Method Not Allowed                all
          406   Not Acceptable                    all
          407   Proxy Authentication Required     all
          408   Request Timeout                   all
          410   Gone                              all
          411   Length Required                   all
          412   Precondition Failed               DESCRIBE, SETUP
          413   Request Entity Too Large          all
          414   Request-URL Too Long              all
          415   Unsupported Media Type            all
          451   Parameter Not Understood          SET_PARAMETER
          452   reserved                          n/a
          453   Not Enough Bandwidth              SETUP
          454   Session Not Found                 all
          455   Method Not Valid In This State    all
          456   Header Field Not Valid            all
          457   Invalid Range                     PLAY, PAUSE is recommended, but not required in that a
   fully functional server can be built that does not support this
   method, for example, for live feeds. If a server does not support a
   particular method, it MUST return
          458   Parameter Is Read-Only            SET_PARAMETER
          459   Aggregate Operation Not Allowed   all
          460   Only Aggregate Operation Allowed  all
          461   Unsupported Transport             all
          462   Destination Unreachable           all
          _______________________________________________________
          500   Internal Server Error             all
          501 (Not Implemented)   Not Implemented                   all
          502   Bad Gateway                       all
          503   Service Unavailable               all
          504   Gateway Timeout                   all
          505   RTSP Version Not Supported        all
   Table 4: Status codes and a client
   SHOULD NOT try this method again for their usage with RTSP methods

   In this server.

11.1 OPTIONS

   The behavior is equivalent section, both sender and recipient refer to that described in [H9.2]. An OPTIONS
   request may be issued at any time, e.g., if either the client  |
   or the server, depending on who sends and who receives the entity.     |

8.1 Entity Header Fields                                                  |

   Entity-header fields define optional meta-information about the        |
   entity-body or, if no body is present, about to
   try a nonstandard request. It does not influence the session state.
   The Public header MUST be included in responses to indicate which
   methods that are supported resource identified   |
   by the server. To specify which methods
   that request. The entity header fields are possible listed in table  8.1.     |

                   Header            Defined in Section
                   ____________________________________
                   Allow             Section  14.5
                   Content-Base      Section  14.11
                   Content-Encoding  Section  14.12
                   Content-Language  Section  14.13
                   Content-Length    Section  14.14
                   Content-Location  Section  14.15
                   Content-Type      Section  14.16
                   Expires           Section  14.19
                   Last-Modified     Section  14.24

   Table 6: The RTSP entity headers

   The extension-header mechanism allows additional entity-header fields  |
   to use for be defined without changing the specified resource, protocol, but these fields cannot   |
   be assumed to be recognizable by the Allow MAY recipient. Unrecognized header    |
   fields SHOULD be
   used. By including in ignored by the OPTIONS request recipient and forwarded by proxies.    |

8.2 Entity Body                                                           |

   See [H7.2] with the addition that a Supported header, RTSP message with an entity body   |
   MUST include the
   requester Content-Type and Content-Length headers.              |

9 Connections

   RTSP requests can determine which features the other part supports. be transmitted in several different ways:

        o persistent transport connections used for several request-
          response transactions;

        o one connection per request/response transaction;
        o connectionless mode.

   The request URI determines which scope type of transport is defined by the OPTIONS request has.  By
   giving RTSP URL (Section 3.2). For    |
   the URI of scheme "rtsp", a certain media connection is assumed, while the capabilities regarding this
   media will scheme "rtspu"   |
   calls for RTSP requests to be responded. By using the "*" URI the request regards the
   next hop only, while having sent without setting up a URL with only the host address regards connection.

   Unlike HTTP, RTSP allows the media server without any to send requests to the
   media relevance.

   The OPTIONS method can be used for RTSP session keep alive
   signalling, however client. However, this method is not the most recommended one, see
   section  13.37 only supported for a preference list. A keep alive OPTIONS request
   SHOULD use persistent
   connections, as the media or aggregated control URI.

   Example:

     C->S:  OPTIONS * RTSP/1.0
            CSeq: 1
            User-Agent: PhonyClient/1.2
            Require:
            Proxy-Require: gzipped-messages
            Supported: play-basic

     S->C:  RTSP/1.0 200 OK
            CSeq: 1
            Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
            Supported: play-basic, implicit-play, gzipped-messages
            Server: PhonyServer/1.0

   Note that some server otherwise has no reliable way of
   reaching the feature-tags in Require and Proxy-Require are
   necessarily fictional features (one would hope that we would not
   purposefully overlook a truly useful feature just so that we could
   have a strong example in client.  Also, this section).

11.2 DESCRIBE

   The DESCRIBE method retrieves the description of a presentation or
   media object identified by is the request URL only way that requests from a server. It may use
   the Accept header
   media server to specify client are likely to traverse firewalls.

9.1 Pipelining

   A client that supports persistent connections or connectionless mode
   MAY "pipeline" its requests (i.e., send multiple requests without
   waiting for each response). A server MUST send its responses to those
   requests in the description formats same order that the client
   understands. requests were received.

9.2 Reliability and Acknowledgements

   The server responds with a description transmission of the requested
   resource. The DESCRIBE reply-response pair constitutes the media
   initialization phase RTSP over UDP was optionally to implement and
   specified in RFC 2326. However that definition was not satisfactory
   for interoperable implementations. Due to lack of RTSP.

   Example:

     C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
           CSeq: 312
           User-Agent: PhonyClient 1.2
           Accept: application/sdp, application/rtsl, application/mheg

     S->C: RTSP/1.0 200 OK
           CSeq: 312
           Date: 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer 1.0
           Content-Type: application/sdp
           Content-Length: 376

           v=0
           o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
           s=SDP Seminar
           i=A Seminar on the session description protocol
           u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
           e=mjh@isi.edu (Mark Handley)
           c=IN IP4 224.2.17.12/127
           t=2873397496 2873404696
           a=recvonly
           m=audio 3456 RTP/AVP 0
           m=video 2232 RTP/AVP 31
           m=application 32416 UDP WB
           a=orient:portrait

   The DESCRIBE response MUST contain all media initialization
   information for the resource(s) that it describes. If a media client
   obtains a presentation description from a source other than DESCRIBE
   and that description contains a complete set of media initialization
   parameters, the client SHOULD use those parameters and interest, this
   specification does not then
   request a description for the same media via RTSP.

   Additionally, servers SHOULD NOT use the DESCRIBE response as a means
   of media indirection.

        By forcing a DESCRIBE response specify how RTSP over UDP shall be
   implemented. However to contain all media
        initialization for maintain backwards compatibility in the set of streams that it describes,
        and discouraging use
   message format certain RTSP headers must be maintained.  These
   mechanism are described below. The next section Unreliable Transport
   (section  9.3) provides documentation of DESCRIBE for media indirection, we
        avoid looping problems certain features that might result from other
        approaches.

   Media initialization is a requirement are
   necessary for any RTSP-based system, but
   the transport protocols like UDP.

   Any RTSP specification does not dictate that request according to this must specification SHALL NOT be done via
   the DESCRIBE method. There are three ways that an sent to
   a multicast address. Any RTSP client may
   receive initialization information:

        o via RTSP's DESCRIBE method;

        o via some other request SHALL be acknowledged. If a
   reliable transport protocol (HTTP, email attachment, etc.);

        o via is used to carry RTSP, requests MUST NOT
   be retransmitted; the command line or standard input (thus working RTSP application MUST instead rely on the
   underlying transport to provide reliability.

        If both the underlying reliable transport such as a
          browser helper TCP and
        the RTSP application launched with an SDP file or other
          media initialization format).

   It retransmit requests, it is RECOMMENDED possible
        that minimal servers support each packet loss results in two retransmissions. The
        receiver cannot typically take advantage of the DESCRIBE method,
   and highly recommended that minimal clients support
        application-layer retransmission since the ability to
   act as a "helper application" that accepts a media initialization
   file from standard input, command line, and/or other means that are
   appropriate to transport stack
        will not deliver the operating environment of application-layer retransmission
        before the client.

11.3 SETUP

   The SETUP first attempt has reached the receiver. If the
        packet loss is caused by congestion, multiple
        retransmissions at different layers will exacerbate the
        congestion.

   Each request for carries a URI specifies sequence number in the transport mechanism to CSeq header (Section
   14.17), which MUST be    |
   used incremented by one for each distinct request
   transmitted to the streamed media. destination end-point.  The SETUP method may initial sequence
   number MAY be used in two       |
   different cases; Create a RTSP session or add a media chosen arbitrary, but is RECOMMENDED to begin with 0.
   If a session,    |
   and change the transport parameters request is repeated because of already set up media stream.    |
   Using SETUP to create or add media to a session when in PLAY state     |
   are not allowed. Otherwise SETUP can be used in all three states;      |
   INIT, and READY, for both purposes and in PLAY to change the           |
   transport parameters.                                                  |

   The Transport header, see section  13.40, specifies the transport      |
   parameters acceptable to the client for data transmission; lack of acknowledgement, the         |
   response will contain
   request MUST carry the transport parameters selected by original sequence number (i.e., the         |
   server. sequence
   number is not incremented).

9.3 Unreliable Transport

   This allows the client section provides some information to enumerate in priority order future specification of
   RTSP over unreliable transport.

   Requests shall be acknowledged by the receiver. If there is no         |
   transport mechanisms and parameters acceptable to it, while
   acknowledgement, the        |
   server can select sender may resend the most appropriate. All transport parameters same message after a        |
   SHOULD be included in the Transport header, the use
   timeout of other headers   |
   for this purpose one round-trip time (RTT). The round-trip time is discouraged due to middle boxes.           |

   For the benefit
   estimated as in TCP (RFC 1123) [14], with an initial round-trip value  |
   of any intervening firewalls, a client SHOULD 500 ms. An implementation MAY cache the last RTT measurement as     |
   indicate
   the transport parameters even if it has no influence initial value for future connections.

   If RTSP is used over     |
   these parameters, a small-RTT LAN, standard procedures for example, where
   optimizing initial TCP round trip estimates, such as those used in
   T/TCP (RFC 1644) [33], can be beneficial.

   The Timestamp header (Section 14.39) is used to avoid the server advertises a fixed     |
   multicast address.                                                     |

        Since SETUP includes all transport initialization            |
        information, firewalls
   retransmission ambiguity problem [34] and other intermediate network        |
        devices (which need this information) are spared the more    |
        arduous task of parsing obviates the DESCRIBE response, which has     |
        been reserved need for media initialization.                      |

   In
   Karn's algorithm.

   If a SETUP response the server SHOULD include request is repeated because of lack of acknowledgement, the Accept-Ranges        |
   header (see section 13.4 to indicate which time formats that are       |
   acceptable to use for this media resource.                             |

     C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0               |
           CSeq: 302                                                      |
           Transport: RTP/AVP;unicast;client_port=4588-4589,              |
                      RTP/AVP/TCP;unicast;interleave=0-1                  |

     S->C: RTSP/1.0 200 OK                                                |
           CSeq: 302                                                      |
           Date: 23 Jan 1997 15:35:06 GMT                                 |
           Server: PhonyServer 1.0                                        |
           Session: 47112344                                              |
           Transport: RTP/AVP;unicast;client_port=4588-4589;              |
                      server_port=6256-6257;ssrc=2A3F93ED                 |
           Accept-Ranges: NPT                                             |

   In
   request must carry the above example original sequence number (i.e., the client want to create a sequence
   number is not incremented).

   A number of RTSP session          |
   containing messages destined for the media resource "rtsp://example.com/foo/bar/baz.rm". same control end point may  |
   be packed into a single lower-layer PDU.

   The transport parameters acceptable to default port for the client RTSP server is either 554 for UDP.

9.4 The usage of connections

   Systems implementing RTSP MUST support carrying RTSP over TCP.  The    |
   RTP/AVP/UDP (UDP per default) to be received on client
   default port 4588 and   |
   4589 or RTP/AVP interleaved on for the RTSP control channel. The server is 554 for TCP. A number of RTSP      |
   selects the RTP/AVP/UDP transport and adds
   packets destined for the ports it will send and  |
   received RTP and RTCP from, and the RTP SSRC that will same control end point may be used by the encapsulated    |
   server.
   into a TCP stream. RTSP data MAY be interleaved with RTP and RTCP      |

   The server
   packets, see section  12. Unlike HTTP, an RTSP message MUST generate a session identifier in response to contain a  |
   successful SETUP request, unless a SETUP request to
   Content-Length header field whenever that message contains a server includes payload   |
   a session identifier, in which case the server MUST bundle this setup
   (entity).  Otherwise, an RTSP packet is terminated with an empty line  |
   request into
   immediately following the existing session (aggregated session) or return       |
   error 459 (Aggregate Operation Not Allowed) (see Section  12.4.11).    |
   An Aggregate control URI MUST last message header.

   TCP can be used to control an aggregated         |
   session. for both persistent connections and for one message
   exchange per connection, as presented above. This URI MUST be different from the stream control URIs of    |
   the individual media streams included in the aggregate. The Aggregate  |
   control URI is section gives
   further rules and recommendations on how to handle these connections
   so maximum interoperability and flexibility can be specified by the session description if the       | achieved.

   A server supports aggregated control SHALL handle both persistent connections and aggregated control is desired   | one
   request/response transaction per connection. A persistent connection
   MAY be used for all transactions between the session. server and client,
   including messages to multiple RTSP sessions. However even if aggregated control is offered the     |
   client persistent
   connection MAY chose to not set up also be closed after a few message exchanges, e.g. the session in aggregated control.      |

   If an Aggregate control URI is not specified
   initial setup and play command in a session. Later when the client
   wishes to send a new request, e.g.  pause, to the session            |
   description, it a new
   connection is probably opened. This connection may either be for a indication that non-aggregated control   |
   should single
   message exchange or can be used. However kept open for several messages, i.e.
   persistent.

   A major motivation for allowing non-persistent connections are that
   they ensure fault tolerance. A second one is to allow for application
   layer mobility. A server and client supporting non-persistent
   connection can survive a loss of a TCP connection, e.g. due to a NAT
   timeout. When the client MAY try has discovered that the TCP connection has
   been lost, it can set up a new one when there is need to SETUP communicate.

   The client MAY close the session in connection at any time when no outstanding    |
   aggregated control. If
   request/response transactions exist. The server SHOULD NOT close the   |
   connection unless at least one RTSP session timeout period has passed  |
   without data traffic. A server refuse SHOULD NOT initiate a close of a        |
   connection directly after responding to aggregate a TEARDOWN request for the specified     |
   media, the
   whole session. A server SHALL use SHOULD NOT close the 459 connection as a result    |
   of responding to a request with an error code.  If the server allows Doing this would        |
   the aggregation, then
   prevent or result in extra overhead for the client MUST create an URI for aggregate when testing        |
   control
   advanced or special types of requests.

   The client SHOULD NOT have more than one connection to the session. This URI MUST contain the servers host         |
   address and MUST contain server at
   any given point. If a client or proxy handles multiple RTSP sessions
   on the port, if applicable (e.g. not default     |
   port). Once an URI same server, it is used to refer RECOMMENDED to an aggregation for use only a given      |
   session, that URI MUST be used single
   connection.

   Older services which was implemented according to refer RFC 2326 sometimes
   requires the client to use persistent connection. The client closing
   the connection may result in that aggregation for the    |
   duration of server removes the session.                                               |
        While the session ID sometimes has enough information for    |
        aggregate control of a session, the Aggregate control URI    | To
   achieve interoperability with old servers any client is still important for some methods such as SET_PARAMETER    |
        where the control URI enables the resource in question strongly
   RECOMMENDED to    |
        be easily identified. The Aggregate control URI use persistent connections.

   A Client is also      |
        useful for proxies, enabling them strongly RECOMMENDED to route use persistent connections
   as it allows the server to send request to    | the appropriate server, and for logging, client.  In cases
   where it is useful  |
        to note no connection exist between the actual resource that a request was operating     |
        on. Finally, presence of server and the Aggregate control URI allows    |
        for backwards compatibility with RFC 2326 [21].

   A session will exist until it is either removed by a TEARDOWN request
   or is timed-out by client, this may
   cause the server. The server MAY remove a to be forced to drop the RTSP session that
   has not demonstrated liveness signs from without
   notifying the client within why, due to the lack of signalling channel. An
   example of such a certain
   timeout period. The default timeout value case is 60 seconds; when the server
   MAY set this desires to send a different value and indicate so in the timeout
   field of the Session header in the SETUP response. For further
   discussion see chapter  13.37. Signs of liveness REDIRECT
   request for a RTSP session
   are:

        o Any RTSP request from a to the client.

   A server implemented according to this specification MUST respond
   that it supports the "play.basic" feature-tag above. A client which includes MAY
   send a Session request including the Supported header
          with that session's ID.

        o If RTP is used as in a transport for request to
   determine support of non-persistent connections. A server supporting
   non-persistent connections will return the underlying media
          streams, an RTCP sender or receiver report from "play.basic" feature-tag
   in its response. If the client for
          any of receives the media streams feature-tag in the
   response, it can be certain that the server handles non-persistent
   connections.

9.5 Timing Out RTSP session.

   If messages                                              |

   Receivers of a SETUP request on (responder) SHOULD respond to requests in a session fails for any reason, the session     |
   state, as well as
   timely manner even when a reliable transport and other parameters for associated        |
   streams SHALL remain unchanged from their values such as if the SETUP TCP is used.      |
   request had never been received by
   Similarly, the server.                         |

   A client MAY issue sender of a SETUP request (requestor) SHOULD wait for a stream that is already set       |
   up or playing in the session to change transport parameters, which
   sufficient time for a response before concluding that the responder    |
   server MAY allow. If it does
   will not allow this, it MUST respond with      |
   error 455 (Method Not Valid In This State). Reasons to support         |
   changing transport parameters, is to allow for application layer be acting upon its request.                                   |
   mobility and flexibility

   A responder SHOULD respond to utilize all requests within 5 seconds. If the best available transport as    |
   it becomes available.    |

   In a SETUP response for
   responder recognizes that processing of a request to change the transport parameters will take longer     |
   while in Play state, the server
   than 5 seconds, it SHOULD include the Range to indicate send a 100 response as soon as possible. It  |
   from what point the new transport parameters are used. Further if RTP
   SHOULD continue sending a 100 response every 5 seconds thereafter      |
   until it is used for delivery ready to send the server SHOULD also include final response to the RTP-Info requestor. After   |
   header to indicate from what timestamp and RTP sequence number
   sending a 100 response, the receiver MUST send a final response        |
   change has taken place. If both RTP-Info and Range is included in
   indicating the success or failure of the request.                      |

   A requestor SHOULD wait at least 10 seconds for a response before      |
   concluding that the "rtp_time" parameter and range MUST responder will not be for the responding to its request.   |
   corresponding time, i.e. be used in
   After receiving a 100 response, the same way as requestor SHOULD continue waiting  |
   for PLAY to further responses. If more than 10 seconds elapses without         |
   ensure
   receiving any response, the correct synchronization information requestor MAY assume the responder is present.      |

   If
   unresponsive and abort the transport parameter change while in PLAY state results in a connection.                                 |
   change of synchronization related information,

   A requestor SHOULD wait longer than 10 seconds for example changing    |
   RTP SSRC, the server MUST provide in the SETUP a response the necessary if it    |
   synchronization information. However the server
   is RECOMMENDED experiencing significant transport delays on its connection to      |
   avoid changing the synchronization information if possible.  |

11.4 PLAY
   responder. The PLAY method tells requestor is capable of determining the server to start sending data via RTT using the   |
   mechanism specified
   Timestamp header (section 14.39) in SETUP. A client MUST NOT issue a PLAY request   |
   until any outstanding SETUP requests have RTSP request.

9.6 Use of IPv6

   This specification has been acknowledged updated so that it supports IPv6.
   However this support was not present in RFC 2326 therefore some
   interoperability issues exist. A RFC 2326 implementation can support
   IPv6 as         |
   successful. PLAY requests long as no explicit IPv6 addresses are valid when the session is in READY       |
   state; the used within RTSP
   messages. This require that any RTSP URL pointing at a IPv6 host must
   use of PLAY requests when the session is in PLAY state is   |
   deprecated. A PLAY request MUST include fully qualified domain name and not a Session header to indicate   |
   which session IPv6 address.  Further the request applies to.

   In an aggregated session
   Transport header must not use the PLAY request parameters source and destination.

   Implementations according to this specification MUST contain an aggregated
   control URL. A server SHALL responde with error 460 (Only Aggregate
   Operation Allowed) if understand IPv6
   addresses in URLs, and headers. By this requirement the feature-tag
   "play.basic" can be used to determine that a server or client PLAY request URI is for one
   capable of handling IPv6 within RTSP.

10 Capability Handling

   This chapter describes the
   media. The media capability handling mechanism available in an aggregate SHALL
   RTSP which allows RTSP to be played in sync. If a client
   want individual control extended. Extensions to this version of
   the media it must use separate RTSP
   sessions for each media. protocol are basically done in two ways. First, new headers can
   be added. Secondly, new methods can be added. The PLAY request SHALL position the normal play time capability handling
   mechanism is designed to handle these two cases.

   When a method is added the beginning  |
   of the range specified by the Range header and delivers stream data    |
   until the end of involved parties can use the range OPTIONS
   method to discover if given, else it is supported. This is done by issuing a
   OPTIONS request to the end of other party. Depending on the URL it will
   either apply in regards to a certain media is   |
   reached. To allow for precise composition multiple ranges MAY be       |
   specified resource, the whole server
   in one PLAY Request. general, or simply the next hop. The range values are valid if OPTIONS response will contain
   a Public header which declares all       |
   given ranges are part methods supported for the
   indicated resource.

   It is not necessary to use OPTIONS to discover support of any media within a method,
   the aggregate. client could simply try the method. If a given    |
   range value points outside of the media, receiver of the response SHALL be
   request does not support the     |
   457 (Invalid Range) method it will respond with an error code.
   code indicating the the method is either not implemented (501) or
   does not apply for the resource (405). The below example will first play seconds 10 through 15, then,
   immediately following, seconds 20 to 25, and finally seconds 30
   through choice between the end.

     C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
           CSeq: 835
           Session: 12345678
           Range: npt=10-15, npt=20-25, npt=30-
   See two
   discovery methods depends on the description requirements of the PAUSE request for further examples. service.

   To handle functionality additions that are not new methods feature-
   tags are defined. Each feature-tag represents a certain block of
   functionality. The amount of functionality that a feature-tag
   represents can vary significantly. A PLAY request without simple feature-tag can simple
   represent the functionality a Range single header gives. Another feature-
   tag is legal. It SHALL start         |
   playing a stream from the beginning (npt=0-) unless "play.basic" which represents the stream has     |
   been paused. If a stream has been paused via PAUSE, stream delivery    |
   resumes at minimal playback
   implementation according to the pause point. updated specification.

   The stream SHALL play until feature-tags are then used to determine if the end of     | client, server or
   proxy supports the media. functionality that is necessary to achieve the
   desired service. To determine support of a feature-tag several
   different headers can be used, each explained below:

        Supported: The Range supported header MUST NOT contain a time parameter. is used to determine the
             complete set of functionality that both client and server
             has. The intended usage of time
   in PLAY method has been deprecated.

   Server MUST include is to determine before one needs to
             use a "Range" header functionality that it is supported. It can be used in
             any PLAY response. The         |
   response MUST use method however OPTIONS is the same format most suitable as one at
             the request's range header        |
   contained. If no Range header was in the request, the NPT same time format  |
   SHOULD be used unless the client showed support for an other format.   |
   Also for determines all methods that are implemented.
             When sending a session with live media streams request the Range header MUST       |
   indicate a valid time. It is RECOMMENDED requestor declares all its
             capabilities by including all supported feature-tags. This
             results in that normal play time is      |
   used, either the "now" indicator, for example "npt=now-", or receiver learns the time  |
   since session start as an open interval, e.g. "npt=96.23-". An         |
   absolute time value (clock) for requestors feature
             support. The receiver then includes its set of features in
             the corresponding time MAY be given,   |
   i.e.  "clock=20030213T143205Z-". response.

        Require: The UTC clock format SHOULD only Require header can be   |
   used if included in any request where
             the end point, i.e. the client has shown support for it.                               |

   A media server only supporting playback MUST support or server, is required to
             understand the npt format    |
   and MAY support feature to correctly perform the clock and smpte formats.                           |

   For request.
             This can for example be a on-demand stream, SETUP request where the server MUST reply with the actual range    |
   that will
             must understand a certain parameter to be played back. This may differ from the requested range if  |
   alignment of the requested range able to valid frame boundaries is          |
   required for set up
             the media source. If no range delivery correctly. Ignoring this parameter would
             not have the desired effect and is specified in not acceptable.
             Therefore the         |
   request, end-point receiving a request containing a
             Require must negatively acknowledge any feature that it
             does not understand and not perform the start position SHALL still be returned request. The
             response in cases where features are not understood are 551
             (Option Not Supported). Also the reply. If   |
   the medias features that are part of an aggregate has different lengths, not
             understood are given in the    |
   PLAY request SHALL be performed as long as Unsupported header in the given range is valid    |
   for any media, for example
             response.

        Proxy-Require: This method has the longest media. Media will be sent       |
   whenever same purpose and workings as
             Require except that it is available for only applies to proxies and not the given play-out
             end point.                 |

   After playing the desired range, the presentation is NOT               |
   automatically paused, media delivery simply stops. A PAUSE request     |
   MUST Features that needs to be issued before another PLAY request can supported by both
             proxies and end-point needs to be issued. Note: included in both the
             Require and Proxy-Require header.

        Unsupported: This   | header is one change resulting used in a non-operability with RFC 2326             |
   implementations. A client 551 error response to tell
             which feature(s) that was not issuing a PAUSE request before supported. Such a new     |
   PLAY will be stuck in PLAY state.                                      |

   A client desiring to play response is
             only the media from result of the beginning MUST send a     |
   PLAY request with a Range header pointing at usage of the beginning, e.g.       |
   npt=0-. If a PLAY request is received without a Range Require and/or Proxy-
             Require header when      |
   media delivery has stopped at where one or more feature where not
             supported. This information allows the end, requestor to make
             the server SHOULD respond with  |
   a 457 "Invalid Range" error response. In best of situations as it knows which features that response the current     |
   pause point in a Range header SHALL be included. was
             not supported.

11 Method Definitions

   The following example plays the whole presentation starting at SMPTE
   time code 0:10:20 until method indicates what is to be performed on the end of resource           |
   identified by the clip. Note: Request-URL. The RTP-Info
   headers has been broken into several lines to fit the page.

   C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
         CSeq: 833
         Session: 12345678
         Range: smpte=0:10:20-

   S->C: RTSP/1.0 200 OK
         CSeq: 833
         Date: 23 Jan 1997 15:35:06 GMT
         Server: PhonyServer 1.0
         Range: smpte=0:10:22-
         RTP-Info:url=rtsp://example.com/twister.en;
            seq=14783;rtptime=2345962545

   For playing back a recording of a live presentation, it method name is case-sensitive.      |
   New methods may be
   desirable to use clock units:

     C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0
           CSeq: 835
           Session: 12345678
           Range: clock=19961108T142300Z-19961108T143520Z

     S->C: RTSP/1.0 200 OK
           CSeq: 835
           Date: 23 Jan 1997 15:35:06 GMT
           Server:PhonyServer 1.0
           Range: clock=19961108T142300Z-19961108T143520Z
           RTP-Info:url=rtsp://example.com/meeting.en;
              seq=53745;rtptime=484589019

   All range specifiers defined in this specification allow for ranges the future. Method names may not start   |
   with
   unspecified begin times (e.g. "npt=-30"). When used in a PLAY
   request, the server treats this as $ character (decimal 24) and must be a request to start/resume playback
   from the current pause point, ending at token as defined by the end time specified  |
   ABNF. Methods are summarized in the
   Range header. If the pause point Table 7.

   Notes on Table 7: PAUSE is located later than the given end
   value, a 457 (Invalid Range) response SHALL be given.

   The queued play functionality described recommended, but not required in RFC 2326 [21] is removed that a     |
    method         direction       object  Server req.    Client req.
    ___________________________________________________________________
    DESCRIBE       C -> S          P,S     recommended    recommended
    GET_PARAMETER  C -> S, S -> C  P,S     optional       optional
    OPTIONS        C -> S, S -> C  P,S     R=Req, Sd=Opt  Sd=Req, R=Opt
    PAUSE          C -> S          P,S     recommended    recommended
    PING           C -> S, S -> C  P,S     recommended    optional
    PLAY           C -> S          P,S     required       required
    REDIRECT       S -> C          P,S     optional       optional
    SETUP          C -> S          S       required       required
    SET_PARAMETER  C -> S, S -> C  P,S     optional       optional
    TEARDOWN       C -> S          P,S     required       required

   Table 7: Overview of RTSP methods, their direction, and multiple ranges what  objects
   (P: presentation, S: stream) they operate on. Legend:  R=Responde to,
   Sd=Send, Opt: Optional, Req: Required, Rec:  Recommended

   fully functional server can be used to achieve a similar performance. built that does not support this        |
   method, for example, for live feeds. If a server receives a PLAY request while in the PLAY state, the server
   SHALL responde using the error code 455 (Method Not Valid In This
   State). This will signal the client that queued play are does not
   supported.

   The use of PLAY for keep-alive signaling, i.e. PLAY request without support a    |
   range header in PLAY state, has also been depreciated. Instead
   particular method, it MUST return 501 (Not Implemented) and a       | client can use, PING, SET_PARAMETER or OPTIONS for keep alive. A   |
   server receiving a PLAY keep alive SHALL respond with the 455 error    |
   code.

11.5 PAUSE
   SHOULD NOT try this method again for this server and resource.

11.1 OPTIONS

   The PAUSE request causes the stream delivery behavior is equivalent to be interrupted
   (halted) temporarily. A PAUSE that described in [H9.2]. An OPTIONS
   request MUST may be done with the
   aggregated control URI for aggregated sessions, resulting in all
   media being halted, or issued at any time, e.g., if the media URI for non-aggregated sessions.
   Any attempt client is about to do muting of
   try a single media with an PAUSE request in
   an aggregated session SHALL be responded with error 460 (Only
   Aggregate Operation Allowed). After resuming playback,
   synchronization of nonstandard request. It does not influence the tracks session state.
   The Public header MUST be maintained. Any server
   resources included in responses to indicate which
   methods that are kept, though servers MAY close supported by the session and free
   resources after being paused server. To specify which methods
   that are possible to use for the duration specified with the
   timeout parameter of resource, the Session header Allow MAY be
   used. By including in the SETUP message.

   Example:                                                               |

     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0                   |
           CSeq: 834                                                      |
           Session: 12345678                                              |

     S->C: RTSP/1.0 200 OK                                                |
           CSeq: 834                                                      |
           Date: 23 Jan 1997 15:35:06 GMT                                 |
           Range: npt=45.76-                                              |

   The PAUSE OPTIONS request MAY contain a Range header specifying when Supported header, the
   stream or presentation is to be halted. We refer to this point as
   requester can determine which features the
   "pause point". other part supports.

   The time parameter in request URL determines which scope the Range MUST NOT be used. The
   Range header MUST contain a single value, expressed as OPTIONS request has.  By
   giving the beginning
   value an open range. For example, URL of a certain media the following clip capabilities regarding this
   media will be played
   from 10 seconds through 21 seconds of the clip's normal play time,
   under responded. By using the assumption that "*" URL the PAUSE request reaches regards the
   next hop only, while having a URL with only the host address regards
   the server within
   11 seconds of without any media relevance.

   The OPTIONS method can be used for RTSP session keep alive             |
   signalling, however this method is not the PLAY request. Note most recommended one, see   |
   section  14.37 for a preference list. A keep alive OPTIONS request     |
   SHOULD use the media or aggregated control URL. For options to         |
   function as session state keep-alive, it is REQUIRED that some lines has been broken the session  |
   ID is included in an non-correct way to fit the page: Session header.

   Example:

     C->S: PLAY rtsp://example.com/fizzle/foo  OPTIONS * RTSP/1.0
            CSeq: 834
           Session: 12345678
           Range: npt=10-30 1
            User-Agent: PhonyClient/1.2
            Require:
            Proxy-Require: gzipped-messages
            Supported: play-basic

     S->C:  RTSP/1.0 200 OK
            CSeq: 834
           Date: 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer 1.0
           Range: npt=10-30
           RTP-Info:url=rtsp://example.com/fizzle/audiotrack;
                   seq=5712;rtptime=934207921,
                   url=rtsp://example.com/fizzle/videotrack;
                   seq=57654;rtptime=2792482193
           Session: 12345678

     C->S: 1
            Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 835
           Session: 12345678
           Range: npt=21-

     S->C: RTSP/1.0 200 OK
           CSeq: 835
           Date: 23 Jan 1997 15:35:09 GMT
            Supported: play-basic, implicit-play, gzipped-messages
            Server: PhonyServer 1.0
           Range: npt=21-
           Session: 12345678

   The pause request becomes effective the first time the server is
   encountering the time point specified in any PhonyServer/1.0

   Note that some of the multiple ranges.
   If the Range header specifies a time outside any range from the PLAY
   request, the error 457 (Invalid Range) SHALL be returned. If a media
   unit (such as an audio or video frame) starts presentation at exactly
   the pause point, it is not played. If the Range header is missing,
   stream delivery is interrupted immediately on receipt of the message
   and the pause point is set to the current normal play time. However,
   the pause point feature-tags in the media stream MUST be maintained. A subsequent
   PLAY request without Range header SHALL resume from the pause point Require and play until media end.

   If the server has already sent data beyond the time specified Proxy-Require are
   necessarily fictional features (one would hope that we would not
   purposefully overlook a truly useful feature just so that we could
   have a strong example in this section).

11.2 DESCRIBE

   The DESCRIBE method retrieves the   |
   PAUSE request's Range header, description of a PLAY without range SHALL resume at presentation or     |
   the point in time specified
   media object identified by the PAUSE request's Range header, as    |
   it is assumed that the client has discarded data after that point.     |
   This ensures continuous pause/play cycling without gaps.               | request URL from a server. The pause point after any PAUSE request SHALL be returned  |
   MAY use the Accept header to specify the description formats that the  |
   client by adding a Range header understands. The server responds with what remains unplayed a description of the      |
   PLAY request's ranges, i.e. including all
   requested resource. The DESCRIBE reply-response pair constitutes the remaining ranges part   |
   media initialization phase of multiple range specification. RTSP.

   Example:

     C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
           CSeq: 312
           User-Agent: PhonyClient 1.2
           Accept: application/sdp, application/rtsl, application/mheg

     S->C: RTSP/1.0 200 OK
           CSeq: 312
           Date: 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer 1.0
           Content-Type: application/sdp
           Content-Length: 376

           v=0
           o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
           s=SDP Seminar
           i=A Seminar on the session description protocol
           u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
           e=mjh@isi.edu (Mark Handley)
           c=IN IP4 224.2.17.12/127
           t=2873397496 2873404696
           a=recvonly
           m=audio 3456 RTP/AVP 0
           m=video 2232 RTP/AVP 31
           m=application 32416 UDP WB
           a=orient:portrait

   The DESCRIBE response MUST contain all media initialization
   information for the resource(s) that it describes. If one desires to resume playing a    |
   ranged request, one simple included the Range header media client
   obtains a presentation description from the PAUSE    |
   response. Note a source other than DESCRIBE
   and that this server behavior was not mandated previously   | description contains a complete set of media initialization
   parameters, the client SHOULD use those parameters and servers implementing according to RFC 2326 will probably not       |
   return then
   request a description for the range header.                                               |

   For example, if same media via RTSP.

   Additionally, servers SHOULD NOT use the server have DESCRIBE response as a play request for ranges 10 to 15     |
   and 20 to 29 pending and then receives means
   of media indirection.

        By forcing a pause request DESCRIBE response to contain all media
        initialization for NPT 21, it  |
   would start playing the second range set of streams that it describes,
        and stop at NPT 21. If the pause  |
   request is discouraging use of DESCRIBE for NPT 12 and the server media indirection, we
        avoid looping problems that might result from other
        approaches.

   Media initialization is playing at NPT 13 serving a requirement for any RTSP-based system, but
   the  |
   first play request, the server stops immediately. If RTSP specification does not dictate that this must be done via
   the pause         |
   request is for NPT 16, DESCRIBE method. There are three ways that an RTSP client may
   receive initialization information:

        o via RTSP's DESCRIBE method;

        o via some other protocol (HTTP, email attachment, etc.);

        o via the server returns command line or standard input (thus working as a 457 error message. To      |
   prevent
          browser helper application launched with an SDP file or other
          media initialization format).

   It is RECOMMENDED that minimal servers support the second range is played DESCRIBE method,
   and highly recommended that minimal clients support the server stops after     |
   completing the first range, ability to
   act as a PAUSE "helper application" that accepts a media initialization
   file from standard input, command line, and/or other means that are
   appropriate to the operating environment of the client.

11.3 SETUP

   The SETUP request for 20 must a URL specifies the transport mechanism to be issued.     |

   As another example, if
   used for the streamed media. The SETUP method may be used in two
   different cases; Create a server has received requests RTSP session or add a media to play ranges   |
   10 a session,
   and change the transport parameters of already set up media stream.
   Using SETUP to 15 create or add media to a session when in PLAY state is
   unspecified. Otherwise SETUP can be used in all three states; INIT,
   and then 13 READY, for both purposes and in PLAY to 20 (that is, overlapping ranges), change the PAUSE transport
   parameters.

   The Transport header, see section  14.40, specifies the transport      |
   request
   parameters acceptable to the client for NPT=14 would take effect while data transmission; the server plays         |
   response will contain the transport parameters selected by the first         |
   range, with
   server. This allows the second range effectively being ignored, assuming client to enumerate in priority order the      |
   PAUSE request arrives before
   transport mechanisms and parameters acceptable to it, while the        |
   server has started playing can select the most appropriate. It is expected that the        |
   second, overlapping range. Regardless of when
   session description format used will enable the PAUSE request client to select a     |
   arrives, it sets
   limited number possible configurations that are offered to the pause point server  |
   to 14. The below example messages is choose from. All transport parameters SHOULD be included in the     |
   Transport header, the use of other headers for this purpose is         |
   discouraged due to middle boxes.

   For the above case when benefit of any intervening firewalls, a client SHOULD
   indicate the PAUSE request arrives before transport parameters even if it has no influence over
   these parameters, for example, where the first     |
   occurrence server advertises a fixed
   multicast address.

        Since SETUP includes all transport initialization
        information, firewalls and other intermediate network
        devices (which need this information) are spared the more
        arduous task of NPT=14.                                                  | parsing the DESCRIBE response, which has
        been reserved for media initialization.

   In a SETUP response the server SHOULD include the Accept-Ranges
   header (see section 14.4 to indicate which time formats that are
   acceptable to use for this media resource.

     C->S: PLAY rtsp://example.com/fizzle/foo SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0                    |
           CSeq: 834                                                      |
           Session: 12345678                                              |
           Range: npt=10-15, npt=13-20                                    | 302
           Transport: RTP/AVP;unicast;client_port=4588-4589,
                      RTP/AVP/TCP;unicast;interleave=0-1
     S->C: RTSP/1.0 200 OK                                                |
           CSeq: 834                                                      | 302
           Date: 23 Jan 1997 15:35:06 GMT                                 |
           Server: PhonyServer 1.0                                        |
           Range: npt=10-15, npt=13-20                                    |
           RTP-Info:url=rtsp://example.com/fizzle/audiotrack;             |
                   seq=5712;rtptime=934207921,                            |
                   url=rtsp://example.com/fizzle/videotrack;              |
                   seq=57654;rtptime=2792482193                           |
           Session: 12345678                                              |

     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0                   |
           CSeq: 835                                                      |
           Session: 12345678                                              |
           Range: npt=14-                                                 |

     S->C: RTSP/1.0 200 OK                                                |
           CSeq: 835                                                      |
           Date: 23 Jan 1997 15:35:09 GMT                                 |
           Server: PhonyServer 1.0                                        |
           Range: npt=14-15, npt=13-20                                    |
           Session: 12345678                                              |

   If a 47112344
           Transport: RTP/AVP;unicast;client_port=4588-4589;
                      server_port=6256-6257;ssrc=2A3F93ED
           Accept-Ranges: NPT

   In the above example the client issues want to create a PAUSE request RTSP session
   containing the media resource "rtsp://example.com/foo/bar/baz.rm".
   The transport parameters acceptable to the client is either
   RTP/AVP/UDP (UDP per default) to be received on client port 4588 and
   4589 or RTP/AVP interleaved on the RTSP control channel. The server acknowledges
   selects the RTP/AVP/UDP transport and     |
   enters adds the READY state, ports it will send and
   received RTP and RTCP from, and the proper server response, if RTP SSRC that will be used by the player      |
   issues another PAUSE, is still 200 OK.
   server.

   The 200 OK response server MUST        |
   include the Range header with the current pause point, even if the     |
   PAUSE generate a session identifier in response to a
   successful SETUP request, unless a SETUP request is asking for some other pause point. See examples       |
   below:

   Examples:

     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 834
           Session: 12345678

     S->C: RTSP/1.0 200 OK
           CSeq: 834
           Session: 12345678
           Date: 23 Jan 1997 15:35:06 GMT
           Range: npt=45.76-

     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 835
           Session: 12345678
           Range:  86-
     S->C: RTSP/1.0 200 OK
           CSeq: 835
           Session: 12345678
           Date: 23 Jan 1997 15:35:07 GMT
           Range: npt=45.76-

11.6 TEARDOWN

   The TEARDOWN client to a server request stops the stream delivery for    | includes
   a session identifier, in which case the given URI, freeing server MUST bundle this setup
   request into the resources associated with it.  TEARDOWN     |
   MAY existing session (aggregated session) or return
   error 459 (Aggregate Operation Not Allowed) (see Section  13.4.11).
   An Aggregate control URL MUST be done using either used to control an aggregated or a media
   session. This URL MUST be different from the stream control URI.         |
   However some restrictions apply depending on URLs of
   the current state. individual media streams included in the aggregate. The    |
   TEARDOWN request SHALL contain a Session header indicating what        |
   session Aggregate
   control URL is to be specified by the request applies to.                                        |

   A TEARDOWN using session description if the
   server supports aggregated control URI or and aggregated control is desired
   for the media URI in a      |
   session under non-aggregated session. However even if aggregated control is offered the
   client MAY be done in any state (Ready,  |
   and Play). A successful request SHALL result chose to not set up the session in that media delivery    | aggregated control. If
   an Aggregate control URL is immediately halted and not specified in the session state description,
   it is destroyed. This SHALL   | normally an indication that non-aggregated control should be indicated through the lack of a Session header in the response.     |

   A TEARDOWN using a
   used. The SETUP of media URI streams in an aggregate which has not been    |
   given an aggregated control URL is unspecified.

        While the session MAY only be      |
   done in Ready state. Such ID sometimes has enough information for
        aggregate control of a request only removes session, the indicated media   |
   stream and associated resources from Aggregate control URL
        is still important for some methods such as SET_PARAMETER
        where the session.  This may result control URL enables the resource in  |
   that a session returns question to non-aggregated control. In the response
        be easily identified. The Aggregate control URL is also
        useful for proxies, enabling them to   |
   TEARDOWN request resulting in that route the session still exist SHALL       |
   contain a Session header request to indicate this.                             |

   Note,
        the indication with appropriate server, and for logging, where it is useful
        to note the session header if sessions state remain  |
   may not be done correctly by actual resource that a request was operating
        on. Finally, presence of the Aggregate control URL allows
        for backwards compatibility with RFC 2326 client, but [1].

   A session will be for any    |
   server signalling the "play.basic" tag.

   Example:

     C->S: exist until it is either removed by a TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 892
           Session: 12345678

     S->C: RTSP/1.0 200 OK
           CSeq: 892
           Server: PhonyServer 1.0

11.7 GET_PARAMETER

   The GET_PARAMETER request retrieves
   or is timed-out by the value of server. The server MAY remove a parameter of session that
   has not demonstrated liveness signs from the client within a
   presentation or stream specified certain
   timeout period. The default timeout value is 60 seconds; the server
   MAY set this to a different value and indicate so in the URI. If timeout
   field of the Session header is
   present in a request, the value SETUP response. For further
   discussion see chapter  14.37. Signs of liveness for a RTSP session
   are:

        o Any RTSP request from a parameter MUST be retrieved in
   the sessions context. The content of the reply and response is left
   to the implementation.  GET_PARAMETER with no entity body may be used
   to test client or server liveness ("ping").

   Example:

     S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 431
           Content-Type: text/parameters
           Session: 12345678
           Content-Length: 15

           packets_received
           jitter

     C->S: RTSP/1.0 200 OK
           CSeq: 431
           Content-Length: 46
           Content-Type: text/parameters

           packets_received: 10
           jitter: 0.3838

        The "text/parameters" section which includes a Session header
          with that session's ID.

        o If RTP is only used as a transport for the underlying media
          streams, an example type RTCP sender or receiver report from the client for
        parameter. This method is intentionally loosely defined
        with
          any of the intention media streams in that RTSP session.

   If a SETUP request on a session fails for any reason, the reply content session
   state, as well as transport and response
        content will be defined after further experimentation.

11.8 SET_PARAMETER

   This method requests to set the value of a parameter other parameters for a
   presentation or stream specified associated
   streams SHALL remain unchanged from their values as if the SETUP
   request had never been received by the URI. server.

   A client MAY issue a SETUP request for a stream that is RECOMMENDED already set
   up or playing in the session to only contain change transport parameters, which a single parameter
   server MAY allow. If it does not allow this, it MUST respond with
   error 455 (Method Not Valid In This State). Reasons to support
   changing transport parameters, is to allow
   the client for application layer
   mobility and flexibility to determine why utilize the best available transport as
   it becomes available.

   In a SETUP response for a particular request failed. If to change the
   request contains several parameters, transport parameters
   while in Play state, the server MUST only act on SHOULD include the
   request if all of Range to indicate
   from what point the new transport parameters can be set successfully. A are used. Further if RTP
   is used for delivery the server
   MUST allow a parameter to be set repeatedly SHOULD also include the RTP-Info
   header to indicate from what timestamp and RTP sequence number the same value, but it
   MAY disallow changing parameter values.
   change has taken place. If the receiver of the
   request does not understand or can locate a parameter error 451
   (Parameter Not Understood) SHALL be used.  In the case a parameter both RTP-Info and Range is
   not allowed to change included in the error code 458 (Parameter Is Read-Only).
   The
   response body SHOULD contain only the parameters that has errors.
   Otherwise no body SHALL "rtp_time" parameter and range MUST be returned.

   Note: transport parameters for the media stream MUST only
   corresponding time, i.e. be set with used in the SETUP command.

        Restricting setting transport parameters same way as for PLAY to SETUP
   ensure the correct synchronization information is for present.

   If the benefit of firewalls.

        The parameters are split transport parameter change while in PLAY state results in a fine-grained fashion so that
        there can be more meaningful error indications. However, it
        may make sense to allow the setting
   change of several parameters
        if an atomic setting is desirable. Imagine device control
        where synchronization related information, for example changing
   RTP SSRC, the client does not want server MUST provide in the camera to pan unless it
        can also tilt to SETUP response the right angle at necessary
   synchronization information. However the same time.

   Example:

     C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 421
           Content-length: 20
           Content-type: text/parameters

           barparam: barstuff

     S->C: RTSP/1.0 451 Parameter Not Understood
           CSeq: 421
           Content-length: 10
           Content-type: text/parameters

           barparam

        The "text/parameters" section server is only an example type for
        parameter. This RECOMMENDED to
   avoid changing the synchronization information if possible.

11.4 PLAY

   The PLAY method is intentionally loosely defined
        with tells the intention that server to start sending data via the reply content and response
        content will be defined after further experimentation.

11.9 REDIRECT
   mechanism specified in SETUP. A redirect request informs the client that it MUST connect to another  |
   server location. The REDIRECT request MAY contain the header           |
   Location, which indicates that the client should NOT issue requests for    |
   that URL. The lack of a Location header in the response SHALL be       |
   interpreted as that the server can't PLAY request
   until any longer fulfill outstanding SETUP requests have been acknowledged as
   successful. PLAY requests are valid when the current    |
   request, but has no alternative at session is in READY
   state; the present where use of PLAY requests when the client        |
   continue.                                                              |

   If a REDIRECT session is in PLAY state is
   deprecated. A PLAY request contains MUST include a Session header, it is end-to-end and  |
   applies only header to indicate
   which session the given session. If there are proxies in the         | request chain, they SHOULD NOT disconnect applies to.

   In an aggregated session the PLAY request MUST contain an aggregated
   control channel unless   |
   there are no remaining sessions. If URL. A server SHALL responde with error 460 (Only Aggregate
   Operation Allowed) if the Location header client PLAY request URL is included    |
   it SHALL contain a full absolute URI pointing out for one of the resource to      |
   reconnect too, i.e. the Location
   media. The media in an aggregate SHALL NOT contain only host and       |
   port.                                                                  | be played in sync. If a REDIRECT request does not contain a Session header, it is next-   |
   hop and applies also to the client
   want individual control connection.  If of the Location       |
   header is included media it SHOULD only contain an absolute URI containing   |
   the host address and OPTIONAL the port number. If there are proxies    |
   in the must use separate RTSP
   sessions for each media.

   The PLAY request chain, they SHOULD do all of SHALL position the following: (1)         |
   respond normal play time to the REDIRECT request, (2) disconnect the control channel    |
   from beginning
   of the requestor, (3) reconnect to range specified by the given host address, Range header and (4)   |
   pass delivers stream data
   until the request end of the range if given, else to each applicable client (typically those clients    |
   with an active session or unanswered request from the requestor).      |
   Note that end of the proxy media is responsible
   reached. To allow for accepting the REDIRECT          |
   response from its clients and these responses MUST NOT precise composition multiple ranges MAY be passed on    |
   to either the requesting or the destination server.
   specified in one PLAY Request. The redirect request MAY contain the header Range, which indicates
   when range values are valid if all
   given ranges are part of any media within the redirection takes effect. aggregate. If the Range contains a "time=" given
   range value that is the wall clock time that the redirection MUST at the
   latest take place. When points outside of the "time=" parameter is present media, the range
   value MUST response SHALL be ignored. However the range entered MUST be syntactical
   correct
   457 (Invalid Range) error code.

   The below example will first play seconds 10 through 15, then,
   immediately following, seconds 20 to 25, and SHALL point at finally seconds 30
   through the beginning of any on-demand content. If
   no time parameter is part end.

     C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
           CSeq: 835
           Session: 12345678
           Range: npt=10-15, npt=20-25, npt=30-

   See the description of the PAUSE request for further examples.

   A PLAY request without a Range header then redirection is legal. It SHALL
   take place when the media playout start
   playing a stream from the server reaches beginning (npt=0-) unless the given
   time. The range value MUST be stream has
   been paused. If a single value in stream has been paused via PAUSE, stream delivery
   resumes at the open ended form,
   e.g. npt=59-.

   A server upon receiving a successful (2xx) response for a REDIRECT     |
   request without any Range header pause point. The stream SHALL consider play until the session as         |
   removed and can free any session state. For this type end of requests
   the  |
   rest of this paragraph applies. media.

   The server MAY close the signalling    |
   connection upon receiving the response for REDIRECT requests without   | Range header MUST NOT contain a Session header. time parameter. The client SHOULD close the signaling connection     |
   after having given the 2xx response to a REDIRECT response, unless it usage of time  |
   in PLAY method has several sessions on the server. been deprecated. If the client has multiple a request with time parameter   |
   session on
   is received the server it SHOULD close the connection when it has       |
   received and responded to REDIRECT requests for all sessions.          |

   A client receiving a REDIRECT request respond with a Range header SHALL issue 457 (Invalid Range) to    |
   a TEARDOWN request when
   indicate that the in indicated redirect point time parameter is reached. not supported.                     |
   The client SHOULD for REDIRECT requests with Range
   Server MUST include a "Range" header close the in any PLAY response. The         |
   signalling connection after a 2xx
   response on its TEARDOWN request.    |
   The normal connection considerations apply for MUST use the server. This        |
   differentiation from REDIRECT requests without same format as the request's range headers is to header        |
   allow clear an explicit state handling. As the state
   contained. If no Range header was in the server request, the NPT time format  |
   needs to
   SHOULD be kept until the point of redirection, used unless the handling becomes client showed support for an other format    |
   more clear if appropriate. Also for a session with live media streams the client       |
   Range header MUST indicate a valid time. It is required to tear down the session at RECOMMENDED that        |
   point.                                                                 |

   If
   normal play time is used, either the client wants to continue to send or receive media "now" indicator, for this example      |
   resource,
   "npt=now-", or the client will have to establish a new time since session with start as an open interval, e.g.  |
   "npt=96.23-". An absolute time value (clock) for the corresponding     |
   designated host. A client SHOULD issue a new DESCRIBE request with
   time MAY be given, i.e.  "clock=20030213T143205Z-". The UTC clock      |
   the URL given in the Location header, unless the URL
   format SHOULD only contains a   |
   host address. In be used if client has shown support for it.

   A media server only supporting playback MUST support the cases npt format
   and MAY support the Location only contains clock and smpte formats.

   For a host address   | on-demand stream, the client MAY assume server MUST reply with the actual range
   that will be played back. This may differ from the media on requested range if
   alignment of the server it is redirected    | requested range to valid frame boundaries is identical. Identical media means that all
   required for the media configuration    |
   information from source. If no range is specified in the old session
   request, the start position SHALL still be returned in the reply. If
   the medias that are part of an aggregate has different lengths, the
   PLAY request SHALL be performed as long as the given range is valid except
   for any media, for example the host    |
   address. In longest media. Media will be sent
   whenever it is available for the case of absolute URLs in given play-out point.

   After playing the location header desired range, the presentation is NOT               |
   automatically paused, media redirected to delivery simply stops. A PAUSE request     |
   MUST be issued before another PLAY request can be either identical, slightly different or     |
   totally different. issued. Note: This   |
   is the reason why one change resulting in a new DESCRIBE non-operability with RFC 2326             |
   implementations. A client not issuing a PAUSE request before a new     |
   SHOULD
   PLAY will be issued.

   This example request redirects traffic for stuck in PLAY state. To mitigate this session to backwards           |
   compatibility issue the new following behavior is recommended. If a        |
   server at receives a PLAY request when in play state and all media has    |
   finished the given absolute time:

     S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 732
           Location: rtsp://bigserver.com:8001
           Range: npt=0- ;time=19960213T143205Z
           Session: uZ3ci0K+Ld-M

11.10 PING

   This method is requested playout, the server MAY interpret this as a bi-directional mechanism for     |
   PLAY request received in ready state. However the server or SHALL NOT do  |
   this if the client
   liveness checking. It has no side effects. The issuer of the request
   MUST include shown any support for this specification, for   |
   example by sending a session Supported header with the session ID of the session that
   is being checked for liveness.

   Prior to using this method, an OPTIONS method is RECOMMENDED play.basic feature      |
   tag.

   A client desiring to be
   issued in play the direction which media from the PING method would be used. This
   method beginning MUST NOT be used if support is not indicated by the Public
   header. Note: That an 501 (Not Implemented) response means that the
   keep-alive timer has not been updated.

   When send a proxy is in use, PING
   PLAY request with a * indicates Range header pointing at the beginning, e.g.
   npt=0-. If a single-hop liveness
   check, whereas PING PLAY request is received without a Range header when
   media delivery has stopped at the end, the server SHOULD respond with
   a URL including an host address indicates an
   end-to-end liveness check.

   Example: 457 "Invalid Range" error response. In that response the current
   pause point in a Range header SHALL be included.

   The following example plays the whole presentation starting at SMPTE
   time code 0:10:20 until the end of the clip. Note: The RTP-Info
   headers has been broken into several lines to fit the page.

   C->S: PING * PLAY rtsp://audio.example.com/twister.en RTSP/1.0                |
         CSeq: 123
           Session:12345678 833                                                        |
         Session: 12345678                                                |
         Range: smpte=0:10:20-                                            |

   S->C: RTSP/1.0 200 OK                                                  |
         CSeq: 123
           Session:12345678

11.11 Embedded (Interleaved) Binary Data

   Certain firewall designs and other circumstances may force 833                                                        |
         Date: 23 Jan 1997 15:35:06 GMT                                   |
         Server: PhonyServer 1.0                                          |
         Range: smpte=0:10:22-0:15:45                                     |
         RTP-Info:url=rtsp://example.com/twister.en;                      |
            seq=14783;rtptime=2345962545                                  |

   For playing back a server
   to interleave RTSP messages and media stream data. This interleaving
   should generally be avoided unless necessary since it complicates
   client and server operation and imposes additional overhead. Also
   head recording of line blocking a live presentation, it may cause problems.  Interleaved binary data
   SHOULD only be
   desirable to use clock units:

     C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0
           CSeq: 835
           Session: 12345678
           Range: clock=19961108T142300Z-19961108T143520Z

     S->C: RTSP/1.0 200 OK
           CSeq: 835
           Date: 23 Jan 1997 15:35:06 GMT
           Server:PhonyServer 1.0
           Range: clock=19961108T142300Z-19961108T143520Z
           RTP-Info:url=rtsp://example.com/meeting.en;
              seq=53745;rtptime=484589019

   All range specifiers in this specification allow for ranges with
   unspecified begin times (e.g. "npt=-30"). When used if RTSP is carried over TCP.

   Stream data such as RTP packets is encapsulated by an ASCII dollar
   sign (24 decimal), followed by in a one-byte channel identifier,
   followed by the length of PLAY
   request, the encapsulated binary data server treats this as a binary,
   two-byte integer request to start/resume playback
   from the current pause point, ending at the end time specified in network byte order. the
   Range header. If the pause point is located later than the given end
   value, a 457 (Invalid Range) response SHALL be given.

   The stream data follows
   immediately afterwards, without queued play functionality described in RFC 2326 [1] is removed     |
   and multiple ranges can be used to achieve a CRLF, but including the upper-layer
   protocol headers. Each $ block contains exactly one upper-layer
   protocol data unit, e.g., one RTP packet.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | "$" = 24      | Channel ID    | Length in bytes similar functionality.    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      : Length number of bytes of binary data                         :

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The channel identifier is defined
   If a server receives a PLAY request while in the Transport header with the
   interleaved parameter(Section 13.40).

   When the transport choice is RTP, RTCP messages are also interleaved
   by PLAY state, the       |
   server over SHALL responde using the TCP connection. error code 455 (Method Not Valid In    |
   This State). This will signal the client that queued play are not      |
   supported.

   The usage use of RTCP messages is
   indicated by including PLAY for keep-alive signaling, i.e. PLAY request without a
   range containing header in PLAY state, has also been depreciated. Instead a second channel
   client can use, PING, SET_PARAMETER or OPTIONS for keep alive. A
   server receiving a PLAY keep alive SHALL respond with the 455 error
   code.

11.5 PAUSE

   The PAUSE request causes the stream delivery to be interrupted
   (halted) temporarily. A PAUSE request MUST be done with the
   aggregated control URL for aggregated sessions, resulting in all
   media being halted, or the
   interleaved parameter media URL for non-aggregated sessions.
   Any attempt to do muting of the Transport header, see section 13.40. If
   RTCP is used, packets a single media with an PAUSE request in
   an aggregated session SHALL be sent on the first available channel
   higher than responded with error 460 (Only
   Aggregate Operation Allowed). After resuming playback,
   synchronization of the RTP channel. The channels are bi-directional and
   therefore RTCP traffic tracks MUST be maintained. Any server
   resources are sent on kept, though servers MAY close the second channel in both
   directions.

        RTCP is needed session and free
   resources after being paused for synchronization when two or more streams
        are interleaved in such a fashion. Also, this provides a
        convenient way to tunnel RTP/RTCP packets through the TCP
        control connection when required by duration specified with the
   timeout parameter of the Session header in the network
        configuration and transfer them onto UDP when possible.

     C->S: SETUP rtsp://foo.com/bar.file message.

   Example:

     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 2
           Transport: RTP/AVP/TCP;unicast;interleaved=0-1 834
           Session: 12345678

     S->C: RTSP/1.0 200 OK
           CSeq: 2 834
           Date: 05 Jun 23 Jan 1997 18:57:18 15:35:06 GMT
           Transport: RTP/AVP/TCP;unicast;interleaved=5-6
           Session: 12345678
           Range: npt=45.76-

   The PAUSE request MAY contain a Range header specifying when the
   stream or presentation is to be halted. We refer to this point as the
   "pause point". The time parameter in the Range MUST NOT be used. The
   Range header MUST contain a single value, expressed as the beginning
   value an open range. For example, the following clip will be played
   from 10 seconds through 21 seconds of the clip's normal play time,
   under the assumption that the PAUSE request reaches the server within
   11 seconds of the PLAY request. Note that some lines has been broken
   in an non-correct way to fit the page:

     C->S: PLAY rtsp://foo.com/bar.file rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 3 834
           Session: 12345678
           Range: npt=10-30

     S->C: RTSP/1.0 200 OK
           CSeq: 3
           Session: 12345678 834
           Date: 05 Jun 23 Jan 1997 18:59:15 15:35:06 GMT
           RTP-Info: url=rtsp://foo.com/bar.file;
             seq=232433;rtptime=972948234
     S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
     S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
           Server: PhonyServer 1.0
           Range: npt=10-30
           RTP-Info:url=rtsp://example.com/fizzle/audiotrack;
                   seq=5712;rtptime=934207921,
                   url=rtsp://example.com/fizzle/videotrack;
                   seq=57654;rtptime=2792482193
           Session: 12345678

     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 835
           Session: 12345678
           Range: npt=21-

     S->C: $006{2 byte length}{"length" bytes  RTCP packet}

12 Status Code Definitions

   Where applicable, HTTP status [H10] codes are reused. Status codes
   that have the same meaning are not repeated here. See Table 1 for a
   listing of which status codes may be returned by which requests. All
   error messages, 4xx and 5xx MAY return a body containing further
   information about the error.

12.1 Success 1xx

12.1.1 100 Continue

   See, [H10.1.1].

12.2 Success 2xx

12.2.1 250 Low on Storage Space RTSP/1.0 200 OK
           CSeq: 835
           Date: 23 Jan 1997 15:35:09 GMT
           Server: PhonyServer 1.0
           Range: npt=21-
           Session: 12345678

   The server returns this warning after receiving a RECORD pause request that
   it may not be able to fulfill completely due to insufficient storage
   space. If possible, becomes effective the first time the server should use is
   encountering the time point specified in any of the multiple ranges.
   If the Range header to
   indicate what specifies a time period it may still be able to record. Since other
   processes on outside any range from the server may PLAY
   request, the error 457 (Invalid Range) SHALL be consuming storage space
   simultaneously, returned. If a client should take this only media
   unit (such as an estimate.

12.3 Redirection 3xx

   The notation "3rr" indicates response codes from 300 to 399 inclusive
   which are meant for redirection. The response code 304 is excluded
   from this set, as audio or video frame) starts presentation at exactly
   the pause point, it is not used for redirection.

   See [H10.3] for definition of status code 300 to 305. However
   comments are given for some to how they apply to RTSP.

   Within RTSP, redirection may be used for load balancing or
   redirecting played. If the Range header is missing,
   stream requests to a server topologically closer to delivery is interrupted immediately on receipt of the
   client.  Mechanisms message
   and the pause point is set to determine topological proximity are beyond the
   scope of this specification.

   If current normal play time. However,
   the pause point in the Location media stream MUST be maintained. A subsequent
   PLAY request without Range header is used in a response it SHALL contain an   |
   absolute URI pointing out resume from the pause point
   and play until media resource end.

   If the client is redirected  |
   to, server has already sent data beyond the URI SHALL NOT only contain time specified in the host name.

12.3.1 300 Multiple Choices

12.3.2 301 Moved Permanently

   The request resource are moved permanently and resides now
   PAUSE request's Range header, a PLAY without range SHALL resume at
   the URI
   given point in time specified by the location header. The user client SHOULD redirect
   automatically to PAUSE request's Range header, as
   it is assumed that the given URI. client has discarded data after that point.
   This response MUST NOT contain a
   message-body.

12.3.3 302 Found ensures continuous pause/play cycling without gaps.

   The requested resource reside temporarily at pause point after any PAUSE request SHALL be returned to the URI given
   client by the
   Location header. The Location adding a Range header MUST be included in the
   response. Is intended to be used for many types with what remains unplayed of temporary
   redirects, e.g. load balancing. It is RECOMMENDED that one set the
   reason phrase to something more meaningful than "Found" in these
   cases. The user client SHOULD redirect automatically to
   PLAY request's ranges, i.e. including all the given
   URI. This response MUST NOT contain remaining ranges part
   of multiple range specification. If one desires to resume playing a message-body.

12.3.4 303 See Other

   This status code SHALL NOT be used in RTSP. However as it
   ranged request, one simply includes the Range header from the PAUSE
   response. Note that this server behavior was allowed not mandated previously
   and servers implementing according to use in RFC 2326 it is possible that such response may be received.

12.3.5 304 Not Modified

   If the client has performed a conditional DESCRIBE or SETUP (see
   12.23) and the requested resource has will probably not been modified, the server
   SHOULD send a 304 response. This response MUST NOT contain a
   message-body.

   The response MUST include
   return the following header fields:

        o Date

        o ETag and/or Content-Location, range header.

   For example, if the header would server have been
          sent in a 200 response to the same request.

        o Expires, Cache-Control, and/or Vary, if the field-value might
          differ from that sent in any previous response for the same
          variant.

   This response is independent play request for the DESCRIBE ranges 10 to 15
   and SETUP requests.
   That is, a 304 response 20 to DESCRIBE does NOT imply that the resource
   content is unchanged 29 pending and then receives a 304 response to SETUP does NOT imply that pause request for NPT 21, it
   would start playing the resource description is unchanged. The ETag second range and If-Match headers
   may be used to link stop at NPT 21. If the DESCRIBE and SETUP in this manner.

12.3.6 305 Use Proxy

   See [H10.3.6].

12.4 Client Error 4xx

12.4.1 400 Bad Request

   The pause
   request could not be understood by is for NPT 12 and the server due to malformed
   syntax. The client SHOULD NOT repeat is playing at NPT 13 serving the request without
   modifications [H10.4.1].
   first play request, the server stops immediately. If the pause
   request does not have a CSeq header, is for NPT 16, the server MUST NOT include returns a CSeq in the response.

12.4.2 405 Method Not Allowed

   The method specified in 457 error message. To
   prevent that the request second range is not allowed for played and the resource
   identified by server stops after
   completing the request URI. The response MUST include an Allow
   header containing first range, a list of valid methods PAUSE request for the requested resource.
   This status code is also to 20 must be used issued.

   As another example, if a request attempts server has received requests to use a
   method not indicated during SETUP, e.g., if a RECORD play ranges
   10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE
   request is
   issued even though for NPT=14 would take effect while the mode parameter in server plays the Transport header only
   specified PLAY.

12.4.3 451 Parameter Not Understood

   The recipient of first
   range, with the second range effectively being ignored, assuming the
   PAUSE request does not support one or more parameters
   contained in arrives before the request.When returning this error message server has started playing the sender
   SHOULD return a entity body containing
   second, overlapping range. Regardless of when the offending parameter(s).

12.4.4 452 reserved

   This error code was removed from RFC 2326 [21] and is obsolete.

12.4.5 453 Not Enough Bandwidth

   The PAUSE request was refused because there was insufficient bandwidth.
   This may,
   arrives, it sets the pause point to 14. The below example messages is
   for example, be the result above case when the PAUSE request arrives before the first
   occurrence of NPT=14.

     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 834
           Session: 12345678
           Range: npt=10-15, npt=13-20

     S->C: RTSP/1.0 200 OK
           CSeq: 834
           Date: 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer 1.0
           Range: npt=10-15, npt=13-20
           RTP-Info:url=rtsp://example.com/fizzle/audiotrack;
                   seq=5712;rtptime=934207921,
                   url=rtsp://example.com/fizzle/videotrack;
                   seq=57654;rtptime=2792482193
           Session: 12345678

     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 835
           Session: 12345678
           Range: npt=14-

     S->C: RTSP/1.0 200 OK
           CSeq: 835
           Date: 23 Jan 1997 15:35:09 GMT
           Server: PhonyServer 1.0
           Range: npt=14-15, npt=13-20
           Session: 12345678

   If a resource reservation
   failure.

12.4.6 454 Session Not Found client issues a PAUSE request and the server acknowledges and
   enters the READY state, the proper server response, if the player
   issues another PAUSE, is still 200 OK. The RTSP session identifier in 200 OK response MUST
   include the Session Range header with the current pause point, even if the
   PAUSE request is missing,
   invalid, or has timed out.

12.4.7 455 Method Not Valid in This State asking for some other pause point. See examples
   below:

   Examples:                                                              |

     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0                   |
           CSeq: 834                                                      |
           Session: 12345678                                              |

     S->C: RTSP/1.0 200 OK                                                |
           CSeq: 834                                                      |
           Session: 12345678                                              |
           Date: 23 Jan 1997 15:35:06 GMT                                 |
           Range: npt=45.76-98.36                                         |

     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0                   |
           CSeq: 835                                                      |
           Session: 12345678                                              |
           Range: 86-                                                     |

     S->C: RTSP/1.0 200 OK                                                |
           CSeq: 835                                                      |
           Session: 12345678                                              |
           Date: 23 Jan 1997 15:35:07 GMT                                 |
           Range: npt=45.76-98.36                                         |

11.6 TEARDOWN

   The TEARDOWN client or to server cannot process this request in its stops the stream delivery for
   the given URL, freeing the resources associated with it.  TEARDOWN
   MAY be done using either an aggregated or a media control URL.

   However some restrictions apply depending on the current state. The response SHOULD
   TEARDOWN request SHALL contain an Allow header to make error
   recovery easier.

12.4.8 456 Header Field Not Valid for Resource

   The server could not act on a required request header. For example,
   if PLAY contains the Range Session header field but the stream does not allow
   seeking. This error message may also be used for specifying when indicating what
   session the
   time format in Range is impossible for request applies to.

   A TEARDOWN using the resource. In that case aggregated control URL or the
   Accept-Ranges header SHOULD media URL in a
   session under non-aggregated control MAY be returned to inform the client of which
   format(s) done in any state (Ready,
   and Play). A successful request SHALL result in that are allowed.

12.4.9 457 Invalid Range

   The Range value given media delivery
   is out of bounds, e.g., beyond the end of immediately halted and the
   presentation.

12.4.10 458 Parameter Is Read-Only

   The parameter to be set by SET_PARAMETER can session state is destroyed. This SHALL
   be read but not
   modified. When returning this error message indicated through the sender SHOULD return lack of a entity body containing the offending parameter(s).

12.4.11 459 Aggregate Operation Not Allowed

   The requested method may not be applied on Session header in the response.

   A TEARDOWN using a media URL in question since
   it is an aggregate (presentation) URL. The method may aggregated session MAY only be applied on      |
   done in Ready state. Such a request only removes the indicated media URL.

12.4.12 460 Only Aggregate Operation Allowed

   The requested method may not be applied on   |
   stream and associated resources from the URL session.  This may result in question since  |
   that a session returns to non-aggregated control, due to that it is not an aggregate control (presentation) URL. The method may be
   applied on only  |
   contains a single media. In the aggregate control URL.

12.4.13 461 Unsupported Transport

   The Transport field did not response to TEARDOWN request           |
   resulting in that the session still exist SHALL contain a supported transport
   specification.

12.4.14 462 Destination Unreachable

   The data transmission channel could not be established because Session      |
   header to indicate this.

   Note, the
   client address could indication with the session header if sessions state remain
   may not be reached. This error done correctly by a RFC 2326 client, but will most likely be for any
   server signalling the result "play.basic" tag.

   Example:

     C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 892
           Session: 12345678

     S->C: RTSP/1.0 200 OK
           CSeq: 892
           Server: PhonyServer 1.0

11.7 GET_PARAMETER

   The GET_PARAMETER request retrieves the value of a client attempt to place an invalid Destination parameter in the Transport field.

12.5 Server Error 5xx

12.5.1 551 Option not supported

   An feature-tag given in the Require or the Proxy-Require fields was
   not supported. The Unsupported header SHOULD be returned stating the
   feature        |
   parameters for which there is no support.

13 Header Field Definitions

             method        direction      object acronym Body
             _________________________________________________
             DESCRIBE      C -> S         P,S    DES     r
             GET_PARAMETER C -> S, S -> C P,S    GPR     R,r
             OPTIONS       C -> S         P,S    OPT
                           S -> C
             PAUSE         C -> S         P,S    PSE
             PING          C -> S, S -> C P,S    PNG
             PLAY          C -> S         P,S    PLY
             REDIRECT      S -> C         P,S    RDR
             SETUP         C -> S         S      STP
             SET_PARAMETER C -> S, S -> C P,S    SPR     R,r
             TEARDOWN      C -> S         P,S    TRD

   Table 3: Overview of RTSP methods, their direction, and what  objects
   (P:  presentation, S: stream) they operate on. Body notes if a method
   is allowed to carry  body  and presentation or stream specified in  which  direction,  R  =  Request,
   r=response. Note: It is allowed for all error messages 4xx and 5xx to
   have a body

   The general syntax for the URL. If the   |
   Session header fields is covered present in Section 4.2 This
   section lists a request, the full set of header fields along with notes on
   syntax, meaning, and usage.  Throughout this section, we use [HX.Y]
   to refer to Section X.Y value of a parameter MUST  |
   be retrieved in the current HTTP/1.1 specification RFC
   2616 [26].  Examples specified session context.  The content of each header field are given.

   Information about header fields in relation to methods the     |
   reply and proxy
   processing response is summarized in Table 4 and Table 5. left to the implementation.                      |

   The "where" column describes method MAY also be used without a body (entity). If the this       |
   request and is successful, i.e. a 200 OK response types in which is received, then the    |
   keep-alive time has been updated. Any non-required header field can be used. Values present in this column are:

        R: header field   |
   such a request, may only appear in requests;

        r: header field may only appear in responses;

        2xx, 4xx, etc.: A numerical value or range indicates response
             codes with which the header field can be used;
        c: may not been processed. The allow a client to   |
   determine if any such header field has been processed, it is copied from the request necessary to    |
   use a feature tag and the response.

   An empty entry in the "where" column indicates Require header. Due to this reason it is     |
   RECOMMENDED that the header field
   may any parameters to be present retrieved are sent in all requests and responses.

   The "proxy" column describes the operations a proxy may perform on a
   header field:

        a: A proxy can add or concatenate the header field if not
             present.

        m: A proxy can modify body,  |
   rather than using any header.

   Example:

     S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 431
           Content-Type: text/parameters
           Session: 12345678
           Content-Length: 15

           packets_received
           jitter

     C->S: RTSP/1.0 200 OK
           CSeq: 431
           Content-Length: 46
           Content-Type: text/parameters

           packets_received: 10
           jitter: 0.3838

        The "text/parameters" section is only an existing header field value.

        d: A proxy can delete a header field value.

        r: A proxy must be able to read example type for
        parameter. This method is intentionally loosely defined
        with the header field, intention that the reply content and thus this
             header field cannot response
        content will be encrypted.

   The rest of the columns relate defined after further experimentation.

11.8 SET_PARAMETER

   This method requests to set the presence value of a header field in parameter or a
   method. The method names when abbreviated, are according to table 3:

        c: Conditional; requirements on the header field depend on the
             context set of       |
   parameters for a presentation or stream specified by the message.

        m: The header field is mandatory.

        m*: URL. The header field SHOULD be sent, but clients/servers need to      |
   method MAY also be prepared to receive messages used without that header field.

        o: The header field is optional.

        *: The header field is required if the message a body (entity). If the this request   |
   is not
             empty. See sections 13.14, 13.16 and 4.3 for details.

        -: The header field is not applicable.

   "Optional" means that successful, i.e. a Client/Server MAY include 200 OK response is received, then the keep-      |
   alive time has been updated. Any non-required header field present in such   |
   a request request, may or response, and may not been processed. The allow a Client/Server MAY ignore the header
   field client to        |
   determine if present in any such header has been processed, it is necessary to    |
   use a feature tag and the request or response (The exception Require header. Due to this
   rule reason it is the Require header field discussed     |
   RECOMMENDED that any parameters are sent in 13.32). the body, rather than      |
   using any header.

   A "mandatory"
   header field MUST be present in request is RECOMMENDED to only contain a request, and MUST be understood by single parameter to allow
   the Client/Server receiving client to determine why a particular request failed. If the request. A mandatory response header
   field
   request contains several parameters, the server MUST be present in only act on the response, and
   request if all of the header field parameters can be set successfully. A server
   MUST allow a parameter to be
   understood by set repeatedly to the Client/Server processing same value, but it
   MAY disallow changing parameter values.  If the response. "Not
   applicable" means that receiver of the header field MUST NOT be present in a
   request. If one is placed in a
   request by mistake, it MUST does not understand or can locate a parameter error 451
   (Parameter Not Understood) SHALL be ignored
   by the Client/Server receiving used.  In the request. Similarly, a header field
   labeled "not applicable" for case a response means that the Client/Server
   MUST NOT place parameter is
   not allowed to change the header field in error code 458 (Parameter Is Read-Only).
   The response body SHOULD contain only the response, and parameters that has errors.
   Otherwise no body SHALL be returned.

   Note: transport parameters for the
   Client/Server media stream MUST ignore only be set with
   the header field in SETUP command.

        Restricting setting transport parameters to SETUP is for
        the response.

   A Client/Server SHOULD ignore extension header benefit of firewalls.

        The parameters that are
   not understood.

   The From, Location, and RTP-Info header fields contain a URI. If the
   URI contains split in a comma, or semicolon, the URI MUST fine-grained fashion so that
        there can be enclosed in
   double quotas ("). Any URI parameters are contained within these
   quotas. If more meaningful error indications. However, it
        may make sense to allow the URI is not enclosed in double quotas, any semicolon-
   delimited setting of several parameters are header-parameters,
        if an atomic setting is desirable. Imagine device control
        where the client does not URI parameters.

13.1 Accept

   The Accept request-header field want the camera to pan unless it
        can be used also tilt to specify certain
   presentation description content types which are acceptable for the
   response. right angle at the same time.

   Example:

     C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 421
           Content-length: 20
           Content-type: text/parameters

           barparam: barstuff

     S->C: RTSP/1.0 451 Parameter Not Understood
           CSeq: 421
           Content-length: 10
           Content-type: text/parameters

           barparam

        The "level" parameter "text/parameters" section is only an example type for presentation descriptions
        parameter. This method is
        properly intentionally loosely defined as part of
        with the MIME type registration, not
        here.

   See [H14.1] for syntax.

   Example of use:

     Accept: application/rtsl q=1.0, application/sdp;level=2

13.2 Accept-Encoding

   See [H14.3]

13.3 Accept-Language

   See [H14.4]. Note intention that the language specified applies to the
   presentation description reply content and any reason phrases, not response
        content will be defined after further experimentation.

11.9 REDIRECT

   A redirect request informs the media
   content.

13.4 Accept-Ranges client that it MUST connect to another
   server location. The Accept-Ranges response-header field allows REDIRECT request MAY contain the server to indicate
   its acceptance of range header
   Location, which indicates that the client should issue requests and possible formats for
   that URL. The lack of a resource:  |
   Accept-Ranges      =  "Accept-Ranges" ":" acceptable-ranges            |
   acceptable-ranges  =  1#range-unit / "none"                            |
   range-unit         =  NPT / SMPTE / UTC / extension-format             |
   extension-format   =  token                                            |

   This Location header has in the same syntax response SHALL be
   interpreted as [H14.5]. However new range-units    |
   are defined. Inclusion of any of the time formats indicates            |
   acceptance by that the server for PLAY and PAUSE requests with this         |
   format. The headers value is valid for can't any longer fulfill the resource specified by current
   request, but has no alternative at the   |
   URI in present where the request, this response corresponds to. A server client can
   continue.

   If a REDIRECT request contains a Session header, it is SHOULD   | end-to-end and
   applies only to use this header the given session. If there are proxies in SETUP responses the
   request chain, they SHOULD NOT disconnect the control channel unless
   there are no remaining sessions. If the Location header is included
   it SHALL contain a full absolute URL pointing out the resource to indicate
   reconnect too, i.e. the Location SHALL NOT contain only host and
   port.

   If a REDIRECT request does not contain a Session header, it is next-
   hop and applies also to the client which  |
   range time formats control connection.  If the media supports. The Location
   header SHOULD also be       | is included it SHOULD only contain an absolute URL containing
   the host address and OPTIONAL the port number. If there are proxies
   in "456" responses which the request chain, they SHOULD do all of the following: (1)
   respond to the REDIRECT request, (2) disconnect the control channel
   from the requestor, (3) reconnect to the given host address, and (4)
   pass the request to each applicable client (typically those clients
   with an active session or unanswered request from the requestor).
   Note that the proxy is responsible for accepting the REDIRECT
   response from its clients and these responses MUST NOT be passed on
   to either the requesting or the destination server.

   A REDIRECT request with a Session header MAY only be received by a result of use of unsupported     |
   range formats.
   client when it has the established session. A REDIRECT request         |

13.5 Allow
   without a Session MAY be received at any time communication is         |
   established with the server.

   The Allow entity-header field lists redirect request MAY contain the methods supported by header Range, which indicates
   when the
   resource identified by redirection takes effect. If the request-URI. The purpose of this field Range contains a "time="
   value that is
   to strictly inform the recipient wall clock time that the redirection MUST at the
   latest take place. When the "time=" parameter is present the range
   value MUST be ignored. However the range entered MUST be syntactical
   correct and SHALL point at the beginning of any on-demand content. If
   no time parameter is part of valid methods associated with the
   resource. An Allow Range header field then redirection SHALL
   take place when the media playout from the server reaches the given
   time. The range value MUST be present a single value in the open ended form,
   e.g. npt=59-.

   A server upon receiving a 405 (Method Not
   Allowed) response. See [H14.7] successful (2xx) response for syntax definition.

   Example a REDIRECT
   request without any Range header SHALL consider the session as
   removed and can free any session state.  For this type of use:

     Allow: SETUP, PLAY, SET_PARAMETER

13.6 Authorization

   See [H14.8]

13.7 Bandwidth requests
   the rest of this paragraph applies. The Bandwidth request-header field describes server MAY close the estimated bandwidth
   available to
   signalling connection upon receiving the client, expressed as response for REDIRECT
   requests without a positive integer and measured
   in bits per second. Session header. The bandwidth available client SHOULD close the
   signaling connection after having given the 2xx response to a
   REDIRECT response, unless it has several sessions on the server. If
   the client may change
   during an RTSP session, e.g., due has multiple session on the server it SHOULD close the
   connection when it has received and responded to modem retraining.

   Bandwidth  =  "Bandwidth" ":" 1*DIGIT REDIRECT requests
   for all sessions.

   A client receiving a REDIRECT request with a Range header SHALL issue
   a TEARDOWN request when the in indicated redirect point is reached.
   The client SHOULD for REDIRECT requests with Range header close the
   signalling connection after a 2xx response on its TEARDOWN request.
   The normal connection considerations apply for the server. This
   differentiation from REDIRECT requests without range headers is to
   allow clear an explicit state handling. As the state in the server
   needs to be kept until the point of redirection, the handling becomes
   more clear if the client is required to tear down the session at that
   point.

   If the client wants to continue to send or receive media for this
   resource, the client will have to establish a new session with the
   designated host. A client SHOULD issue a new DESCRIBE request with
   the URL given in the Location header, unless the URL only contains a
   host address. In the cases the Location only contains a host address
   the client MAY assume that the media on the server it is redirected
   to is identical. Identical media means that all media configuration
   information from the old session still is valid except for the host
   address. In the case of absolute URLs in the location header the
   media redirected to can be either identical, slightly different or
   totally different. This is the reason why a new DESCRIBE request
   SHOULD be issued.

   This example request redirects traffic for this session to the new
   server at the given absolute time:

     S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 732
           Location: rtsp://s2.example.com:8001
           Range: npt=0- ;time=19960213T143205Z
           Session: uZ3ci0K+Ld-M

11.10 PING
   This method is a bi-directional mechanism for server or client
   liveness checking. It has no side effects. The issuer of the request
   MUST include a session header with the session ID of the session that
   is being checked for liveness.

   Prior to using this method, an OPTIONS method is RECOMMENDED to be
   issued in the direction which the PING method would be used. This
   method MUST NOT be used if support is not indicated by the Public
   header. Note: That an 501 (Not Implemented) response means that the
   keep-alive timer has not been updated.

   When a proxy is in use, PING with a * indicates a single-hop liveness
   check, whereas PING with a URL including an host address indicates an
   end-to-end liveness check.

   Example:

     C->S: PING * RTSP/1.0
           CSeq: 123
           Session:12345678

     S->C: RTSP/1.0 200 OK
           CSeq: 123
           Session:12345678

12 Embedded (Interleaved) Binary Data

   Certain firewall designs and other circumstances may force a server
   to interleave RTSP messages and media stream data. This interleaving
   should generally be avoided unless necessary since it complicates
   client and server operation and imposes additional overhead. Also
   head of line blocking may cause problems.  Interleaved binary data
   SHOULD only be used if RTSP is carried over TCP.

   Stream data such as RTP packets is encapsulated by an ASCII dollar
   sign (24 decimal), followed by a one-byte channel identifier,
   followed by the length of the encapsulated binary data as a binary,
   two-byte integer in network byte order. The stream data follows
   immediately afterwards, without a CRLF, but including the upper-layer
   protocol headers. Each $ block SHALL contain exactly one upper-layer
   protocol data unit, e.g., one RTP packet.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | "$" = 24      | Channel ID    | Length in bytes               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      : Length number of bytes of binary data                         :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The channel identifier is defined in the Transport header with the
   interleaved parameter(Section 14.40).

   When the transport choice is RTP, RTCP messages are also interleaved
   by the server over the TCP connection. The usage of RTCP messages is
   indicated by including a range containing a second channel in the
   interleaved parameter of the Transport header, see section 14.40. If
   RTCP is used, packets SHALL be sent on the first available channel
   higher than the RTP channel. The channels are bi-directional and
   therefore RTCP traffic are sent on the second channel in both
   directions.

        RTCP is needed for synchronization when two or more streams
        are interleaved in such a fashion. Also, this provides a
        convenient way to tunnel RTP/RTCP packets through the TCP
        control connection when required by the network
        configuration and transfer them onto UDP when possible.

     C->S: SETUP rtsp://example.com/bar.file RTSP/1.0                     |
           CSeq: 2                                                        |
           Transport: RTP/AVP/TCP;unicast;interleaved=0-1                 |

     S->C: RTSP/1.0 200 OK                                                |
           CSeq: 2                                                        |
           Date: 05 Jun 1997 18:57:18 GMT                                 |
           Transport: RTP/AVP/TCP;unicast;interleaved=5-6                 |
           Session: 12345678                                              |

     C->S: PLAY rtsp://example.com/bar.file RTSP/1.0                      |
           CSeq: 3                                                        |
           Session: 12345678                                              |

     S->C: RTSP/1.0 200 OK                                                |
           CSeq: 3                                                        |
           Session: 12345678                                              |
           Date: 05 Jun 1997 18:59:15 GMT                                 |
           RTP-Info: url=rtsp://example.com/bar.file;                     |
             seq=232433;rtptime=972948234                                 |

     S->C: $005{2 byte length}{"length" bytes data, w/RTP header}         |
     S->C: $005{2 byte length}{"length" bytes data, w/RTP header}         |
     S->C: $006{2 byte length}{"length" bytes  RTCP packet}               |

13 Status Code Definitions

   Where applicable, HTTP status [H10] codes are reused. Status codes
   that have the same meaning are not repeated here. See Table 4 for a
   listing of which status codes may be returned by which requests. All
   error messages, 4xx and 5xx MAY return a body containing further
   information about the error.

13.1 Success 1xx

13.1.1 100 Continue

   See, [H10.1.1].

13.2 Success 2xx

13.3 Redirection 3xx

   The notation "3rr" indicates response codes from 300 to 399 inclusive
   which are meant for redirection. The response code 304 is excluded
   from this set, as it is not used for redirection.

   See [H10.3] for definition of status code 300 to 305. However
   comments are given for some to how they apply to RTSP.

   Within RTSP, redirection may be used for load balancing or
   redirecting stream requests to a server topologically closer to the
   client.  Mechanisms to determine topological proximity are beyond the
   scope of this specification.

   A 3rr code MAY be used to respond to any request. It is RECOMMENDED    |
   that they are used if necessary before a session is established, i.e.  |
   in response to DESCRIBE or SETUP. However in cases where a server is   |
   not able to send a REDIRECT request to the client, the server MAY      |
   need to resort to using 3rr responses to inform a client with a        |
   established session about the need for redirecting the session. If an  |
   3rr response is received for an request in relation to a established   |
   session, the client SHOULD send a TEARDOWN request for the session,    |
   and MAY reestablish the session using the resource indicated by the    |
   Location.

   If the the Location header is used in a response it SHALL contain an
   absolute URL pointing out the media resource the client is redirected
   to, the URL SHALL NOT only contain the host name.

13.3.1 300 Multiple Choices

13.3.2 301 Moved Permanently

   The request resource are moved permanently and resides now at the URL
   given by the location header. The user client SHOULD redirect
   automatically to the given URL. This response MUST NOT contain a
   message-body.

13.3.3 302 Found

   The requested resource reside temporarily at the URL given by the
   Location header. The Location header MUST be included in the
   response. Is intended to be used for many types of temporary
   redirects, e.g. load balancing. It is RECOMMENDED that one set the
   reason phrase to something more meaningful than "Found" in these
   cases. The user client SHOULD redirect automatically to the given
   URL. This response MUST NOT contain a message-body.

13.3.4 303 See Other

   This status code SHALL NOT be used in RTSP. However as it was allowed  |
   to use in RFC 2326 it is possible that such response may be received,  |
   in which case the behavior is undefined.

13.3.5 304 Not Modified

   If the client has performed a conditional DESCRIBE or SETUP (see
   12.23) and the requested resource has not been modified, the server
   SHOULD send a 304 response. This response MUST NOT contain a
   message-body.

   The response MUST include the following header fields:

        o Date

        o ETag and/or Content-Location, if the header would have been
          sent in a 200 response to the same request.

        o Expires, Cache-Control, and/or Vary, if the field-value might
          differ from that sent in any previous response for the same
          variant.

   This response is independent for the DESCRIBE and SETUP requests.
   That is, a 304 response to DESCRIBE does NOT imply that the resource
   content is unchanged and a 304 response to SETUP does NOT imply that
   the resource description is unchanged. The ETag and If-Match headers
   may be used to link the DESCRIBE and SETUP in this manner.

13.3.6 305 Use Proxy

   See [H10.3.6].

13.4 Client Error 4xx

13.4.1 400 Bad Request

   The request could not be understood by the server due to malformed
   syntax. The client SHOULD NOT repeat the request without
   modifications [H10.4.1]. If the request does not have a CSeq header,
   the server MUST NOT include a CSeq in the response.

13.4.2 405 Method Not Allowed

   The method specified in the request is not allowed for the resource
   identified by the request URL. The response MUST include an Allow
   header containing a list of valid methods for the requested resource.
   This status code is also to be used if a request attempts to use a
   method not indicated during SETUP, e.g., if a RECORD request is
   issued even though the mode parameter in the Transport header only
   specified PLAY.

13.4.3 451 Parameter Not Understood

   The recipient of the request does not support one or more parameters
   contained in the request.When returning this error message the sender
   SHOULD return a entity body containing the offending parameter(s).

13.4.4 452 reserved

   This error code was removed from RFC 2326 [1] and is obsolete.

13.4.5 453 Not Enough Bandwidth

   The request was refused because there was insufficient bandwidth.
   This may, for example, be the result of a resource reservation
   failure.

13.4.6 454 Session Not Found

   The RTSP session identifier in the Session header is missing,
   invalid, or has timed out.

13.4.7 455 Method Not Valid in This State

   The client or server cannot process this request in its current
   state.  The response SHOULD contain an Allow header to make error
   recovery easier.

13.4.8 456 Header Field Not Valid for Resource

   The server could not act on a required request header. For example,
   if PLAY contains the Range header field but the stream does not allow
   seeking. This error message may also be used for specifying when the
   time format in Range is impossible for the resource. In that case the
   Accept-Ranges header SHOULD be returned to inform the client of which
   format(s) that are allowed.

13.4.9 457 Invalid Range

   The Range value given is out of bounds, e.g., beyond the end of the
   presentation.

13.4.10 458 Parameter Is Read-Only

   The parameter to be set by SET_PARAMETER can be read but not
   modified. When returning this error message the sender SHOULD return
   a entity body containing the offending parameter(s).

13.4.11 459 Aggregate Operation Not Allowed

   The requested method may not be applied on the URL in question since
   it is an aggregate (presentation) URL. The method may be applied on a
   media URL.

13.4.12 460 Only Aggregate Operation Allowed

   The requested method may not be applied on the URL in question since
   it is not an aggregate control (presentation) URL. The method may be
   applied on the aggregate control URL.

13.4.13 461 Unsupported Transport

   The Transport field did not contain a supported transport
   specification.

13.4.14 462 Destination Unreachable

   The data transmission channel could not be established because the
   client address could not be reached. This error will most likely be
   the result of a client attempt to place an invalid Destination
   parameter in the Transport field.

13.5 Server Error 5xx

13.5.1 551 Option not supported

   An feature-tag given in the Require or the Proxy-Require fields was
   not supported. The Unsupported header SHOULD be returned stating the
   feature for which there is no support.

14 Header Field Definitions

             method        direction      object acronym Body
             _________________________________________________
             DESCRIBE      C -> S         P,S    DES     r
             GET_PARAMETER C -> S, S -> C P,S    GPR     R,r
             OPTIONS       C -> S         P,S    OPT
                           S -> C
             PAUSE         C -> S         P,S    PSE
             PING          C -> S, S -> C P,S    PNG
             PLAY          C -> S         P,S    PLY
             REDIRECT      S -> C         P,S    RDR
             SETUP         C -> S         S      STP
             SET_PARAMETER C -> S, S -> C P,S    SPR     R,r
             TEARDOWN      C -> S         P,S    TRD

   Table 8: Overview of RTSP methods, their direction, and what  objects
   (P:  presentation, S: stream) they operate on. Body notes if a method
   is allowed to carry  body  and  in  which  direction,  R  =  Request,
   r=response. Note: It is allowed for all error messages 4xx and 5xx to
   have a body

   The general syntax for header fields is covered in Section 4.2 This
   section lists the full set of header fields along with notes on
   meaning, and usage. The syntax definition for headers are present in
   section 17.2.3. Throughout this section, we use [HX.Y] to refer to
   Section X.Y of the current HTTP/1.1 specification RFC 2616 [4].
   Examples of each header field are given.

   Information about header fields in relation to methods and proxy
   processing is summarized in Table 9 and Table 10.

   The "where" column describes the request and response types in which
   the header field can be used. Values in this column are:

        R: header field may only appear in requests;

        r: header field may only appear in responses;

        2xx, 4xx, etc.: A numerical value or range indicates response
             codes with which the header field can be used;

        c: header field is copied from the request to the response.

   An empty entry in the "where" column indicates that the header field
   may be present in all requests and responses.

   The "proxy" column describes the operations a proxy may perform on a
   header field:

        a: A proxy can add or concatenate the header field if not
             present.

        m: A proxy can modify an existing header field value.

        d: A proxy can delete a header field value.

        r: A proxy must be able to read the header field, and thus this
             header field cannot be encrypted.

   The rest of the columns relate to the presence of a header field in a
   method. The method names when abbreviated, are according to table 8:

        c: Conditional; requirements on the header field depend on the
             context of the message.

        m: The header field is mandatory.

        m*: The header field SHOULD be sent, but clients/servers need to
             be prepared to receive messages without that header field.

        o: The header field is optional.

        *: The header field is required if the message body is not
             empty. See sections 14.14, 14.16 and 4.3 for details.

        -: The header field is not applicable.
        "Optional" means that a Client/Server MAY include the header      |
        field in a request or response. The Client/Server behavior when   |
        receiving such headers varies, for some it may ignore the header  |
        field, in other case it is request to process the header. This    |
        is regulated by the method and header descriptions. Example of    |
        such headers that require processing are the Require and Proxy-   |
        Require header fields discussed in 14.32 and 14.27. A             |
        "mandatory" header field MUST be present in a request, and MUST   |
        be understood by the Client/Server receiving the request. A       |
        mandatory response header field MUST be present in the response,  |
        and the header field MUST be understood by the Client/Server      |
        processing the response. "Not applicable" means that the header   |
        field MUST NOT be present in a request. If one is placed in a     |
        request by mistake, it MUST be ignored by the Client/Server       |
        receiving the request. Similarly, a header field labeled "not     |
        applicable" for a response means that the Client/Server MUST NOT  |
        place the header field in the response, and the Client/Server     |
        MUST ignore the header field in the response.

   A Client/Server SHOULD ignore extension header parameters that are
   not understood.

   The From, Location, and RTP-Info header fields contain a URL. If the
   URL contains a comma, or semicolon, the URL MUST be enclosed in
   double quotas ("). Any URL parameters are contained within these
   quotas. If the URL is not enclosed in double quotas, any semicolon-
   delimited parameters are header-parameters, not URL parameters.

14.1 Accept

   The Accept request-header field can be used to specify certain
   presentation description content types which are acceptable for the
   response.

        The "level" parameter for presentation descriptions is
        properly defined as part of the MIME type registration, not
        here.

   See [H14.1] for syntax.

   Example of use:                                                        |

     Accept: application/rtsl q=1.0, application/sdp                      |

14.2 Accept-Encoding
   See [H14.3]

14.3 Accept-Language

   See [H14.4]. Note that the language specified applies to the
   presentation description and any reason phrases, not the media
   content.

14.4 Accept-Ranges

   The Accept-Ranges response-header field allows the server to indicate
   its acceptance of range requests and possible formats for a resource:

   Accept-Ranges: NPT, SMPTE

   This header has the same syntax as [H14.5] and the syntax is defined
   in 17.2.3. However new range-units are defined. Inclusion of any of
   the time formats indicates acceptance by the server for PLAY and
   PAUSE requests with this format. The headers value is valid for the
   resource specified by the URL in the request, this response
   corresponds to. A server SHOULD use this header in SETUP responses to
   indicate to the client which range time formats the media supports.
   The header SHOULD also be included in "456" responses which is a
   result of use of unsupported range formats.

14.5 Allow

   The Allow entity-header field lists the methods supported by the
   resource identified by the request-URL. The purpose of this field is
   to strictly inform the recipient of valid methods associated with the
   resource. An Allow header field MUST be present in a 405 (Method Not
   Allowed) response. See [H14.7] for syntax definition.

   Example of use:

     Allow: SETUP, PLAY, SET_PARAMETER

14.6 Authorization

   See [H14.8]

14.7 Bandwidth
   Header              Where  Proxy DES OPT SETUP PLAY PAUSE TRD
   _____________________________________________________________
   Accept                R           o   -    -    -     -   -
   Accept-Encoding       R      r    o   -    -    -     -   -
   Accept-Language       R      r    o   -    -    -     -   -
   Accept-Ranges         r      r    -   -    o    -     -   -
   Accept-Ranges        456     r    -   -    -    o     o   -
   Allow                 r           -   o    -    -     -   -
   Allow                405          -   -    -          m   m   -    m    m     m   m
   Authorization         R           o   o    o    o     o   o
   Bandwidth             R           o   o    o    o     -   -
   Blocksize             R           o   -    o    o     -   -
   Cache-Control                r    -   -    o    -     -   -
   Connection                        o   o    o    o     o   o
   Content-Base          r           o   -    -    -     -   -
   Content-Base         4xx          o   o    o    o     o   o
   Content-Encoding      R      r    -   -    -    -     -   -
   Content-Encoding      r      r    o   -    -    -     -   -
   Content-Encoding     4xx     r    o   o    o    o     o   o
   Content-Language      R      r    -   -    -    -     -   -
   Content-Language      r      r    o   -    -    -     -   -
   Content-Language     4xx     r    o   o    o    o     o   o
   Content-Length        r      r    *   -    -    -     -   -
   Content-Length       4xx     r    *   *    *    *     *   *
   Content-Location      r           o   -    -    -     -   -
   Content-Location     4xx          o   o    o    o     o   o
   Content-Type          r           *   -    -    -     -   -
   Content-Type         4xx          *   *    *    *     *   *
   CSeq                 Rc           m   m    m    m     m   m
   Date                        am    o   o    o    o     o   o
   Expires               r      r    o   -    -    -     -   -
   From                  R      r    o   o    o    o     o   o
   Host                              -   -    -    -     -   -
   If-Match              R      r    -   -    o    -     -   -
   If-Modified-Since     R      r    o   -    o    -     -   -
   Last-Modified         r      r    o   -    -    -     -   -
   Location             3rr          o   o    o    o     o   o
   Proxy-Authenticate   407    amr   m   m    m    m     m   m
   Proxy-Require         R     ar    o   o    o    o     o   o
   Public                r    admr   -  m*    -    -     -   -
   Public               501   admr  m*  m*   m*    m*   m*   m*
   Range                 R           -   -    -    o     o   -
   Range                 r           -   -    c    m*   m*   -
   Referer               R           o   o    o    o     o   o
   Require               R           o   o    o    o     o   o
   Retry-After        3rr,503        o   o    o    -     -   -
   Header           Where Proxy DES OPT SETUP PLAY PAUSE TRD
   _________________________________________________________
   Scale                         -   -    -    o     -   -
   Session            R          -   o    o    m     m   m
   Session            r          -   c    m    m     m   o
   Server             R          -   o    -    -     -   -
   Server             r          o   o    o    o     o   o
   Speed                         -   -    -    o     -   -
   Supported          R          o   o    o    o     o   o
   Supported          r          c   c    c    c     c   c
   Timestamp          R          o   o    o    o     o   o
   Timestamp          c          m   m    m    m     m   m
   Transport                     -   -    m    -     -   -
   Unsupported        r          c   c    c    c     c   c
   User-Agent         R         m*  m*   m*    m*   m*   m*
   Vary               r          c   c    c    c     c   c
   Via                R    amr   o   o    o    o     o   o
   Via                c    dr    m   m    m    m     m   m
   WWW-Authenticate  401         m   m    m    m     m   m

_________________________________________________________
   Header           Where Proxy DES OPT SETUP PLAY PAUSE TRD

   Table 4: 9: Overview of RTSP header fields related to methods  DESCRIBE,
   OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.

   The Bandwidth request-header field describes the estimated bandwidth
   available to the client, expressed as a positive integer and measured
   in bits per second. The bandwidth available to the client may change
   during an RTSP session, e.g., due to modem retraining.

   Example:

     Bandwidth: 4000

13.8

14.8 Blocksize

   The Blocksize request-header field is sent from the client to the
   media server asking the server for a particular media packet size.
   This packet size does not include lower-layer headers such as IP,
   UDP, or RTP. The server is free to use a blocksize which is lower
   than the one requested. The server MAY truncate this packet size to
   the closest multiple of the minimum, media-specific block size, or
   override it with the media-specific size if necessary. The block size
   MUST be a positive decimal number, measured in octets. The server
   only returns an error

   (400) if the value is syntactically invalid.

   Blocksize  =  "Blocksize" ":" 1*DIGIT
   Header              Where  Proxy GPR SPR RDR PNG
   __________________________________________________
   Allow                405          -   -   -   -          m   m   m   m
   Authorization         R           o   o   o   o
   Bandwidth             R           -   o   -   -
   Blocksize             R           -   o   -   -
   Connection                        o   o   o   -              Content-
   Base
   Content-Base          R           o   o   -   -                      Content-
   Base
   Content-Base          r           o   o   -   -                      Content-
   Base
   Content-Base         4xx          o   o   o   -                      Content-
   Encoding
   Content-Encoding      R      r    o   o   -   -                      Content-
   Encoding
   Content-Encoding      r      r    o   o   -   -                      Content-
   Encoding
   Content-Encoding     4xx     r    o   o   o   -                      Content-
   Language
   Content-Language      R      r    o   o   -   -                      Content-
   Language
   Content-Language      r      r    o   o   -   -                      Content-
   Language
   Content-Language     4xx     r    o   o   o   -                      Content-
   Length
   Content-Length        R      r    *   *   -   -                      Content-
   Length
   Content-Length        r      r    *   *   -   -                      Content-
   Length
   Content-Length       4xx     r    *   *   *   -                      Content-
   Location
   Content-Location      R           o   o   -   -                      Content-
   Location
   Content-Location      r           o   o   -   -                      Content-
   Location
   Content-Location     4xx          o   o   o   -                      Content-
   Type
   Content-Type          R           *   *   -   -                      Content-
   Type
   Content-Type          r           *   *   -   -                      Content-
   Type
   Content-Type         4xx          *   *   *   -
   CSeq                 Rc           m   m   m   m
   Date                        am    o   o   o   o
   From                  R      r    o   o   o   o
   Host                              -   -   -   -                 Last-
   Modified
   Last-Modified         R      r    -   -   -   -                      Last-
   Modified
   Last-Modified         r      r    o   -   -   -
   Location             3rr          o   o   o   o
   Location              R           -   -   m   -                Proxy-
   Authenticate
   Proxy-Authenticate   407    amr   m   m   m   m                      Proxy-
   Require
   Proxy-Require         R     ar    o   o   o   o
   Public               501   admr  m*  m*  m*  m*
   Range                 R           -   -   o   -
   Referer               R           o   o   o   -
   Require               R           o   o   o   o                Retry-
   After
   Retry-After        3rr,503        o   o   -   -
   Scale                             -   -   -   -
   Session               R           o   o   o   m
   Session               r           c   c   o   m
   Server                R           o   o   o   o
   Server                r           o   o   -   o
   Timestamp
   Supported             R           o   o   o   o
   Timestamp             c           m   m   m   m
   Unsupported           r           c   c   c   c                 User-
   Agent
   User-Agent            R          m*  m*   -  m*                      User-
   Agent
   User-Agent            r           -   -  m*   -
   Vary                  r           c   c   -   -
   Via                   R     amr   o   o   o   o
   Via                   c     dr    m   m   m   m                  WWW-
   Authenticate
   WWW-Authenticate     401          m   m   m   m
   __________________________________________________
   Header              Where  Proxy GPR SPR RDR PNG

   Table  5:  10:  Overview  of  RTSP  header  fields  related  to   methods
   GET_PARAMETER, SET_PARAMETER,REDIRECT, SET_PARAMETER, REDIRECT, and PING.

13.9

   only returns an error (4xx) if the value is syntactically invalid.

14.9 Cache-Control

   The Cache-Control general-header field is used to specify directives
   that MUST be obeyed by all caching mechanisms along the
   request/response chain.

   Cache directives must be passed through by a proxy or gateway
   application, regardless of their significance to that application,
   since the directives may be applicable to all recipients along the
   request/response chain. It is not possible to specify a cache-
   directive for a specific cache.

   Cache-Control should only be specified in a SETUP request and its      |
   response. Note: Cache-Control does not govern the caching of           |
   responses as for HTTP, but rather of instead it applies to the media stream          |
   identified by the SETUP request. Responses to  The caching of RTSP requests are     |
   generally not cacheable, except for responses to DESCRIBE. further information see 15. Below is the  |
   description of the cache directives that can be included in the        |
   Cache-Control             =  "Cache-Control" ":" 1#cache-directive
   cache-directive           =  cache-request-directive
                            /   cache-response-directive
   cache-request-directive   =  "no-cache"
                            /   "max-stale" ["=" delta-seconds]
                            /   "min-fresh" "=" delta-seconds
                            /   "only-if-cached"
                            /   cache-extension
   cache-response-directive  =  "public"
                            /   "private"
                            /   "no-cache"
                            /   "no-transform"
                            /   "must-revalidate"
                            /   "proxy-revalidate"
                            /   "max-age" "=" delta-seconds
                            /   cache-extension
   cache-extension           =  token [ "=" ( token / quoted-string ) ]
   delta-seconds             =  1*DIGIT header.

        no-cache: Indicates that the media stream MUST NOT be cached
             anywhere. This allows an origin server to prevent caching
             even by caches that have been configured to return stale
             responses to client requests.

        public: Indicates that the media stream is cacheable by any
             cache.

        private: Indicates that the media stream is intended for a
             single user and MUST NOT be cached by a shared cache. A
             private (non-shared) cache may cache the media stream.

        no-transform: An intermediate cache (proxy) may find it useful
             to convert the media type of a certain stream. A proxy
             might, for example, convert between video formats to save
             cache space or to reduce the amount of traffic on a slow
             link.  Serious operational problems may occur, however,
             when these transformations have been applied to streams
             intended for certain kinds of applications. For example,
             applications for medical imaging, scientific data analysis
             and those using end-to-end authentication all depend on
             receiving a stream that is bit-for-bit identical to the
             original entity-body. media stream. Therefore, if a response includes
             the no-transform directive, an intermediate cache or proxy
             MUST NOT change the encoding of the stream.  Unlike HTTP,
             RTSP does not provide for partial transformation at this
             point, e.g., allowing translation into a different
             language.

        only-if-cached: In some cases, such as times of extremely poor
             network connectivity, a client may want a cache to return
             only those media streams that it currently has stored, and
             not to receive these from the origin server. To do this,
             the client may include the only-if-cached directive in a
             request. If it receives this directive, a cache SHOULD
             either respond using a cached media stream that is
             consistent with the other constraints of the request, or
             respond with a 504 (Gateway Timeout) status. However, if a
             group of caches is being operated as a unified system with
             good internal connectivity, such a request MAY be forwarded
             within that group of caches.

        max-stale: Indicates that the client is willing to accept a
             media stream that has exceeded its expiration time. If
             max-stale is assigned a value, then the client is willing
             to accept a response that has exceeded its expiration time
             by no more than the specified number of seconds. If no
             value is assigned to max-stale, then the client is willing
             to accept a stale response of any age.

        min-fresh: Indicates that the client is willing to accept a
             media stream whose freshness lifetime is no less than its
             current age plus the specified time in seconds. That is,
             the client wants a response that will still be fresh for at
             least the specified number of seconds.

        must-revalidate: When the must-revalidate directive is present
             in a SETUP response received by a cache, that cache MUST
             NOT use the entry after it becomes stale to respond to a
             subsequent request without first revalidating it with the
             origin server.  That is, the cache must do an end-to-end
             revalidation every time, if, based solely on the origin
             server's Expires, the cached response is stale.)

        proxy-revalidate: The proxy-revalidate directive has the same
             meaning as the must-revalidate directive, except that it
             does not apply to non-shared user agent caches. It can be
             used on a response to an authenticated request to permit
             the user's cache to store and later return the response
             without needing to revalidate it (since it has already been
             authenticated once by that user), while still requiring
             proxies that service many users to revalidate each time (in
             order to make sure that each user has been authenticated).
             Note that such authenticated responses also need the public
             cache control directive in order to allow them to be cached
             at all.

        max-age: When an intermediate cache is forced, by means of a
             max-age=0 directive, to revalidate its own cache entry, and
             the client has supplied its own validator in the request,
             the supplied validator might differ from the validator
             currently stored with the cache entry. In this case, the
             cache MAY use either validator in making its own request
             without affecting semantic transparency.

             However, the choice of validator might affect performance.
             The best approach is for the intermediate cache to use its
             own validator when making its request. If the server
             replies with 304 (Not Modified), then the cache can return
             its now validated copy to the client with a 200 (OK)
             response. If the server replies with a new entity and cache
             validator, however, the intermediate cache can compare the
             returned validator with the one provided in the client's
             request, using the strong comparison function. If the
             client's validator is equal to the origin server's, then
             the intermediate cache simply returns 304 (Not Modified).
             Otherwise, it returns the new entity with a 200 (OK)
             response.

13.10

14.10 Connection

   See [H14.10]. The use of the connection option "close" in RTSP
   messages SHOULD be limited to error messages when the server is
   unable to recover and therefore see it necessary to close the
   connection. The reason is that the client shall have the choice of
   continue using a connection indefinitely as long as it sends valid
   messages.

13.11

14.11 Content-Base

   The Content-Base entity-header field may be used to specify the base
   URI
   URL for resolving relative URLs within the entity.

   Content-Base  =  "Content-Base" ":" absoluteURI

   Content-Base: rtsp://media.example.com/movie/twister

   If no Content-Base field is present, the base URI URL of an entity is
   defined either by its Content-Location (if that Content-Location URI URL
   is an absolute URI) URL) or the URI URL used to initiate the request, in that
   order of precedence. Note, however, that the base URI URL of the contents
   within the entity-body may be redefined within that entity-body.

13.12

14.12 Content-Encoding

   See [H14.11]

13.13

14.13 Content-Language

   See [H14.12]

13.14

14.14 Content-Length

   The Content-Length general-header field contains the length of the
   content of the method (i.e. after the double CRLF following the last
   header). Unlike HTTP, it MUST be included in all messages that carry
   content beyond the header portion of the message. If it is missing, a
   default value of zero is assumed. It is interpreted according to
   [H14.13].

13.15

14.15 Content-Location

   See [H14.14]

13.16

14.16 Content-Type

   See [H14.17]. Note that the content types suitable for RTSP are
   likely to be restricted in practice to presentation descriptions and
   parameter-value types.

13.17

14.17 CSeq

   The CSeq general-header field specifies the sequence number for an     |
   RTSP request-response pair. This field MUST be present in all          |
   requests and responses. For every RTSP request containing the given    |
   sequence number, the corresponding response will have the same         |
   number. Any retransmitted request must contain the same sequence       |
   number as the original (i.e. the sequence number is not incremented    |
   for retransmissions of the same request). For each new RTSP request    |
   the CSeq value SHALL be incremented by one. The initial sequence       |
   number MAY be any number. number, however it is RECOMMENDED to start at 1.     |
   Each sequence number series is unique between each requester and       |
   responder, i.e. the client has one series for its request to a server  |
   and the server has another when sending request to the client. Each    |
   requester and responder is identified with its network address.

   CSeq  =  "Cseq" ":" 1*DIGIT

13.18

   Example:

   CSeq: 239

14.18 Date

   See [H14.18]. An RTSP message containing a body MUST include a Date
   header if the sending host has a clock. Servers SHOULD include a Date
   header in all other RTSP messages.

13.19

14.19 Expires

   The Expires entity-header field gives a date and time after which the
   description or media-stream should be considered stale. The
   interpretation depends on the method:

        DESCRIBE response: The Expires header indicates a date and time
             after which the description should SHOULD be considered stale.

        SETUP response: The Expires header indicate a date and time
             after which the media stream SHOULD be considered stale.

   A stale cache entry may not normally be returned by a cache (either a
   proxy cache or an user agent cache) unless it is first validated with
   the origin server (or with an intermediate cache that has a fresh
   copy of the entity). See section 14 15 for further discussion of the
   expiration model.

   The presence of an Expires field does not imply that the original
   resource will change or cease to exist at, before, or after that
   time.

   The format is an absolute date and time as defined by HTTP-date in
   [H3.3]; it MUST be in RFC1123-date format:

   Expires  =  "Expires" ":" HTTP-date

   An example of its use is

     Expires: Thu, 01 Dec 1994 16:00:00 GMT

   RTSP/1.0 clients and caches MUST treat other invalid date formats,
   especially including the value "0", as having occurred in the past
   (i.e., already expired).

   To mark a response as "already expired," an origin server should use
   an Expires date that is equal to the Date header value. To mark a
   response as "never expires," an origin server SHOULD use an Expires
   date approximately one year from the time the response is sent.
   RTSP/1.0 servers SHOULD NOT send Expires dates more than one year in
   the future.

   The presence of an Expires header field with a date value of some
   time in the future on a media stream that otherwise would by default
   be non-cacheable indicates that the media stream is cacheable, unless
   indicated otherwise by a Cache-Control header field (Section 13.9).

13.20 14.9).

14.20 From

   See [H14.22].

13.21

14.21 Host

   The Host HTTP request header field [H14.23] is not needed for RTSP,    |
   and SHALL NOT be sent. It SHALL be silently ignored if received.

13.22

14.22 If-Match

   See [H14.24].

   The If-Match request-header field is especially useful for ensuring
   the integrity of the presentation description, in both the case where
   it is fetched via means external to RTSP (such as HTTP), or in the
   case where the server implementation is guaranteeing the integrity of
   the description between the time of the DESCRIBE message and the
   SETUP message.

   The identifier is an opaque identifier, and thus is not specific to
   any particular session description language.

13.23

14.23 If-Modified-Since

   The If-Modified-Since request-header field is used with the DESCRIBE
   and SETUP methods to make them conditional. If the requested variant
   has not been modified since the time specified in this field, a
   description will not be returned from the server (DESCRIBE) or a
   stream will not be set up (SETUP). Instead, a 304 (Not Modified)
   response will SHALL be returned without any message-body.

   If-Modified-Since  =  "If-Modified-Since" ":" HTTP-date

   An example of the field is:

     If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

13.24

14.24 Last-Modified

   The Last-Modified entity-header field indicates the date and time at
   which the origin server believes the presentation description or
   media stream was last modified. See [H14.29]. For the methods
   DESCRIBE, the header field indicates the last modification date and
   time of the description, for SETUP that of the media stream.

13.25

14.25 Location

   See [H14.30].

13.26

14.26 Proxy-Authenticate

   See [H14.33].

13.27

14.27 Proxy-Require

   The Proxy-Require request-header field is used to indicate proxy-      |
   sensitive features that MUST be supported by the proxy. Any Proxy-     |
   Require header features that are not supported by the proxy MUST be    |
   negatively acknowledged by the proxy to the client using the           |
   Unsupported header. The proxy SHALL use the 551 (Option Not
   Supported) status code in the response. Any feature tag included in
   the Proxy-Require      | does not apply to the server. To ensure that a
   feature is supported    | by both proxies and servers the tag must be
   included in also a         | Require header.

   See Section 13.32 14.32 for more details on the mechanics of this message
   and a usage example.

        Proxy-Require  =  "Proxy-Require" ":" 1#feature-tag               |

   Example of use:                                                           |

      Proxy-Require: play.basic                                              |

13.28

14.28 Public

   The Public response-header field lists the set of methods supported
   by the server. The purpose of this field is strictly to inform the
   recipient of the capabilities of the server regarding unusual
   methods. The methods listed may or may not be applicable to the
   Request-URI;
   Request-URL; the Allow header field (section 14.7) MAY be used to
   indicate methods allowed for a particular URI.

        Public  =  "Public" ":" 1#method URL.

   Example of use:

      Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN

   This header field applies only to the server directly connected to
   the client (i.e., the nearest neighbor in a chain of connections).
   If the response passes through a proxy, the proxy MUST either remove
   the Public header field or replace it with one applicable to its own
   capabilities.

13.29

14.29 Range

   The Range request and response header field specifies a range of       |
   time. The header is used in PLAY request to indicate the range of      |
   time the client desires the server to play back. The Range header in   |
   a PLAY indicates what range of time that is actually being played. In  |
   a SETUP response the header MAY be used, to ensure correct             |
   synchronization information after changes of transport parameters.     |

   The range can be specified in a number of units. This specification    |
   defines the smpte (Section 3.4), npt (Section 3.5), and clock          |
   (Section 3.6) range units. Within RTSP, byte ranges [H14.35.1] are     |
   normally not meaningful.  The header MAY contain a time parameter
   in UTC, specifying the time at which meaningful, and the operation behavior is to be made
   effective. This functionality SHALL only unspecified, but they     |
   and other extended units MAY be used with the REDIRECT
   method. used. Servers supporting the Range     |
   header MUST understand the NPT range format and SHOULD understand the  |
   SMPTE range format. The Range
   response header indicates what range of time is actually being
   played. If the Range header is given in a time format      |
   that is not understood, the recipient should return 501 (Not Implemented). 456 (Header Field  |
   Not Valid for Resource) and include a Accept-Ranges header indicating  |
   which time format that is supported for this resource.

   The header MAY contain a time parameter in UTC, specifying the time
   at which the operation is to be made effective. This functionality
   SHALL only be used with the REDIRECT method.

   Ranges are half-open intervals, including the first point, but
   excluding the second point. In other words, a range of A-B starts
   exactly at time A, but stops just before B. Only the start time of a
   media unit such as a video or audio frame is relevant. As an example,
   assume that video frames are generated every 40 ms. A range of
   10.0-10.1 would include a video frame starting at 10.0 or later time
   and would include a video frame starting at 10.08, even though it
   lasted beyond the interval. A range of 10.0-10.08, on the other hand,
   would exclude the frame at 10.08.

   Range             =  "Range" ":" 1#ranges-specifier [ ";" "time" "=" utc-time ]
   ranges-specifier  =  npt-range / utc-range / smpte-range

   Example:

     Range: clock=19960213T143205Z-;time=19970123T143720Z

        The notation is similar to that used for the HTTP/1.1 [26] [4]
        byte-range header. It allows clients to select an excerpt
        from the media object, and to play from a given point to
        the end as well as from the current location to a given
        point. The start of playback can be scheduled for any time
        in the future, although a server may refuse to keep server
        resources for extended idle periods.

   By default, range intervals increase, where the second point is
   larger than the first point.

   Example:

       Range: npt=10-15

   However, range intervals can also decrease if the Scale header (see
   section  13.34)  14.34) indicates a negative scale value. For example, this
   would be the case when a playback in reverse is desired.

   Example:

       Scale: -1
       Range: npt=15-10

   Decreasing ranges are still half open intervals as described above.
   Thus, For range A-B, A is closed and B is open. In the above example,
   15 is closed and 10 is open. An exception to this rule is the case
   when B=0 in a decreasing range. In this case, the range is closed on
   both ends, as otherwise there would be no way to reach 0 on a reverse
   playback.

   Example:

       Scale: -1
       Range: npt=15-0

   In this range both 15 and 0 are closed.

   A decreasing range interval without a corresponding negative Scale
   header is not valid.

13.30

14.30 Referer

   See [H14.36]. The URL refers to that of the presentation description,
   typically retrieved via HTTP.

13.31

14.31 Retry-After

   See [H14.37].

13.32

14.32 Require

   The Require request-header field is used by clients or servers to
   ensure that the other end-point supports features that are required
   in respect to this request. It can also be used to query if the other
   end-point supports certain features, however the use of the Supported
   (Section  13.38)  14.38) is much more effective in this purpose. The server
   MUST respond to this header by using the Unsupported header to
   negatively acknowledge those feature-tags which are NOT supported.
   The response SHALL use the error code 551 (Option Not Supported).
   This header does not apply to proxies, for the same functionality in
   respect to proxies see, header Proxy-Require (Section  13.27). 14.27).

        This is to make sure that the client-server interaction
        will proceed without delay when all features are understood
        by both sides, and only slow down if features are not
        understood (as in the example below). For a well-matched
        client-server pair, the interaction proceeds quickly,
        saving a round-trip often required by negotiation
        mechanisms. In addition, it also removes state ambiguity
        when the client requires features that the server does not
        understand.

   Require  =  "Require" ":" feature-tag *("," feature-tag)

   Example:

   C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
           CSeq: 302
           Require: funky-feature
           Funky-Parameter: funkystuff

   S->C:   RTSP/1.0 551 Option not supported
           CSeq: 302
           Unsupported: funky-feature

   C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
           CSeq: 303

   S->C:   RTSP/1.0 200 OK
           CSeq: 303

   In this example, "funky-feature" is the feature-tag which indicates
   to the client that the fictional Funky-Parameter field is required.
   The relationship between "funky-feature" and Funky-Parameter is not
   communicated via the RTSP exchange, since that relationship is an
   immutable property of "funky-feature" and thus should not be
   transmitted with every exchange.

   Proxies and other intermediary devices SHOULD ignore features that
   are not understood in this field. If a particular extension requires
   that intermediate devices support it, the extension should be tagged
   in the Proxy-Require field instead (see Section 13.27).

13.33 RTP-Info

   The RTP-Info response-header field is used to set RTP-specific
   parameters in the PLAY response. For streams using RTP as transport
   protocol the 14.27).

14.33 RTP-Info header SHALL be part of a 200 response to PLAY.

   The RTP-Info response-header field is used to set RTP-specific         |
   parameters in the PLAY response. These parameters correspond to the    |
   synchronization source identified by the ssrc parameter of the         |
   Transport response header in the SETUP reponse. For streams using RTP  |
   as transport protocol the RTP-Info header SHALL SHOULD be part of a 200      |
   response to PLAY.                                                      |

        The exclusion of the RTP-Info in a PLAY response for RTP     |
        transported media will result in that a client needs to      |
        synchronize the media streams using RTCP. This may have      |
        negative impact as the RTCP can be lost, and does not need   |
        to be particulary timely in their arrival. Also              |
        functionality as informing the client from which packet a    |
        seek has occurred is affected.                               |

   The RTP-Info MAY also be included in SETUP responses to provide        |
   synchronization information when changing transport parameters, see    |
   11.3.                                                                  |

   The header can carry the following parameters:

        url: Indicates the stream URL which for which the following RTP
             parameters correspond, this URL MUST be the same used in
             the SETUP request for this media stream. Any relative URL
             SHALL use the request URL as base URL.

        seq: Indicates the sequence number of the first packet of the
             stream. This allows clients to gracefully deal with packets
             when seeking. The client uses this value to differentiate
             packets that originated before the seek from packets that
             originated after the seek.

        rtptime: Indicates the RTP timestamp corresponding to the time
             value in the Range response header. (Note: For aggregate
             control, a particular stream may not actually generate a
             packet for the Range time value returned or implied. Thus,
             there is no guarantee that the packet with the sequence
             number indicated by seq actually has the timestamp
             indicated by rtptime.) The client uses this value to
             calculate the mapping of RTP time to NPT.

             A mapping from RTP timestamps to NTP timestamps (wall
             clock) is available via RTCP. However, this
             information is not sufficient to generate a mapping
             from RTP timestamps to NPT. Furthermore, in order to
             ensure that this information is available at the
             necessary time (immediately at startup or after a
             seek), and that it is delivered reliably, this mapping
             is placed in the RTSP control channel.

             In order to compensate for drift for long, uninterrupted
             presentations, RTSP clients should additionally map NPT to
             NTP, using initial RTCP sender reports to do the mapping,
             and later reports to check drift against the mapping.

   Additionally, the RTP-Info header parameter fields only apply to a     |
   single SSRC within a stream (the SSRC reported in the transport        |
   response header; see section  13.40).  14.40). If there are multiple            |
   synchronization sources (SSRCs) present within a RTP session, RTCP session           |
   transmitting media, RTCP must be used to map RTP and NTP timestamps    |
   for those sources, for      | both synchronization and drift-checking.

   Syntax:

   RTP-Info        =  "RTP-Info" ":" 1#rtsp-info-spec
   rtsp-info-spec  =  stream-url 1*parameter
   stream-url      =  quoted-url / unquoted-url
   unquoted-url    =  "url" "=" safe-url
   quoted-url      =  "url" "=" <"> needquote-url <">
   safe-url        =  url
   needquote-url   =  url //That contains ; or ,
   url             =  ( absoluteURI / relativeURI )
   parameter       =  ";" "seq" "=" 1*DIGIT
                   /  ";" "rtptime" "=" 1*DIGIT Due    |
   to backwards compatibility reasons these shortcomings can't be fixed   |
   without defining a new header, which is for future work if needed.

   Additional constraint: safe-url The syntax element "safe-url" (see section
   17.2.3) MUST NOT contain the semicolon (";") or comma (",")
   characters. The quoted-url form SHOULD only be used when a URL does
   not meet the safe-url constraint, in order to ensure compatibility
   with implementations conformant to RFC 2326 [21].

   absoluteURI and relativeURI are defined in RFC 2396 [22] with RFC
   2732 [30] applied. [1].

   Example:                                                               |

   RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102,
             url=rtsp://foo.com/bar.avi/streamid=1;seq=30211

13.34 url=rtsp://example.com/bar.avi/streamid=0;seq=45102,         |
             url=rtsp://example.com/bar.avi/streamid=1;seq=30211          |

14.34 Scale

   A scale value of 1 indicates normal play at the normal forward         |
   viewing rate. If not 1, the value corresponds to the rate with         |
   respect to normal viewing rate. For example, a ratio of 2 indicates    |
   twice the normal viewing rate ("fast forward") and a ratio of 0.5      |
   indicates half the normal viewing rate. In other words, a ratio of 2   |
   has normal play time increase at twice the wallclock rate. For every   |
   second of elapsed (wallclock) time, 2 seconds of content will be       |
   delivered. A negative value indicates reverse direction. For certain   |
   media transports this may require certain considerations to work       |
   consistent, see section B.1 for description on how RTP handles this.

   Unless requested otherwise by the Speed parameter, the data rate
   SHOULD not be changed. Implementation of scale changes depends on the
   server and media type. For video, a server may, for example, deliver
   only key frames or selected key frames. For audio, it may time-scale
   the audio while preserving pitch or, less desirably, deliver
   fragments of audio.

   The server should try to approximate the viewing rate, but may
   restrict the range of scale values that it supports. The response
   MUST contain the actual scale value chosen by the server.

   If the server does not implement the possibility to scale, it will
   not return a Scale header. A server supporting Scale operations for
   PLAY SHALL indicate this with the use of the "play.scale" feature-
   tags.

   Scale  =  "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]

   When indicating a negative scale for a reverse playback, the Range
   header must indicate a decreasing range as described in section
   13.29.
   14.29.

   Example of playing in reverse at 3.5 times normal rate:

     Scale: -3.5
     Range: npt=15-10

13.35

14.35 Speed
   The Speed request-header field requests the server to deliver data to
   the client at a particular speed, contingent on the server's ability
   and desire to serve the media stream at the given speed.
   Implementation by the server is OPTIONAL. The default is the bit rate
   of the stream.

   The parameter value is expressed as a decimal ratio, e.g., a value of
   2.0 indicates that data is to be delivered twice as fast as normal. A
   speed of zero is invalid. All speeds may not be possible to support.
   Therefore the actual used speed MUST be included in the response. The
   lack of a response header is indication of lack of support from the
   server of this functionality. Support of the speed functionality are
   indicated by the "play.speed" feature-tag.

   Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ] featuretag.

   Example:

     Speed: 2.5

   Use of this field changes the bandwidth used for data delivery. It is  |
   meant for use in specific circumstances where preview of the           |
   presentation at a higher or lower rate is necessary. Implementors      |
   should keep in mind that bandwidth for the session may be negotiated   |
   beforehand (by means other than RTSP), and therefore re-negotiation    |
   may be necessary. When data is delivered over UDP, it is highly        |
   recommended that means such as RTCP be used to track packet loss       |
   rates. If the data transport is performed over public best-effort      |
   networks the sender SHOULD perform congestion control of the           |
   stream(s). This can result in that the communicated speed is           |
   impossible to maintain.

13.36

14.36 Server

   See [H14.38], however the header syntax is here corrected.

   Server  =  "Server" ":" ( product / comment ) *(SP (product / comment))

13.37 corrected in section
   17.2.3.

14.37 Session

   The Session request-header and response-header field identifies an     |
   RTSP session. An RTSP session is created by the server as a result of  |
   a successful SETUP request and in the response the session identifier  |
   is given to the client. The RTSP session exist until destroyed by a    |
   TEARDOWN or timed out by the server.                                   |

   The session identifier is chosen by the server (see Section 3.3) and   |
   MUST be returned in the SETUP response. Once a client receives a       |
   session identifier, it SHALL be included in any request related to     |
   that session.  This means that the Session header MUST be included in  |
   a request using the following methods: PLAY, PAUSE, PING, and          |
   TEARDOWN, and MAY be included in SETUP, OPTIONS, SET_PARAMETER,        |
   GET_PARAMETER, and REDIRECT, and SHALL NOT be included in DESCRIBE.    |
   In a RTSP response the session header SHALL be included in methods,    |
   SETUP, PING, PLAY, and PAUSE, and MAY be included in methods,          |
   TEARDOWN, and REDIRECT, and if included in the request of the          |
   following methods it SHALL also be included in the response, OPTIONS,  |
   GET_PARAMETER, and SET_PARAMETER, and SHALL NOT be included in         |
   DESCRIBE.                                                              |

   Note that RFC 2326 servers and client may in some cases not include    |
   or return a Session header when expected according to the above text.  |
   Any client or server is RECOMMENDED to be forgiving of this error if   |
   possible (which it is in many cases).

   Session  =  "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]

   The timeout parameter MAY be included in a SETUP response, and SHALL   |
   NOT be  | included in requests. The server uses it to indicate to the client     |
   client how long the server is prepared to wait between RTSP commands or   |
   or other signs of life before closing the session due to lack of       |
   activity (see below and Section A). The timeout is measured in         |
   seconds, with a default of 60 seconds (1 minute). The length of the    |
   session timeout SHALL NOT be changed in a established session.

   The mechanisms for showing liveness of the client is, any RTSP         |
   request with a Session header, if RTP & RTCP is used an RTCP message,  |
   or through any other used media protocol capable of indicating         |
   liveness of the RTSP client. It is RECOMMENDED that a client does not  |
   wait to the last second of the timeout before trying to send a         |
   liveness message. The RTSP message may be lost or when using reliable  |
   protocols, such as TCP, the message may take some time to arrive       |
   safely at the receiver. To show liveness between RTSP request issued   |
   to accomplish other things, the following mechanisms can be used, in   |
   descending order of preference:                                        |

        RTCP: If RTP is used for media transport RTCP SHOULD be used. If  |
             RTCP is used to report transport statistics, it SHALL also   |
             work as keep alive. The server can determine the client by   |
             used network address and port together with the fact that    |
             the client is reporting on the servers SSRC(s). A downside   |
             of using RTCP is that it only gives statistical guarantees   |
             to reach the server. However that probability is so low      |
             that it can be ignored in most cases. For example, a         |
             session with 60 seconds timeout and enough bitrate assigned  |
             to RTCP messages to send a message from client to server on  |
             average every 5 seconds. That client have for a network      |
             with 5 % packet loss, the probability to fail showing        |
             liveness sign in that session within the timeout interval    |
             of 2.4*E-16. In sessions with shorter timeout times, or      |
             much higher packet loss, or small RTCP bandwidths SHOULD     |
             also use any of the mechanisms below.                        |

        PING: The use of the PING method is the best of the RTSP based    |
             methods. It has no other effects than updating the timeout   |
             timer. In that way it will be a minimal message, that also   |
             does not cause any extra processing for the server. The      |
             downside is that it may not be implemented. A client SHOULD  |
             use a OPTIONS request to verify support of the PING at the   |
             server. It is also possible to detect support by sending a   |
             PING to the server. If a 200 (OK) message is received the    |
             server supports it. In case a 501 (Not Implemented) is       |
             received it does not support PING and there is no meaning    |
             in continue trying.  Also the reception of a error message   |
             will also mean that the liveness timer has not been          |
             updated.                                                     |

        SET_PARAMETER: When using SET_PARAMETER for keep alive, no body   |
             SHOULD be included. This method is basically as good as      |
             PING, however the implementation support of the method is    |
             today limited. The same considerations as for PING apply     |
             regarding checking of support in server and proxies.         |

        OPTIONS: This method does also work. However it causes the        |
             server to perform unnecessary processing and result in       |
             bigger responses than necessary for the task. The reason     |
             for this is that the Public is always included creating      |
             overhead.                                                    |

   Note that a session identifier identifies an RTSP session across       |
   transport sessions or connections. RTSP requests for a given session   |
   can use different URIs URLs (Presentation and media URIs). URLs).  Note, that      |
   there are restrictions depending on the session which URIs URLs that are    |
   acceptable for a given method. However, multiple "user" sessions for   |
   the same URI URL from the same client will require use of different        |
   session identifiers.                                                   |

        The session identifier is needed to distinguish several      |
        delivery requests for the same URL coming from the same      |
        client.                                                      |

   The response 454 (Session Not Found) SHALL be returned if the session  |
   identifier is invalid.

13.38

14.38 Supported

   The Supported header field enumerates all the extensions supported by
   the client or server. When offered in a request, the receiver MUST
   respond with its corresponding Supported header.

   The Supported header field contains a list of feature-tags, described
   in Section 3.7, that are understood by the client or server.

        Supported  =  "Supported" ":" [feature-tag *("," feature-tag)]

   Example:

     C->S:  OPTIONS rtsp://example.com/ RTSP/1.0
            Supported: foo, bar, blech

     S->C:  RTSP/1.0 200 OK
            Supported: bar, blech, baz

13.39

14.39 Timestamp

   The Timestamp general-header field describes when the client sent the
   request to the server. The value of the timestamp is of significance
   only to the client and may use any timescale. The server MUST echo
   the exact same value and MAY, if it has accurate information about
   this, add a floating point number indicating the number of seconds
   that has elapsed since it has received the request. The timestamp is
   used by the client to compute the round-trip time to the server so
   that it can adjust the timeout value for retransmissions. It also
   resolves retransmission ambiguities for unreliable transport of RTSP.

   Timestamp  =  "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
   delay      =  *(DIGIT) [ "." *(DIGIT) ]

13.40

14.40 Transport

   The Transport request- request and response- response header field indicates which
   transport protocol is to be used and configures its parameters such
   as destination address, compression, multicast time-to-live and
   destination port for a single stream. It sets those values not
   already determined by a presentation description.

   Transports are comma separated, listed in order of preference.         |
   Parameters may be added to each transport, separated by a semicolon.   |
   The server SHOULD return a Transport response-header field in the      |
   response to indicate the values actually chosen. The Transport header  |
   field MAY also be used to change certain transport parameters. A       |
   server MAY refuse to change parameters of an existing stream.

   The server MAY return a Transport response-header field in the
   response to indicate the values actually chosen.          |

   A Transport request header field MAY contain a list of transport       |
   options acceptable to the client, in the form of multiple              |
   transportspec entries. In that case, the server MUST return the        |
   single option (transport-spec) which was actually chosen. The number   |
   of transportspec entries is expected to be limited as the client will  |
   get guidance on what configurations that are possible from the         |
   presentation description.

   A transport-spec transport option may only contain one of any given    |
   parameter within it. Parameters may be given in any order.             |
   Additionally, it may only contain the unicast or multicast transport   |
   parameter. Unknown transport parameters SHALL be ignored. The          |
   requester need to ensure that the responder understands the            |
   parameters through the use of feature tags and the Require header.     |

   The usage of any parameter that was not defined in RFC 2326 or in an   |
   extended way requires that request or response contains a Require      |
   header with the "play.basic" feature tag.

        The Transport header field is restricted to describing a
        single media stream. (RTSP can also control multiple
        streams as a single entity.) Making it part of RTSP rather
        than relying on a multitude of session description formats
        greatly simplifies designs of firewalls.

   The syntax for the transport specifier is

   transport/profile/lower-transport. transport specifier is

   transport/profile/lower-transport.

   The default value for the "lower-transport" parameters is specific to
   the profile. For RTP/AVP, the default is UDP.

   There is three different methods for how to specify where the media    |
   should be delivered:                                                   |

        o The presence of this parameter and its values indicates         |
          address and port pairs for one or more IP flow necessary for    |
          the media transport. This is an improved version of the         |
          Destination parameter.                                          |

        o The presence of this parameter and its value indicates what IP  |
          address the media shall be delivered to. This method is kept    |
          for backwards compatibility reasons, dest_addr is a better      |
          choice.                                                         |

        o The lack of of both of the above parameters indicates that the  |
          server SHALL send media to same address for which the RTSP      |
          messages originates.                                            |

   The default value choice of method for indicating where the "lower-transport" parameters is specific media shall be           |
   delivered depends on the use case. In many case the only allowed       |
   method will be to use no explicit indication and have the profile. For RTP/AVP, server       |
   deliver media to the default source of the RTSP messages.                      |

   An RTSP proxy will also need to take care. If the media is UDP. not         |
   desired to be routed through the proxy, the proxy will need to         |
   introduce the destination indication.

   Below are the configuration parameters associated with transport:

   General parameters:

        unicast / multicast: This parameter is a mutually exclusive
             indication of whether unicast or multicast delivery will be
             attempted. One of the two values MUST be specified. Clients
             that are capable of handling both unicast and multicast
             transmission MUST indicate such capability by including two
             full transport-specs with separate parameters for each.

        destination: The address of the stream recipient to which a
             stream will be sent. The client originating the RTSP
             request may specify the destination address of the stream
             recipient with the destination parameter. When the
             destination field is specified, the recipient may be a
             different party than the originator of the request. To
             avoid becoming the unwitting perpetrator of a remote-
             controlled denial-of-service attack, a server SHOULD
             authenticate the client originating the request and SHOULD
             log such attempts before allowing the client to direct a
             media stream to a recipient address not chosen by the
             server. While, this is particularly important if RTSP
             commands are issued via UDP, implementations cannot rely on
             TCP as reliable means of client identification by itself
             either.

             The server SHOULD NOT allow the destination field to be set
             unless a mechanism exists in the system to authorize the
             request originator to direct streams to the recipient. It
             is preferred that this authorization be performed by the
             recipient itself and the credentials passed along to the
             server. However, in certain cases, such as when recipient
             address is a multicast group, or when the recipient is
             unable to communicate with the server in an out-of-band
             manner, this may not be possible. In these cases server may
             chose another method such as a server-resident
             authorization list to ensure that the request originator
             has the proper credentials to request stream delivery to
             the recipient.

             This parameter SHALL NOT be used when src_addr and dst_addr  |
             dest_addr is used in a transport declaration. For IPv6
             addresses it    | is RECOMMENDED that they be given as fully
             qualified domain  | to make it backwards compatible with RFC
             2326                | implementations.

        source: If the source address for the stream is different than
             can be derived from the RTSP endpoint address (the server
             in playback), the source address SHOULD be specified. To
             maintain backwards compatibility with RFC 2326, any IPv6
             host's address must be given as a fully qualified domain
             name. This parameter SHALL NOT be used when src_addr and
             dst_addr
             dest_addr is used in a transport declaration.

             This information may also be available through SDP.
             However, since this is more a feature of transport
             than media initialization, the authoritative source
             for this information should be in the SETUP response.

        layers: The number of multicast layers to be used for this media
             stream. The layers are sent to consecutive addresses
             starting at the destination address.

        dest_addr: A general destination address parameter that can       |
             contain one or more address and port pair. For each          |
             combination of Protocol/Profile/Lower Transport the          |
             interpretation of the address or addresses needs to be       |
             defined.  The host address part of the tuple MAY be empty,   |
             for example ":8000", in cases when only destination port is  |
             desired to be specified.

             The client or server SHALL NOT use this parameter unless
             both client and server has shown support. This parameter
             MUST be supported by client and servers that implements
             this specification. Support is indicated by the use of the
             feature-tag "play.basic". This parameter SHALL NOT be used
             in the same transport specification as any of the
             parameters "destination", "source", "port", "client_port",
             and "server_port".

             The same security consideration that are given for the
             "Destination" parameter does also applies to this
             parameter. This parameter can be used for redirecting
             traffic to recipient not desiring the media traffic.

        src_addr: A General source address parameter that can contain
             one or more address and port pair. For each combination of
             Protocol/Profile/Lower Transport the interpretation of the
             address or addresses needs to be defined. The client or
             server SHALL NOT use this parameter unless both client and
             server has shown support. This parameter MUST be supported
             by client and servers that implements this specification.
             Support is indicated by the use the feature-tag
             "play.basic". This parameter SHALL NOT be used in the same
             transport specification as any of the parameters
             "destination", "source", "port", "client_port", and
             "server_port".

             This parameter MUST be specified by the server if it         |
             transmits media packets from another address than the one    |
             RTSP messages are sent to. This will allow the client to     |
             verify source address and give it a destination address for  |
             its RTCP feedback packets if RTP is used. The address or     |
             addresses indicated in the src_addr parameter SHOULD be      |
             used both for sending and receiving of the media streams     |
             data packet. packets. The main reasons are two: three: First by sending   |
             from the indicated ports the source address will be known    |
             by the receiver of the packet. Secondly, in the presence of  |
             NATs some traversal mechanism requires either knowledge      |
             from which address and port a packet flow is coming, or      |
             having the possibility to send data to the sender port.

        mode: The mode parameter indicates the methods to be supported
             for this session. Valid values are PLAY and RECORD. If not
             provided, the default is PLAY.  The RECORD value was
             defined in RFC 2326 and is deprecated in this
             specification.

        append: The append parameter was used together with RECORD and
             is now deprecated.

        interleaved: The interleaved parameter implies mixing the media
             stream with the control stream in whatever protocol is
             being used by the control stream, using the mechanism
             defined in Section 11.11. 12. The argument provides the channel
             number to be used in the $ statement and MUST be present.
             This parameter MAY be specified as a range, e.g.,
             interleaved=4-5 in cases where the transport choice for the
             media stream requires it, e.g. for RTP with RTCP.  The
             channel number given in the request are only a guidance
             from the client to the server on what channel number(s) to
             use. The server MAY set any valid channel number in the
             response. The declared channel(s) are bi-directional, so
             both end-parties MAY send data on the given channel. One
             example of such usage is the second channel used for RTCP,
             where both server and client sends RTCP packets on the same
             channel.

             This allows RTP/RTCP to be handled similarly to the
             way that it is done with UDP, i.e., one channel for
             RTP and the other for RTCP.

   Multicast-specific:

        ttl: multicast time-to-live.

   RTP-specific:

   These parameters are MAY only be used if the media transport protocol
   is RTP.

        port: This parameter provides the RTP/RTCP port pair for a
             multicast session. It is should be specified as a range,
             e.g., port=3456-3457

        client_port: This parameter provides the unicast RTP/RTCP port
             pair on the client where media data and control information
             is to be sent. It is specified as a range, e.g.,
             port=3456-3457
             port=3456-3457. This parameter SHALL NOT be used when
             src_addr and dest_addr is used in a transport declaration.

        server_port: This parameter provides the unicast RTP/RTCP port
             pair on the server where media data and control information
             is to be sent. It is specified as a range, e.g.,
             port=3456-3457
             port=3456-3457. This parameter SHALL NOT be used when
             src_addr and dest_addr is used in a transport declaration.

        ssrc: The ssrc parameter, if included in a SETUP response,
             indicates the RTP SSRC [23] [15] value that will be used by the
             media server for RTP packets within the stream. It is
             expressed as an eight digit hexadecimal value. If the
             server does not act as a synchronization source for stream
             data (for instance, server is a translator, reflector,
             etc.) the value will be the "packet sender's SSRC" that
             would have been used in the RTCP Receiver Reports generated
             by the server, regardless of whether the server actually
             generates RTCP RRs. If there are multiple sources within
             the stream, the ssrc parameter only indicates the value for
             a single synchronization source. Other sources must be
             deduced from the actual RTP/RTCP stream.

             The functionality of specifying the ssrc parameter in a
             SETUP request is deprecated as it is incompatible with the
             specification of RTP in RFC 3550. 3550  [15]. If the parameter is
             included in the transport header of a SETUP request, the
             server MAY ignore it, and choose an appropriate SSRC for
             the stream. The server MAY set the ssrc parameter in the
             transport header of the response.

   Transport                =  "Transport" ":" 1#transport-spec
   transport-spec           =  transport-id *parameter
   transport-id             =  transport-protocol "/" profile ["/" lower-transport]
                               ; no LWS is allowed inside transport-id
   transport-protocol       =  "RTP" / token
   profile                  =  "AVP" / token
   lower-transport          =  "TCP" / "UDP" / token
   parameter                =  ";" ( "unicast" / "multicast" )
                           /   ";" "source" "=" host
                           /   ";" "destination" [ "=" host ]
                           /   ";" "interleaved" "=" channel [ "-" channel ]
                           /   ";" "append"
                           /   ";" "ttl" "=" ttl
                           /   ";" "layers" "=" 1*DIGIT
                           /   ";" "port" "=" port-spec
                           /   ";" "client_port" "=" port-spec
                           /   ";" "server_port" "=" port-spec
                           /   ";" "ssrc" "=" ssrc
                           /   ";" "mode" "=" mode-spec
                           /   ";" "dest_addr" "=" addr-list
                           /   ";" "src_addr" "=" addr-list
                           /   ";" trn-parameter-extension
   port-spec                =  port [ "-" port ]
   trn-parameter-extension  =  par-name "=" trn-par-value
   par-name                 =  token
   trn-par-value            =  *unreserved
   ttl                      =  1*3(DIGIT)
   ssrc                     =  8*8(HEX)
   channel                  =  1*3(DIGIT)
   mode-spec                =  <"> 1#mode <"> / mode
   mode                     =  "PLAY" / "RECORD" / token
   addr-list                =  quoted-host-port *("/" quoted-host-port)
   quoted-host-port         =  <"> host [":" port]<">
   host                     =  see chapter  16
   port                     =  see chapter  16

   The combination of transport protocol, profile and lower transport
   needs to be defined. A number of combinations are defined in the
   appendix B.

   Below is a usage example, showing a client advertising the capability
   to handle multicast or unicast, preferring multicast.  Since this is
   a unicast-only stream, the server responds with the proper transport
   parameters for unicast.

     C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
           CSeq: 302
           Transport: RTP/AVP;multicast;mode="PLAY",
               RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"

     S->C: RTSP/1.0 200 OK
           CSeq: 302
           Date: 23 Jan 1997 15:35:06 GMT
           Session: 47112344
           Transport: RTP/AVP;unicast;client_port=3456-3457;
               server_port=6256-6257;mode="PLAY"

13.41

14.41 Unsupported

   The Unsupported response-header field lists the features not
   supported by the server. In the case where the feature was specified
   via the Proxy-Require field (Section 13.27), 14.27), if there is a proxy on
   the path between the client and the server, the proxy MUST send a
   response message with a status code of 551 (Option Not Supported).
   The request SHALL NOT be forwarded.

   See Section 13.32 14.32 for a usage example.

   Unsupported  =  "Unsupported" ":" feature-tag *("," feature-tag)

13.42

14.42 User-Agent

   See [H14.43] for explanation, however the syntax is clarified due to
   an error in RFC 2616. A Client SHOULD include this header in all RTSP
   messages it sends.

   User-Agent           =  "User-Agent" ":" ( product / comment ) 0*(SP
   (product / comment)

13.43

14.43 Vary

   See [H14.44]

13.44

14.44 Via

   See [H14.45].

13.45

14.45 WWW-Authenticate

   See [H14.47].

14

15 Caching

   In HTTP, response-request pairs are cached. RTSP differs
   significantly in that respect. Responses are not cacheable, with the
   exception of the presentation description returned by DESCRIBE.
   (Since the responses for anything but DESCRIBE and GET_PARAMETER do
   not return any data, caching is not really an issue for these
   requests.) However, it is desirable for the continuous media data,
   typically delivered out-of-band with respect to RTSP, to be cached,
   as well as the session description.

   On receiving a SETUP or PLAY request, a proxy ascertains whether it
   has an up-to-date copy of the continuous media content and its
   description. It can determine whether the copy is up-to-date by
   issuing a SETUP or DESCRIBE request, respectively, and comparing the
   Last-Modified header with that of the cached copy. If the copy is not
   up-to-date, it modifies the SETUP transport parameters as appropriate
   and forwards the request to the origin server. Subsequent control
   commands such as PLAY or PAUSE then pass the proxy unmodified. The
   proxy delivers the continuous media data to the client, while
   possibly making a local copy for later reuse. The exact behavior
   allowed to the cache is given by the cache-response directives
   described in Section 13.9. 14.9. A cache MUST answer any DESCRIBE requests
   if it is currently serving the stream to the requestor, as it is
   possible that low-level details of the stream description may have
   changed on the origin-server.

   Note that an RTSP cache, unlike the HTTP cache, is of the "cut-
   through" variety. Rather than retrieving the whole resource from the
   origin server, the cache simply copies the streaming data as it
   passes by on its way to the client. Thus, it does not introduce
   additional latency.

   To the client, an RTSP proxy cache appears like a regular media
   server, to the media origin server like a client. Just as an HTTP
   cache has to store the content type, content language, and so on for
   the objects it caches, a media cache has to store the presentation
   description.  Typically, a cache eliminates all transport-references
   (that is, multicast information) from the presentation description,
   since these are independent of the data delivery from the cache to
   the client.  Information on the encodings remains the same. If the
   cache is able to translate the cached media data, it would create a
   new presentation description with all the encoding possibilities it
   can offer.

15

16 Examples

   The following

   This section contains several different examples refer trying to stream description formats that are
   not standards, such as RTSL. illustrate  |
   possible ways of using RTSP. The following examples are not can also help with the       |
   understanding of how functions of RTSP work. However remember that     |
   this is examples and the normative and syntax description in the       |
   other chapters takes precedence. Please also note that many of the     |
   example MAY contain syntax illegal line breaks to be
   used as a reference for those formats.

15.1 accommodate the      |
   formatting restriction that the RFC series impose.                     |

16.1 Media on Demand (Unicast)                                            |

   Client C requests a movie distributed from two different media         |
   servers A ( audio.example.com (audio.example.com ) and V (video.example.com ). The media   |
   description is stored on a web server W. The media description         |
   contains descriptions of the presentation and all its streams,         |
   including the codecs that are available, dynamic RTP payload types,    |
   the protocol stack, and content information such as language or        |
   copyright restrictions. It may also give an indication about the       |
   timeline of the movie.                                                 |

   In this example, the client is only interested in the last part of     |
   the movie.                                                             |

   C->W: GET /twister.sdp HTTP/1.1                                        |
         Host: www.example.com                                            |
         Accept: application/sdp                                          |

   W->C: HTTP/1.0 200 OK                                                  |
         Date: 23 Jan 1997 15:35:06 GMT                                   |
         Content-Type: application/sdp                                    |
         Content-Length: 255                                              |
         Expires: 23 Jan 1998 15:35:06 GMT                                |

         v=0                                                              |
         o=- 2890844526 2890842807 IN IP4 192.16.24.202                   |
         s=RTSP Session                                                   |
         e=adm@example.com                                                |
         a=range:npt=0-1:49:34                                            |
         t=0 0                                                            |
         m=audio 0 RTP/AVP 0                                              |
         a=control:rtsp://audio.example.com/twister/audio.en              |
         m=video 0 RTP/AVP 31                                             |
         a=control:rtsp://video.example.com/twister/video                 |

   C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0         |
         CSeq: 1                                                          |
         User-Agent: PhonyClient/1.2                                      |
         Transport: RTP/AVP/UDP;unicast;client_port=3056-3057 RTP/AVP/UDP;unicast;client_port=3056-3057,            |
                    RTP/AVP/TCP;unicast;interleave=0-1                    |

   A->C: RTSP/1.0 200 OK                                                  |
         CSeq: 1                                                          |
         Session: 12345678                                                |
         Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;            |
                    server_port=5000-5001                                 |
         Date: 23 Jan 1997 15:35:12 GMT                                   |
         Server: PhonyServer/1.0                                          |
         Expires: 24 Jan 1997 15:35:12 GMT                                |
         Cache-Control: public                                            |
         Accept-Ranges: NPT, SMPTE                                        |

   C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0            |
         CSeq: 1                                                          |
         User-Agent: PhonyClient/1.2                                      |
         Transport: RTP/AVP/UDP;unicast;client_port=3058-3059 RTP/AVP/UDP;unicast;client_port=3058-3059,            |
                    RTP/AVP/TCP;unicast;interleave=0-1                    |

   V->C: RTSP/1.0 200 OK                                                  |
         CSeq: 1                                                          |
         Session: 23456789                                                |
         Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;            |
                    server_port=5002-5003                                 |
         Date: 23 Jan 1997 15:35:12 GMT                                   |
         Server: PhonyServer/1.0                                          |
         Cache-Control: public                                            |
         Expires: 24 Jan 1997 15:35:12 GMT                                |
         Accept-Ranges: NPT, SMPTE                                        |

   C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0             |
         CSeq: 2                                                          |
         User-Agent: PhonyClient/1.2                                      |
         Session: 23456789                                                |
         Range: smpte=0:10:00-                                            |
   V->C: RTSP/1.0 200 OK                                                  |
         CSeq: 2                                                          |
         Session: 23456789                                                |
         Range: smpte=0:10:00-0:20:00 smpte=0:10:00-1:49:23                                     |
         RTP-Info: url=rtsp://video.example.com/twister/video;            |
                   seq=12312232;rtptime=78712811                          |
         Server: PhonyServer/2.0                                          |
         Date: 23 Jan 1997 15:35:13 GMT                                   |

   C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0          |
         CSeq: 2                                                          |
         User-Agent: PhonyClient/1.2                                      |
         Session: 12345678                                                |
         Range: smpte=0:10:00-                                            |

   A->C: RTSP/1.0 200 OK                                                  |
         CSeq: 2
         User-Agent: PhonyClient/1.2                                                          |
         Session: 12345678                                                |
         Range: smpte=0:10:00-0:20:00 smpte=0:10:00-1:49:23                                     |
         RTP-Info: url=rtsp://audio.example.com/twister/audio.en;         |
                   seq=876655;rtptime=1032181                             |
         Server: PhonyServer/1.0                                          |
         Date: 23 Jan 1997 15:35:13 GMT                                   |

   C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0      |
         CSeq: 3                                                          |
         User-Agent: PhonyClient/1.2                                      |
         Session: 12345678                                                |

   A->C: RTSP/1.0 200 OK                                                  |
         CSeq: 3                                                          |
         Server: PhonyServer/1.0                                          |
         Date: 23 Jan 1997 15:36:52 GMT                                   |

   C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0         |
         CSeq: 3                                                          |
         User-Agent: PhonyClient/1.2                                      |
         Session: 23456789                                                |

   V->C: RTSP/1.0 200 OK                                                  |
         CSeq: 3                                                          |
         Server: PhonyServer/2.0                                          |
         Date: 23 Jan 1997 15:36:52 GMT                                   |
   Even though the audio and video track are on two different servers,    |
   and may start at slightly different times and may drift with respect   |
   to each other, the client can synchronize the two using standard RTP   |
   methods, in particular the time scale contained in the RTCP sender     |
   reports.

15.2 Initial synchronization is achieved through the RTP-Info and  |
   Range headers information in the PLAY response.                        |

16.2 Streaming of a Container file                                        |

   For purposes of this example, a container file is a storage entity in  |
   which multiple continuous media types pertaining to the same end-user  |
   presentation are present. In effect, the container file represents an  |
   RTSP presentation, with each of its components being RTSP streams.     |
   Container files are a widely used means to store such presentations.   |
   While the components are transported as independent streams, it is     |
   desirable to maintain a common context for those streams at the        |
   server end.                                                            |

        This enables the server to keep a single storage handle      |
        open easily. It also allows treating all the streams         |
        equally in case of any prioritization of streams by the      |
        server.                                                      |

   It is also possible that the presentation author may wish to prevent   |
   selective retrieval of the streams by the client in order to preserve  |
   the artistic effect of the combined media presentation. Similarly, in  |
   such a tightly bound presentation, it is desirable to be able to       |
   control all the streams via a single control message using an          |
   aggregate URL.                                                         |

   The following is an example of using a single RTSP session to control  |
   multiple streams. It also illustrates the use of aggregate URLs. In a  |
   container file it is also desirable to not write any URL parts which   |
   is not kept, when the container is distributed, like the host and      |
   most of the path element. Therefore this example also uses the "*"     |
   and relative URL in the delivered SDP.                                 |

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

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

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

         v=0                                                              |
         o=- 2890844256 2890842807 IN IP4 172.16.2.93                     |
         s=RTSP Session                                                   |
         i=An Example of RTSP Session Usage                               |
         e=adm@example.com
         a=control:rtsp://example.com/twister                                                |
         a=control: *                                                     |
         a=range: npt=0-0:10:34.10                                        |
         t=0 0                                                            |
         m=audio 0 RTP/AVP 0
         a=control:rtsp://example.com/twister/audio                                              |
         a=control: trackID=1                                             |
         m=video 0 RTP/AVP 26
         a=control:rtsp://example.com/twister/video                                             |
         a=control: trackID=4                                             |

   C->M: SETUP rtsp://example.com/twister/audio rtsp://example.com/twister.3gp/trackID=1 RTSP/1.0          |
         CSeq: 2                                                          |
         User-Agent: PhonyClient/1.2                                      |
         Require: play.basic                                              |
         Transport: RTP/AVP;unicast;client_port=8000-8001 RTP/AVP;unicast;dest_addr=":8000"/":8001"             |

   M->C: RTSP/1.0 200 OK                                                  |
         CSeq: 2                                                          |
         Server: PhonyServer/1.0                                          |
         Transport: RTP/AVP;unicast;client_port=8000-8001;
                    server_port=9000-9001 RTP/AVP;unicast;dest_addr=":8000"/":8001;             |
                    src_addr="172.16.2.93:9000"/"172.16.2.93:9001"        |
                    ssrc=93CB001E                                         |
         Session: 12345678                                                |
         Expires: 24 Jan 1997 15:35:12 GMT                                |
         Date: 23 Jan 1997 15:35:12 GMT                                   |
         Accept-Ranges: NPT                                               |

   C->M: SETUP rtsp://example.com/twister/video rtsp://example.com/twister.3gp/trackID=4 RTSP/1.0          |
         CSeq: 3                                                          |
         User-Agent: PhonyClient/1.2                                      |
         Require: play.basic                                              |
         Transport: RTP/AVP;unicast;client_port=8002-8003 RTP/AVP;unicast;dest_addr=":8002"/":8003"             |
         Session: 12345678                                                |

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

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

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

   C->M: PAUSE rtsp://example.com/twister/video RTSP/1.0
         CSeq: 5
         Session: 12345678

   M->C: rtsp://example.com/twister.3gp/ RTSP/1.0 460 Only aggregate operation allowed                   |
         CSeq: 5
   C->M: PAUSE rtsp://example.com/twister RTSP/1.0
         CSeq: 6                                                          |
         User-Agent: PhonyClient/1.2                                      |
         Session: 12345678                                                |

   M->C: RTSP/1.0 200 OK                                                  |
         CSeq: 6 5                                                          |
         Server: PhonyServer/1.0                                          |
         Date: 23 Jan 1997 15:36:01 GMT                                   |
         Session: 12345678                                                |
         Range: npt=34.57-623.10                                          |

   C->M: SETUP rtsp://example.com/twister RTSP/1.0
         CSeq: 7
         Transport: RTP/AVP;unicast;client_port=10000
         Session: 12345678

   M->C: PLAY rtsp://example.com/twister.3gp/ RTSP/1.0 459 Aggregate operation not allowed
         CSeq: 7

   In the first instance of failure, the client tries to pause one
   stream (in this case video) of the presentation. This is not allowed
   as this session is set up for aggregated control. In the second
   instance, the aggregate URL may not be used for SETUP and one control
   message is required per stream to set up transport parameters.

        This keeps the syntax of the Transport header simple and
        allows easy parsing of transport information by firewalls.

15.3                    |
         CSeq: 6                                                          |
         User-Agent: PhonyClient/1.2                                      |
         Range: npt=34.57-623.10                                          |
         Session: 12345678                                                |

   M->C: RTSP/1.0 200 OK                                                  |
         CSeq: 6                                                          |
         Server: PhonyServer/1.0                                          |
         Date: 23 Jan 1997 15:36:01 GMT                                   |
         Session: 12345678                                                |
         Range: npt=34.57-623.10                                          |
         RTP-Info: url=rtsp://example.com/twister.3gp/trackID=4;          |
            seq=12555;rtptime=6330012,                                    |
           url=rtsp://example.com/twister.3gp/trackID=1;                  |
            seq=55021;rtptime=3132889                                     |

16.3 Single Stream Container Files                                        |

   Some RTSP servers may treat all files as though they are "container    |
   files", yet other servers may not support such a concept. Because of   |
   this, clients SHOULD use the rules set forth in the session            |
   description for request URLs, rather than assuming that a consistent   |
   URL may always be used throughout. Here's an example of how a multi-   |
   stream server might expect a single-stream file to be served:

       C->S          |

   C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/1.0                        |
         Accept: application/x-rtsp-mh, application/sdp                   |
         CSeq: 1

       S->C                                                          |
         User-Agent: PhonyClient/1.2                                      |

   S->C: RTSP/1.0 200 OK                                                  |
         CSeq: 1                                                          |
         Content-base: rtsp://foo.com/test.wav/                           |
         Content-type: application/sdp                                    |
         Content-length: 48                                               |
         Server: PhonyServer/1.0                                          |
         Date: 23 Jan 1997 15:35:06 GMT                                   |
         Expires: 23 Jan 1997 17:00:00 GMT                                |

         v=0                                                              |
         o=- 872653257 872653257 IN IP4 172.16.2.187                      |
         s=mu-law wave file                                               |
         i=audio test                                                     |
         t=0 0                                                            |
         a=control: *                                                     |
         m=audio 0 RTP/AVP 0                                              |
         a=control:streamid=0

       C->S                                             |

   C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0                |
         Transport: RTP/AVP/UDP;unicast;                                  |
            client_port=6970-6971;mode="PLAY"                             |
         CSeq: 2

       S->C                                                          |
         User-Agent: PhonyClient/1.2                                      |
   S->C: RTSP/1.0 200 OK                                                  |
         Transport: RTP/AVP/UDP;unicast;client_port=6970-6971;
                        server_port=6970-6971;mode="PLAY"            |
                     server_port=6970-6971;mode="PLAY";ssrc=EAB98712      |
         CSeq: 2                                                          |
         Session: 2034820394

       C->S                                              |
         Expires: 23 Jan 1997 16:00:00 GMT                                |
         Server: PhonyServer/1.0                                          |
         Date: 23 Jan 1997 15:35:07 GMT                                   |

   C->S: PLAY rtsp://foo.com/test.wav RTSP/1.0                            |
         CSeq: 3                                                          |
         User-Agent: PhonyClient/1.2                                      |
         Session: 2034820394

       S->C                                              |

   S->C: RTSP/1.0 200 OK                                                  |
         CSeq: 3                                                          |
         Server: PhonyServer/1.0                                          |
         Date: 23 Jan 1997 15:35:08 GMT                                   |
         Session: 2034820394                                              |
         Range: npt=0-600                                                 |
         RTP-Info: url=rtsp://foo.com/test.wav/streamid=0;                |
            seq=981888;rtptime=3781123                                    |

   Note the different URL in the SETUP command, and then the switch back  |
   to the aggregate URL in the PLAY command.  This makes complete sense   |
   when there are multiple streams with aggregate control, but is less    |
   than intuitive in the special case where the number of streams is      |
   one. However the server has declared that the aggregated control URL   |
   in the SDP and therefore this is fine.                                 |

   If however the server had not declared an aggregated control URL it    |
   would be another question, in which the client should consider it      |
   lucky if it works.                                                     |

   In this special case, it is recommended also required that servers be forgiving of accept implementations  |
   that send:

       C->S  PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
             CSeq: 3
   In uses the worst case, servers should send back:

       S->C  RTSP/1.0 460 Only aggregate operation allowed
             CSeq: 3

   One would also hope that server implementations are also forgiving of non-aggregated interpretation and uses the following:

       C->S  SETUP rtsp://foo.com/test.wav individual    |
   media URL, like this:                                                  |

   C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/1.0
             Transport: rtp/avp/udp;client_port=6970-6971;mode="PLAY"             |
         CSeq: 2

   Since there is only a single stream in this file, it's not ambiguous
   what this means.

15.4 3                                                          |
         User-Agent: PhonyClient/1.2                                      |

16.4 Live Media Presentation Using Multicast                              |
   The media server M chooses the multicast address and port. Here, we    |
   assume that the web server only contains a pointer to the full         |
   description, while the media server M maintains the full description.  |

   Editors note: Is this example really valid? In what situations does    |
   it make sense to do a setup to a multicast distribution channel, and   |
   also issue PLAY requests?                                              |

   C->W: GET /concert.sdp /sessions.html HTTP/1.1                                      |
         Host: www.example.com                                            |

   W->C: HTTP/1.1 200 OK                                                  |
         Content-Type: application/x-rtsl

         <session>
           <track text/html                                          |

         <html>                                                           |
           ...                                                            |
           <href "Stremed Live Music performance"                         |
              src="rtsp://live.example.com/concert/audio">
         </session>                |
           ...                                                            |
         </html>                                                          |

   C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0          |
         CSeq: 1                                                          |
         Supported: play.basic, play.scale                                |

   M->C: RTSP/1.0 200 OK                                                  |
         CSeq: 1                                                          |
         Content-Type: application/sdp                                    |
         Content-Length: 44 181                                              |
         Server: PhonyServer/1.0                                          |
         Date: 23 Jan 1997 15:35:06 GMT                                   |
         Supported: play.basic                                            |

         v=0                                                              |
         o=- 2890844526 2890842807 IN IP4 192.16.24.202                   |
         s=RTSP Session                                                   |
         m=audio 3456 RTP/AVP 0                                           |
         c=IN IP4 224.2.0.1/16
         a=control:rtsp://live.example.com/concert/audio                                            |
         a=control: rtsp://live.example.com/concert/audio                 |
         a=range:npt=0-                                                   |

   C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0             |
         CSeq: 2                                                          |
         Transport: RTP/AVP;multicast                                     |

   M->C: RTSP/1.0 200 OK                                                  |
         CSeq: 2                                                          |
         Server: PhonyServer/1.0                                          |
         Date: 23 Jan 1997 15:35:06 GMT                                   |
         Transport: RTP/AVP;multicast;destination=224.2.0.1;              |
                    port=3456-3457;ttl=16                                 |
         Session: 0456804596                                              |
         Accept-Ranges: NPT, UTC                                          |

   C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0              |
         CSeq: 3                                                          |
         Session: 0456804596                                              |

   M->C: RTSP/1.0 200 OK                                                  |
         CSeq: 3                                                          |
         Server: PhonyServer/1.0                                          |
         Date: 23 Jan 1997 15:35:07 GMT                                   |
         Session: 0456804596                                              |
         Range:npt=1256-                                                  |
         RTP-Info: url=rtsp://live.example.com/concert/audio;             |
                   seq=1473; rtptime=80000                                |

16.5 Capability Negotiation                                               |

   This examples illustrate how the client and server determines there    |
   capability to support a special feature, in this case "play.scale".    |
   The server through the clients request, and included Supported header  |
   learns that the client is supporting this updated specification, and   |
   also support the playback time scaling feature of RTSP. The server's   |
   response declares that it is also an updated specification minimal     |
   implementation and supports the extra features, of client requested    |
   time scaling and faster than normal transmission rates, plus one       |
   "example.com" proprietary feature "flight". The client also learns     |
   what methods that are possible to use in regards to the indicated      |
   resource.                                                              |

   C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/1.0      |
         CSeq: 2
         Transport: RTP/AVP;multicast

   M->C: 1                                                          |
         Supported: play.basic, play.scale                                |
         User-Agent: PhonyClient/1.2                                      |

   S->C: RTSP/1.0 200 OK                                                  |
         CSeq: 2
         Transport: RTP/AVP;multicast;destination=224.2.0.1;
                    port=3456-3457;ttl=16
         Session: 0456804596

   C->M: PLAY rtsp://live.example.com/concert/audio 1                                                          |
         Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN                    |
         Server: PhonyServer/2.0                                          |
         Supported: play.basic, play.scale, play.speed, example.com.flight|
   When the client sends its SETUP request it tells the server that it    |
   is must support the play.scale feature for this session by including   |
   the Require header.                                                    |

   C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/1.0    |
         CSeq: 3
         Session: 0456804596

   M->C:                                                          |
         User-Agent: PhonyClient/1.2                                      |
         Transport: RTP/AVP/UDP;unicast;client_port=3056-3057,            |
                    RTP/AVP/TCP;unicast;interleave=0-1                    |
         Require: play.scale                                              |

   S->C: RTSP/1.0 200 OK                                                  |
         CSeq: 3                                                          |
         Session: 0456804596
         Range:npt=now-

16 12345678                                                |
         Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;            |
                    server_port=5000-5001                                 |
         Server: PhonyServer/2.0                                          |
         Accept-Ranges: NPT, SMPTE                                        |

17 Syntax

   The RTSP syntax is described in an augmented Backus-Naur form Form (BNF)    |
   as defined in RFC 2234 [14]. Also the "#" rule from RFC 2616 [26] is
   also defined and used in this syntax description.

16.1 [5].                                            |

17.1 Base Syntax                                                          |

   OCTET      =  %x00-FF <any 8-bit sequence of data>                     |
   CHAR       =  %x01-7F <any US-ASCII character (octets 0 1 - 127)>        |
   UPALPHA    =  %x41-5A <any US-ASCII uppercase letter "A".."Z">         |
   LOALPHA    =  %x61-7A <any US-ASCII lowercase letter "a".."z">         |
   ALPHA      =  UPALPHA / LOALPHA                                        |
   DIGIT      =  %x30-39 <any US-ASCII digit "0".."9">                    |
   CTL        =  %x00-1F / %x7F <any US-ASCII control character           |
                 (octets 0 - 31) and DEL (127)>                           |
   CR         =  %x0D <US-ASCII CR, carriage return (13)>                 |
   LF         =  %x0A <US-ASCII LF, linefeed (10)>                        |
   SP         =  %x20 <US-ASCII SP, space (32)>                           |
   HT         =  %x09 <US-ASCII HT, horizontal-tab (9)>
   <">                   |
   DQUOTE     =  %x22 <US-ASCII double-quote mark (34)>                   |
   BACKSLASH  =  %x5C <US-ASCII backslash (92)>                           |
   CRLF       =  CR LF                                                    |
   LWS            =  [CRLF] 1*( SP / HT )                                 |
   TEXT           =  %x20-7D / %x80-FF <any OCTET except CTLs>            |
   tspecials      =  "(" / ")" / "<" / ">" / "@"                          |
                  /  "," / ";" / ":" / BACKSLASH / <"> DQUOTE                 |
                  /  "/" / "[" / "]" / "?" / "="                          |
                  /  "{" / "}" / SP / HT                                  |
   token          =  %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39         |
                  /  %x41-5A / %x5E-7A / %x7C / %x7E                      |
                     1*<any CHAR except CTLs or tspecials>                |
   quoted-string  =  ( <"> *(qdtext) <"> DQUOTE *(qdtext) DQUOTE )                          |
   qdtext         =  %x20-21 / %x23-7D / %x80-FF <any TEXT except <">>    |
   quoted-pair    =  BACKSLASH CHAR                                       |

   safe        =  "$" / "-" / "_" / "." / "+"                             |
   extra       =  "!" / "*" / "'" / "(" / ")" / ","                       |
   hex         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F" /             |
                  "a" / "b" / "c" / "d" / "e" / "f"                       |
   escape      =  "%" hex hex                                             |
   reserved    =  ";" / "/" / "?" / ":" / "@" / "&" / "="                 |
   unreserved  =  alpha / digit / safe / extra                            |
   xchar       =  unreserved / reserved / escape                          |

17.2 RTSP Protocol Definition                                             |

17.2.1 Generic Protocol elements                                          |

   absoluteURL  =  as defined in RFC 2396  [12] and RFC2732  [11]         |
   relativeURL  =  as defined in RFC 2396  [12] and RFC2732  [11]         |
   rtsp_URL     =  rtsp-scheme "//" host [":" port]                       |
                   [abs_path ["?" query]] ["#" fragment]                  |
   rtsp-scheme  = ( "rtsp:" / "rtspu:" / "rtsps:" )                       |
   host         =  As defined by RFC 2732 [11]                            |
   abs_path     =  As defined by RFC 2396 [12]                            |
   port         =  *DIGIT                                                 |
   query        =  As defined by RFC 2396 [12]                            |
   fragment     =  As defined by RFC 2396 [12]                            |

   smpte-range           =  smpte-type "=" smpte-range-spec               |
                            ;Section 3.4                                  |
   smpte-range-spec      =  ( smpte-time "-" [ smpte-time ] )             |
                         /  ( "-" smpte-time )                            |
   smpte-type            =  "smpte" / "smpte-30-drop"                     |
                         /  "smpte-25" / smpte-type-extension             |
                            ; other timecodes may be added                |
   smpte-type-extension  =  token                                         |
   smpte-time            =  1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT            |
                            [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ]             |

   npt-range       =  ["npt" "="] npt-range-spec ; Section 3.5            |
                      ; implementations SHOULD use npt= prefix,           |
                      ;but SHOULD be prepared to interoperate with        |
                      ; RFC 2326 implementations which don't use it.      |
   npt-range-spec  =  ( npt-time "-" [ npt-time ] ) / ( "-" npt-time )    |
   npt-time        =  "now" / npt-sec / npt-hhmmss                        |
   npt-sec         =  1*DIGIT [ "." *DIGIT ]                              |
   npt-hhmmss      =  npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]         |
   npt-hh          =  1*DIGIT ; any positive number                       |
   npt-mm          =  1*2DIGIT ; 0-59                                     |
   npt-ss          =  1*2DIGIT ; 0-59                                     |

   utc-range       =  "clock" "=" utc-range-spec ; Section 3.6            |
   utc-range-spec  =  ( utc-time "-" [ utc-time ] )
   qdtext / ( "-" utc-time )    |
   utc-time        =  <any TEXT except <">>
   quoted-pair  utc-date "T" utc-clock "Z"                          |
   utc-date        =  BACKSLASH CHAR  8DIGIT ; < YYYYMMDD >                               |
   utc-clock       =  6DIGIT [ "." fraction ]; < HHMMSS.fraction >        |
   fraction        =  1*DIGIT                                             |

   feature-tag     =  token                                               |
   session-id      =  8*( ALPHA / DIGIT / safe )                          |
   message-header  =  field-name ":" [ field-value ] CRLF                 |
   field-name      =  token                                               |
   field-value     =  *( field-content / LWS )                            |
   field-content   =  <the OCTETs making up the field-value and           |
                      consisting of either *TEXT or combinations          |
                      of token, tspecials, and quoted-string>
   safe            =  "$" / "-" / "_" / "." / "+"
   extra           =  "!" / "*" / "'" / "(" / ")" / ","
   hex             =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F" /
                      "a" / "b" / "c" / "d" / "e" / "f"
   escape          =  "%" hex hex
   reserved        =  ";" / "/" / "?" / ":" / "@" / "&" / "="
   unreserved      =  alpha / digit / safe / extra
   xchar           =  unreserved / reserved / escape

16.2 RTSP Protocol Definition

16.2.1             |

17.2.2 Message Syntax                                                     |

        RTSP-message  =   Request / Response  ; RTSP/1.0 messages
        generic-message  =  start-line
                            *(message-header CRLF)
                            CRLF
                            [ message-body ]
        start-line       =  Request-Line / Status-Line         |
        Request       =   Request-Line        ; Section 6.1               |
                          *( general-header   ; Section 5                 |
                      /   request-header      ; Section  6.2              |
                      /   entity-header )     ; Section  8.1              |
                          CRLF                                            [
     message-body                                            |
                          [message-body ]     ; Section 4.3               |
        Response      =   Status-Line         ; Section 7.1             *(  general-header               |
                          *(general-header    ; Section 5                 |
                      /   response-header     ; Section 7.1.2             |
                      /   entity-header )     ; Section 8.1               |
                          CRLF                                            |
                          [ message-body ]    ; Section 4.3               |

   Request-Line  =  Method SP Request-URI SP RTSP-Version CRLF            |
   Status-Line   =  RTSP-Version SP Status-Code SP Reason-Phrase CRLF     |

   Method            =  "DESCRIBE"        ; Section 11.2                  |
                     /  "GET_PARAMETER"   ; Section 11.7                  |
                     /  "OPTIONS"         ; Section 11.1                  |
                     /  "PAUSE"           ; Section 11.5                  |
                     /  "PLAY"            ; Section 11.4                  |
                     /  "PING"            ; Section 11.10                 |
                     /  "REDIRECT"        ; Section 11.9                  |
                     /  "SETUP"           ; Section 11.3                  |
                     /  "SET_PARAMETER"   ; Section 11.8                  |
                     /  "TEARDOWN"        ; Section 11.6                  |
                     /  extension-method                                  |
   extension-method  =  token                                             |

   Request-URI   =  "*" / absolute_URI absolute_URL                                    |
   RTSP-Version  =  "RTSP" "/" 1*DIGIT "." 1*DIGIT                        |

        Status-Code  =  "100" ; Continue                             |
                     /  "200" ; OK                                   |
                     /  "201" ; Created                              |
                     /  "250" ; Low on Storage Space                 |
                     /  "300" ; Multiple Choices                     |
                     /  "301" ; Moved Permanently                    |
                     /  "302" ; Moved Temporarily                    |
                     /  "303" ; See Other                            |
                     /  "304" ; Not Modified                         |
                     /  "305" ; Use Proxy                            |
                     /  "400" ; Bad Request                          |
                     /  "401" ; Unauthorized                         |
                     /  "402" ; Payment Required                     |
                     /  "403" ; Forbidden                            |
                     /  "404" ; Not Found                            |
                     /  "405" ; Method Not Allowed                   |
                     /  "406" ; Not Acceptable                       |
                     /  "407" ; Proxy Authentication Required        |
                     /  "408" ; Request Time-out                     |
                     /  "410" ; Gone                                 |
                     /  "411" ; Length Required                      |
                     /  "412" ; Precondition Failed                  |
                     /  "413" ; Request Entity Too Large             |
                     /  "414" ; Request-URI Too Large                |
                     /  "415" ; Unsupported Media Type               |
                     /  "451" ; Parameter Not Understood             |
                     /  "452" ; reserved                             |
                     /  "453" ; Not Enough Bandwidth                 |
                     /  "454" ; Session Not Found                    |
                     /  "455" ; Method Not Valid in This State       |
                     /  "456" ; Header Field Not Valid for Resource  |
                     /  "457" ; Invalid Range                        |
                     /  "458" ; Parameter Is Read-Only               |
                     /  "459" ; Aggregate operation not allowed      |
                     /  "460" ; Only aggregate operation allowed     |
                     /  "461" ; Unsupported transport                |
                     /  "462" ; Destination unreachable              |
                     /  "500" ; Internal Server Error                |
                     /  "501" ; Not Implemented                      |
                     /  "502" ; Bad Gateway                          |
                     /  "503" ; Service Unavailable                  |
                     /  "504" ; Gateway Time-out                     |
                     /  "505" ; RTSP Version not supported           |
                     /  "551" ; Option not supported                 |
                     /  extension-code                               |

        extension-code  =  3DIGIT                                    |
        Reason-Phrase   =  *<TEXT, excluding CR, LF>                 |

   general-header  =  Cache-Control     ; Section 13.9 14.9                    |
                   /  Connection        ; Section 13.10 14.10                   |
                   /  CSeq              ; Section 13.17 14.17                   |
                   /  Date              ; Section 13.18 14.18                   |
                   /  Supported         ; Section 14.38                   |
                   /  Timestamp         ; Section 13.39 14.39                   |
                   /  Via               ; Section 13.44 14.44                   |
                   /  extension-header                                    |

   request-header  =  Accept             ; Section 13.1 14.1 and [H14.1]       |
                   /  Accept-Encoding    ; Section 13.2 14.2 and [H14.3]       |
                   /  Accept-Language    ; Section 13.3 14.3 and [H14.4]       |
                   /  Authorization      ; Section 13.6 14.6 and [H14.8]       |
                   /  Bandwidth          ; Section 13.7 14.7                   |
                   /  Blocksize          ; Section 13.8 14.8                   |
                   /  From               ; Section 13.20 14.20                  |
                   /  If-Match           ; Section 14.22                  |
                   /  If-Modified-Since  ; Section 13.23 14.23 and [H14.25]     |
                   /  Proxy-Require      ; Section 13.27 14.27                  |
                   /  Range              ; Section 13.29 14.29                  |
                   /  Referer            ; Section 13.30 14.30                  |
                   /  Require            ; Section 13.32 14.32                  |
                   /  Scale              ; Section 13.34 14.34                  |
                   /  Session            ; Section 13.37 14.37                  |
                   /  Speed              ; Section 13.35 14.35                  |
                   /  Supported          ; Section 13.38 14.38                  |
                   /  Transport          ; Section 13.40 14.40                  |
                   /  User-Agent         ; Section 13.42 14.42                  |
                   /  extension-header                                    |

   response-header  =  Accept-Ranges       ; Section 13.4 14.4                 |
                    /  Location            ; Section 13.25 14.25                |
                    /  Proxy-Authenticate  ; Section 13.26 14.26                |
                    /  Public              ; Section 13.28 14.28                |
                    /  Range               ; Section 13.29 14.29                |
                    /  Retry-After         ; Section 14.31                |
                    /  RTP-Info            ; Section 14.33                |
                    /  Scale               ; Section 14.34                |
                    /  Session             ; Section 14.37                |
                    /  Server              ; Section 14.36                |
                    /  Speed               ; Section 14.35                |
                    /  Transport           ; Section 14.40                |
                    /  Unsupported         ; Section 14.41                |
                    /  Vary                ; Section 14.43                |
                    /  WWW-Authenticate    ; Section 14.45                |
                    /  extension-header                                   |
   entity-header     =  Allow             ; Section 14.5                  |
                     /  Content-Base      ; Section 14.11                 |
                     /  Content-Encoding  ; Section 14.12                 |
                     /  Content-Language  ; Section 14.13                 |
                     /  Content-Length    ; Section 14.14                 |
                     /  Content-Location  ; Section 14.15                 |
                     /  Content-Type      ; Section 14.16                 |
                     /  Expires           ; Section 14.19 and [H14.21]    |
                     /  Last-Modified     ; Section 14.24                 |
                     /  extension-header                                  |
   extension-header  =  message-header                                    |

17.2.3 Header Syntax                                                      |

   All header syntaxes not defined in this section are defined in         |
   chapter 14 of the HTTP 1.1 specification [4].                          |

   Accept-Ranges      =  "Accept-Ranges" ":" acceptable-ranges            |
   acceptable-ranges  =  (range-unit *("," LWS range-unit))               |
                      /  "none"                                           |
   range-unit         =  NPT / SMPTE / UTC / extension-format             |
   extension-format   =  token                                            |
   Bandwidth          =  "Bandwidth" ":" 1*DIGIT                          |
   Blocksize          =  "Blocksize" ":" 1*DIGIT                          |

   Cache-Control             =  "Cache-Control" ":" cache-directive       |
                                *("," LWS cache-directive)                |
   cache-directive           =  cache-request-directive                   |
                             /  cache-response-directive                  |
   cache-request-directive   =  "no-cache"                                |
                             /  "max-stale" ["=" delta-seconds]           |
                             /  Retry-After         ; Section 13.31  "min-fresh" "=" delta-seconds             |
                             /  RTP-Info            ; Section 13.33  "only-if-cached"                          |
                             /  Scale               ; Section 13.34  cache-extension                           |
   cache-response-directive  =  "public"                                  |
                             /  Session             ; Section 13.37  "private"                                 |
                             /  Server              ; Section 13.36  "no-cache"                                |
                             /  Speed               ; Section 13.35  "no-transform"                            |
                             /  Transport           ; Section 13.40  "must-revalidate"                         |
                             /  Unsupported         ; Section 13.41  "proxy-revalidate"                        |
                             /  Vary                ; Section 13.43  "max-age" "=" delta-seconds               |
                             /  WWW-Authenticate    ; Section 13.45

rtsp_URL  cache-extension                           |
   cache-extension           =  ( "rtsp:" / "rtspu:"  token ["=" (token / "rtsps" )
                     "//" host [ ":" port ] [ abs_path ] [ "#" fragment ]
host quoted-string)]       |
   delta-seconds             =  As defined by RFC 2732 [30]
abs_path  1*DIGIT                                   |
   Content-Base   =  As defined by RFC 2396 [22]
port  "Content-Base" ":" absoluteURL                       |
   CSeq           =  *DIGIT
smpte-range  "Cseq" ":" 1*DIGIT                                   |
   Proxy-Require  =  smpte-type "=" smpte-range-spec
smpte-range-spec  "Proxy-Require" ":" feature-tag                      |
                     *("," LWS feature-tag)                               |
   Public         =  ( smpte-time "-"  "Public" ":" method *("," LWS method)                |
   Range          =  "Range" ":" ranges-spec *("," LWS ranges-spec)       |
                     [ smpte-time ";" "time" "=" utc-time ] ) / ( "-" smpte-time )

smpte-type                          |
   ranges-spec    =  "smpte"  npt-range / "smpte-30-drop" utc-range / "smpte-25"
                     ; other timecodes may be added
smpte-time smpte-range                  |
   Require        =  1*2DIGIT ":" 1*2DIGIT  "Require" ":" 1*2DIGIT
                     [ feature-tag *("," LWS feature-tag)     |

   RTP-Info        =  "RTP-Info" ":" 1*2DIGIT [ "." 1*2DIGIT ] ]

npt-range rtsp-info-spec                       |
                      *("," LWS rtsp-info-spec)                           |
   rtsp-info-spec  =  ["npt" "="] npt-range-spec
                   ; implementations SHOULD use npt= prefix, but SHOULD
                   ; be prepared to interoperate with RFC 2326  stream-url 1*parameter                              |
   stream-url      =  quoted-url / unquoted-url                           |
   unquoted-url    =  "url" "=" safe-url                                  |
   quoted-url      =  "url" "=" DQUOTE needquote-url DQUOTE               |
   safe-url        =  url                                                 |
   needquote-url   =  url //That contains ; implementations which don't use it
npt-range-spec or ,                          |
   url             =  ( npt-time "-" [ npt-time ] ) absoluteURL / ( "-" npt-time relativeURL )
npt-time                       |
   parameter       =  "now" / npt-sec  ";" "seq" "=" 1*DIGIT                               |
                   / npt-hhmmss
npt-sec  ";" "rtptime" "=" 1*DIGIT                           |

   Scale      =  "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
npt-hhmmss               |
   Speed      =  npt-hh ":" npt-mm  "Speed" ":" npt-ss 1*DIGIT [ "." *DIGIT ]
npt-hh          =  1*DIGIT ; any positive number
npt-mm          =  1*2DIGIT ; 0-59
npt-ss          =  1*2DIGIT ; 0-59
utc-range       =  "clock" "=" utc-range-spec
utc-range-spec                       |
   Server     =  "Server" ":" ( utc-time "-" [ utc-time ] ) product / ( "-" utc-time comment )
utc-time                       |
                 *(SP (product / comment))                                |
   Session    =  utc-date "T" utc-time "Z"
utc-date  "Session" ":" session-id                                 |
                 [ ";" "timeout" "=" delta-seconds ]                      |
   Supported  =  8DIGIT ; < YYYYMMDD >
utc-time  "Supported" ":" [feature-tag *("," LWS feature-tag)]     |

   Timestamp       =  6DIGIT  "Timestamp" ":" *(DIGIT) ["." *(DIGIT)] [delay]     |
   delay           =  *(DIGIT) [ "." fraction ]; < HHMMSS.fraction >
fraction        =  1*DIGIT

feature-tag  =  token

16.2.2 Header Syntax *(DIGIT) ]                           |
   Transport       =  "Transport" ":" 1#transport-spec transport-spec                      |
                      *("," LWS transport-spec)                           |
   transport-spec  =  transport-id *parameter                             |
   transport-id    =  transport-protocol  transport-prot "/" profile ["/" lower-transport]    |
                      ; no LWS is allowed inside transport-id
   transport-protocol             |

   transport-prot    =  "RTP" / token                                     |
   profile           =  "AVP" / token                                     |
   lower-transport   =  "TCP" / "UDP" / token                             |
   parameter         =  ";" ( "unicast" / "multicast" )                   |
                    /   ";" "source" "=" host                             |
                    /   ";" "destination" [ "=" host ]                    |
                    /   ";" "interleaved" "=" channel [ "-" channel ]     |
                    /   ";" "append"                                      |
                    /   ";" "ttl" "=" ttl                                 |
                    /   ";" "layers" "=" 1*DIGIT                          |
                    /   ";" "port" "=" port-spec                          |
                    /   ";" "client_port" "=" port-spec                   |
                    /   ";" "server_port" "=" port-spec                   |
                    /   ";" "ssrc" "=" ssrc                               |
                    /   ";" "client_ssrc" "=" ssrc                        |
                    /   ";" "mode" "=" mode-spec                          |
                    /   ";" "dest_addresses" "dest_addr" "=" addr-list                     |
                    /   ";" "src_addresses" "src_addr" "=" addr-list                      |
                    /   ";" trn-parameter-extension trn-param-ext                                 |
   port-spec         =  port [ "-" port ]
   trn-parameter-extension                                 |
   trn-param-ext     =  par-name "=" trn-par-value                        |
   par-name          =  token                                             |
   trn-par-value     =  *unreserved  *(unreserved / DQUOTE *TEXT DQUOTE)               |
   ttl               =  1*3(DIGIT)                                        |
   ssrc              =  8*8(HEX)                                          |
   channel           =  1*3(DIGIT)                                        |
   mode-spec         =  <"> 1#mode <">  ( DQUOTE mode *("," *SP mode) DQUOTE ) / mode     |
   mode              =  "PLAY" / "RECORD" / token                         |
   addr-list         =  quoted-host-port *("/" quoted-host-port)          |
   quoted-host-port  =  <">  DQUOTE host [":" port]<">

17 port] DQUOTE                     |

   Unsupported  =  "Unsupported" ":" feature-tag *("," feature-tag)       |
   User-Agent   =  "User-Agent" ":" ( product / comment )                 |
                   0*(SP (product / comment)                              |

18 Security Considerations

   Because of the similarity in syntax and usage between RTSP servers
   and HTTP servers, the security considerations outlined in [H15]
   apply.  Specifically, please note the following:

        Authentication Mechanisms: RTSP and HTTP share common
             authentication schemes, and thus should follow the same
             prescriptions with regards to authentication . See chapter
             15.1 of [2] [16] for client authentication issues, and chapter
             15.2 of [2] [16] for issues regarding support for multiple
             authentication mechanisms. Also see [H15.6].

        Abuse of Server Log Information: RTSP and HTTP servers will
             presumably have similar logging mechanisms, and thus should
             be equally guarded in protecting the contents of those
             logs, thus protecting the privacy of the users of the
             servers. See [H15.1.1] for HTTP server recommendations
             regarding server logs.

        Transfer of Sensitive Information: There is no reason to believe
             that information transferred via RTSP may be any less
             sensitive than that normally transmitted via HTTP.
             Therefore, all of the precautions regarding the protection
             of data privacy and user privacy apply to implementors of
             RTSP clients, servers, and proxies. See [H15.1.2] for
             further details.

        Attacks Based On File and Path Names: Though RTSP URLs are
             opaque handles that do not necessarily have file system
             semantics, it is anticipated that many implementations will
             translate portions of the request URLs directly to file
             system calls. In such cases, file systems SHOULD follow the
             precautions outlined in [H15.5], such as checking for ".."
             in path components.

        Personal Information: RTSP clients are often privy to the same
             information that HTTP clients are (user name, location,
             etc.)  and thus should be equally. See [H15.1] for further
             recommendations.

        Privacy Issues Connected to Accept Headers: Since may of the
             same "Accept" headers exist in RTSP as in HTTP, the same
             caveats outlined in [H15.1.4] with regards to their use
             should be followed.

        DNS Spoofing: Presumably, given the longer connection times
             typically associated to RTSP sessions relative to HTTP
             sessions, RTSP client DNS optimizations should be less
             prevalent.  Nonetheless, the recommendations provided in
             [H15.3] are still relevant to any implementation which
             attempts to rely on a DNS-to-IP mapping to hold beyond a
             single use of the mapping.

        Location Headers and Spoofing: If a single server supports
             multiple organizations that do not trust one another, then
             it must check the values of Location and Content-Location
             header fields in responses that are generated under control
             of said organizations to make sure that they do not attempt
             to invalidate resources over which they have no authority.
             ([H15.4])

   In addition to the recommendations in the current HTTP specification
   (RFC 2616 [26], [4], as of this writing) and also of the previous RFC2068
   [2],
   [16], future HTTP specifications may provide additional guidance on
   security issues.

   The following are added considerations for RTSP implementations.

        Concentrated denial-of-service attack: The protocol offers the
             opportunity for a remote-controlled denial-of-service
             attack.

             The attacker may initiate traffic flows to one or more IP
             addresses by specifying them as the destination in SETUP
             requests. While the attacker's IP address may be known in
             this case, this is not always useful in prevention of more
             attacks or ascertaining the attackers identity. Thus, an
             RTSP server SHOULD only allow client-specified destinations
             for RTSP-initiated traffic flows if the server has verified
             the client's identity, either against a database of known
             users using RTSP authentication mechanisms (preferably
             digest authentication or stronger), or other secure means.

        Session hijacking: Since there is no or little relation between
             a transport layer connection and an RTSP session, it is
             possible for a malicious client to issue requests with
             random session identifiers which would affect unsuspecting
             clients. The server SHOULD use a large, random and non-
             sequential session identifier to minimize the possibility
             of this kind of attack.

        Authentication: Servers SHOULD implement both basic and digest
             [6]
             [7] authentication. In environments requiring tighter
             security for the control messages, transport layer
             mechanisms such as TLS (RFC 2246 [27]) [26]) SHOULD be used.

        Stream issues: RTSP only provides for stream control. Stream
             delivery issues are not covered in this section, nor in the
             rest of this draft. RTSP implementations will most likely
             rely on other protocols such as RTP, IP multicast, RSVP and
             IGMP, and should address security considerations brought up
             in those and other applicable specifications.

        Persistently suspicious behavior: RTSP servers SHOULD return
             error code 403 (Forbidden) upon receiving a single instance
             of behavior which is deemed a security risk. RTSP servers
             SHOULD also be aware of attempts to probe the server for
             weaknesses and entry points and MAY arbitrarily disconnect
             and ignore further requests clients which are deemed to be
             in violation of local security policy.

18

19 IANA Considerations

   This section set up a number of registers for RTSP that should be
   maintained by IANA. For each registry there is a description on what
   it shall contain, what specification is needed when adding a entry
   with IANA, and finally the entries that this document needs to
   register. See also the section 1.6 "Extending RTSP". There is also a an
   IANA registration of two SDP attributes.

   The sections describing how to register an item uses some of the
   requirements level described in RFC 2434 [29], [17], namely " First Come,
   First Served", "Specification Required", and "Standards Action".

   A registration request to IANA MUST contain the following
   information:

        o A name of the item to register according to the rules
          specified by the intended registry.

        o Indication of who has change control over the feature (for
          example, IETF, ISO, ITU-T, other international standardization
          bodies, a consortium or consortium, a particular company or group of
          companies);
          companies, or an individual);

        o A reference to a further description, if available, for
          example (in order of preference) an RFC, a published standard,
          a published paper, a patent filing, a technical report,
          documented source code or a computer manual;

        o For proprietary features, contact information (postal and
          email address);

18.1

19.1 Feature-tags

18.1.1

19.1.1 Description

   When a client and server try to determine what part and functionality
   of the RTSP specification and any future extensions that its counter
   part implements there is need for a namespace.  This registry
   contains named entries representing certain functionality.

   The usage of feature-tags is explained in section 10 and 11.1.

18.1.2

19.1.2 Registering New Feature-tags with IANA

   The registering of feature-tags is done on a first come, first served
   basis.

   The name of the feature MUST follow these rules: The name may be of    |
   any length, but SHOULD be no more than twenty characters long. The     |
   name MUST not contain any spaces, or control characters.  The          |
   registration SHALL indicate if the feature tag applies to servers      |
   only, proxies only or both server and proxies. Any proprietary         |
   feature SHALL have as the first part of the name a vendor tag, which   |
   identifies the organization.

18.1.3

19.1.3 Registered entries

   The following feature-tags are in this specification defined and
   hereby registered. The change control belongs to the Authors and the
   IETF MMUSIC WG.

        play.basic: The minimal implementation for playback operations    |
             according to section D. Applies for both servers and         |
             proxies.                                                     |

        play.scale: Support of scale operations for media playback.       |
             Applies only for servers.                                    |

        play.speed: Support of the speed functionality for playback.      |
             Applies only for servers                                     |

18.2

19.2 RTSP Methods

18.2.1

19.2.1 Description

   What a method is, is described in section 11.  Extending the protocol
   with new methods allow for totally new functionality.

18.2.2

19.2.2 Registering New Methods with IANA

   A new method MUST be registered through an IETF standard track
   document. The reason is that new methods may radically change the
   protocols behavior and purpose.

   A specification for a new RTSP method MUST consist of the following
   items:

        o A method name which follows the BNF rules for methods.

        o A clear specification on what action and response a request
          with the method will result in. Which directions the method is
          used, C -> S or S -> C or both. How the use of headers, if
          any, modifies the behavior and effect of the method.

        o A list or table specifying which of the registered headers
          that are allowed to use with the method in request or/and
          response.

        o Describe how the method relates to network proxies.

18.2.3

19.2.3 Registered Entries

   This specification, RFCXXXX, registers 10 methods: DESCRIBE,
   GET_PARAMETER, OPTIONS, PAUSE, PING, PLAY, REDIRECT, SETUP,
   SET_PARAMETER, and TEARDOWN.

18.3

19.3 RTSP Status Codes

18.3.1

19.3.1 Description

   A status code is the three digit numbers used to convey information
   in RTSP response messages, see  7.  The number space is limited and
   care should be taken not to fill the space.

18.3.2

19.3.2 Registering New Status Codes with IANA

   A new status code can only be registered by an IETF standards track
   document. A specification for a new status code MUST specify the
   following:

        o The requested number.

        o A description what the status code means and the expected
          behavior of the sender and receiver of the code.

18.3.3

19.3.3 Registered Entries

   RFCXXX, registers the numbered status code defined in the BNF entry
   "Status-Code" except "extension-code" in section 7.1.1.

18.4 17.2.2.

19.4 RTSP Headers

18.4.1

19.4.1 Description

   By specifying new headers a method(s) can be enhanced in many
   different ways. An unknown header will be ignored by the receiving
   entity. If the new header is vital for a certain functionality, a
   feature-tag for the functionality can be created and demanded to be
   used by the counter-part with the inclusion of a Require header
   carrying the feature-tag.

18.4.2

19.4.2 Registering New Headers with IANA

   A public available specification is required to register a header.
   The specification SHOULD be a standards document, preferable an IETF
   RFC.

   The specification MUST contain the following information:

        o The name of the header.

        o A BNF specification of the header syntax.

        o A list or table specifying when the header may be used,
          encompassing all methods, their request or response, the
          direction (C -> S or S -> C).

        o How the header shall be handled by proxies.

        o A description of the purpose of the header.

18.4.3

19.4.3 Registered entries

   All headers specified in section 13 14 in RFCXXXX are to be registered.

   Furthermore the following RTSP headers defined in other
   specifications are registered:

        o x-wap-profile defined in [35].

        o x-wap-profile-diff defined in [35].

        o x-wap-profile-warning defined in [35].

        o x-predecbufsize defined in [35].

        o x-initpredecbufperiod defined in [35].

        o x-initpostdecbufperiod defined in [35].

          Note: The use of "X-" is NOT RECOMMENDED but the above headers
          in the register list was defined prior to the clarification.

18.5

19.5 Transport Header registries

   The transport header contains a number of parameters which have
   possibilities for future extensions. Therefore registries for these
   must be defined.

18.5.1

19.5.1 Transport Protocols

   A registry for the parameter transport-protocol shall be defined with
   the following rules:

        o Registering requires public available standards specification.

        o A contact person or organization with address and email.

        o A value definition that are following the BNF token
          definition.

        o A describing text that explains how the registered value are
          used in RTSP.

   This specification register registers 1 value:

        o Use of the RTP  [23]  [15] protocol for media transport. The usage
          is explained in RFC XXXX, appendix B.1.

18.5.2

19.5.2 Profile

   A registry for the parameter profile shall be defined with the
   following rules:

        o Registering requires public available standards specification.

        o A contact person or organization with address and email.

        o A value definition that are following the BNF token
          definition.

        o A definition of which Transport protocol(s) that this profile
          is valid for.

        o A describing text that explains how the registered value are
          used in RTSP.

   This specification registers 1 value:

        o The "RTP profile for audio and video conferences with minimal
          control"  [1]  [3] MUST only be used when the transport headers
          specification's transport-protocol is "RTP".

18.5.3

19.5.3 Lower Transport
   A registry for the parameter lower-transport shall be defined with
   the following rules:

        o Registering requires public available standards specification.

        o A contact person or organization with address and email.

        o A value definition that are following the BNF token
          definition.

        o A describing text that explains describing how the registered value are used in RTSP.

   This includes specification registers 2 values:                                 |

        o Indicates the use of the "User datagram protocol"  [7]  [8] for
          media transport.

        o Indicates the use Transmission control protocol  [9] for media
          transport.

18.5.4

19.5.4 Transport modes

   A registry for the transport parameter mode shall be defined with the
   following rules:

        o Registering requires a IETF standard tracks document.

        o A contact person or organization with address and email.

        o A value definition that are following the BNF token
          definition.

        o A describing text that explains how the registered value are
          used in RTSP.

   This specification registers 2 values:                                 |

        o See RFC XXXX.

        o See RFC XXXX.

18.6

19.6 Cache Directive Extensions

   There exist a number of cache directives which can be sent in the
   Cache-Control header. A registry for this cache directives shall be
   defined with the following rules:

        o Registering requires a IETF standard tracks document.

        o A registration shall name a contact person.

        o Name of the directive and a definition of the value, if any.

        o Specification if it is an request or response directive.

        o A describing text that explains how the cache directive is
          used for RTSP controlled media streams.

18.7

   This specification registers the following values:                     |

19.7 SDP attributes

   This specification defines two SDP [24] [2] attributes that it is
   requested that IANA register.

   SDP Attribute ("att-field"):                                           |

        Attribute name:     range                                         |
        Long form:          Media Range Attribute                         |
        Type of name:       att-field                                     |
        Type of attribute:  Media and session level                       |
        Subject to charset: No                                            |
        Purpose:            RFC XXXX                                      |
        Reference:          RFC XXXX                                      |
        Values:             See ABNF definition.                          |

        Attribute name:     control                                       |
        Long form:          RTSP control URL                              |
        Type of name:       att-field                                     |
        Type of attribute:  Media and session level                       |
        Subject to charset: No                                            |
        Purpose:            RFC XXXX                                      |
        Reference:          RFC XXXX                                      |
        Values:             Absolute or Relative URLs.                    |

        Attribute name:     etag                                          |
        Long form:          Entity Tag                                    |
        Type of name:       att-field                                     |
        Type of attribute:  Media and session level                       |
        Subject to charset: No                                            |
        Purpose:            RFC XXXX                                      |
        Reference:          RFC XXXX                                      |
        Values:             See ABNF definition                           |

A RTSP Protocol State Machine

   The RTSP session state machine describe the behavior of the protocol   |
   from RTSP session initialization through RTSP session termination.     |

   State machine is defined on a per session basis which is uniquely      |
   identified by the RTSP session identifier. The session may contain     |
   one or more media streams depending on state. If a single media        |
   stream is part of the session it is in non-aggregated control. If two  |
   or more is part of the session it is in aggregated control.            |

   This state machine is one possible representation that helps explain   |
   how the protocol works and when different requests are allowed.  We    |
   find it a reasonable representation but does not mandate it, and       |
   other representations can be created.                                  |

A.1 States                                                                |

   The state machine contains three states, described below. For each     |
   state there exist a table which shows which requests and events that   |
   is allowed and if they will result in a state change.                  |

        Init: Initial state no session exist.                             |

        Ready: Session is ready to start playing.                         |

        Play: Session is playing, i.e. sending media stream data in the   |
             direction S -> C.                                            |

A.2 State variables                                                       |

   This representation of the state machine needs more than its state to  |
   work. A small number of variables are also needed and is explained     |
   below.                                                                 |

        NRM: The number of media streams part of this session.            |

        RP: Resume point, the point in the presentation time line at      |
             which a request to continue will resume from. A time format  |
             for the variable is not mandated.                            |

A.3 Abbreviations                                                         |

   To make the state tables more compact a number of abbreviations are    |
   used, which are explained below.                                       |

        IFI: IF Implemented.                                              |

        md: Media                                                         |

        PP: Pause Point, the point in the presentation time line at       |
             which the presentation was paused.                           |

        Prs: Presentation, the complete multimedia presentation.          |

        RedP: Redirect Point, the point in the presentation time line at  |
             which a REDIRECT was specified to occur.                     |

        SES: Session.                                                     |

A.4 State Tables                                                          |

   This section contains a table for each state. The table contains all   |
   the requests and events that this state is allowed to act on.  The     |
   events which is method names are, unless noted, requests with the      |
   given method in the direction client to server (C -> S). In some       |
   cases there exist one or more requisite. The response column tells     |
   what type of response actions should be performed. Possible actions    |
   that is requested for an event includes: response codes, e.g. 200,     |
   headers that MUST be included in the response, setting of state        |
   variables, or setting of other session related parameters. The new     |
   state column tells which state the state machine shall change to.      |

   The response to valid request meeting the requisites is normally a     |
   2xx (SUCCESS) unless other noted in the response column. The           |
   exceptions shall be given a response according to the response         |
   column. If the request does not meet the requisite, is erroneous or    |
   some other type of error occur the appropriate response code MUST be   |
   sent. If the response code is a 4xx the session state is unchanged. A  |
   response code of 3rr will result in that the session is ended and its  |
   state is changed to Init. A response code of 304 results in no state   |
   change. However there exist restrictions to when a 3xx response may    |
   be used. A 5xx response SHALL not result in any change of the session  |
   state, except if the error is not possible to recover from. A          |
   unrecoverable error SHALL result the ending of the session. As it in   |
   the general case can't be determined if it was a unrecoverable error   |
   or not the client will be required to test. In the case that the next  |
   request after a 5xx is responded with 454 (Session Not Found) the      |
   client SHALL shall assume that the session has been ended.                   |

   The server will timeout the session after the period of time           |
   specified in the SETUP response, if no activity from the client is     |
   detected.  Therefore there exist a timeout event for all states        |
   except Init.                                                           |

   In the case that NRM=1 the presentation URL is equal to the media      |
   URL. For NRM>1 the presentation URL MUST be other than any of the      |
   medias that are part of the session. This applies to all states.       |

   Event         Prerequisite    Response
   ______________________________________________________________
   DESCRIBE      Needs REDIRECT  3rr Redirect
   DESCRIBE                      200, Session description
   OPTIONS       Session ID      200, Reset session timeout timer
   OPTIONS                       200
   SET_PARAMETER Valid parameter 200, change value of parameter
   GET_PARAMETER Valid parameter 200, return value of parameter

   Table 6: 11: None state-machine changing events

   The methods in Table 6 11 do not have any effect on the state machine
   or  | the state variables. However some methods do change other session      |
   related parameters, for example SET_PARAMETER which will set the       |
   parameter(s) specified in its body.                                    |

       Action           Requisite       New State  Response

________________________________________________

_____________________________________________________________
       SETUP                              Ready    NRM=1, RP=0.0
       SETUP            Needs Redirect    Init     3rr Redirect
       S -> C:REDIRECT  No Session hdr    Init     Terminate all SES

   Table 7: 12: State: Init

   The initial state of the state machine, see Table 7 12 can only be left   |
   by processing a correct SETUP request. As seen in the table the two    |
   state variables are also set by a correct request. also set by a correct request. This table also
   shows that a correct SETUP can in some cases be redirected to another
   URL and/or server by a 3rr response.

   In the Ready state, see Table 13, some of the actions are depending
   on the number of media streams (NRM) in the session, i.e. aggregated
   or non-aggregated control. A setup request in the ready state can
   either add one more media stream to the session or if the media
   stream (same URL) already is part of the session change the transport
   parameters. TEARDOWN is depending on both the request URL and the
   Action           Requisite          New State  Response
   ______________________________________________________________________
   SETUP            New URL              Ready    NRM+=1
   SETUP            Setten up URL        Ready    Change transport param.
   TEARDOWN         Prs URL,NRM>1        Init     No session hdr
   TEARDOWN         md URL,NRM=1         Init     No Session hdr, NRM=0
   TEARDOWN         md URL,NRM>1         Ready    Session hdr, NRM-=1
   PLAY             Prs URL, No range    Play     Play from RP
   PLAY             Prs URL, Range       Play     according to range
   PAUSE            Prs URL              Ready    Return PP
   S -> C:REDIRECT  Range hdr            Ready    Set RedP
   S -> C:REDIRECT  no range hdr         Init     Session is removed
   Timeout                               Init
   RedP reached                          Ready    TEARDOWN of session

   Table 13: State: Ready

   number of media stream within the session. If the request URL is the
   presentations URL the whole session is torn down. If a media URL is
   used in the TEARDOWN request and more than one media exist in the
   session, the session will remain and a session header MUST be
   returned in the response. If only a single media stream remains in
   the session when performing a TEARDOWN with a media URL the session
   is removed. The number of media streams remaining after tearing down
   a media stream determines the new state.

   The Play state table, see Table 14, is the largest. The table
   contains an number of request that has presentation URL as a
   prerequisite on the request URL, this is due to the exclusion of
   non-aggregated stream control in sessions with more than one media
   stream.

   To avoid inconsistencies between the client and server, automatic
   state transitions are avoided. This table also     |
   shows that a correct SETUP can be seen at for example "End
   of media" event when all media has finished playing, the session
   still remain in some cases Play state. An explicit PAUSE request must be redirected sent to another  |
   URL and/or server
   change the state to Ready. It may appear that there exist two
   automatic transitions in "RedP reached" and "PP reached", however
   they are requested and acknowledge before they take place. The time
   at which the transition will happen is known by a 3rr response.                                   | looking at the range
   header. If the client sends request close in time to these
   transitions it must be prepared for getting error message as the
   state may or may not have changed.

B Media Transport Alternatives
   Action           Requisite         New State  Response
   ______________________________________________________________________
   ________________________________________________________________________
   PAUSE            PrsURL,No range     Ready    Set RP to present point
   PAUSE            PrsURL,Range>now    Play     Set RP & PP to given point
   PAUSE            PrsURL,Range<now    Ready    Set RP to Range Hdr.
   PP reached                           Ready    RP = PP
   End of media     All media           Play     No action, RP = Invalid
   End of media     >1 Media plays      Play     No action
   End of range                         Play     Set RP = End of range
   SETUP            New URL                      Ready
   NRM+=1             Play     455
   SETUP              Setten   up            Setuped URL
   Ready         Play     455
   SETUP            Setuped URL, IFI    Play     Change transport param.
   TEARDOWN         Prs URL,NRM>1       Init     No session hdr
   TEARDOWN         md URL,NRM=1        Init     No Session hdr, NRM=0
   TEARDOWN         md     URL,NRM>1            Ready       Session    hdr,    NRM-=1
   PLAY              Prs   URL,   No   range      Play       Play   from
   RP              PLAY               Prs   URL,   Range        Play
   according  to  range        PAUSE              Prs URL
   Ready       Return    PP              Play     455
   S -> C:REDIRECT  Range hdr            Ready           Play     Set RedP
   S -> C:REDIRECT  no range hdr        Init     Session is removed
   Timeout
   Init
   RedP reached                          Ready                         Play     TEARDOWN of session
   Timeout                              Init     Stop Media playout

   Table 8: 14: State: Ready

   In Play

   This chapter defines how certain combinations of protocols, profiles
   and lower transports are used. This includes the usage of the
   Transport header's general source and destination parameters
   "src_addr" and "dest_addr".

B.1 RTP

   This section defines the interaction of RTSP with respect to the RTP
   protocol [15]. It also defines any necessary media transport
   signalling with regards to RTP.

   The available RTP profiles and lower layer transports are described
   below along with rules on signalling the available combinations.

B.1.1 AVP

   The usage of the "RTP Profile for Audio and Video Conferences with
   Minimal Control" [3] when using RTP for media transport over
   different lower layer transport protocols are defined below in
   regards to RTSP.

   On such case is defined within this document, the use of embedded
   (interleaved) binary data as defined in section  12.  The usage of
   this method is indicated by include the "interleaved" parameter.

   When using embedded binary data the "src_addr" and "dest_addresses"
   SHALL NOT be used. This addressing and multiplexing is used as
   defined with use of channel numbers and the interleaved parameter.

B.1.2 AVP/UDP

   This part descibes sending of RTP [15] over lower transport layer UDP
   [8] according to the profile "RTP Profile for Audio and Video
   Conferences with Minimal Control" defined in RFC 3551 [3]. This
   profiles requires that one or two uni- or bi-directional UDP flows
   per media stream.  The first UDP flow is for RTP and the second is
   for RTCP. Embedded (interleaved) data when RTSP messages is
   transported over UDP SHOULD NOT be performed.

   The RTP/UDP and RTCP/UDP flows can be established in two ways using
   the Ready state, see Table 8, some of Transport header's parameters. The way provided in RFC 2326 was
   to use the actions are depending on  | necessary parameters from the number set of media streams (NRM) "source",
   "destination", "client_port", and "server_port". This has the
   advantage of being compatible with all RTP capable RTSP servers and
   clients. However this method does not provide a possibility to
   specify non-continues port ranges for RTP and RTCP.  The other way is
   to use the parameters "src_addr", and "dest_addr". This method
   provides total flexibility in specifying address and port number for
   each transport flow. However the session, disadvantage is that it is not
   supported by non-updated clients, i.e. aggregated or   |
   non-aggregated control. A setup request clients not supporting the
   "play.basic" feature-tag.

   When using the "source", "destination", "client_port", and
   "server_port" the packets are be addressed in the ready state can either  |
   add one more following way for
   media stream playback:

        o RTP/UDP packet from the server to the session or if client SHALL be sent to
          the media stream (same  |
   URL) already address specified in the "destination" parameter and first
          even port number given in client_port range. If there is part of only
          a single port number given that MUST be given.

        o The server SHOULD send its RTP/UDP packets from the session change address
          specified in "source" parameter and from the transport parameters.   |
   TEARDOWN first even port
          number specified in "server_port" parameter.

        o If there is depending on both specified a range in "client_port" parameter that
          contains at least two port numbers, the request URI and RTCP/UDP packets from
          server to client SHALL be sent to address specified in the
          "destination" parameter and first odd port number part of media  |
   stream within the session. If
          range specified in the request URI is client_port parameter.

        o The Server SHOULD send its RTCP/UDP packets from the presentations address    |
   URI the whole session is torn down. If a media URL is used
          specified in "source" parameter and from the first odd port     |
   TEARDOWN request and more
          number greater than one media exist the RTP port number specified in            |
          "server_port" parameter.                                        |

        o RTCP/UDP packets from the session, client to the     |
   session will remain and a session header MUST server SHALL be returned sent    |
          to the address specified in the "source" parameter and first    |
   response. If only a single media stream remains
          odd port number greater than the RTP port number given in       |
          client_port range.                                              |

        o The client SHOULD send its RTCP/UDP packets from the session when address    |
   performing a TEARDOWN with a media URL
          specified in "destination" parameter and from the session is removed. The first odd     |
          port number specified in "server_port" parameter.               |

   The usage of "src_addr" and "dest_addr" parameters to specify the
   address and port numbers are done in the following way for media streams remaining after tearing down
   playback, i.e. Mode=PLAY:

        o The "src_addr" and "dest_addr" parameters MUST contain either
          1 or 2 address and port pairs.

        o Each address and port pair MUST contain both and address and a media stream    |
   determines
          port number.

        o The first address and port pair given in either of the new state.                                              |
          parameters applies to the RTP stream. The Play state table, see Table 9, is second address and
          port pair if present applies to the largest. RTCP stream.

        o The table contains  |
   an number of request that has presentation URL as a prerequisite on    | RTP/UDP packets from the request URL, this is due server to the exclusion client SHALL be
          sent to the address and port given by first address and port
          pair of non-aggregated        |
   stream control in sessions with more than one media stream.            |
   Action           Requisite         New State  Response
   ________________________________________________________________________

   PAUSE            PrsURL,No  range      Ready     Set  RP the "dest_addr" parameter.

        o The RTCP/UDP packets from the server to  present
   point    PAUSE            PrsURL,Range>now    Play     Set RP & PP the client SHALL be
          sent to the address and port given point PAUSE            PrsURL,Range<now    Ready    Set  RP  to
   Range  Hdr.        PP reached                           Ready    RP =
   PP                    End of media     All  media            Play
   No  action,  RP  =  Invalid      End of media     >1 Media plays
   Play           No        action                         End        of
   range                          Play      Set  RP  = End by the second address and
          port pair of range
   SETUP                    New         URL                     Play
   455                          SETUP              Setuped   URL
   Play      455                         SETUP             Setuped  URL,
   IFI     Play      Change  transport  param.     TEARDOWN          Prs
   URL,NRM>1       Init     No session hdr              TEARDOWN
   md    URL,NRM=1           Init       No   Session   hdr,   NRM=0
   TEARDOWN                 md         URL                      Play
   455                          S -> C:REDIRECT    Range   hdr
   Play      Set  RedP                     S -> C:REDIRECT the "dest_addr" parameter. If no   range
   hdr           Init        Session second pair is    removed               RedP
   reached                         Play     TEARDOWN of  session
   Timeout                                   Init         Stop     Media
   playout

   Table 9: State: Play

   To avoid inconsistencies between
          given RTCP SHALL NOT be sent.

        o The RTCP/UDP packets from the client and server, automatic      |
   state transitions are avoided. This can be seen at for example "End    |
   of media" event when all media has finished playing, to the session       |
   still remain in Play state. An explicit PAUSE request must server SHALL be
          sent to  |
   change the state to Ready. It may appear that there exist two          |
   automatic transitions in "RedP reached" address and "PP reached", however      |
   they are requested port given by the second address and acknowledge before they take place. The time    |
   at which
          port pair of the transition will happen "dest_addr" parameter. If no second pair is known by looking at
          given RTCP SHALL NOT be sent.

        o RTP and RTCP Packets SHOULD be sent from the range   |
   header. If corresponding
          receiver port, i.e. RTCP packets from server should be sent
          from the client sends request close "src_addr" parameters second address port pair.

B.1.3 AVP/TCP
   Note that this combination is not yet defined using sperate TCP
   connections. However the use of embedded (interleaved) binary data
   transported on the RTSP connection is possible as specified in time to these             |
   transitions it must
   section  12. When using this declared combination of interleaved
   binary data the RTSP messages MUST be prepared transported over TCP.

   A possible future for getting error message as this profile would be to define the       |
   state may or may not have changed.

B Media Transport Alternatives

   This chapter defines how certain combinations use of protocols, profiles
   and lower transports are used. This includes the usage a
   combination of the two drafts "Connection-Oriented Media Transport header's general source and destination parameters
   "src_addresses" in
   SDP" [36] and "dst_addresses".

B.1 "Framing RTP

   This section defines the interaction and needed media transport
   signalling RTCP Packets over Connection-Oriented
   Transport" [37].  However as this work is not finished, this
   functionality is unspecified.

B.1.4 Handling NPT Jumps in regards to the RTP protocol [23]. Media Layer                           |

   RTSP allows media clients to control selected, non-contiguous          |
   sections of media presentations, rendering those streams with an RTP   |
   media layer[23]. layer[15]. Such control allows jumps to be created in NPT        |
   timeline of the RTSP session. For example, jumps in NPT can be caused  |
   by multiple ranges in the range specifier of a PLAY request or         |
   through a "seek" opertaion on an RTSP session which involves a PLAY,   |
   PAUSE, PLAY scenario where a new NPT is set for the session. The       |
   media layer rendering the RTP stream should not be affected by jumps   |
   in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be     |
   continuous and monotonic across jumps of NPT.

   As an example, assume a clock frequency of 8000 Hz, a packetization
   interval of 100 ms and an initial sequence number and timestamp of
   zero. First we play NPT 10 through 15, then skip ahead and play NPT
   18 through 20. The first segment is presented as RTP packets with
   sequence numbers 0 through 49 and timestamp 0 through 39,200. The
   second segment consists of RTP packets with sequence number 50
   through 69, with timestamps 40,000 through 55,200.                          |

        We cannot assume that the RTSP client can communicate with   |
        the RTP media agent, as the two may be independent           |
        processes.  If the RTP timestamp shows the same gap as the   |
        NPT, the media agent will assume that there is a pause in    |
        the presentation. If the jump in NPT is large enough, the    |
        RTP timestamp may roll over and the media agent may believe  |
        later packets to be duplicates of packets just played out.

   For certain datatypes, tight integration between the RTSP layer and
   the RTP layer will be necessary. This by no means precludes the above
   restriction. Combined RTSP/RTP media clients should use the RTP-Info
   field to determine whether incoming RTP packets were sent before or
   after a seek.

   For continuous audio, the server SHOULD set the RTP marker bit at the
   beginning of serving a new PLAY request. This allows the client to
   perform playout delay adaptation.

   For scaling (see Section 13.34), RTP timestamps should correspond to
   the playback timing. For   |

   As an example, when playing video recorded at 30
   frames/second at assume a scale of two and speed (Section 13.35) of one, the
   server would drop every second frame to maintain and deliver video
   packets with the normal timestamp spacing clock frequency of 3,000 per frame, but NPT
   would increase by 1/15 second for each video frame.

   The client can maintain 8000 Hz, a correct display of NPT by noting the RTP
   timestamp value of the first packet arriving after repositioning.
   The sequence parameter packetization    |
   interval of the RTP-Info (Section 13.33) header
   provides the first 100 ms and an initial sequence number and timestamp of the next segment.

   Note that more than one SSRC MAY be sent in the media stream.     |
   However without further extensions RTSP can't synchronize more than
   zero.                                                                  |
   the single one indicated in the Transport header. In these cases RTCP

      C->S: PLAY rtsp://xyz/fizzle RTSP/1.0                               |
   needs to be used for synchronization.
        CSeq: 4                                                           |
        Session: abcdefg                                                  |
        Range: npt=10-15;                                                 |

      S->C: RTSP/1.0 200 OK                                               |
        CSeq: 4                                                           |
        Session: abcdefg                                                  |
        Range: npt=10-15                                                  |
        RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=0;                |
              rtptime=0                                                   |

   The transmission of RTCP SHOULD be done the whole time from ensuing RTP data stream is depicted below:                         |
   session creation by the SETUP request and continue until the session

      S -> C: RTP packet - seq = 0,  rtptime = 0,     NPT time = 10s      |
   is removed by the TEARDOWN request, that is including during the
      S -> C: RTP packet - seq = 1,  rtptime = 800,   NPT time = 10.1s    |
   period in Ready state. This ensures that neither end part times out
       . . .                                                              |
   the other. Thus ensuring liveness information to both end-points,
      S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s    |
   allow for packet-loss detection at

   Immediately after the end of playout period, ensure the play range, the client follows up     |
   media synchronization in cases multiple SSRCs are used, and
   with a request to keep PLAY from a new NPT.                                 |
   synchronization information updated allowing for correct synch also

   C->S: PAUSE rtsp://xyz/fizzle RTSP/1.0                                 |
   at the beginning of a stream before any
         CSeq: 5                                                          |
         Session: abcdefg                                                 |

   S->C: RTSP/1.0 200 OK                                                  |
         CSeq: 5                                                          |
         Session: abcdefg                                                 |
         Range: npt=15-15                                                 |

   C->S: PLAY response has arrived. rtsp://xyz/fizzle RTSP/1.0                                  |

   The sending of the RTCP BYE message is connected to the existence of
         CSeq: 6                                                          |
   the RTCP session and the SSRC. Therefore a client or server SHALL not
         Session: abcdefg                                                 |
   send an RTCP BYE message until it has finished using an SSRC. A
         Range: npt=18-20;                                                |
   server SHOULD not stop using an SSRC until the RTP session is

   S->C: RTSP/1.0 200 OK                                                  |
   terminated. This is due to that a SSRC that has been used has an
         CSeq: 6                                                          |
   established synchronization context that ensures synchronization also
         Session: abcdefg                                                 |
   if the PLAY response is late, for an subsequent PLAY request after
         Range: npt=18-20                                                 |
   the first one. Changing the server side SSRC will also prevent the
         RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=50;              |
   server from synchronizing that new SSRC within RTSP as it
                   rtptime=40000                                          |
                                                                          |

   The ensuing RTP data stream is depicted below:                         |
   connected to the one declared in the SSRC parameter in the Transport

      S->C: RTP packet - seq = 50, rtptime = 40000, NPT time = 18s        |
   header.

   Below the available
      S->C: RTP profiles packet - seq = 51, rtptime = 40800, NPT time = 18.1s      |
       . . .                                                              |
      S->C: RTP packet - seq = 69, rtptime = 55200, NPT time = 19.9s      |

   First we play NPT 10 through 15, then skip ahead and lower layer transports are given
   together play NPT 18       |
   through 20. The first segment is presented as RTP packets with the necessary rules on how to signal that combination.

B.1.1 AVP         |
   sequence numbers 0 through 49 and timestamp 0 through 39,200. The usage      |
   second segment consists of the "RTP Profile for Audio and Video Conferences with
   Minimal Control" [1] when using RTP for media transport over
   different lower layer transport protocols are defined below packets with sequence number 50         |
   through 69, with timestamps 40,000 through 55,200. While there is a    |
   gap in
   regards to RTSP.

   On such case the NPT, there is defined within this document, no gap in the use sequence number or timestamp    |
   space of embedded
   (interleaved) binary the RTP data as defined stream.                                          |

B.1.5 Handling RTP Timestamps after PAUSE                                 |

   During a PAUSE / PLAY interaction in section  11.11.  The usage of
   this method is indicated by include a RTSP session, the "interleaved" parameter.

   When using embedded binary data duration of   |
   time for which the "src_addresses" and
   "dst_addresses" SHALL NOT RTP transmission was halted MUST be used. This addressing and multiplexing
   is used as defined with use of channel numbers and reflected in    |
   the interleaved
   parameter.

B.1.2 AVP/UDP

   This part descibes sending RTP timestamp of each RTP [23] over lower transport layer UDP
   [7] according to the profile "RTP Profile for Audio and Video
   Conferences with Minimal Control" defined in RFC 3551 [1].

   This profiles requires that one or two uni- or bi-directional UDP
   flows per media stream. The first UDP flow is duration can be calculated   |
   for each RTP and stream as the second
   is for RTCP. Embedded (interleaved) data time elapsed from when RTSP messages is
   transported over UDP SHOULD NOT be performed. the last RTP packet  |
   was sent before the PAUSE request was received and when the first RTP  |
   packet was sent after thesubsequent PLAY request was received. The RTP/UDP     |
   duration includes all latency incurred and RTCP/UDP flows can be established in two ways using processing time required    |
   to complete the Transport header's parameters. request.                                               |

        The way provided in RTP RFC 2326 was [15] states that: The RTP timestamp for each     |
        unit[packet] would be related to use the necessary parameters from wallclock time at       |
        which the set of "source",
   "destination", "client_port", and "server_port". This has unit becomes current on the
   advantage virtual presentation   |
        timeline.                                                    |

   In order to satisfy the requirements of being compatible with all [15], the RTP capable RTSP servers and
   clients. However timestamp space  |
   must increase continously with real time.  While this method does is not provide a possibility to
   specify non-continues port ranges optimal   |
   for stored media, it is required for RTP and RTCP.  The other way is RTCP to use function as       |
   intended. Using a continous RTP timestamp space allows the parameters "src_addresses", same        |
   timestamp model for both stored and "dst_addresses". This
   method provides total flexibility in specifying address live media and port allows better       |
   opportunity to integrate both types of media under a single control.   |

   As an example, assume a clock frequency of 8000 Hz, a packetization    |
   interval of 100 ms and an initial sequence number for each transport flow.  However the disadvantage is that it and timestamp of     |
   zero.                                                                  |

   C->S: PLAY rtsp://xyz/fizzle RTSP/1.0                                  |
         CSeq: 4                                                          |
         Session: abcdefg                                                 |
         Range: npt=10-15;                                                |

   S->C: RTSP/1.0 200 OK                                                  |
         CSeq: 4                                                          |
         Session: abcdefg                                                 |
         Range: npt=10-15                                                 |
         RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=0;               |
              rtptime=0                                                   |

   The ensuing RTP data stream is not supported by non-updated clients, i.e. clients not supporting
   the "play.basic" feature-tag.

   When using the "source", "destination", "client_port", depicted below:                         |

      S -> C: RTP packet - seq = 0, rtptime = 0,    NPT time = 10s        |
      S -> C: RTP packet - seq = 1, rtptime = 800,  NPT time = 10.1s      |
      S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s      |
      S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s      |

   The client then sends a PAUSE request:                                 |

   C->S: PAUSE rtsp://xyz/fizzle RTSP/1.0                                 |
         CSeq: 5                                                          |
         Session: abdcdefg                                                |

   S->C: RTSP/1.0 200 OK                                                  |
         CSeq: 5                                                          |
         Session: abcdefg                                                 |
         Range: npt=10.4-15                                               |

   20 seconds elapse and
   "server_port" the packets are be addressed in then the following way for
   media playback:

        o RTP/UDP packet from client sends a PLAY request. In         |
   addtion the server requires 15 ms to process the client SHALL be sent to
          the address specified in the "destination" parameter and first
          even port number given in client_port range. If there request:              |

   C->S: PLAY rtsp://xyz/fizzle RTSP/1.0                                  |
         CSeq: 6                                                          |
         Session: abcdefg                                                 |

   S->C: RTSP/1.0 200 OK                                                  |
         CSeq: 6                                                          |
         Session: abcdefg                                                 |
         Range: npt=10.4-15                                               |
         RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=4;               |
                 rtptime=164400                                           |
   The ensuing RTP data stream is depicted below:                         |

      S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s    |
      S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s    |
      S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s    |

   First, we play NPT 10 through 10.3, when a PAUSE is only received by the    |
   server. After 20 seconds a single port number given that MUST be given.

        o The server SHOULD send its RTP/UDP packets from PLAY is recieved by the address
          specified in "source" parameter and from server which take   |
   15ms to process. The duration of time for which the first even port
          number specified in "server_port" parameter.

        o If there session was        |
   paused is specified a range reflected in "client_port" parameter that
          contains at least two port numbers, the RTCP/UDP RTP timestamp of the RTP packets from
          server to client SHALL be sent       |
   after this PLAY request.                                               |

   A client can use the RTSP range header and RTP-Info header to address specified in map NPT  |
   time of a presentation with the
          "destination" parameter RTP timestamp.                         |

   Note: In RFC 2326 [1], this matter was not clearly defined and first odd port number part was     |
   misunderstood commonly. Therefore, clients SHOULD expect servers to    |
   break the continuity of the
          range specified RTP timestamp space in various arbitrary   |
   manners after a PAUSE request. In these cases, it is RECOMMENDED that  |
   clients accept the client_port parameter.

        o The Server SHOULD send its RTCP/UDP packets from RTP stream after the address
          specified in "source" parameter and from pause with appropriate         |
   mappings provided by the first odd port
          number specified in "server_port" parameter.

        o RTCP/UDP packets from RTP-Info and Range headers.                   |

B.1.6 RTSP / RTP Integration                                              |

   For certain datatypes, tight integration between the client to RTSP layer and    |
   the server SHALL RTP layer will be sent
          to necessary. This by no means precludes the address specified in above  |
   restrictions. Combined RTSP/RTP media clients should use the "source" parameter and first
          odd port number given in client_port range.

        o The client SHOULD send its RTCP/UDP RTP-Info  |
   field to determine whether incoming RTP packets from the address
          specified in "destination" parameter and from were sent before or    |
   after a seek or before or after a PAUSE.                               |

B.1.7 Scaling with RTP                                                    |

   For scaling (see Section 14.34), RTP timestamps should correspond to   |
   the first odd
          port number specified in "server_port" parameter.

   The usage playback timing. For example, when playing video recorded at 30    |
   frames/second at a scale of "src_addresses" two and "dst_addresses" parameters to
   specify speed (Section 14.35) of one, the address  |
   server would drop every second frame to maintain and port numbers are done in deliver video     |
   packets with the following way normal timestamp spacing of 3,000 per frame, but NPT  |
   would increase by 1/15 second for media playback, i.e. Mode=PLAY:

        o each video frame.                    |

B.1.8 Maintaining NPT synchronization with RTP timesatmps                 |

   The "src_addresses" and "dst_addresses" parameters MUST
          contain either 1 or 2 address and port pairs.

        o Each address and port pair MUST contain both and address and client can maintain a
          port number.

        o The first address and port pair given in either correct display of the
          parameters applies to NPT by noting the RTP stream. The second address and
          port pair if present applies to     |
   timestamp value of the RTCP stream.

        o first packet arriving after repositioning.      |
   The RTP/UDP packets from the server to sequence parameter of the client SHALL be
          sent to RTP-Info (Section 14.33) header          |
   provides the address and port given by first address and port
          pair sequence number of the "dst_addresses" parameter.

        o The RTCP/UDP packets from next segment.                |

B.1.9 Continuous Audio                                                    |

   For continuous audio, the server to SHOULD set the RTP marker bit at the  |
   beginning of serving a new PLAY request. This allows the client SHALL to     |
   perform playout delay adaptation.                                      |

B.1.10 Multiple Sources in an RTP Session                                 |

   Note that more than one SSRC MAY be sent to in the address and port given by media stream.          |
   However, without further extensions RTSP can't synchronize more than   |
   the second address and
          port pair of single one indicated in the "dst_addresses" parameter. If no second pair
          is given Transport header. In these cases RTCP SHALL NOT be sent.

        o The RTCP/UDP packets from the client  |
   needs to the server SHALL be
          sent to the address used for synchronization.                                  |

B.1.11 Usage of SSRCs and port given by the second address and
          port pair RTCP BYE Message During a RTSP Session      |

   The RTCP BYE message indicates the end of a RTP session as well as     |
   the "dst_addresses" parameter. If no second pair
          is end of use of a given RTCP SSRC. Therefore, a client or server SHALL    |
   NOT be sent.

        o RTP and RTCP Packets SHOULD be sent from the corresponding
          receiver port, i.e. send a RTCP packets from BYE message until it has finished using a SSRC. A      |
   server should be sent
          from SHOULD keep using a SSRC until the "src_addresses" parameters second address port pair.

B.1.3 AVP/TCP

   Note that this combination RTP session is not yet defined using sperate TCP
   connections. However terminated.   |
   Prologing the use of embedded (interleaved) binary data
   transported on a SSRC allows the RTSP connection established synchronization     |
   context associated with that SSRC to be used to sychronize subsequent  |
   PLAY requests even if the PLAY response is possible as specified in
   section  11.11. When using this declared combination of interleaved
   binary data late. Additionally,         |
   changing the server side SSRC will prevent the server from             |
   synchronizing the new SSRC within RTSP messages MUST be transported over TCP.

   A possible future for this profile would be as it is connected to define the use of a
   combination of one   |
   declared in the two drafts "Connection-Oriented Media Transport ssrc parameter in
   SDP" [36] and "Framing RTP and RTCP Packets over Connection-Oriented
   Transport" [37]. the Transport header.                |

B.2 Future Additions

   It is the intention that any future protocol or profile regarding
   both for media delivery and lower transport should be easy to add to
   RTSP. This chapter provides the necessary steps that needs to be
   meet.

   The following things needs to be considered when adding a new
   protocol of profile for use with RTSP:

        o The protocol or profile needs to define a name tag
          representing it. This tag is required to be a ABNF "token" to
          be possible to use in the Transport header specification.

        o The useful combinations of protocol/profile/lower-layer needs
          to be defined and for each combination declare the necessary
          parameters to use in the Transport header.

        o For new media protocols the interaction with RTSP needs to be
          addressed. One important factor will be the media
          synchronization.

   See the IANA section ( 18) 19) on how to register the necessary
   attributes.

C Use of SDP for RTSP Session Descriptions

   The Session Description Protocol (SDP, RFC 2327 [24]) [2]) may be used to   |
   describe streams or presentations in RTSP. This description is         |
   typically returned in reply to a DESCRIBE request on a URL from a      |
   server to a client, or received via HTTP from a server to a client.    |

   This appendix describes how an SDP file determines the operation of    |
   an RTSP session. SDP as is provides no mechanism by which a client     |
   can distinguish, without human guidance, between several media         |
   streams to be rendered simultaneously and a set of alternatives        |
   (e.g., two audio streams spoken in different languages). However the   |
   SDP extension "Grouping of Media Lines in the Session Description      |
   Protocol (SDP)" [40] [38] may provide such functionality depending on       |
   need. Also future grouping semantics may in the future be developed.

C.1 Definitions

   The terms "session-level", "media-level" and other key/attribute
   names and values used in this appendix are to be used as defined in
   SDP (RFC 2327 [24]): [2]):

C.1.1 Control URL

   The "a=control:" attribute is used to convey the control URL. This     |
   attribute is used both for the session and media descriptions. If      |
   used for individual media, it indicates the URL to be used for         |
   controlling that particular media stream.  If found at the session     |
   level, the attribute indicates the URL for aggregate control           |
   (presentation URL). The session level URL SHALL be different from any  |
   media level URI. URL. The presence of a session level control attribute     |
   SHALL be interpreted as support for aggregated control. The control    |
   attribute SHALL be present on media level unless the presentation      |
   only contains a single media stream, in which case the attribute MAY   |
   only be present on the session level.

   control-attribute  =  "a=" "control" ":" url

   Example:

     a=control:rtsp://example.com/foo
   This attribute MAY contain either relative and absolute URLs,
   following the rules and conventions set out in RFC 2396 [22]. [12].
   Implementations SHALL look for a base URL in the following order:

        1.   the RTSP Content-Base field;

        2.   the RTSP Content-Location field;

        3.   the RTSP request URL.

   If this attribute contains only an asterisk (*), then the URL SHALL    |
   be treated as if it were an empty embedded URL, and thus inherit the   |
   entire base URL.                                                       |

   For SDP retrieved from a container file, there are certain things to   |
   consider. Lets say that the container file has the following URL:      |
   "rtsp://example.com/container.mp4". A media level relative URL needs   |
   to contain the file name container.mp4 in the beginning to be          |
   resolved correctly relative to the before given URL. An alternative    |
   if one does not desire to enter the container files name is to ensure  |
   that the base URL for the SDP document becomes:                        |
   "rtsp://example.com/container.mp4/", i.e. an extra trailing slash.     |
   When using the URL resolution rules in RFC 2396 that will resolve      |
   correctly. However, please note that if the session level control URL  |
   is a *, that control URL will be equal to                              |
   "rtsp://example.com/container.mp4/" and include the slash.             |

C.1.2 Media Streams                                                       |

   The "m=" field is used to enumerate the streams. It is expected that   |
   all the specified streams will be rendered with appropriate            |
   synchronization. If the session is a multicast, the port number        |
   indicated SHOULD be used for reception. The client MAY try to          |
   override the destination port, through the Transport header.  The      |
   servers MAY allow this, the response will indicate if allowed or not.  |
   If the session is unicast, the port number is the ones RECOMMENDED by  |
   the server to the client, about which receiver ports to use; the       |
   client MUST still include its receiver ports in its SETUP request.     |
   The client MAY ignore this recommendation. If the server has no        |
   preference, it SHOULD set the port number value to zero.               |

   The "m=" lines contain information about what transport protocol,      |
   profile, and possibly lower-layer shall be used for the media stream.  |
   The combination of transport, profile and lower layer, like            |
   RTP/AVP/UDP needs to be defined for how to be used with RTSP.  The     |
   currently defined combinations are defined in section B, further       |
   combinations MAY be specified.                                         |

   TODO: Write something about the usage of Grouping of media line, RFC   |
   3388 [40].                                                             | [38].

   Example:

     m=audio 0 RTP/AVP 31

C.1.3 Payload Type(s)

   The payload type(s) are specified in the "m=" field. In case the       |
   payload type is a static payload type from RFC 3551 [1], [3], no other      |
   information is required. In case it is a dynamic payload type, the     |
   media attribute "rtpmap" is used to specify what the media is. The     |
   "encoding name" within the "rtpmap" attribute may be one of those      |
   specified in RFC 3551 (Sections 5 and 6), or an MIME type registered   |
   with IANA, or an experimental encoding with a "X-" prefix as           | specified in SDP (RFC 2327 [24]).   |
   [2]). Codec-specific parameters are not    | specified in this field, but   |
   rather in the "fmtp" attribute described  | below.                                                                 |

C.1.4 Format-Specific Parameters                                          |

   Format-specific parameters are conveyed using the "fmtp" media         |
   attribute. The syntax of the "fmtp" attribute is specific to the       |
   encoding(s) that the attribute refers to. Note that some of the        |
   format specific parameters may be specified outside of the fmtp        |
   parameters, like for example the "ptime" attribute for most audio      |
   encodings.                                                             |

C.1.5 Range of Presentation                                               |

   The "a=range" attribute defines the total time range of the stored     |
   session or an individual media. Non-seekable Live live sessions can be      |
   indicated, while the length of live sessions can be deduced from the   |
   "t" and "r" SDP parameters.                                            |

   The attribute is both a session and a media level attribute. For       |
   presentations that contains media streams of the same durations, the   |
   range attribute SHOULD only be used at session-level. In case of       |
   different length the range attribute MUST be given at media level for  |
   all media, and SHOULD NOT be given at session level. If the attribute  |
   is present at both media level and session level the media level       |
   values SHALL be used.

   The unit is specified first, followed by the value range. The units    |
   and their values are as defined in Section 3.4, 3.5 and 3.6. 3.6 and MAY    |
   be extended with further formats. Any open ended range (start-), i.e.  |
   without stop range, is of unspecified duration and SHALL be            |
   considered as non-seekable content unless this property is             |
   overridden.

   This attribute is defined in ABNF [14] [5] as:

   a-range-def = "a" "=" "range" ":" ranges-specifier CRLF

   Examples:

     a=range:npt=0-34.4368
     a=range:clock=19971113T2115-19971113T2203
     Non seekable stream of unknown duration:
     a=range:npt=0-

C.1.6 Time of Availability

   The "t=" field MUST contain suitable values for the start and stop     |
   times for both aggregate and non-aggregate stream control.  The        |
   server SHOULD indicate a stop time value for which it guarantees the   |
   description to be valid, and a start time that is equal to or before   |
   the time at which the DESCRIBE request was received. It MAY also       |
   indicate start and stop times of 0, meaning that the session is        |
   always available. session is
   always available.

   For sessions that are of live type, i.e. specific start time, unknown  |
   stop time, likely unseekable, the "t=" and "r=" field SHOULD be used   |
   to indicate the start time of the event. The stop time SHOULD be       |
   given so that the live event will with high probability have ended at  |
   that time, while still not be unnecessary long into the future.

C.1.7 Connection Information

   In SDP, the "c=" field contains the destination address for the media  |
   stream. For a media destination address that is a IPv6 one, the SDP    |
   extension defined in [38] [18] needs to be used. For on-demand unicast      |
   streams and some multicast streams, the destination address MAY be     |
   specified by the client via the SETUP request, thus overriding any     |
   specified address. To identify streams without a fixed destination     |
   address, where the client must specify a destination address, the      |
   "c=" field SHOULD be set to a null value. For addresses of type        |
   "IP4", this value SHALL be "0.0.0.0", and for type "IP6", this value   |
   SHALL be "0:0:0:0:0:0:0:0", i.e. the unspecified address according to  |
   RFC 3513 [39]. [19].

C.1.8 Entity Tag

   The optional "a=etag" attribute identifies a version of the session
   description. It is opaque to the client. SETUP requests may include
   this identifier in the If-Match field (see section 13.22) 14.22) to only
   allow session establishment if this attribute value still corresponds
   to that of the current description.  The attribute value is opaque
   and may contain any character allowed within SDP attribute values.

   a-etag-def   =  "a" "=" "etag" ":" etag-string CRLF
   etag-string  =  1*(%x01-09/%x0B-0C/%x0E-FF)

   Example:

     a=etag:158bb3e7c7fd62ce67f12b533f06b83a

        One could argue that the "o=" field provides identical
        functionality. However, it does so in a manner that would
        put constraints on servers that need to support multiple
        session description types other than SDP for the same piece
        of media content.

C.2 Aggregate Control Not Available

   If a presentation does not support aggregate control no session level  |
   "a=control:" attribute is specified. For a SDP with multiple media     |
   sections specified, each section will have its own control URL         |
   specified via the "a=control:" attribute.

   Example:

   v=0
   o=- 2890844256 2890842807 IN IP4 204.34.34.32
   s=I came from a web page
   e=adm@example.com
   c=IN IP4 0.0.0.0
   t=0 0
   m=video 8002 RTP/AVP 31
   a=control:rtsp://audio.com/movie.aud
   m=audio 8004 RTP/AVP 3
   a=control:rtsp://video.com/movie.vid
   Note that the position of the control URL in the description implies
   that the client establishes separate RTSP control sessions to the
   servers audio.com and video.com

   It is recommended that an SDP file contains the complete media
   initialization information even if it is delivered to the media
   client through non-RTSP means. This is necessary as there is no
   mechanism to indicate that the client should request more detailed
   media stream information via DESCRIBE.

C.3 Aggregate Control Available

   In this scenario, the server has multiple streams that can be
   controlled as a whole. In this case, there are both a media-level
   "a=control:" attributes, which are used to specify the stream URLs,
   and a session-level "a=control:" attribute which is used as the
   request URL for aggregate control. If the media-level URL is
   relative, it is resolved to absolute URLs according to Section C.1.1
   above.

   Example:                                                               |

   C->M: DESCRIBE rtsp://example.com/movie RTSP/1.0                       |
         CSeq: 1                                                          |

   M->C: RTSP/1.0 200 OK                                                  |
         CSeq: 1                                                          |
         Date: 23 Jan 1997 15:35:06 GMT                                   |
         Content-Type: application/sdp                                    |
         Content-Base: rtsp://example.com/movie/                          |
         Content-Length: 164                                              |

         v=0                                                              |
         o=- 2890844256 2890842807 IN IP4 204.34.34.32                    |
         s=I contain                                                      |
         i=<more info>                                                    |
         e=adm@example.com                                                |
         c=IN IP4 0.0.0.0                                                 |
         t=0 0                                                            |
         a=control:*                                                      |
         m=video 8002 RTP/AVP 31                                          |
         a=control:trackID=1                                              |
         m=audio 8004 RTP/AVP 3                                           |
         a=control:trackID=2                                              |
   In this example, the client is required to establish a single RTSP     |
   session to the server, and uses the URLs                               |
   rtsp://example.com/movie/trackID=1 and                                 |
   rtsp://example.com/movie/trackID=2 to set up the video and audio       |
   streams, respectively. The URL rtsp://example.com/movie/ , which is    |
   resolved from the "*", controls the whole presentation (movie).        |

   A client is not required to issues SETUP requests for all streams      |
   within an aggregate object. Servers should allow the client to ask     |
   for only a subset of the streams.                                      |

C.4 RTSP external SDP delivery                                            |

   There are some considerations that needs to be made when the session   |
   description is delivered to client outside of RTSP, for example in     |
   HTTP or email.                                                         |

   First of all the SDP needs to contain absolute URIs, URLs, relative will in  |
   most cases not work as the delivery will not correctly forward the     |
   base URI. URL. And as SDP might be temporarily stored on file system        |
   before being loaded into a RTSP capable client, thus if possible to    |
   transport the base URI URL it still would need to be merged into the       |
   file.                                                                  |

   The writing of the SDP session availability information, i.e. "t="     |
   and "r=", needs to be carefully considered. When the SDP is fetched    |
   by the DESCRIBE method it is with very high probability that the it    |
   is valid. However the same are much less certain for SDPs distributed  |
   using other methods. Therefore the publisher of the SDP should take    |
   care to follow the recommendations about availability in the SDP       |
   specification [24]. [2].

D Minimal RTSP implementation

D.1 Client

   A client implementation MUST be able to do the following :

        o Generate the following requests: SETUP, TEARDOWN, PLAY.

        o Include the following headers in requests: CSeq, Connection,
          Session, Transport.

        o Parse and understand the following headers in responses:
          CSeq, Connection, Session, Transport, Content-Language,
          Content-Encoding, Content-Length, Content-Type.

        o Understand the class of each error code received and notify
          the end-user, if one is present, of error codes in classes 4xx
          and 5xx. The notification requirement may be relaxed if the
          end-user explicitly does not want it for one or all status
          codes.

        o Expect and respond to asynchronous requests from the server,
          such as REDIRECT. This does not necessarily mean that it
          should implement the REDIRECT method, merely that it MUST
          respond positively or negatively to any request received from
          the server.

   Though not required, the following are RECOMMENDED.

        o Implement RTP/AVP/UDP as a valid transport.

        o Inclusion of the User-Agent header.

        o Understand SDP session descriptions as defined in Appendix C

        o Accept media initialization formats (such as SDP) from
          standard input, command line, or other means appropriate to
          the operating environment to act as a "helper application" for
          other applications (such as web browsers).

        There may be RTSP applications different from those
        initially envisioned by the contributors to the RTSP
        specification for which the requirements above do not make
        sense. Therefore, the recommendations above serve only as
        guidelines instead of strict requirements.

D.1.1 Basic Playback

   To support on-demand playback of media streams, the client MUST
   additionally be able to do the following:

        o generate the PAUSE request;

        o implement the REDIRECT method, and the Location header.

D.1.2 Authentication-enabled

   In order to access media presentations from RTSP servers that require
   authentication, the client MUST additionally be able to do the
   following:

        o recognize the 401 (Unauthorized) status code;
        o parse and include the WWW-Authenticate header;

        o implement Basic Authentication and Digest Authentication.

D.2 Server

   A minimal server implementation MUST be able to do the following:

        o Implement the following methods: SETUP, TEARDOWN, OPTIONS and
          PLAY.

        o Include the following headers in responses:  Connection,
          Content-Length, Content-Type, Content-Language, Content-
          Encoding, Timestamp, Transport, Public, and Via, and
          Unsupported.  RTP-compliant implementations MUST also
          implement the RTP-Info field.

        o Parse and respond appropriately to the following headers in
          requests: Connection, Proxy-Require, Session, Transport, and
          Require.

   Though not required, the following are highly recommended at the time
   of publication for practical interoperability with initial
   implementations and/or to be a "good citizen".

        o Implement RTP/AVP/UDP as a valid transport.                     |

        o Inclusion of the Server header. Server, Cache-Control Date, and Expires        |
          headers.                                                        |

        o Implement the DESCRIBE method.                                  |

        o Generate SDP session descriptions as defined in Appendix C      |

        There may be RTSP applications different from those
        initially envisioned by the contributors to the RTSP
        specification for which the requirements above do not make
        sense. Therefore, the recommendations above serve only as
        guidelines instead of strict requirements.

D.2.1 Basic Playback

   To support on-demand playback of media streams, the server MUST
   additionally be able to do the following:

        o Recognize the Range header, and return an error if seeking is
          not supported.

        o Implement the PAUSE method.

   In addition, in order to support commonly-accepted user interface
   features, the following are highly recommended for on-demand media
   servers:

        o Include and parse the Range header, with NPT units.
          Implementation of SMPTE units is recommended.

        o Include the length of the media presentation in the media
          initialization information.

        o Include mappings from data-specific timestamps to NPT. When
          RTP is used, the rtptime portion of the RTP-Info field may be
          used to map RTP timestamps to NPT.

        Client implementations may use the presence of length
        information to determine if the clip is seekable, and
        visably disable seeking features for clips for which the
        length information is unavailable. A common use of the
        presentation length is to implement a "slider bar" which
        serves as both a progress indicator and a timeline
        positioning tool.

   Mappings from RTP timestamps to NPT are necessary to ensure correct
   positioning of the slider bar.

D.2.2 Authentication-enabled

   In order to correctly handle client authentication, the server MUST
   additionally be able to do the following:

        o Generate the 401 (Unauthorized) status code when
          authentication is required for the resource.

        o Parse and include the WWW-Authenticate header

        o Implement Basic Authentication and Digest Authentication

E Open Issues

        1.   Should we add the header Accept-Ranges as proposed in this
             specification?

        2.   Upon receiving a response on a REDIRECT request can the
             server close the session or should it wait for a TEARDOWN
             request from the client?

        3.   The proxy indications in the two header tables in chapter
             13    |
             14 needs review.

        4.                                             |
        2.   Should the Allow header be possible to use optional in       |
             request or responses besides the now specified 405 error     |
             code?

        5.                                                        |

        3.   What text should be written on use of authorization in this  |
             spec?

        6.                                                        |

        4.   How does entity tags relate to the If-Match header? The      |
             usage in SDP must also be clarified related to syntax, etc.

        7.   Should the Last-Modified header be required on other level
             than optional?

        8.   How to handle range headers for negative scale playback.

        9.  |

        5.   The minimal implementation must be looked over to see if it  |
             complies with the specification. All must and should shall
             be included in specification. All must and should shall   |
             be included in the minimal. Feature-tags for these needs to  |
             be defined. Further feature-tags needs to be discussed.      |

        6.   The list specifying which status codes are allowed on which  |
             request methods seem to be in error and need review.         |

        7.   The capability negotiation statement in section 1.5 does     |
             not declare something that RTSP really supports fully.       |

        8.   Should we define a 463 status code that informs the client   |
             that the tried media stream destination was not allowed?     |

        9.   There is need for clearer rule in regards to Transport       |
             parameters changes in mid session.                           |

        10.  Can fragment be included in a request URL? Or should it as   |
             for HTTP only be handled on the User-Agent side?             |

        11.  Write the use case descriptions.                             |

F Changes

   Compared to RFC 2326, the following issues has been addressed:         |

        o The Transport header has been changed in the following way:     |

          - The ABNF has been changed to define that extensions are       |
            possible, and that unknown extension parameters shall be      |
            ignored.                                                      |

          - To prevent backwards compatibility issues, any extension or   |
            new parameter requires the usage of a feature tag combined    |
            with the Require header.                                      |

          - Syntax unclarities with the Mode parameter has been           |
            resolved.                                                     |
          - Syntax error with ";" for multicast and unicast has been      |
            resolved.                                                     |

          - Two new addressing parameters has been defined, src_addr and  |
            dest_addr. These allow one to specify more than one complete  |
            address and port tuple if needed.                             |

          - Support for IPv6 explicit addresses in all address fields     |
            has been included.                                            |

          - To handle URI definitions that contain ";" or "," a quoted    |
            URL format has been introduced.                               |

          - Defined IANA registries for the transport headers             |
            parameters, transport-protocol, profile, lower-transport,     |
            and mode.                                                     |

          - The transport headers interleave parameter's text was made    |
            more strict and use formal requirements levels. However no    |
            change on how it is used was made.                            |

          - It has been clarified that the client can't request of the minimal. Feature-tags for these needs to
             be defined. Further feature-tags needs    |
            server to be discussed.

        10.  The list specifying which status codes are allowed on which use a certain RTP SSRC, using a request methods seem to be in error and need review.

F Changes
   Compared to RFC 2326, with the following issues are addressed:

        o http://rtsp.org/bug448521 - "URLs in Rtp-Info need to be
          quoted". URLs in RTP-info header now MAY be quoted if needed.

        o http://rtsp.org/bug448525    |
            transport parameter SSRC.                                     |

          - Syntax defintion for SSRC should be
          clarified. Require 8*8 HEX and corresponding text added.

        o http://rtsp.org/bug461083 - "Body w/o Content-Length
          clarification". This is has been clarified and any message with a
          message body is required to have a Content-Length header.

        o http://rtsp.org/bug477407 require 8*8   |
            HEX.                                                          |

          - Transport BNF doesn't properly
          deal with semicolon Updated the text on the transport headers "destination" and comma

        o http://rtsp.org/bug477413   |
            "dest_addr" parameters regarding what security precautions    |
            the server shall perform.                                     |

          - Transport BNF: mode The embedded (interleaved) binary data and its transport      |
            parameter
          issues

        o http://rtsp.org/bug477416 - "BNF error section 3.6 NPT", Added
          an optional [NPT] definition. Fixed so was clarified to being symmetric and that it is     |
            the same
          possibilities exist for all time formats. server that sets the channel numbers.                     |

        o http://rtsp.org/bug477421 - "When to send response". A
          clarifying note The Range formats has been changed in the status code chapter following way:        |

          - The NPT format has been given a initial NPT identifier that when sending
          400 responses, the server MUST NOT add cseq   |
            should be used, if missing.

        o http://rtsp.org/bug507347 missing NPT is assumed.                    |

          - Removal All formats now support initial open ended formats of destination redirection type    |
            "npt=-10".                                                    |

        o RTSP message handling has been changed in the transport header.

        o http://rtsp.org/bug477404 following way:    |

          - "Errors in table in chapter 12".
          The table It has been updated using the SIP structure. However
          the table become to big clarified that a 4xx message due to fit in missing CSeq  |
            header shall be returned without a single page and CSeq header.               |
          - Rules for how to handle timing out RTSP messages has been
          split.     |
            added.                                                        |

        o http://rtsp.org/bug477419 - Updating The HTTP references has been updated to
          rfc2616 by adding RFC 2616 and RFC 2617.  |
          This has required that public, and content-base header. Section
          references in header chapter updated. are now  |
          defined in the RTSP specification. Known effects on RTSP due    |
          to HTTP clarifications:                                         |

          - Content-Encoding header can include encoding of type          |
            "identity".                                                   |

        o http://rtsp.org/bug500803 - Rewritten the complete The state machine chapter on has completely been rewritten. It     |
          includes now more details and are also more clear about the state machine.     |
          model used.                                                     |

        o http://rtsp.org/bug513753 - Created a A IANA section defining
          several registries. has been included with contains a number of      |
          registries and their rules. This will allow us to use IANA to   |
          keep track of all RTSP extensions.                              |

        o http://rtsp.org/bug477427 Than transport of RTSP messages has seen the following          |
          changes:                                                        |

          - A new subsection in The use of UDP has been deprecated due to missing interest    |
            and to broken specification.                                  |

          - The rules for how TCP connections shall be handled has been   |
            clarified. Now it is made clear that servers should not       |
            close the TCP connection unless they have been unused for     |
            significant time.                                             |

          - Strong recommendations why server and clients should use      |
            persistent connections chapter clarifying how has also been added.                   |

          - There is now a requirement to handle non-persistent           |
            connections as this provides great fault tolerance.           |

          - Added wording on the server and client may
          handle transport connections. usage of Connection:Close for RTSP.      |

        o The following header related changes has been made:             |

          - Accept-Ranges response header is added. This header           |
            clarifies which range formats that can be used for a          |
            resource.

        o - Added Headers Timestamp, Via, Unsupported as required for a
          minimal server implementation.

        o http://rtsp.org/bug477425                                                     |

          - "Inconsistency between
          timeformats". Fixed so Clarified that all formats has the same
          capabilities as NPT.

        o http://rtsp.org/bug499573 - "Incorrect grammar on Server
          header". Added corrected BNF for User-Agent and Server header
          as a complement to the reference.

        o The definition in the introduction of the RTSP session has
          been changed.

        o Updated RTSP URL's and source and destination parameters in
          the transport Range header to handle IPv6 addresses.

        o All BNF definitions are updated according to the rules defined
          in RFC 2234 [14].

        o The use of status code 303 "See Other" has been decapitated as
          it does not make sense to use in RTSP.

        o Added status code 350, 351 and updated usage of the other
          redirect status codes, see chapter  12.3.

        o Removed Queued play (http://rtsp.org/bug508211) and
          decapitated use of PLAY for keep-alive while in playing state.

        o Explicitly wrote out the possibilities to use allows multiple ranges to allow   |
            for editing.

        o Text specifying the special behavior of PLAY for live content.

        o When sending response 451 and 458 the response body should
          contain the offending parameters.

        o creating editing list.                                    |

          - Fixed the missing definitions for the Cache-Control header.   |
            Also added to the syntax definition the missing delta-seconds delta-        |
            seconds for max-stale and min-fresh parameters.

        o Added wording on the usage of Connection:Close for RTSP.

        o               |

          - Put requirement on CSeq header that the value is increased    |
            by one for each new RTSP request.

        o A Recommendation to start   |
            at 1 has also been added.                                     |

          - Added requirement that the Date header must be used for all   |
            messages with entity. Also the Server should always include   |
            it.

        o                                                           |

          - Removed possibility to use Range header combined with Scale   |
            header to indicate when it shall be activated, due to that    |
            it can't work as defined. Also added rule that lack of scale  |
            header in response indicate lack of support. Feature-tags     |
            for scaled playback defined.

        o                                  |

          - The Speed header must now be responded to indicate support    |
            and the actual speed going to be used. A feature-tag is       |
            defined.  Notes on congestion control was also added.

        o         |

          - The Supported header was borrowed from SIP to help with the   |
            feature negotiation in RTSP.

        o                                  |

          - Clarified that the timestamp Timestamp header can be used to resolve    |
            retransmission ambiguities.

        o Added two transport header parameters to be used to signal
          RTCP port for server and client when not assigned in pairs.
          Shall be used for NAT traversal with mechanisms like STUN. The
          interoperability issue is solved by requiring a client to know
          that a server supports this specification.

        o Defined a IANA registries for the transport headers
          parameters, transport-protocol, profile, lower-transport, and
          mode.

        o The OPTIONS method has been clarified on how to use the Public
          and Allow headers.

        o                                   |

          - The Session header text has been expanded with a explanation  |
            on keep alive and which methods to use.

        o http://rtsp.org/bug503949                       |

          - Range header format for PAUSE is
          unclear. This It has been resolved by requiring a ranged pause to
          only contain a single value as a beginning of an open range.

        o The transport headers interleave parameter's text was made
          more strict and use formal requirements levels. However no
          change on clarified how it is used was made.

        o Added a fragment part to the RTSP URL. This seem to be
          indicated by the note below the definition however it was not
          part of the BNF.

        o The RECORD and ANNOUNCE methods are removed as they are
          lacking implementation and not considered necessary in the
          core specification. Any work on these methods should Range header formats shall be done
          as a extension document to RTSP.

        o The description on how rtspu and rtsps is not part of the core
          specification and will require external description.

        o The Transport headers RTP port parameters has been updated to
          support non-continuous port numbers. Also a possibility for
          the client   |
            used to specify SSRC has been added.

        o indicate pause points.                                |

          - Clarified that RTP-Info URLs that are relative relative, uses the      |
            request URL as base URL. Also clarified that the URL that     |
            must be used is the SETUP.

        o Included two new general address parameters "src_addresses"
          and "dst_addresses" to be used to give address source and
          destination of media traffic.

        o Updated the text on the transport headers "destination"
          parameter regarding what security precautions the server shall
          perform.

        o Wrote a new chapter about how to setup different media
          transport alternatives and their profiles, and lower layer
          protocols. This resulted that the appendix on RTP interaction
          was moved there instead in the part describing RTP. The
          chapter also includes guidelines what to think of when writing
          usage guidelines for new protocols and profiles.

        o The embedded (interleaved) binary data and its transport
          parameter was clarified to being symmetric and that it is the
          server that sets the channel numbers.

        o Added a new chapter describing the available mechanisms to
          determine if functionality is supported, called "Capability
          Handling". Renamed option-tags to feature-tags.

        o Added a contributors chapter with people who has contribute
          actual text to the specification.

        o                                    |

          - Added text that requires the Range to always be present in    |
            PLAY responses. Clarified what should be sent in case of      |
            live streams.

        o Clarified                                                 |

          - The quoted URL format may also be used with the usage of "a=range" RTP-Info      |
            header. Backwards compatibility issues exist with such        |
            usage, thus it can only be used for implementations           |
            following this specification.                                 |

          - The Headers table has been updated using a structured         |
            borrowed from SIP. This table carries much more information   |
            and how to indicate live
          content should provide a good overview of the available headers.  |

          - It has been is clarified that are not seekable any message with this a message      |
            body is required to have a Content-Length header.

        o Depreciated This was    |
            the use of case in RFC 2326 but could be misinterpreted.             |

        o The minimal implementation specification has been changed:      |

          - Added Headers Timestamp, Via, Unsupported as required for a   |
            minimal server implementation.                                |

          - Added headers Cache-Control, Expires and Date as recommended  |
            headers to support by server implementations.                 |

        o The Protocol Syntax has been changed in the Range header "time=" parameter due following way:      |

          - All BNF definitions are updated according to synchronization problems the rules        |
            defined in PLAY RFC 2234 [5] and PAUSE methods.

   Note that this list does not reflect minor changes has been gathered in wording or
   correction of typographical errors.

   A word-by-word diff from RFC 2326 can be found at
   http://rtsp.org/2002/drafts

G Author Addresses

   Henning Schulzrinne
   Dept. a separate   |
            chapter  17.                                                  |

          - The BNF for the User-Agent and Server headers has been        |
            corrected so now only the description is in the HTTP          |
            specification.                                                |

          - The definition in the introduction of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027
   USA
   electronic mail: schulzrinne@cs.columbia.edu

   Anup Rao
   Cisco
   USA
   electronic mail: anrao@cisco.com

   Robert Lanphier
   RealNetworks
   P.O. Box 91123
   Seattle, WA 98111-9223
   USA
   electronic mail: robla@real.com

   Magnus Westerlund
   Ericsson AB, ERA/TVA/A
   Torshamsgatan 23
   SE-164 80 STOCKHOLM
   SWEDEN
   electronic mail: magnus.westerlund@ericsson.com

   Aravind Narasimhan
   Sun Microsystems, Inc.
   101 Park Avenue, 3rd & 4th Floor
   New York, NY
   USA
   electronic mail: aravind.narasimhan@sun.com

H Contributors the RTSP session has    |
            been changed.                                                 |

          - The following people protocol has been made written contribution included fully IPv6 capable. Certain of     |
            the functionality, like using explicit IPv6 addresses in      |
            fields requires that the
   specification: protocol support this updated        |
            specification.                                                |

          - Added a fragment part to the RTSP URL. This seem to be        |
            indicated by the note below the definition however it was     |
            not part of the BNF.                                          |

        o Tom Marshall The Status codes has contributed with text about been changed in the usage following way:         |

          - The use of 3rr status codes.

        o Thomas Zheng code 303 "See Other" has contributed with text regarding the been decapitated   |
            as it does not make sense to use in RTSP.                     |

          - Added status code 350, 351 and updated usage of the Range in PLAY responses.

I Acknowledgements

   This draft is based on other     |
            redirect status codes, see chapter  13.3.                     |

          - When sending response 451 and 458 the functionality of response body should    |
            contain the original RTSP draft
   submitted in October 1996. It also borrows format and descriptions
   from HTTP/1.1.

   This document offending parameters.                             |

          - Clarification on when a 3rr redirect status code can be       |
            received has benefited greatly from the comments been added. This includes receiving 3rr as a     |
            result of all those
   participating in the MMUSIC-WG. In addition request within a established session. This          |
            provides clarification to those already
   mentioned, a previous unspecified behavior.    |

          - Removed the following individuals have contributed 250 (Low On Storage Space) status code as it      |
            only is relevant to this
   specification:

   Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning,
   Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari,
   Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V.
   Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt,
   John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Anders Klemets,
   Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas
   Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal
   Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov,
   Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith,
   Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen
   Chesire, David Walker, and Geetha Srikantan.

   [1] H. Schulzrinne, "RTP profile for audio and video conferences with
   minimal control," RFC 3351, Internet Engineering Task Force, July
   2003.

   [2] R. Fielding, J. Gettys, J. Mogul, H. Nielsen, and T. Berners-Lee,
   "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet
   Engineering Task Force, Jan. 1997.

   [3] F. Yergeau, G. Nicol, G. Adams, and M. Duerst,
   "Internationalization of recording which is deprecated.            |

        o The following functionality has been deprecated from the hypertext markup language," RFC 2070,
   Internet Engineering Task Force, Jan.  1997.

   [4] S. Bradner, "Key words for        |
          protocol:                                                       |

          - The use in RFCs to indicate requirement
   levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.

   [5] ISO/IEC, "Information technology -- generic coding of moving
   pictures and associated audio informaiton -- part 6: extension for
   digital storage media and control," Draft International Standard ISO
   13818-6, International Organization Queued Play.                                       |

          - The use of PLAY method for Standardization ISO/IEC
   JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995.

   [6] J. Franks, P. Hallam-Baker, and J. Hostetler, "An extension to
   HTTP: digest access authentication," RFC 2069, Internet Engineering
   Task Force, Jan.  1997.

   [7] J. Postel, "User datagram protocol," RFC STD 6, 768, Internet
   Engineering Task Force, Aug. 1980.

   [8] B. Hinden keep-alive in play state.          |

          - The RECORD and C. Partridge, "Version 2 ANNOUNCE methods and all related               |
            functionality. Some of the reliable data
   protocol (RDP)," RFC 1151, Internet Engineering Task Force, Apr.
   1990.

   [9] J. Postel, "Transmission control protocol," RFC STD 7, 793,
   Internet Engineering Task Force, Sept. 1981.

   [10] H. Schulzrinne, "A comprehensive multimedia control architecture
   for syntax has been removed.           |

          - The possibility to use timed execution of methods with the Internet,"    |
            time parameter in Proc. International Workshop the Range header.                           |

          - The description on Network how rtspu and
   Operating System Support for Digital Audio rtsps works is not part of   |
            the core specification and Video (NOSSDAV), (St.
   Louis, Missouri), May 1997.

   [11] P. McMahon, "GSS-API authentication method will require external              |
            description. Only that they exist is defined here.            |

        o Text specifying the special behavior of PLAY for SOCKS version 5,"
   RFC 1961, Internet Engineering Task Force, June 1996.

   [12] J. Miller, P. Resnick, and D. Singer, "Rating services and
   rating systems (and their machine readable descriptions),"
   Recommendation REC-PICS-services-961031, W3C (World Wide Web
   Consortium), Boston, Massachusetts, Oct. 1996.

   [13] J. Miller, T. Krauskopf, P. Resnick, live content.  |

        o The following changes has been made in relation to methods:     |

          - The OPTIONS method has been clarified on how to use the       |
            Public and W. Treese, "PICS label
   distribution label syntax Allow headers.                                     |

          - The RECORD and communication protocols,"
   Recommendation REC-PICS-labels-961031, W3C (World Wide Web
   Consortium), Boston, Massachusetts, Oct. 1996.

   [14] D. Crocker ANNOUNCE methods are removed as they are       |
            lacking implementation and P. Overell, "Augmented BNF for syntax
   specifications:  ABNF," RFC 2234, Internet Engineering Task Force,
   Nov. 1997.

   [15] B. Braden, "Requirements for internet hosts not considered necessary in the    |
            core specification. Any work on these methods should be done  |
            as a extension document to RTSP.                              |

          - application and
   support," RFC STD 3, 1123, Internet Engineering Task Force, Oct.
   1989.

   [16] R. Elz, "A compact representation Added text clarifying the usage of IPv6 addresses," RFC 1924,
   Internet Engineering Task Force, Apr. 1996.

   [17] T. Berners-Lee, L. Masinter, SET_PARAMETER for keep-    |
            alive and M. McCahill, "Uniform resource
   locators (URL)," RFC 1738, Internet Engineering Task Force, Dec.
   1994.

   [18] F. Yergeau, "UTF-8, usage without any body.                             |

          - Added a transformation format of ISO 10646," RFC
   2279, Internet Engineering Task Force, Jan. 1998.

   [19] B. Braden, "T/TCP -- TCP extensions backwards compatibility resolution for transactions functional
   specification," RFC 1644, Internet Engineering Task Force, July 1994.

   [20] W. R. Stevens, TCP/IP illustrated: how to handle  |
            the implementation, vol. 2.
   Reading, Massachusetts: Addison-Wesley, 1994.

   [21] H. Schulzrinne, R. Lanphier, new state machine without automatic state transition,     |
            for example for returning to ready when finished playing.     |

        o Wrote a new chapter about how to setup different media          |
          transport alternatives and A. Rao, "Real time streaming
   protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr.
   1998.

   [22] T. Berners-Lee, R. Fielding, their profiles, and L. Masinter, "Uniform resource
   identifiers (URI): generic syntax," RFC 2396, Internet Engineering
   Task Force, Aug. 1998.

   [23] H. Schulzrinne, S. Casner, R. Frederick, lower layer      |
          protocols. This resulted that the appendix on RTP interaction   |
          was moved there instead in the part describing RTP. The         |
          chapter also includes guidelines what to think of when writing  |
          usage guidelines for new protocols and V. Jacobson, "RTP: profiles.                |

        o Added a transport protocol new chapter describing the available mechanisms to      |
          determine if functionality is supported, called "Capability     |
          Handling". Renamed option-tags to feature-tags.                 |

        o Added a contributors chapter with people who has contribute     |
          actual text to the specification.                               |

        o Added a chapter Use Cases that describes the major use cases    |
          for real-time applications," RFC 3550, Internet
   Engineering Task Force, July 2003.

   [24] M. Handley RTSP.                                                       |

        o Clarified the usage of "a=range" and V. Jacobson, "SDP: session description protocol,"
   RFC 2327, Internet Engineering Task Force, Apr. 1998.

   [25] R. Fielding, "Relative uniform resource locators," RFC 1808,
   Internet Engineering Task Force, June 1995.

   [26] R. Fielding, "Hypertext Transfer Protocol -- HTTP/1.1," RFC
   2616, Internet Engineering Task Force, June 1999.

   [27] T. Dierks, C. Allen, "The TLS Protocol, Version 1.0," how to indicate live       |
          content that are not seekable with this header.                 |

   Note that this list does not reflect minor changes in wording or       |
   correction of typographical errors.                                    |

   A word-by-word diff from RFC 2246,
   Internet Engineering Task Force, Januari 1999.

   [28] International Telecommunication Union, "Visual telephone systems
   and equipment for local area networks which provide a non-guaranteed
   quality 2326 can be found at http://rtsp.org/

G Author Addresses

   Henning Schulzrinne
   Dept. of service," Recommendation H.323, Telecommunications
   Standarization Sector Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027
   USA
   electronic mail: schulzrinne@cs.columbia.edu

   Anup Rao
   Cisco
   USA
   electronic mail: anrao@cisco.com

   Robert Lanphier
   RealNetworks
   P.O. Box 91123
   Seattle, WA 98111-9223
   USA
   electronic mail: robla@real.com

   Magnus Westerlund
   Ericsson AB, EAB/TVA/A
   Torshamsgatan 23
   SE-164 80 STOCKHOLM
   SWEDEN
   electronic mail: magnus.westerlund@ericsson.com
   Aravind Narasimhan
   Sun Microsystems, Inc.
   101 Park Avenue, 3rd & 4th Floor
   New York, NY
   USA
   electronic mail: aravind.narasimhan@sun.com

H Contributors

   The following people has made written contribution included in the
   specification:

        o Tom Marshall has contributed with text about the usage of ITU, Geneva, Switzerland, May 1996.

   [29] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
   Considerations Section 3rr
          status codes.

        o Thomas Zheng has contributed with text regarding the usage of
          the Range in PLAY responses.

        o Sean Sheedy has contributed with text regarding timing out
          RTSP messages.

I Acknowledgements

   This draft is based on the functionality of the original RTSP draft
   submitted in RFCs," RFC2434, Internet Engineering Task
   Force, October 1998.

   [30] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal IPv6
   Addresses 1996. It also borrows format and descriptions
   from HTTP/1.1.

   This document has benefited greatly from the comments of all those
   participating in URL's," RFC 2732, Internet Engineering Task Force,
   December 1999.

   [31] J. Rosenberg, J. Weinberger, C. Huitema, the MMUSIC-WG. In addition to those already
   mentioned, the following individuals have contributed to this
   specification:

   Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning,
   Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari,
   Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V.
   Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt,
   John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Anders Klemets,
   Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas
   Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal
   Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov,
   Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith,
   Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen
   Chesire, David Walker, and Geetha Srikantan.

J Normative References

   [1] H. Schulzrinne, R. Mahy, "STUN - Simple
   Traversal of UDP Through Network Address Translators," Internet
   Engineering Task Force, Work in Progress, October 2002.

   [32] P. Srisuresh, K. Egevang, "Traditional IP Network Address
   Translator (Traditional NAT)," Lanphier, and A. Rao, "Real time streaming
   protocol (RTSP)," RFC 3022, 2326, Internet Engineering Task Force, January 2001.

   [33] Apr.

   1998.

   [2] M. Westerlund, "How to make Real-Time Streaming Protocol (RTSP)
   traverse Network Address Translators (NAT) and interact with
   Firewalls.", Internet Engineering Task Force Draft, draft-ietf-
   mmusic-rtsp-nat-00.txt, Work in Progress, Feb 2003.

   [34] A. Narasimhan, A. Narasimhan, "MUTE and UNMUTE extension to
   RTSP", Internet Engineering Task Force Draft, draft-sergent-rtsp-
   mute-00.txt, Work in Progress, Feb 2002.

   [35] Third Generation Partnership Project (3GPP), "Transparent end-
   to-end Packet-switched Streaming Service (PSS); Protocols and codecs"
   3GPP Technical Specification 26.234, Release 5.

   [36] D. Yon, "Connection-Oriented Media Transport in SDP", Internet
   Engineering Task Force Draft, draft-ietf-mmusic-sdp-comedia-04.txt,
   July 2002.

   [37] John Lazzaro, "Framing RTP Handley and RTCP Packets over Connection-
   Oriented Transport", V. Jacobson, "SDP: session description protocol,"
   RFC 2327, Internet Engineering Task Force Draft , draft-
   lazzaro-avt-rtp-framing-contrans-00.txt, January 2003.

   [38] Force, Apr. 1998.

   [3] S. Olson, G. Camarill, A. B. Roach, "Support C. H. Schulzrinne, "RTP profile for IPv6 in Session
   Description Protocol (SDP)," audio and video
   conferences with minimal control," RFC 3266, 3551, Internet Engineering
   Task Force, June 2002.

   [39] July 2003.

   [4] e. a. R. Hinden, S. Deering, "Internet Protocol Version 6 (IPv6)
   Addressing Architecture," Fielding, "Hypertext transfer protocol -- http/1.1," RFC 3513,
   2616, Internet Engineering Task Force,
   April 2003.

   [40] G. Camarillo, G. Eriksson, J. Holler, H. Schulzrinne, "Grouping
   of Media Lines in the Session Description Protocol (SDP)," June 1999.

   [5] D. Crocker and P. Overell, "Augmented BNF for syntax
   specifications:  ABNF," RFC 3388, 2234, Internet Engineering Task Force, December 2002.

   IPR Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission
   Nov. 1997.

   [6] S. Bradner, "Key words for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

   Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references in RFCs to the indicate requirement
   levels," RFC 2119, Internet Society or other Engineering Task Force, Mar. 1997.

   [7] J. F. et. al., "Http authentication: Basic and digest access
   authentication," RFC 2617, Internet organizations, except as needed for the purpose Engineering Task Force, June
   1999.

   [8] J. Postel, "User datagram protocol," RFC STD 6, 768, Internet
   Engineering Task Force, Aug. 1980.

   [9] J. Postel, "Transmission control protocol," RFC STD 7, 793,
   Internet Engineering Task Force, Sept. 1981.

   [10] R. Elz, "A compact representation of
   developing IPv6 addresses," RFC 1924,
   Internet standards in which case the procedures Engineering Task Force, Apr. 1996.

   [11] L. M. R. Hinden, B. Carpenter, "Format for
   copyrights defined literal ipv6
   addresses in the url's," RFC 2732, Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual Engineering Task Force, Dec.
   1999.

   [12] T. Berners-Lee, R. Fielding, and will not be
   revoked by the L. Masinter, "Uniform resource
   identifiers (URI): generic syntax," RFC 2396, Internet Society or its successors or assigns.

   This document Engineering
   Task Force, Aug.  1998.

   [13] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC
   2279, Internet Engineering Task Force, Jan. 1998.

   [14] B. Braden, "Requirements for internet hosts - application and the information contained herein is provided on an
   "AS IS" basis
   support," RFC STD 3, 1123, Internet Engineering Task Force, Oct.
   1989.

   [15] e. a. H. Schulzrinne, "RTP: a transport protocol for real-time
   applications," RFC 3550, Internet Engineering Task Force, July 2003.

   [16] R. Fielding, J. Gettys, J. Mogul, H. Nielsen, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

                           Table of Contents

   1          Introduction ........................................    2
   1.1        The Update of the RTSP Specification ................    2
   1.2        Purpose .............................................    3
   1.3        Requirements ........................................    5
   1.4        Terminology .........................................    5
   1.5        Protocol Properties .................................    8
   1.6        Extending RTSP ......................................    9
   1.7        Overall Operation ...................................   10
   1.8        RTSP States .........................................   11
   1.9        Relationship with Other Protocols ...................   12
   2          Notational Conventions ..............................   13
   3          Protocol Parameters .................................   13
   3.1        RTSP Version ........................................   13
   3.2        RTSP URL ............................................   13
   3.3        Session Identifiers .................................   15
   3.4        SMPTE Relative Timestamps ...........................   15
   3.5        Normal Play Time ....................................   16
   3.6        Absolute Time .......................................   17
   3.7        Feature-tags ........................................   17
   4          RTSP Message ........................................   18
   4.1        Message Types .......................................   19
   4.2        Message Headers .....................................   19
   4.3        Message Body ........................................   19
   4.4        Message Length ......................................   19
   5          General Header Fields ...............................   19
   6          Request .............................................   20
   6.1        Request Line ........................................   20
   6.2        Request Header Fields ...............................   20
   7          Response ............................................   22
   7.1        Status-Line .........................................   22
   7.1.1      Status Code T. Berners-
   Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet
   Engineering Task Force, Jan. 1997.

   [17] H. Alvestrand and T. Narten, "Guidelines for writing an IANA
   considerations section in RFCs," RFC 2434, Internet Engineering Task
   Force, Oct. 1998.

   [18] A. B. R. S. Olson, G. Camarill, "Support for ipv6 in session
   description protocol (sdp)," RFC 3266, Internet Engineering Task
   Force, June 2002.

   [19] S. D. R. Hinden, "Internet protocol version 6 (ipv6) addressing
   architecture," RFC 3513, Internet Engineering Task Force, Apr. 2003.

K Informative References

   [20] T. Z. M. Westerlund, "How to make real-time streaming protocol
   (rtsp) traverse network address translators (nat) and Reason Phrase .......................   22
   7.1.2      Response Header Fields ..............................   24
   8          Entity ..............................................   25
   8.1        Entity Header Fields ................................   25
   8.2        Entity Body .........................................   27
   9          Connections .........................................   27
   9.1        Pipelining ..........................................   27
   9.2        Reliability interact with
   firewalls.," internet draft, Internet Engineering Task Force, Feb.
   2004.  Work in progress.

   [21] A. Narasimhan, "Mute and Acknowledgements ....................   28  |
   9.3        Unreliable Transport ................................   28  |
   9.4        The usage unmute extension to rtsp," internet
   draft, Internet Engineering Task Force, Feb. 2002.  Work in progress.

   [22] P. Gentric, "Rtsp stream switching," internet draft, Internet
   Engineering Task Force, Jan. 2004.  Work in progress.

   [23] A. L. G. Srikantan, J. Murata, "Streaming relays," internet
   draft, Internet Engineering Task Force, Dec. 2003.  Work in progress.

   [24] F. Yergeau, G. Nicol, G. Adams, and M. Duerst,
   "Internationalization of connections ............................   29
   9.5        Use the hypertext markup language," RFC 2070,
   Internet Engineering Task Force, Jan.  1997.

   [25] ISO/IEC, "Information technology -- generic coding of IPv6 .........................................   31
   10         Capability Handling .................................   31
   11         Method Definitions ..................................   32
   11.1       OPTIONS .............................................   33
   11.2       DESCRIBE ............................................   34
   11.3       SETUP ...............................................   36
   11.4       PLAY ................................................   39
   11.5       PAUSE ...............................................   42
   11.6       TEARDOWN ............................................   46
   11.7       GET_PARAMETER .......................................   47
   11.8       SET_PARAMETER .......................................   47
   11.9       REDIRECT ............................................   48
   11.10      PING ................................................   50
   11.11      Embedded (Interleaved) Binary Data ..................   51
   12         Status Code Definitions .............................   53
   12.1       Success 1xx .........................................   53
   12.1.1     100 Continue ........................................   53
   12.2       Success 2xx .........................................   53
   12.2.1     250 Low on Storage Space ............................   53
   12.3       Redirection 3xx .....................................   53
   12.3.1     TBW .................................................   54
   12.3.2     301 Moved Permanently ...............................   54
   12.3.3     302 Found ...........................................   54
   12.3.4     303 See Other .......................................   54
   12.3.5     304 Not Modified ....................................   54
   12.3.6     305 Use Proxy .......................................   55
   12.4       Client Error 4xx ....................................   55
   12.4.1     400 Bad Request .....................................   55
   12.4.2     405 Method Not Allowed ..............................   55
   12.4.3     451 Parameter Not Understood ........................   55
   12.4.4     452 reserved ........................................   55
   12.4.5     453 Not Enough Bandwidth ............................   55
   12.4.6     454 Session Not Found ...............................   55
   12.4.7     455 Method Not Valid in This State ..................   55
   12.4.8     456 Header Field Not Valid for Resource .............   56
   12.4.9     457 Invalid Range ...................................   56
   12.4.10    458 Parameter Is Read-Only ..........................   56
   12.4.11    459 Aggregate Operation Not Allowed .................   56
   12.4.12    460 Only Aggregate Operation Allowed ................   56
   12.4.13    461 Unsupported Transport ...........................   56
   12.4.14    462 Destination Unreachable .........................   56
   12.5       Server Error 5xx ....................................   56
   12.5.1     551 Option not supported ............................   57
   13         Header Field Definitions ............................   57
   13.1       Accept ..............................................   59
   13.2       Accept-Encoding .....................................   59
   13.3       Accept-Language .....................................   59
   13.4       Accept-Ranges .......................................   59
   13.5       Allow ...............................................   60
   13.6       Authorization .......................................   60
   13.7       Bandwidth ...........................................   60
   13.8       Blocksize ...........................................   62
   13.9       Cache-Control .......................................   64
   13.10      Connection ..........................................   67
   13.11      Content-Base ........................................   67
   13.12      Content-Encoding ....................................   67
   13.13      Content-Language ....................................   67
   13.14      Content-Length ......................................   67
   13.15      Content-Location ....................................   68
   13.16      Content-Type ........................................   68
   13.17      CSeq ................................................   68
   13.18      Date ................................................   68
   13.19      Expires .............................................   68
   13.20      From ................................................   69
   13.21      Host ................................................   69
   13.22      If-Match ............................................   70
   13.23      If-Modified-Since ...................................   70
   13.24      Last-Modified .......................................   70
   13.25      Location ............................................   70
   13.26      Proxy-Authenticate ..................................   70
   13.27      Proxy-Require .......................................   71
   13.28      Public ..............................................   71
   13.29      Range ...............................................   72
   13.30      Referer .............................................   73
   13.31      Retry-After .........................................   74
   13.32      Require .............................................   74
   13.33      RTP-Info ............................................   75
   13.34      Scale ...............................................   77
   13.35      Speed ...............................................   78
   13.36      Server ..............................................   78
   13.37      Session .............................................   78
   13.38      Supported ...........................................   81
   13.39      Timestamp ...........................................   81
   13.40      Transport ...........................................   82
   13.41      Unsupported .........................................   88
   13.42      User-Agent ..........................................   88
   13.43      Vary ................................................   88
   13.44      Via .................................................   88
   13.45      WWW-Authenticate ....................................   88
   14         Caching .............................................   88
   15         Examples ............................................   89
   15.1       Media on Demand (Unicast) ...........................   89
   15.2       Streaming moving
   pictures and associated audio informaiton -- part 6: extension for
   digital storage media and control," Draft International Standard ISO
   13818-6, International Organization for Standardization ISO/IEC
   JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995.

   [26] C. A. T. Dierks, "The tls protocol, version 1.0," RFC 2246,
   Internet Engineering Task Force, Jan. 1999.

   [27] B. Hinden and C. Partridge, "Version 2 of the reliable data
   protocol (RDP)," RFC 1151, Internet Engineering Task Force, Apr.

   1990.

   [28] H. Schulzrinne, "A comprehensive multimedia control architecture
   for the Internet," in Proc. International Workshop on Network and
   Operating System Support for Digital Audio and Video (NOSSDAV), (St.
   Louis, Missouri), May 1997.

   [29] International Telecommunication Union, "Visual telephone systems
   and equipment for local area networks which provide a Container file .......................   92
   15.3       Single Stream Container Files .......................   94
   15.4       Live Media Presentation Using Multicast .............   96
   16         Syntax ..............................................   97
   16.1       Base Syntax .........................................   97
   16.2       RTSP Protocol Definition ............................   98
   16.2.1     Message Syntax ......................................   98
   16.2.2     Header Syntax .......................................  102
   17         Security Considerations .............................  103
   18         IANA Considerations .................................  105
   18.1       Feature-tags ........................................  106
   18.1.1     Description .........................................  106
   18.1.2     Registering New Feature-tags with IANA ..............  106
   18.1.3     Registered entries ..................................  106
   18.2       RTSP Methods ........................................  107
   18.2.1     Description .........................................  107
   18.2.2     Registering New Methods with IANA ...................  107
   18.2.3     Registered Entries ..................................  107
   18.3       RTSP Status Codes ...................................  107
   18.3.1     Description .........................................  107
   18.3.2     Registering New Status Codes with IANA ..............  108
   18.3.3     Registered Entries ..................................  108
   18.4       RTSP Headers ........................................  108
   18.4.1     Description .........................................  108
   18.4.2     Registering New Headers with IANA ...................  108
   18.4.3     Registered entries ..................................  109
   18.5       Transport Header registries .........................  109
   18.5.1     Transport Protocols .................................  109
   18.5.2     Profile .............................................  110
   18.5.3     Lower Transport .....................................  110
   18.5.4     Transport modes .....................................  110
   18.6       Cache Directive Extensions ..........................  111
   18.7       SDP attributes ......................................  111
   A          RTSP Protocol State Machine .........................  112
   A.1        States ..............................................  112  |
   A.2        State variables .....................................  112  |
   A.3        Abbreviations .......................................  113  |
   A.4        State Tables ........................................  113  |
   B          Media Transport Alternatives ........................  116
   B.1        RTP .................................................  117
   B.1.1      AVP .................................................  118
   B.1.2      AVP/UDP .............................................  119
   B.1.3      AVP/TCP .............................................  120
   B.2        Future Additions ....................................  121
   C          Use non-guaranteed
   quality of service," Recommendation H.323, Telecommunication
   Standardization Sector of ITU, Geneva, Switzerland, May 1996.

   [30] P. McMahon, "GSS-API authentication method for SOCKS version 5,"
   RFC 1961, Internet Engineering Task Force, June 1996.

   [31] J. Miller, P. Resnick, and D. Singer, "Rating services and
   rating systems (and their machine readable descriptions),"
   Recommendation REC-PICS-services-961031, W3C (World Wide Web
   Consortium), Boston, Massachusetts, Oct. 1996.

   [32] J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS label
   distribution label syntax and communication protocols,"
   Recommendation REC-PICS-labels-961031, W3C (World Wide Web
   Consortium), Boston, Massachusetts, Oct. 1996.

   [33] B. Braden, "T/TCP -- TCP extensions for transactions functional
   specification," RFC 1644, Internet Engineering Task Force, July 1994.

   [34] W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2.
   Reading, Massachusetts: Addison-Wesley, 1994.

   [35] Third Generation Partnership Project (3GPP), "Transparent end-
   to-end packet-switched streaming service (pss); protocols and
   codecs," Technical Specification 26.234, Third Generation Partnership
   Project (3GPP), Dec. 2002.

   [36] D. Yon, "Connection-oriented media transport in sdp," internet
   draft, Internet Engineering Task Force, Mar. 2003.  Work in progress.

   [37] J. Lazzaro, "Framing rtp and rtcp packets over connection-
   oriented transport," internet draft, Internet Engineering Task Force,
   Oct. 2003.  Work in progress.

   [38] e. a. G. Camarillo, "Grouping of media lines in the session
   description protocol (sdp)," RFC 3388, Internet Engineering Task
   Force, Dec. 2002.

   IPR Notice

   The IETF takes no position regarding the validity or scope of SDP any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for RTSP Session Descriptions ............  121
   C.1        Definitions .........................................  121
   C.1.1      Control URL .........................................  122
   C.1.2      Media Streams .......................................  123  |
   C.1.3      Payload Type(s) .....................................  123
   C.1.4      Format-Specific Parameters ..........................  124  |
   C.1.5      Range publication and any assurances of Presentation ...............................  124  |
   C.1.6      Time
   licenses to be made available, or the result of Availability ................................  125
   C.1.7      Connection Information ..............................  125
   C.1.8      Entity Tag ..........................................  125
   C.2        Aggregate Control Not Available .....................  125
   C.3        Aggregate Control Available .........................  126
   C.4        RTSP external SDP delivery ..........................  127  |
   D          Minimal RTSP implementation .........................  128
   D.1        Client ..............................................  128
   D.1.1      Basic Playback ......................................  129
   D.1.2      Authentication-enabled ..............................  129
   D.2        Server ..............................................  129
   D.2.1      Basic Playback ......................................  130
   D.2.2      Authentication-enabled ..............................  131
   E          Open Issues .........................................  131
   F          Changes .............................................  131
   G          Author Addresses ....................................  136
   H          Contributors ........................................  137
   I          Acknowledgements ....................................  137 an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

   Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.