Internet DRAFT - draft-zeng-rtsp-end-of-stream
draft-zeng-rtsp-end-of-stream
MMUSIC Thomas M. Zeng
P. Greg Sherwood
Internet-Draft PacketVideo
Expires: April 29, 2004 Oct 15, 2003
Signalling End Of Stream in RTSP
draft-zeng-mmusic-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on Apr. 29, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes a new RTSP method called END_OF_STREAM, which
extends the core RTSP protocol to enable one RTSP protocol entity to
signal other entity(s)
that it has no more media data to send. This request could be issued
either with a
non-aggregate or aggregate control URI, the latter implies that all
media streams
in the aggregate session have run out of media data.
The receiver of this RTSP request is expected to reply with 200 OK
response.
Since END_OF_STREAM represents an extension to the core RTSP protocol,
a feature tag,
"method.eos", is defined to facilitate capability negotiation using
RTSP extension
mechanism [RTSP_NEW].
1. Motivation
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
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.
2. RTCP BYE packet method does not offer a simple, gurranteed
method of delievering
an end-of-stream announcement.
3. RTCP BYE packet method does not offer the option to have a single
aggregate
end-of-stream announcemnt 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)
signalling 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 also that using ANNOUNCE from server to client is not
suitable, for two reasons:
1. ANNOUNCE from server to client is used in RFC2326 to update
session description.
Extending it to indicate end-of-stream event is awkward.
2. ANNOUNCE is not in the core RTSP protocol [RTSP_NEW].
The next section describes our solution.
3. Solution Using END_OF_STREAM method
We introduce a new RTSP method to signal end of stream in applications
where an persistent RTSP connection is maintained between server
and client.
The new method is an RTSP "extension-method" [RTSP_NEW]. It is called
END_OF_STREAM, and is a request from media sender
to receiver. In the case of RTSP client playing media streams sent by
RTSP server,
the END_OF_STREAM is sent from server to client. In the use case where
RTSP server is
recording media sent by RTSP client, the END_OF_STREAM requet could
be sent from an
RTSP client to server.
As any other RTSP request method, END_OF_STREAM must be acknowledged
with a response.
3.1 The Definition of END_OF_STREAM
The END_OF_STREAM request for a URI signals the fact that no more
RTP packets will be
sent. Here is an example:
S->C: END_OF_STREAM rtsp://foo.com/bar.avi RTSP/1.0
CSeq: 10
Session: 12345678
Range: npt=0-200
RTP-Info: url=//foo.com/bar.avi/streamid=0;seq=45102,
url=rtsp://foo.com/bar.avi/streamid=1;seq=30211
Reason: End of range reached
C->S: RTSP/1.0 200 OK
CSeq: 10
Session: 12345678
An END_OF_STREAM request MUST include "CSeq", "Range" and "Session"
headers.
It SHOULD include "RTP-Info" header.
The RTP-Info in server's END_OF_STREAM request
is used to indicate the sequence number of
the ending RTP packet for each media stream.
An END_OF_STREAM requet MAY include a new "Reason" header,
defined as a
string, whose purpose is to allow the server to explain why stream
has ended, and whose ABNF definition is given below:
Reason = "Reason" ":" Reason-Phrase CRLF
where:
-- "Reason-Phrase" is a parameter defined in section 7.1.1 of
[RTSP_NEW].
Note that the server is free to use any text as "Reason-Phrase". In
certain applications, the client
may display the text, in its entirety, to end user to improve user
friendliness.
END_OF_STREAM does not remove session ID, nor does it change the
state of the RTSP session.
END_OF_STREAM may be applied to either aggregate or non-aggregate URI.
END_OF_STREAM does not apply if the RTSP session is not in PLAYING
state. If a client receives END_OF_STREAM while it is not in PLAYING
state, it must reply with a 455 response: Method Not Valid in This
State.
We note that client can piggy back QoS statistics as a entity body in
its 200 OK response to the END_OF_STREAM request from the server.
3.2 Limitations
END_OF_STREAM method is applicable only if the server has the means
to contact the client when it reaches the end of a media stream.
This may not be possible if the RTSP connection between server and
client is not persistent. When it is time to send END_OF_STREAM but
the server does not have connection to the client, the server will
simply skip END_OF_STREAM. That is to say, the server will not
queue up the END_OF_STREAM message.
4. Feature tag
The END_OF_STREAM feature is represented by a feature tag (see
[RTSP_NEW]
for how to use feature tags in capability negotiations).
The feature tag is:
method.eos
which means that the END_OF_STREAM method is fully supported. By
fully we mean either at non-aggregate or aggregate level.
5. Use Case
In this example, the server sends END_OF_STREAM request 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 END_OF_STREAM request.
C->S: PLAY rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0
Supported: method.eos
CSeq: 10
Session: 12345678
Range: 0-200
S->C: RTSP/1.0 200 OK
Supported: method.eos
CSeq: 10
Session: 12345678
RTP-Info: url=//foo.com/bar.avi/streamid=0;seq=0; rtptime=0
S->C: END_OF_STREAM rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0
CSeq: 123
Session: 12345678
Range: npt=0-200; bytes=0-200000
RTP-Info: url=//foo.com/bar.avi/streamid=0;seq=45102
Reason: End of range reached
C->S: RTSP/1.0 200 OK
CSeq: 123
Session: 12345678
In the END_OF_STREAM request, the client will learn that the server has
completed the stream as requested (as indicated by the "End of range
reached" Reason).
From the two RTP-Info headers, one in PLAY response, one in
END_OF_STREAM requst, 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, while the byte-range field
can optional inform the
client how much media data, in bytes, that the server has sent.
5. Security Considerations
Because there is only one new TEXT header, "Reason", added by our
new RTSP method,
the security considerations outlined in [RTSP_NEW] apply here as well.
6. IANA Considerations
A new method name, and its associated feature tag need to be registered
with IANA.
-- Method name: END_OF_STREAM
-- feature tag: method.eos
Normative References
[RTSP_NEW] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
"Real Time Streaming Protocol",
draft-ietf-mmusic-rfc2326bis-04.txt
[RTP_NEW] RFC3550 "Real-time Transport Protocol", July 2003
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 implementation 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 assignees.
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.
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 Corp.
10350 Science Center Dr., Suite 210
San Diego, CA 92127
email: zeng@pv.com
P. Greg Sherwood
PacketVideo Corp.
10350 Science Center Dr., Suite 210
San Diego, CA 92127
email: sherwood@pv.com
