MMUSIC Thomas M. Zeng
PacketVideo Network Solutions
P. Greg Sherwood
Internet-Draft PacketVideo Corp.
Expires: Jan. 17, 2005 July 18,2004
RTSP Announce Method
draft-zeng-mmusic-rtsp-announce-01
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 (BCP 79).
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-
Drafts.
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
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
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.
Abstract
This memo describes an extension RTSP method, ANNOUNCE, which
extends the core RTSP protocol [RTSP_NEW]
to enable a RTSP protocol entity to
push to the other side various types of information without the
other side asking for it, as long as the other
side has singaled the capability to support ANNOUNCE.
Examples of information in ANNOUNCE requests
include session descriptions and end of stream events.
The receiver of this RTSP request is expected to reply with 200 OK
response.
Since ANNOUNCE represents an extension to the core RTSP protocol,
a feature tag,
"method.announce", is defined to facilitate capability negotiation
using RTSP extension mechanism [RTSP_NEW].
1. Motivation
In RFC2326, ANNOUNCE is part of the RTSP protocol. In the updated
core RTSP protocol [RTSP_NEW], ANNOUNCE method is NOT part of the
core RTSP protocol.
There are use cases that require ANNOUNCE method to convey session
description as well as other event information. Hence there is a
need to make the announce functionality still available but in
a way consistent to the extension mechanism in [RTSP_NEW].
As an example, there is a need to signal end of stream event from
server to client, as detailed below.
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
stream.
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
UDP.
3. RTCP BYE packet method does not offer the option to have a single
aggregate
end-of-stream announcement for all media streams in the RTSP
session.
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
direction,
the definition of TEARDOWN requires that, if the request
URI is
aggregate, that the session must be de-allocated by the
server.
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
TEARDOWN
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.
This memo proposes to define ANNOUNCE method to signal serveral event
types including End-Of-Stream events.
The ANNOUNCE method is an RTSP request originally
defined in RFC2326 but excluded from the core RTSP protocol due
to lack of support [RTSP_NEW].
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.
3. The Definition of 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 to be defined later.
S->C: ANNOUNCE rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0
CSeq: 10
Session: 12345678
Event-Type: 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
3.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:
"Range",
"Session",
"RTP-Info",
"Event-Type"
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
event.
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:
"Event-Type".
3.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
RFC2326.
The Event-Type header is defined in ABNF as:
Event-Type = "Event-Type" ":" event-type
event-type = "Session-Descriptoin" / "End-Of-Stream"
/ "Error" / extension-event-type
extension-event-type = token
where:
-- token is defined in section 17 of [RTSP_NEW].
The only method that "Event-Type" applies is the ANNOUNCE method,
either from client to server or from server to client.
3.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.
4. Feature tag
The support of the ANNOUNCE method is represented by the feature tag
below:
method.announce
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.
5. Use Cases
This section presents several use cases of the ANNOUNCE method.
5.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
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, RECORD,ANNOUNCE
C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0
CSeq: 90
Content-Type: application/sdp
Content-Length: 121
v=0
o=camera1 3080117314 3080118787 IN IP4 195.27.192.36
s=IETF Meeting, Munich - 1
i=The thirty-ninth IETF meeting will be held in Munich, Germany
u=http://www.ietf.org/meetings/Munich.html
e=IETF Channel 1 <ietf39-mbone@uni-koeln.de>
p=IETF Channel 1 +49-172-2312 451
c=IN IP4 224.0.1.11/127
t=3080271600 3080703600
a=tool:sdr v2.4a6
a=type:test
m=audio 21010 RTP/AVP 5
c=IN IP4 224.0.1.11/127
a=ptime:40
m=video 61010 RTP/AVP 31
c=IN IP4 224.0.1.12/127
M->C: RTSP/1.0 200 OK
CSeq: 90
5.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.
C->S: PLAY rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0
Supported: method.annonce
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
Range: npt=0-200
RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102
Require: method.announce
Event-Type: End-Of-Stream
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. From the npt field in the
Range header, the client knows the presentation time that this stream
has covered, from the server's point of view.
6. 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.
7. 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 3.1 for the relevant definition.
-- Feature tag: method.announce. See section 4 for the relevant
definition.
-- Header name: Event-Type, see section 3.2 for the relevant information.
Normative References
[RTSP_NEW] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
"Real Time Streaming Protocol",
draft-ietf-mmusic-rfc2326bis-06.txt
[RTP_NEW] RFC3550 "Real-time Transport Protocol", July 2003
[ABNF] RFC2234 "Augmented BNF for Syntax Specifications: ABNF",
Nov. 1997
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-
ipr@ietf.org.
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
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
This Internet-Draft expires in January 2005.
Acknowledgement
Thanks to Sean Sheedy for suggesting the inclusion of "Range" header
and for contributing some text in the motivations section.
Funding for the RFC Editor function is currently provided by the
Internet Society.
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