MMUSIC H. Hatano Internet-Draft K. Taniguchi Intended status: Standards Track A. Kobayashi Expires: January 14, 2010 NEC Corp. M. Stiemerling NEC Europe Ltd. July 13, 2009 RTSP 2.0 Bitrate Notification draft-hayano-rtsp-bitrate-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 January 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Hatano, et al. Expires January 14, 2010 [Page 1] Internet-Draft Bitrate Notification July 2009 Abstract Typically, there is no use for providing bandwidth information from an RTSP 2.0 server to RTSP 2.0 clients. The bandwidth of the medias played out by the server is different from the available bandwidth in the network (which is also changing) and there is anyhow the need to perform congestion control during media playout. This is true for Internet deployments, or similar, but conveying information about bandwidth of the medias can be required in other deployments of RTSP 2.0. It might necessarily for RTSP 2.0 clients to obtain information about the by medias used bandwidth in networks that rely on bandwidth reservation initiated by the end host. An example is the Next Generation Network (NGN) standardized by ETSI TISPAN, where RTSP 2.0 clients must indicate the required bandwidth to the network. This memo discusses how to provide bandwidth information from RTSP 2.0 servers to clients and how to introduce it in RTSP 2.0. Hatano, et al. Expires January 14, 2010 [Page 2] Internet-Draft Bitrate Notification July 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Current Implementations . . . . . . . . . . . . . . . . . 4 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Solution Proposal . . . . . . . . . . . . . . . . . . . . . . 7 4. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Hatano, et al. Expires January 14, 2010 [Page 3] Internet-Draft Bitrate Notification July 2009 1. Introduction Typically, there is no use for providing bandwidth information from an RTSP 2.0 server to RTSP 2.0 clients. The bandwidth of the medias played out by the server is different from the available bandwidth in the network (which is also changing) and there is anyhow the need to perform congestion control during media playout. This is true for Internet deployments, or similar, but conveying information about bandwidth of the medias can be required in other deployments of RTSP 2.0. It might necessarily for RTSP 2.0 clients to obtain information about the by medias used bandwidth in networks that rely on bandwidth reservation initiated by the end host. An example is the Next Generation Network (NGN) standardized by ETSI TISPAN [ETSI-183-063], where RTSP 2.0 clients must indicate the required bandwidth to the network. This memo discusses how to provide bandwidth information from RTSP 2.0 servers to clients and how to introduce it in RTSP 2.0. Some IPTV deployments that are using the Real Time Streaming Protocol (RTSP) require the ability of the server to notify clients about the used bitrate occurring during an RTSP session. This information can be send at the start of a session or during an already established session. However, past discussions in the MMUSIC WG concluded that a bitrate notification from the server to client is of no use, as: o the streaming server and RTSP server can be separated, so that the RTSP server does not have any knowledge about the bitrate; o the bitrate sent at the server is not necessary the same as the client receives, as there might be cases when parts of the stream get lost in the network (e.g., congestion or not enough bandwidth anyhow due to low bandwidth links); o a bitrate does not release the client/server from performing congestion control on the media streams (see Section C.3. [I-D.ietf-mmusic-rfc2326bis] for similar initial considerations). There is no means right now in RTSP 2.0 to tell clients about the used bandwidth. The remainder of this document discusses same state of the art in the space of RTSP 1.0 with respect to bitrate notification in Section 1.1. Section 2 describes the intended use case and Section 3 sketches an early solution. 1.1. Current Implementations To our knowledge there is at least one implementation of the bitrate header. The Hikari Service Architecture (HSA), which is using RTSP 1.0 [RFC2326] , defines bitrate parameter in Transport header. It can notify a client of a bitrate of contents from a server by the Hatano, et al. Expires January 14, 2010 [Page 4] Internet-Draft Bitrate Notification July 2009 response of SETUP. This specification is implemented by HSA RTSP vendors. HSA was developed by the Hikari Service Architecture Consortium (HSAC, [HSAC]) in Japan. NB: The consortium itself was closed, as the service specification was completed, and the specification is currently used. There are also standards bodies working on bitrate notifications from server to clients in RTSP. For instance, ETSI TISPAN method 2-2 ([ETSI-183-063]) is using the message body (SDP) in the response of DESCRIBE to notify the client about the bitrate. Hatano, et al. Expires January 14, 2010 [Page 5] Internet-Draft Bitrate Notification July 2009 2. Use Case There is a use case when bitrate notification is beneficial. In certain deployments, clients have to tell the network the required bandwidth via a resource reservation (e.g., ETSI TISPAN NGN [ETSI-183-063]). In this case, RTSP servers are not able to tell the required bandwidth to the network, but the client can. Therefore, there is the need to notify the clients about the required bandwidth. However, this holds only true for the described case and does not apply to the general Internet use case. ,---. ,' `. +------+ / Network \ +------+ | RTSP |<---------------->| RTSP | | Media|.................>|Client| |Server| : <~~~~| | +------+ \ (NGN) / +------+ `. ,' '---' <--> RTSP signaling ...> Media transport <~~> Bandwidth Reservation Signaling This notification can be required on startup and during a session. An example for changing of bandwidth during a session is the use of playlists. The bandwidth of each entry in a play list might be different and the client should be able to make a bandwidth reservation according to the bitrate of the particular content to improve the use efficiency in a network bandwidth. A play list could, for instance, consist out of: o A movie with 6 MBit per second, interrupted by o advertisements with 12 MBit per second, and so on. Hatano, et al. Expires January 14, 2010 [Page 6] Internet-Draft Bitrate Notification July 2009 3. Solution Proposal The bitrate is a property of the media delivered and so it seem natural to include the information about the bitrate in the media- property header. (see Section 16.29 [I-D.ietf-mmusic-rfc2326bis]). The media-property header can be included in the response to SETUP and in PLAY_NOTIFY and thus fulfills the need of getting bandwidth information delivered from a server to client at the appropriate time. The bitrate can be expressed in two values, as bitrate of the media without any transport specific headers (i.e., purely the media, e.g., MPEG2) and as bitrate on the wire (i.e., media encapsulated with transport specific header, e.g., RTP/UDP/IP). The bitrate of the media is called media-bitrate and the bitrate on the wire is called transport-bitrate for the remainder of this memo. It is good to have both information provided by the server to the client, as the client probably cannot determine the transport-bitrate from the meida- bitrate at all events, or vice versa. Adding bitrate field to media-properties requires a change of the syntax by using the media-prob-ext (taken from [I-D.ietf-mmusic-rfc2326bis]): Media-Properties = "Media-Properties" HCOLON media-prop-list media-prop-list = media-prop-value *(COMMA media-prop-value) media-prop-value = ("Random-Access" [EQUAL POS-FLOAT]) / "Begining-Only" / "No-Seeking" / "Unmutable" / "Dynamic" / "Time-Progressing" / "Unlimited" / ("Time-Limited" EQUAL utc-range-spec) / ("Time-Duration" EQUAL POS-FLOAT) / media-prop-ext media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)] The media-prob-ext is extended this way to carry the bitrate. The media-bitrate and the transport-bitrate is measured in bits per second: ("Media-Bitrate" EQUAL POS-FLOAT) ("Transport-Bitrate" EQUAL POS-FLOAT) NOTE WELL: However, it should be noted that these bitrate fields can be used in limited deployment scenarios and cannot be used in the open Internet! Hatano, et al. Expires January 14, 2010 [Page 7] Internet-Draft Bitrate Notification July 2009 Editor's: need to clarify the relationship to Bandwidth parameter in [I-D.ietf-mmusic-rfc2326bis] Hatano, et al. Expires January 14, 2010 [Page 8] Internet-Draft Bitrate Notification July 2009 4. Usage Example This section is showing one possible usage example for bitrate. The example combines the usage in response messages and also for PLAY_NOTIFY. Note that (*1) and (*2) link to a later explanation. Client Server | | | SETUP | |--------------------------->| | 200OK(*1) | |<---------------------------| | PLAY | |--------------------------->| | 200OK | |<---------------------------| | | |<=======Media Stream========| | (Bitrate of contens=8Mbps) | | | | PLAY_NOTIFY(*2) | |<---------------------------| | 200OK | |--------------------------->| | | |<=======Media Stream========| | (Bitrate of contens=2Mbps) | *1:RTSP server sends 200OK response of SETUP that includes Media- Properties header. This Media-Properties header includes Bitrate parameter to notify bitrate of contents. Here is the message content sent from the server to the client marked (*1): Server -> Client : RTSP/2.0 200 OK CSeq: 852 Date: Tue, 14 Apr 2008 15:35:06 GMT Session: uZ3ci0K+Ld-M;timeout=60 Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/ "192.0.2.53:4589"; src_addr="192.0.2.241:6256"/ "192.0.2.241:6257"; ssrc=2A3F93ED Accept-Ranges: NPT Media-Properties: Random-Access=5.0, Dynamic,/ Time-Duration=3600.0, Media-Bitrate=8000000 *2:When bitrate of contents changes (e.g., play-list playout), RTSP server sends PLAY_NOTIFY request that indicates bitrate change. This Notify-Reason of PLAY_NOTIFY uses media-properties-update, and Media- Properties header includes Bitrate parameter to notify new bitrate of Hatano, et al. Expires January 14, 2010 [Page 9] Internet-Draft Bitrate Notification July 2009 contents.Here is the message content sent from the server to the client marked (*2): Server -> Client : PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 Date: Tue, 14 Apr 2008 15:48:06 GMT CSeq: 854 Notify-Reason: media-properties-update Session: uZ3ci0K+Ld-M Media-Properties: Random-Access=5.0, Dynamic,/ Time-Duration=3600.0, Media-Bitrate=2000000 Range: npt=0:15:00.000- Hatano, et al. Expires January 14, 2010 [Page 10] Internet-Draft Bitrate Notification July 2009 5. Security Considerations This initial version of this memo does not yet have any security considerations, but they will be added with one of the next revision. Hatano, et al. Expires January 14, 2010 [Page 11] Internet-Draft Bitrate Notification July 2009 6. Conclusion This memo is work in progress and is requesting feedback from the MMUSIC working group. However, it should be noted well that using the bitrate header is limited to controlled environments only (see also see Section C.3. of [I-D.ietf-mmusic-rfc2326bis]), as notification of bitrate from a server to a client does usually not have real meaning (see also Section 1). RTSP defines a Bandwidth header (see Section 16.8 of [I-D.ietf-mmusic-rfc2326bis]) that "The Bandwidth request-header field describes the estimated bandwidth available to the client.", i.e., it is a client estimate about it's locally available bandwidth and is not tight to any bitrate of the media playout from the server. Hatano, et al. Expires January 14, 2010 [Page 12] Internet-Draft Bitrate Notification July 2009 7. References 7.1. Normative References [I-D.ietf-mmusic-rfc2326bis] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, "Real Time Streaming Protocol 2.0 (RTSP)", draft-ietf-mmusic-rfc2326bis-21 (work in progress), June 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [ETSI-183-063] ETSI TISPAN, "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification", June 2008. [HSAC] "Hikari Service Architecture Consortium", Web Site http:// web.archive.org/web/20040518075704/http:// www.hikari-sac.org/, October 2007. [Hikari] "Hikari Service Architecture", Web Site http:// www.itu.int/itudoc/itu-t/com13/ipexpert/ipmedia/ 71304_pp7.ppt, October 2007. [I-D.ietf-mmusic-rtsp-announce] Zeng, T., "RTSP Announce Method", draft-ietf-mmusic-rtsp-announce-01 (work in progress), February 2005. [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. Hatano, et al. Expires January 14, 2010 [Page 13] Internet-Draft Bitrate Notification July 2009 Authors' Addresses Hiroyuki Hatano NEC Corporation 11-5 Shibaura 2-chone Minato-ku, Tokyo 108-8557 Japan Phone: +81 3 5476 1084 Email: h-hatano@aj.jp.nec.com Kunihiro Taniguchi NEC Corporation 1753 Shimonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 Japan Phone: +81 44 431 7661 Email: Email: k-taniguchi@da.jp.nec.com Akira Kobayashi NEC Corporation 11-5 Shibaura 2-chone Minato-ku, Tokyo 108-8557 Japan Phone: +81 3 5476 1084 Email: a-kobayashi@ce.jp.nec.com Martin Stiemerling NEC Laboratories Europe Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 113 Fax: +49 6221 4342 155 Email: stiemerling@nw.neclab.eu URI: http://www.nw.neclab.eu/ Hatano, et al. Expires January 14, 2010 [Page 14]