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