Internet DRAFT - draft-wei-mmusic-rtsp-bitrate-header
draft-wei-mmusic-rtsp-bitrate-header
MMUSIC WG Kylin Wei
Internet-Draft Huawei Technologies
Expires: December 12, 2006 June 12, 2006
Bitrate header in RTSP
draft-wei-mmusic-rtsp-bitrate-header-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 November 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document presents an integrated solution for multiple bitrates
by defining the Bitrate header in RTSP. A client can inquire bitrate
range of media source after a successful SETUP request by sending a
GET_PARAMETER request with the bitrate parameter to the RTSP server,
and then server responds with bitrate range parameter of media
source. According to bitrate range parameter value, the client MAY
apply for bandwidth reservation by RSVP (Resource Reservation
Protocol) [5] or apply for increasing access bandwidth. The client
MAY select a suitable bitrate to start with or change transport
bitrate during the playing by sending a PLAY request with the Bitrate
header.
Kylin Wei Expires: December 12, 2006 [Page 1]
Internet-Draft Bitrate header in RTSP June 12, 2006
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................4
3. "Bitrate" header and "bitrate" parameter definitions...........5
4. The difference between "a=alt"
and "Bitrate" in media description..........................5
5. Use Cases......................................................7
5.1. Inquire bitrate range......................................7
5.2. Changing transport bitrate.................................8
5.2.1. Single media file......................................8
5.2.2. Multiple media files...................................9
6. Security Considerations.......................................10
7. IANA Considerations...........................................11
8. Acknowledges..................................................12
9. References....................................................10
9.1. Normative References......................................13
9.2. Informative References....................................13
Author's Address..................................................14
Intellectual Property and Copyright Statements....................15
Kylin Wei Expires: December 12, 2006 [Page 2]
Internet-Draft Bitrate header in RTSP June 12, 2006
1. Introduction
There are two obvious problems in QOS (Quality of Service) of video
on-demand now.
First, the network condition of the internet isn't reliable because
the bandwidth and the load of internet often change acutely. But the
transport bitrate of media source is constant. So it will affect the
quality of video on-demand such as delay and jitter.
Second, the actual access bandwidths of many subscribers who order
the same media program are different. Such as the access bandwidths
of some subscribers are tens of Mbps, and others may be hundreds of
Kbps. But media source only has one bitrate, so some users with
high access bandwidth can't get better video quality and some
users with very low access bandwidth have not enough bandwidth to
watch video. So it's necessary that media source can provide more
than one bitrate to adapt to complex network condition.
Media source has two methods to provide multiple bitrates.
First, the simplest way is that media server prepares several media
files for the same media program. The bitrates of these files are
different from each other. The server could redirect a client to a
corresponding media file (URI) according to the client's selection on
the bitrate.
Second, some scalable coding and multi-rate coding technologies are
presented. By using these two kinds of technologies, one media file
can provide multiple bitrates. As technology progresses, future
advanced video codec can provide a large number of bitrates within
one media file.
RTSP should provide a way that a client can inquire bitrate range of
media source and the client can change transport bitrate at any time.
This specification defines the Bitrate header to solve this problem.
If a client wants to inquire the bitrate range of media source, it
SHOULD send a GET_PARAMETER request with the bitrate parameter after
a success SETUP request unless the client does not plan to adjust
transport bitrate. When RTSP server receives this request, it will
respond bitrate range values in the bitrate parameter field.
Kylin Wei Expires: December 12, 2006 [Page 3]
Internet-Draft Bitrate header in RTSP June 12, 2006
After the client got the bitrate parameter value, it can take action
according to the bitrate parameter value. For example, bitrate
parameter is "512K, 1M, 2M", but access bandwidth of a subscriber
is 0.5Mbps, the subscriber could temporarily apply for more access
bandwidth in the service gateway from 0.5Mbps to 1Mbps or 2Mbps, and
original access bandwidth would be restored after two hours. This
action may be common use in the community video on-demand and IPTV.
If video on-demand occurs on the internet, to get a steady network
bandwidth, a subscriber can apply for bandwidth reservation by RSVP.
For instance, the bitrate parameter is "1M, 2M, 3M", and the
subscriber can apply for reserving 2Mbps bandwidth to specified
media stream. A user may also directly select a suitable bitrate to
start with according to his evaluation of current network
condition and access bandwidth. For instance, the user may select
2Mbps bitrate because subscriber access bandwidth is 2.5Mbps.
Other important use case is that a user can change transport bitrate
during the play. For example, a user has played a movie for ten
minutes, and he felt that the video starts to show slowly. He
thought that congestion may occur in current network, so he
selected a lower bitrate on his own initiative. Such as bitrate
parameter is "1M, 2M, 3M", he changed transport bitrate from 2Mbps
to 1Mbps.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [1].
Kylin Wei Expires: December 12, 2006 [Page 4]
Internet-Draft Bitrate header in RTSP June 12, 2006
3. "Bitrate" header and "bitrate" parameter definitions
The bitrate parameter is used by a client to inquire bitrate range
of media source. A GET_PARAMETER request with the bitrate parameter
indicates that a client want to inquire bitrate range of media
source. The Bitrate header is used to change transport bitrate. A
PLAY request with the Bitrate header indicates that a client
want to change transport bitrate. Bitrate header filed value MUST be
one value of bitrate range of media source.
The bitrate parameter may be several separate values such as
"512K, 1M, 2M", and may also be a continuous range value such as
"512K-2.5M".
Syntax:
HCOLON, CRLF, COMMA and DIGIT are defined in rfc2326bis [2].
Bitrate header:
Bitrate = "Bitrate" HCOLON bitrate-value CRLF
bitrate parameter:
bitrate = "bitrate" HCOLON bitrate-sep / bitrate-con CRLF
bitrate-sep = bitrate-value *(COMMA bitrate-value)
bitrate-con = bitrate-value "-" bitrate-value
bitrate-value = (1*DIGIT "K") / (1*DIGIT [ "." 1*DIGIT] "M")
4. The difference between "a=alt" and "Bitrate" in media description
"a=alt" attribute had been defined in 3GPP TS 26.234 [6] used to
present some alternative bitrates and then client can use the URI to
indicate which alternative bitrate it wishes to start with.
Sometimes it will result in a large SDP body [4]. For example,
advanced video codec which can provide a large number of bitrates
within one media file will be presented. If a media file can present
hundreds or thousands of bitrates, by using "a=alt" attribute, server
must offer all these alternative bitrates and their private
description to the client. Then SDP which the client wishes to
receive will become very large and redundant.
A better plan is that the server should only offer the default
alternative bitrate within one media description in the DESCRIBE
Kylin Wei Expires: December 12, 2006 [Page 5]
Internet-Draft Bitrate header in RTSP June 12, 2006
response. The private description of other alternatives will be
offered when only this alternative is going to be used. A client
SHOULD inquire bitrate range after a successful SETUP request. The
server then respond with bitrate parameter value of the media file.
If the client wants to change transport bitrate, it will send a PLAY
request with Bitrate header field. Server then changes transport
bitrate as the client wanted and then appends necessary description
of this bitrate into the PLAY response.
Follow example is a simple contrast. Unnecessary details are omitted
for clarity in this example.
Using "a=alt" attribute
v=0
o=ericsson_user 1 1 IN IP4 130.240.188.69
s=A basic video presentation
c=IN IP4 0.0.0.0
b=AS:44
a=control:*
a=alt-group:BW:AS:16="3",44="4",104="5"
a=range:npt=0-150.2
t=0 0
m=video 0 RTP/AVP 98
b=AS:44
a=rtpmap:98 MP4V-ES/90000
a=control:trackID=4
a=fmtp:98 profile-level-id=8; config=01010000012000884006682C2090A21F
a=range:npt=0-150.2
a=X-initpredecbufperiod:98000
a=alt-default-id:4
a=alt:3:b=AS:16
a=alt:3:a=control:trackID=3
a=alt:3:a=X-initpredecbufperiod:48000
a=alt:5:b=AS:104
a=alt:5:a=control:trackID=5
a=alt:5:a=X-initpredecbufperiod:150000
Using Bitrate header
v=0
o=ericsson_user 1 1 IN IP4 130.240.188.69
s=A basic video presentation
c=IN IP4 0.0.0.0
b=AS:44
Kylin Wei Expires: December 12, 2006 [Page 6]
Internet-Draft Bitrate header in RTSP June 12, 2006
a=control:*
a=range:npt=0-150.2
t=0 0
m=video 0 RTP/AVP 98
b=AS:44
a=rtpmap:98 MP4V-ES/90000
a=control:trackID=4
a=fmtp:98 profile-level-id=8; config=01010000012000884006682C2090A21F
a=range:npt=0-150.2
a=X-initpredecbufperiod:98000
C->S SETUP rtsp://media.example.com/examples/3G_systems.3gp
/trackid=4
S->C 200 OK
C->S GET_PARAMATER rtsp://media.example.com/examples/3G_systems.3gp/
trackid=4
bitrate
S->C 200 OK
bitrate: 44K, 16K, 104K
C->S PLAY rtsp://media.example.com/examples/3G_systems.3gp/trackid=4
Bitrate: 104K
S->C 200 OK
Bitrate: 104K
x-initpredecbufperiod: 150000
5. Use Cases
5.1. Inquire bitrate range
After a successful SETUP request, a client SHOULD send a
GET_PARAMATER request with the bitrate parameter to inquire bitrate
range of media source unless the client does not plan to adjust
transport bitrate. If RTSP server doesn't support the bitrate
parameter, it MUST respond error 451(Parameter Not Understood) or
other error code. Otherwise it MUST respond 200 OK followed by
the bitrate parameter value.
Example:
C->S: GET_PARAMETER rtsp://example.com/movie/ring.avi RTSP/2.0
CSeq: 210
Kylin Wei Expires: December 12, 2006 [Page 7]
Internet-Draft Bitrate header in RTSP June 12, 2006
Content-Type: text/parameters
Session: mymovie
Content-Length: 9
bitrate
S->C: RTSP/2.0 200 OK
CSeq: 210
Session: mymovie
Content-Length: 27
Content-Type: text/parameters
bitrate: 512K, 1M, 2M, 3M
After the client got the bitrate parameter value, it MUST record
these values and show these values to the user.
5.2. Changing transport bitrate
After getting the bitrate parameter value, a user can change
transport bitrate at any time. The process of changing transport
bitrate of single media file is different from that of multiple
media files.
The Range header is RECOMMENDED to indicate time range of playing
program with modified transport bitrate. If a movie has been played
for a long time before changing transport bitrate, the client SHOULD
start playing from current time point with modified transport
bitrate.
5.2.1. Single media file
This kind of media file should be encoded by multi-rate coding
technology so that it has multiple bitrates. When RTSP server
received a client's PLAY request with the Bitrate header, it SHOULD
change transport bitrate according to the Bitrate header values. If
RTSP server doesn't support the Bitrate header, it MUST respond
error 456(Header Field Not Valid) or other error code.
If the request of changing transport bitrate can be implemented by
server, the private description of new transport bitrate SHOULD be
appended into the PLAY response to report to the client unless there
isn't necessary private description.
The following example will replay from the tenth second by 512Kbps
bitrate:
Kylin Wei Expires: December 12, 2006 [Page 8]
Internet-Draft Bitrate header in RTSP June 12, 2006
C->S: PLAY rtsp://example.com/movie/ring.avi RTSP/2.0
CSeq: 20
User-Agent: PhonyClient/1.2
Bitrate: 512K
Range: npt=10-
Session: mymovie
S->C: RTSP/2.0 200 OK
CSeq: 20
Server: PhonyServer/1.0
Date: 2 Feb 2006 18:00:00 GMT
Session: mymovie
Bitrate: 512K
Range: npt=0-5400
RTP-Info: url="rtsp://example.com/movie/ring.avi"
ssrc=0E756890:seq=7892;rtptime=78905432
5.2.2. Multiple media files
Sometimes there are multiple media files of the same program. They
have the same content but their bitrates are different. Such as
there are four media files (ring_1.avi, ring_2.avi, ring_3.avi,
ring_4.avi) for movie "Ring". Their bitrates are 4Mbps, 2Mbps, 1Mbps
and 512Kbps. To avoid a large SDP body, we SHOULD only offer the
default media file to a client such as ring_2.avi (2Mbps). RTSP
server MUST understand all these information in advance.
When a client requests changing transport bitrate, RTSP server
responds 200 OK and then redirects the client to a corresponding URI.
Example:
C->S: PLAY rtsp://example.com/movie/ring_2.avi RTSP/2.0
CSeq: 200
User-Agent: PhonyClient/1.2
Bitrate: 512K
Range: npt=10-
Session: mymovie
S->C: RTSP/2.0 200 OK
CSeq: 200
Server: PhonyServer/1.0
Date: 2 Feb 2007 18:00:00 GMT
Kylin Wei Expires: December 12, 2006 [Page 9]
Internet-Draft Bitrate header in RTSP June 12, 2006
Session: mymovie
Bitrate: 512K
Range: npt=0-5400
RTP-Info: url="rtsp://example.com/movie/ring_2.avi"
ssrc=0E756890:seq=7892;rtptime=78905432
S->C: REDIRECT rtsp://example.com/movie/ring_2.avi RTSP/2.0
CSeq: 201
Location: rtsp://example.com/movie/ring_4.avi
Range: npt=10- ;time=20060509T103205Z
Session: mymovie
C->S: RTSP/2.0 200 OK
CSeq: 201
6. Security Considerations
The same security considerations apply as for the base RTSP
specification, as described in [3].
Kylin Wei Expires: December 12, 2006 [Page 10]
Internet-Draft Bitrate header in RTSP June 12, 2006
7. IANA Considerations
It is request of IANA to register the "Bitrate" header in the RTSP
1.0 registry at:
http://www.iana.org/assignments/rtsp-parameters.
Contact name: kylin Wei (weiqikun@huawei.com).
Header Name: Bitrate
Purpose: See Section 3
Methods: PLAY Request and Response
Reference: Section 3
Values: See Reference
Kylin Wei Expires: December 12, 2006 [Page 11]
Internet-Draft Bitrate header in RTSP June 12, 2006
8. Acknowledges
Thanks Spencer Dawkins for providing his valuable advices for this
document. Thanks for the discussions from Jaehwan Kim, Colin Perkins
and Magnus Westerlund. Thanks Philippe Gentric for providing his
draft about stream-switching.
Kylin Wei Expires: December 12, 2006 [Page 12]
Internet-Draft Bitrate header in RTSP June 12, 2006
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] H. Schulzrinne, A. Rao, R. Lanphier, Magnus Westerlund,
A. Narasimhan, "Real Time Streaming Protocol 2.0 (RTSP)",
draft-ietf-mmusic-rfc2326bis-12, March 2006.
[3] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[4] M. Handley, V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
9.2. Informative References
[5] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[6] 3GPP TS 26.234 "Transparent end-to-end Packet-switched
Streaming Service (PSS); Protocols and codecs" (Release 6)
version 6.7.0 (2006-03), 3rd Generation Partnership Project
(3GPP)
Kylin Wei Expires: December 12, 2006 [Page 13]
Internet-Draft Bitrate header in RTSP June 12, 2006
Author's Address
Kylin Wei
Huawei Technologies
NanJing Institute,Huawei Technologies Co.,Ltd.
Floor 10, HuiHong Mansion, No.91 BaiXia Rd.
NanJing, P.R. of China
Phone: +86 25 8456 5404
Email: weiqikun@huawei.com
URI: www.huawei.com
Kylin Wei Expires: December 12, 2006 [Page 14]
Internet-Draft Bitrate header in RTSP June 12, 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kylin Wei Expires: December 12, 2006 [Page 15]
