[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
MMUSIC                                                     Thomas M. Zeng
                                            PacketVideo Network Solutions
                                                         P. Greg Sherwood
Internet-Draft                                          PacketVideo Corp.
Expires: Aug. 6, 2005                                          Feb 7,2005

                            RTSP Announce Method

Status of this Memo

  By submitting this Internet-Draft, I (we) certify that any
  applicable patent or other IPR claims of which I am (we are) aware
  have been disclosed, and any of which I (we) become aware will be
  disclosed, in accordance with RFC 3668.

  By submitting this Internet-Draft, I (we) accept the provisions of
  Section 3 of RFC 3667 (BCP 78).

  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-

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

  The list of current Internet-Drafts can be accessed at

  The list of Internet-Draft Shadow Directories can be accessed at

  This document is an individual submission to the IETF. Comments
  should be directed to the authors.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   Changes since the last revision:
      The only change is the update of dates in order to prevent the
   draft from expiring.

   This memo describes an extension RTSP request, ANNOUNCE, which
   extends the core RTSP protocol [RTSP_NEW] to allow one end to
   push to the other end various types of information by RTSP

   This RTSP extension is identified by a feature tag, "method.announce",
   and supports capability exchange via the feature-tag framework
   as detailed in [RTSP_NEW].

   Examples of information in ANNOUNCE requests include session
   descriptions and end of stream events.

   The receiver of the ANNOUNCE request is expected to reply with
   200 OK response.

1. Motivation

   In RFC2326, ANNOUNCE is part of the RTSP protocol. In the updated
   core RTSP protocol [RTSP_NEW], however, ANNOUNCE method has been
   removed from the core RTSP protocol because, for one, ANNOUNCE is
   not required for basic RTSP playback, for the other, ANNOUNCE had
   a lack of implementation at the time when [RTSP_NEW] was being

   Nonetheless, there are advanced use cases that require
   ANNOUNCE method for the server to asynchronously publish session
   descriptions or other event information. It is clear that such
   functionality needs to be made available in a way consistent
   to the extension mechanism in [RTSP_NEW].

   The first use case is for either the server or the client to publish
   a new or updated session description pertinent to a RTSP session URL.
   Specifically, a multi-unicast live video server utilizing RTSP may
   want to publish an updated SDP (Session Description Protocol)
   when a new media track is added to the RTSP session. When client
   receives the ANNOUNCE request (with an SDP entity body),
   it has the option to perform SETUP on the newly available media

   The second use case is for the server to signal end of stream
   event to its client(s). Appendix A presents the reasons why
   ANNOUNCE is better suited to signal end of stream than the
   other options using RTCP BYE packet, RTSP TEARDOWN, PAUSE or
   SET_PARAMETER requests.

   Given the use cases presented above, we propose to utilize
   ANNOUNCE method to signal several types of events common to
   RTSP-based media applications, including
   session description events and End-Of-Stream events.

2. The Definition of ANNOUNCE method

   This memo defines ANNOUNCE as an extension to the core RTSP
   protocol [RTSP_NEW]. It presents ANNOUNCE method as a
   general mechanism for RTSP server to signal to its clients
   various events including end of stream events or session
   description updates events. This memo will discuss the general
   usage of ANNOUNCE, its feature tag, as well as well as a
   new "Event-Type" header for ANNOUNCE method.

   [RTSP_NEW] has defined a mechanism to extend the core RTSP
   protocol. Following that mechanism, a feature tag is used to
   identify ANNOUCE method as an extension to the core RTSP protocol.

   The ANNOUNCE method is an RTSP request that can be sent in both
   directions, either from client to server or server to client.
   When server intends to send ANNOUNCE to client, it must have the
   means to reach the client, because the RTSP client is not required
   to keep a persistent connection with the RTSP server. It is
   beyond the scope of this memo to define the exact means for server
   to reach client. It suffices to say that if the client intends to
   receive server's ANNOUNCE requests, it must keep the RTSP
   connection open, or inform the server on how to reach it without
   a persistent RTSP connection.

   Below is an example RTSP conversation in which an RTSP server
   announces an end of stream event for a media stream using a
   non-aggregate URI. The new header, "Event-Type" is formally
   defined later in this section.

    S->C: ANNOUNCE rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0
          CSeq: 10
          Session: 12345678
          Event-Type: 2000 End-Of-Stream
          Range: npt=0-200
          RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102
          Content-Type: text/parameters
          Content-Length: 49

          eos-reason: Reached the end of requested range.

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

  2.1 Normative definitions

   "ANNOUNCE" is an "extension-method" in the ABNF in section 16.2
   "RTSP Protocol Definitions" in [RTSP_NEW].

   The request-URI of an ANNOUNCE request can be either aggregate
   or non-aggregate URI.

   An ANNOUNCE request must include "CSeq" header. It MAY include
   the following optional headers:


   An ANNOUNCE request MAY include entity body, in which case it
   MUST follow the rules for entity body defined in section 8.2
   of [RTSP_NEW]. Entity body can be used to convey further details
   specific to an event type. For instance, if the event type is
   session description announcement, the actual SDP SHOULD be
   included in the entity body. If the event type is end-of-stream
   announcement, the entity body MAY contain "text/parameter"
   content type that conveys the reason of the end-of-stream

   ANNOUNCE does NOT affect RTSP session state. If a receiver does not
   understand any of the headers in an ANNOUNCE request, it simply
   ignores those headers.

   The next section defines a new RTSP headers for ANNOUNCE method:

  2.2 Event-Type Header

   The Event-Type header is an optional header to identify the type of
   event pertaining to the ANNOUNCE request. Example event types include
   session description, end of stream and error.

   If an ANNOUNCE request does not contain Event-Type header, the
   Event-Type defaults to "Session-Description", consistent with

   The Event-Type header is defined in ABNF as:
          Event-Type           = "Event-Type" ":"  event-type
          event-type           = event-type-code SP event-type-string
          event-type-code      = 4DIGITS
          event-type-string    = token

       -- token is  defined in section 17 of [RTSP_NEW].

   The only method that "Event-Type" header applies is the ANNOUNCE method,
   either from client to server or from server to client.

   The following pairs fo event-type-code and event-type-string are
   defined in this memo.

        Code   Message

        1000   Session-Description

        2000   End-of-Stream

        3000   Error

   If "Event-Type" header is missing, the default is
   "1000 Session-Description".
   This is to be consistent with the usage of ANNOUNCE in RFC2326.

   If "Event-Type" is "2000 End-Of-Stream", the optional RTP-Info header
   SHOULD contain the "seq" attribute that indicates the sequence number
   of the next RTP packet. See example in section 4.2.

  2.3 Limitations on serve to client "ANNOUNCE" requests

   Server to client ANNOUNCE method is issued only if the server
   has the means to contact the client when it has information to push.
   This may not be possible if the RTSP connection between server and
   client is not persistent. In such cases, the server will
   simply skip the sending of ANNOUNCE requests. That is to say, the
   server will not queue up the ANNOUNCE requests to be sent
   when client eventually connects. Such a queue would unnecessarily
   complicate server implementations.

3. Feature tag

   The support of the ANNOUNCE method is represented by the feature tag


   This feature tag applies to both servers and proxies.

   Implementations claiming "method.announce" feature tag MUST support
   the new "Event-Type" header defined in previous section.

4. Use Cases

   This section presents several use cases of the ANNOUNCE method.

   4.1 Client Announcing SDP To Server For Recording

   This use case is the same as the first RTSP exchange presented in
   section 14.6 in RFC2326, with capability exchange via
   OPTIONS method.

   The conference participant client C asks the media server M to record
   the audio and video portions of a meeting. After first verifying that
   the server supports the "ANNOUNCE" feature, the client uses the
   ANNOUNCE method to provide meta-information about the recorded
   session to the server.  The client omits "Event-Type"
   because "Event-Type: Session-Description" is the default.

     C->M: OPTIONS * RTSP/1.0
           Require: method.announce
           CSeq: 1

     M->C: RTSP/1.0 200 OK
           CSeq: 1
           Supported: method.announce

     C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0
           CSeq: 90
           Content-Type: application/sdp
           Content-Length: 121

           o=camera1 3080117314 3080118787 IN IP4
           s=IETF Meeting, Munich - 1
           i=The thirty-ninth IETF meeting will be held in Munich
           e=IETF Channel 1 <ietf39-mbone@uni-koeln.de>
           p=IETF Channel 1 +49-172-2312 451
           c=IN IP4
           t=3080271600 3080703600
           a=tool:sdr v2.4a6
           m=audio 21010 RTP/AVP 5
           c=IN IP4
           m=video 61010 RTP/AVP 31
           c=IN IP4

     M->C: RTSP/1.0 200 OK
           CSeq: 90

   4.2 Server Announcing End Of Stream

   In this example, the server announces the End-Of-Stream event to
   client for one live media stream, because upstream source terminates
   the stream after 200 seconds. The fact that the stream has played for
   200 seconds is communicated by the Range header in the ANNOUNCE request.
   The fact that the server has sent a total of 45102 RTP packets is
   conveyed in the RTP-Info headers.

     C->S: PLAY rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0
           Supported: method.announce
           CSeq: 10
           Session: 12345678
           Range: npt=0-200

     S->C: RTSP/1.0 200 OK
           Supported: method.announce
           CSeq: 10
           Session: 12345678
           RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=0; rtptime=0

     S->C: ANNOUNCE rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0
           CSeq: 123
           Session: 12345678
           Require: method.announce
           Event-Type: 2000 End-Of-Stream
           Range: npt=0-200
           RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102

           Content-Type: text/parameters
           Content-Length: 49

           eos-reason: reached the end of requested range.

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

   The Require header in the above ANNOUNCE request indicates that in
   order to understand the ùEvent-Typeÿ header the client must support
   the feature tag in the Require header. In this case the client happens
   to signal its support in its PLAY request.

   From the ANNOUNCE request, the client will learn that the server has
   completed the stream as requested.

   From the two RTP-Info headers, one in PLAY response, one in
   ANNOUNCE request, the client can derive the total number
   of RTP packets that the server has sent. In this example,
   the server has sent RTP packets 0 to 45101, for a total of 45102
   packets. The "seq" attribute of the RTP-Info header in ANNOUNCE
   tells the client that the next RTP packet was going to be packet
   number 45102 when the stream stops.

   From the npt field in the Range header, the client can derive
   the presentation time that this stream has covered.

5. Security Considerations

   Because there is only one new TEXT header, "Event-Type", added by the
   extension RTSP method,
   the security considerations outlined in [RTSP_NEW] apply here as well.

6. IANA Considerations

   A new method name, its associated feature tag, and a new header,
   need to be registered with IANA.

     -- Method name: ANNOUNCE. See section 2.1 for the relevant definition.

     -- Feature tag: method.announce. See section 3 for the relevant

     -- Header name: Event-Type, see section 2.2 for the relevant information.

 Appendix A: Justification for Using ANNOUNCE to Signal End Of Stream

  This appendix presents the reasons why we have selected the
  ANNOUNCE proposal from several proposals to signal end of stream.
  The competing proposals were based on:
   1) RTCP BYE packet,
   2) RTSP TEARDOWN request,
   3) RTSP PAUSE request,
   4) SET_PARAMETER request.

  In the core RTSP protocol [RTSP_NEW], an RTSP client relies on the
  media transport mechanism  to signal end of stream.

  When the media transport mechanism happens to be RTP over UDP, this
  is carried out by RTCP BYE packet [RTP_NEW]. In practice, there are
  some drawbacks with this approach:

     1. When the server sends an RTCP BYE packet with its SSRC, the
        server is giving up on
        the SSRC (see section 8.2 in [RTP_NEW]). The server would be
        required to
        switch to a new SSRC on a subsequent PLAY of the same media
        Since server's SSRC is only communicated in the Transport header
        of SETUP
        response, the server would not have an opportunity to send a new
        value to
        the player, and the client would have to discover the SSRC from
        the incoming RTP packets -- a non-trivial process.

     2. RTCP BYE packet method does not offer a simple, guaranteed
        method of delivering
        an end-of-stream announcement, given BYE packet is carried over

     3. RTCP BYE packet method does not offer the option to have a single
        end-of-stream announcement for all media streams in the RTSP

     4. Section 6.3.7 of RFC3550 stipulates that an RTP sender cannot
        send RTCP BYE
        before leaving the RTP session if it has not already sent at
        least one RTP or RTCP packet. This is a problem under
        error conditions. Consider the case
        where an RTP session has just started (i.e., RTSP PLAY has been
        successfully acknowledged with an RTSP 200 OK response), and the
        sender attempts to
        retrieve media frames from its media source. The media source
        fails to provide any media frame due to its internal error such
        as file corruption. The sender should inform its receiver(s)
        but it cannot send BYE packets.

   The motivation to solve the above issues is particularly high for
   unicast-streaming applications that use RTSP over TCP in the control
   plane, and RTP over UDP in the media transport.

   There is also the desire to have an EOS (End Of Stream)
   signaling mechanism
   for non-RTP delivery. One such delivery is MPEG2 transport streams
   used in the cable TV environment. In non-IP delivery environments,
   the transport typically remains allocated even if no media is being
   delivered.  This
   means that a client cannot watch for the server to close the
   transport to signal the end of stream. Meanwhile,  watching for the
   incoming media to stop is unreliable.  Short
   timeouts can trigger a false end of media detection if the
   media flow is temporarily delayed.  Long timeouts introduce
   unacceptable latencies.  Clients are unable to distinguish
   between a normal end of stream and an error condition that
   resulted in the media delivery stopping.

   We note that using TEARDOWN from server to client is not
   appropriate because:
     1. TEARDOWN is currently not allowed from server to
        client [RTSP_NEW];
     2. Even if TEARDOWN is made available in server to client
        the definition of TEARDOWN requires that, if the request
        URI is
        aggregate, that the session must be de-allocated by the
        There are RTSP applications that use SET_PARAMETER from
        client to
        server as the means to report session QoS statistics, but if
        server uses TEARDOWN on aggregate URL to signal end of stream,
        the client can no longer use SET_PARAMETER with a
        session header.
     3. In general, RTSP, being a client-server protocol,
        should let client, not server to control session state. But
        on aggregate URL will change session from PLAYING state
        to INIT state.

   We note that using PAUSE from server to client is not appropriate
   either, because PAUSE will change the state of the RTSP session.

   We note that using SET_PARAMETER from server to client will require
   at least two parameters in the entity body, one for event type that
   should be set to End-Of-Stream, and the other parameter for the
   reason of End-Of-Stream. Also using SET_PARAMETER with an SDP
   entity body to update session descriptoin will not be compatible
   with RFC2326 where ANNOUNCE was defined for that purpose.
   Therefore, SET_PARAMETER is not appropriate to convey the
   announcement of End-Of-Stream and other events.

