[Community-allwww-cvs] www/2006/devdocs sod-rtsp-adaptation-signaling-02.txt, NONE, 1.1
jgordon at helixcommunity.org jgordon at helixcommunity.orgUpdate of /cvsroot/protocol/www/2006/devdocs
In directory cvs01.internal.helixcommunity.org:/tmp/cvs-serv9938
Added Files:
sod-rtsp-adaptation-signaling-02.txt
Log Message:
Include clarification and spelling fixes from various parties.
--- NEW FILE: sod-rtsp-adaptation-signaling-02.txt ---
RealNetworks
Statement of Design Damon Lanphear
sod-rtsp-adaptation-signaling-02.txt Business Products and Services
23 October 2006
RTSP Signaling Requirements for Activation of Server Rate Control
Abstract
This document defines the RTSP protocol interaction that is
required to enable server controlled rate adaptation for
RTSP/RDTv3 streaming. This document does not discuss the
implementation details of the described protocol interaction.
Lanphear [Page 1]
Statement of Design October 2006
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . 3
2. Design Overview . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Interaction. . . . . . . . . . . . . . . . . . 4
3.1. Advertising Adaptation . . . . . . . . . . . . . . . 4
3.2. Announcing Client Parameters . . . . . . . . . . . . 5
3.2.1. 3GPP Defined Headers. . . . . . . . . . . . . . . 7
3.2.2. Exclude Rules Header. . . . . . . . . . . . . . . 7
3.2.3. Stream Switch Header. . . . . . . . . . . . . . . 7
3.2.4. Feedback Level Header . . . . . . . . . . . . . . 7
3.3. Server Indication of Parameter Acceptance. . . . . . 8
3.4. Requirement for the Indication of Available
Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 8
4. References. . . . . . . . . . . . . . . . . . . . . . . 8
5. Contributing Authors. . . . . . . . . . . . . . . . . . 8
6. Changes . . . . . . . . . . . . . . . . . . . . . . . . 8
Lanphear [Page 2]
Statement of Design October 2006
1. Problem Statement
In the current Helix system the server may perform rate adaptation
independently of the client. Server rate adaptation is activated by
the server without explicit agreement from the client. Therefore,
both client and server side rate adaptation may occur simultaneously
for the same session. When this situation occurs, the server
ignores the client rate adaptation requests in favor of its own rate
adaptation.
Server controlled rate adaptation, whether it is for live or on-
demand sessions, is optimal only to the extent that both sides of
the client server connection agree to the required terms of the
adaptation scheme. In cases where server controlled rate adaptation
requires specific forms of feedback from the client, or where the
extent of adaptation is limited by the encoding parameters of the
session, the client and server must agree to only use adaptation
when all requirements are met. The alternative is for the server to
attempt rate control in the absence of robust feedback. While
possible, server driven rate control with minimal feedback is
clearly sub-optimal.
This document therefore addresses the problem of unambiguously
signaling that both the client and server agree to server controlled
rate adaptation and that sufficient information is communicated
during the feature negotiation to allow rate adaptation to occur
with minimal assumptions.
2. Design Overview
A mechanism for RTSP [RFC 2326] signaling of adaptation parameters
is being standardized by 3GPP in [3GPP 26.234] , which will be
implemented in the client and server through efforts to insure
system compliance with 3GPP Release 6. This mechanism is sufficient
to indicate that:
o The 3GPP Release 6 adaptation scheme will be employed
o The RTCP NADU APP feedback extension will be used during the
session.
o There will be an indicated frequency of RTCP NADU feedback
o There are specific operating bounds for the client buffer that
must be observed by the server.
This mechanism can therefore communicate that a rate adaptation
scheme will be employed, and what the parameters will be for the
Lanphear Section 2. [Page 3]
Statement of Design October 2006
rate adaptation session. Because the next generation helix client
and server will, over time, implement 3GPP R6 rate adaptation, this
mechanism can be reused with some extensions to achieve the stated
goal of providing a way to unambiguously activate server driven
adaptation for the Helix system.
The extension to the 3GPP scheme will in no way invalidate the 3GPP
adaptation exchange for either Helix or interoperable clients.
Rather, it will be used in place of the 3GPP signaling scheme when
3GPP adaptation is not a valid choice for example, when streaming via
RTSP/RDTv3.
The basic protocol mechanism is an offer/answer model implemented in
RTSP. The server advertises that it is capable of a particular
adaptation style in response to an RTSP DESCRIBE request, or when
the SDP file is generated by the server that will be providing the
session. If the client is capable of the advertised adaptation
style, it will respond with a header in RTSP SETUP that indicates
the parameters for the adaptation style on a per stream basis. The
server is responsible for echoing these parameters in the SETUP
response.
The advertised parameters, and the decision to use 3GPP adaptation,
or a subset of the adaptation is determined by the attributes of the
session and the capabilities of the client. The form the RTSP
conversation takes on a per session basis may therefore vary in ways
that will be defined in this document.
3. Protocol Interaction
This section describes the protocol interaction, header format, and
header definitions. It assumes the format and header definitions in
[3GPP 26.234] and adds an additional set of headers that will be
defined here. The protocol interaction defined in [3GPP 26.234]
will therefore not be repeated in this document.
3.1. Advertising Adaptation
The client issues an RTSP DESCRIBE on the given session content, and
the server responds with and RTSP DESCRIBE response that includes an
SDP description of the session content. When the server generates
the SDP description it must determine if it can perform rate
adaptation and what type of rate adaptation may be supported by the
requested content. If the content is defined as 3GPP content the
server must follow the signaling semantics defined in [3GPP 26.234]
If the content is to be streamed via RDT then the server must add an
Helix-Adaptation-Support attribute field of the syntax:
Lanphear Section 3.1. [Page 4]
Statement of Design October 2006
Helix-Adaptation-Support = "Helix-Adaptation-Support" ":"
1*DIGIT ; 0-1
A value of 1 indicates that the server supports Helix system server
driven rate adaptation for this session. A value 0 indicates that
the server will not support Helix system server driven rate
adaptation for this session. An example of the header used to
indicated server support of rate adaptation is given here. The
meaning of the RTSP conversation is defined in [RFC 2326]
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh at isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait
a=Helix-Adaptation-Support:1
The server may announce adaptation support using the 3GPP semantics
defined in [3GPP 26.234] but the client may elect to return the
helix specific adaptation headers in response. The client may elect
to do so only if it can not fully support 3GPP rate adaptation.
3.2. Announcing Client Parameters
If a client does not understand the Helix-Adaptation-Support header
or if it is not willing to accept server driven rate adaptation then
it can do nothing. The server must interpret the lack of response
to a Helix-Adaptation-Support announcement as indication that the
client does not accept server driven rate adaptation, and must
disable rate adaptation for that stream.
Lanphear Section 3.2. [Page 5]
Statement of Design October 2006
If the client is willing to accept server driven rate adaptation for
a stream of the given session, it indicates its acceptance with the
Helix-Adaptation RTSP header. The Helix-Adaptation header may be
sent with any of the RTSP verbs: SETUP, PLAY, OPTIONS, and
SET_PARAMETER.
The client may send multiple Helix-Adaptation headers for a given
stream. Subsequent Helix-Adaptation headers that contain the same
fields overwrite the values of the given fields from previous Helix-
Adaptation headers. The server must echo the exact header values
from the most recent Helix-Adaptation header in the response message
if it is willing to accept the new parameters. If the server fails
to echo the exact parameters, then both the client and server
implicitly agree not to engage in, or continue with, server driven rate
adaptation for that stream.
The Helix-Adaptation headers may also be additive. A subsequent
Helix-Adaptation header for a given stream may add parameters to the
stream adaptation configuration that were not present in the
previous Helix-Adaptation header.
The response header is Helix-Adaptation, and is to be set on a per
stream basis. The Helix-Adaptation header has the syntax:
Helix-Adaptation = "Helix-Adaptation:" adaptation-spec *(","
adaptation-spec)
adaptation-spec = stream-url ";" buffer-size-header ";"
target-time-header ";" exclude-rules-header ";" stream-switch-header
";" feedback-level-header
stream-url = "url" "=" url
buffer-size-header = "size" "=" *DIGIT
target-time-header = "target-time" "=" *DIGIT
exclude-rules-header = "exclude-rules" "=(" 1*DIGIT "," 1*DIGIT
"," ... ")"
stream-switch-header = "stream-switch" "=" 1*DIGIT ; 0-1
feedback-level-header = "feedback-level" "=" 1*DIGIT ; 0-1
An example of the Helix-Adaptation header is as follows:
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Lanphear Section 3.2. [Page 6]
Statement of Design Draft October 2006
Transport: RTP/AVP;unicast;client_port=4588-4589
Helix-Adaptation:
url="rtsp://example.com/foo/bar/baz.rm";size=14500;target-
time=5000;exclude-rules=(3,4,7,8);stream-switch=1;feedback-
level=0
3.2.1. 3GPP Defined Headers
The headers: stream-url, buffer-size-header and target-time-header
are all inherited from [3GPP 26.234] and will inherit their meaning
and semantics from that specification. This specification does not
add any additional meaning to those parameters other than to require
their presence in the Helix-Adaptation header.
3.2.2. Exclude Rules Header
The purpose of the exclude-rules-header is to indicate which ASM
rules may be used in rate adaptation. The vector in the value field
is an N-tuple in which each element is the rule number to be
excluded from adaptation for the associated stream. The associated
stream is that which has been indicated in the RTSP SETUP message
that contains the Helix-Adaptation header.
The exclude-rules-header is optional. If no exclude-rules-header is
present, then the server may assume that any rule may be used on
rate adaptation for the given stream. If the exclude-rules-header
is present then the server must not use any of the exluded rules for
rate adaptation on the given stream.
3.2.3. Stream Switch Header
The purpose of the stream switch header is to indicate that rate
adaptations beyond the initial subscription are permitted by the
client. The header is optional. If the header is not present, the
server may assume that it may adapt the stream within the bounds
permitted by the exclude-rules-header. If the header is present,
and set to 0, then the server must select the initial rate and may
not change that rate through the course of the session. If the
header is 1, then the server may adapt the rate.
3.2.4. Feedback Level Header
The purpose of the feedback-level-header is to indicate if the
client will provide buffer state feedback via either RTCP NADU APP
packets defined in [3GPP 26.234] or via RDTv3. The feedback type is
determined by the transport selected in the RTSP SETUP exchange. The
feedback-level-header is optional. If the header is not present the
server assumes that there will be feedback via either RTCP NADU or
Lanphear Section 3.2.4. [Page 7]
Statement of Design Draft October 2006
RDTv3. If the header is present, a value of 0 indicates that no
buffer state feedback is available. If the header is present and
the value 1 then the client will provide buffer state feedback.
3.3. Server Indication of Parameter Acceptance
The server may indicate either acceptance or rejection of rate
adaptation responsibilities of each stream. The server may not
attempt a negotiation of the feature set and parameters announced by
the client. If the server accepts the feature set and
parameters announced by the client then it must echo the same Helix-
Adaptation header that was sent by the client. The echo must be sent
in the RTSP SETUP response.
If the server does not echo the Helix-Adaptation header, then the
client must assume that the server will not perform rate adaptation
of any kind for the given stream. On the contrary, the client must
assume that the server will perform rate adaptation on the given
stream if the header echo is present, and act accordingly.
3.4. Requirement for the Indication of Available Bandwidth
If the client accepts the indicated rate adaptation method announced
by the server, and announces this acceptance through the Helix-
Adaptation SETUP header then the client must also indicate the
available bandwidth on the operating channel. The client may use
either the Bandwidth header defined in [RFC 2326] or the Link-Char
header defined in [3GPP 26.234] This specification places no
restrictions on which RTSP message must contain the bandwidth
announcement. The server must obey the announced bandwidth as the
optimal capacity of the channel, and use the announced bandwidth to
select the inital stream for the session.
Clients should send either the Bandwidth header defined in [RFC 2326]
or 3GPP Link-Char headers mid-stream as defined in TS 26.234 when the link
characteristics change in order to inform the server immediately of known
large-scale changes such as network handovers.
4. References
[RFC 2326]
Real Time Streaming Protocol (RTSP);
http://www.ietf.org/rfc/rfc2326.txt
[3GPP 26.234]
Transparent end-to-end streaming service; Protocols and codecs;
http://www.3gp.org/ftp/Specs/html-info/2634.htm
5. Contributing Authors
Lanphear Section 5. [Page 8]
Statement of Design October 2006
Damon Lanphear
<damonlan at real.com>
Milko Boic
<milko at real.com>
Go Hori
<ghori at real.com>
Jamie Gordon
<jgordon at real.com>
6. Changes
6.1 Version 01 - May 2006:
Updated OBSN references to NADU in keeping with 3GPP TS 26.234.
6.2 Version 02 - October 2006:
Updated the following sections for clarification purposes only: Abstract;
Section 2; Section 3.1; Section 3.2; Section 3.4.
Lanphear Section 6. [Page 9]