Internet DRAFT - draft-hayano-rtsp-bitrate
draft-hayano-rtsp-bitrate
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]