Normative References

   [RTSP_NEW] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
         "Real Time Streaming Protocol",

   [RTP_NEW] RFC3550 "Real-time Transport Protocol", July 2003

   [ABNF]    RFC2234 "Augmented BNF for Syntax Specifications: ABNF",
         Nov. 1997


   Thanks to Sean Sheedy for suggesting the inclusion of "Range" header
   and for contributing part of the text in the motivations section.

   Thanks to Anders Klemets for suggesting the current semantics of the
   "seq" attribtue in the RTP-Info header.

Author Addresses

   Thomas Zeng
   PacketVideo Network Solutions
   9605 Scranton Road, Suite 400
   San Diego, CA 92121
   email: zeng@pvnetsolutions.com

   P. Greg Sherwood
   PacketVideo Device Solutions.
   10350 Science Center Dr., Suite 210
   San Diego, CA 92121
   email: sherwood@pv.com

IPR Notice

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights 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; nor does it represent that
  it has made any independent effort to identify any such rights.
  Information on the procedures with respect to rights in RFC
  documents can be found in BCP 78 and BCP 79.

  Copies of IPR disclosures made to the IETF Secretariat and any
  assurances of licenses to be made available, or the result of an
  attempt made to obtain a general license or permission for the use
  of such proprietary rights by implementers or users of this
  specification can be obtained from the IETF on-line IPR repository
  at http://www.ietf.org/ipr.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights that may cover technology that may be required to implement
  this standard.  Please address the information to the IETF at ietf-

Copyright Notice

Copyright (C) The Internet Society (2004).  This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on