RTSP Extension for Substream Control
draft-yue-mmusic-rtsp-substream-control-extension-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Peiyu Yue | ||
| Last updated | 2011-10-20 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yue-mmusic-rtsp-substream-control-extension-00
mmusic P. Yue
Internet-Draft Huawei Technologies
Intended status: Standards Track October 21, 2011
Expires: April 23, 2012
RTSP Extension for Substream Control
draft-yue-mmusic-rtsp-substream-control-extension-00
Abstract
This document defines extensions to RTSP 2.0 protocol, including
header "Substream", feature tag "Play.substream" , and related new
status codes. These extensions enables the playback control of a
media stream on substream basis.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 23, 2012.
Copyright Notice
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Yue Expires April 23, 2012 [Page 1]
Internet-Draft RTSP Extension for Substream Control October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions and Abbreviations . . . . . . . . . . . . . . 3
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4
4.1. Substream Annotation . . . . . . . . . . . . . . . . . . . 4
4.2. Capability Negotiation . . . . . . . . . . . . . . . . . . 5
4.3. Substream Playback Control . . . . . . . . . . . . . . . . 5
4.3.1. Play a Substream . . . . . . . . . . . . . . . . . . . . . 5
4.3.2. Pause a Substream . . . . . . . . . . . . . . . . . . . . 7
5. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . 7
5.1. Substream Header . . . . . . . . . . . . . . . . . . . . . 7
5.2. Play.substream Feature Tag . . . . . . . . . . . . . . . . 8
5.3. Status Code Extension . . . . . . . . . . . . . . . . . . 8
5.3.1. 552 Substream Type Not Recognized . . . . . . . . . . . . 8
5.3.2. 553 Substream Control Not Allowed . . . . . . . . . . . . 8
5.3.3. 554 Substream Id Not Valid . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 9
7.1. RTSP Feature-tag Extensions . . . . . . . . . . . . . . . 9
7.2. RTSP Status Code Extension . . . . . . . . . . . . . . . . 9
7.3. RTSP Header Extensions . . . . . . . . . . . . . . . . . . 10
7.4. Hold of Substream Type Registration . . . . . . . . . . . 10
7.4.1. Guidance of Substream Type Registration . . . . . . . . . 10
7.4.2. Registration of Substream Types . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . 11
Yue Expires April 23, 2012 [Page 2]
Internet-Draft RTSP Extension for Substream Control October 2011
1. Introduction
Single Session Transmission (SST) is recommended for the SVC (
Scalable Video Codec) video transport [RFC6190] and MVC (Multiview
Video Codec) video transport [I-D.ietf-payload-rtp-mvc] . In SST, a
single RTP session conveys all the related media data, namely all the
bitstream components. A bitstream component here is part of a media
stram that has a common property which could be:
o Layer: in SVC media stream; In this case, a bitstream component is
media data of a specific layer.
o View: in MVC media stream; In this case, a bitstream component is
media data of a specific view.
In such a SST session,one or several bitstream components together
may be decodable by themselves and therefore make sense to the
receiver. These bitstream component(s) combinations are here called
Substream.
In SVC and MVC RTP sessions, such a Substream is identified by an
Operation Point.
There are cases that a client wants to retrieve a specific substream
in such a SST session. However, in the current RTSP 2.0 protocol,
the control of the media is on media stream basis, e.g. as an RTP
session when RTP is used. This prevents a client to receive only
certain substream(s) from the media.
This memo extends the RTSP 2.0[I-D.ietf-mmusic-rfc2326bis] to
establish a substream playback control framework, which enables a
client to play a part of a media stream.
This memo also defines the substream usage for SVC and MVC.
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 [RFC2119].
3. Definitions and Abbreviations
3.1. Definitions
The following terms are used in this document and have specific
meaning within the context of this document.
Yue Expires April 23, 2012 [Page 3]
Internet-Draft RTSP Extension for Substream Control October 2011
o Substream: a part of a media stream containing one or more
bitstream components, which can be independently decoded.
Typically a Substream is identified by one operation point.
o Substream type: the compound mode of the bitstream components in a
substream, e.g. SVC, MVC, etc
3.2. Abbreviations
SVC: Scalable Video Coding
MVC: Multiview Video Coding
SST: Single Session Transmission
4. Protocol Overview
The whole framework includes substream annotation, capability
negotiation and substream playback control. This section provides an
overview of substream control.
4.1. Substream Annotation
Substream annotation is used to announce identifiers for all
substreams available in a media stream. which can be retrieved
selectively. It is done through a presentation description,
typically using an SDP description. Substream annotation based on
SDP is described in this section. Substream annotation based on
other formats is out of scope of this document.
In SVC, a substream is described as an operation point, which
consists of the bitstream components required to be able to decode a
particular dependency_id, quality_id, and temporal_id combination.
SVC operation points are described through the sprop-operation-point-
info attribute in SDP as defined in [RFC6190].
According to [RFC6190], the value of sprop-operation-point-info
consists of a comma-separated list of operation-point-description
vectors. Each operation-point-description vector represents a
substream. Each operation-point-description vector has ten
elements,where the first element layer-ID is the identifier of the
operation point. This layer-ID can be taken as the identifier for
the SVC substream. Since the layer-ID is optional, it may not be
included. In this case, a [dependency-ID, temporal_ID, quality-ID]
combination is taken as the identifier instead.
Annocation of MVC substreams is specified in
[I-D.ietf-payload-rtp-mvc].
editor notes: pending on the complement of
Yue Expires April 23, 2012 [Page 4]
Internet-Draft RTSP Extension for Substream Control October 2011
[I-D.ietf-payload-rtp-mvc].
4.2. Capability Negotiation
Capability negotiation can be used to negotiate support of substream
control between RTSP client and server. It makes use of the RTSP
feature tag mechanism defined in RTSP
2.0[I-D.ietf-mmusic-rfc2326bis]. A new feature tag (play.substream)
is defined in Section 5.2.
Whenever it has received a media presentation with substream
annotation, a substream control capable RTSP client SHALL include
play.substream in the SUPPORTED header of the RTSP SETUP request.
This indicates that the client is able to control the playback of the
media on substream basis.
A 2xx response implies that the server is capable of substream
control. A server MAY refuse the request with a 551 "Option not
supported" response, with an UNSUPPORT header including
play.substream.
The receiving client may try to setup a session without this feature
later. This means that the client will not perform substream control
and play the media as a whole. In the SVC case, the client will play
all the layers in the session, whereas in the MVC case it will play
all the views in the session.
4.3. Substream Playback Control
In case the session is setup correctly, the client may control the
play back on substream basis, including:
o start to play a substream
o pause a substream. Note that this means it will pause the play
back of the whole session.
4.3.1. Play a Substream
After successful set up of an RTSP session, the client may perform
substream playback control. The playback of a substream is similar
with the normal playback of a session, except that the PLAY request
shall contain a "SubstreamCtrl" header with substream type and the
substream id corresponding to the substream that the client intends
to play. Here the substream id idetifies a specific operation point.
The actual definition of the substream id is defined by each
substream type.
When more than one media stream are controlled, the header shall
further contain Request-URIs for each of the the substreams.
Yue Expires April 23, 2012 [Page 5]
Internet-Draft RTSP Extension for Substream Control October 2011
Following is the specification of substream types for SVC and MVC
media stream. Specification for other substream type is out of scope
of current document and should be registered in IANA, as described in
Section 7.4.
When the media stream is an SVC stream as defined in [RFC6190], the
substream type shall be "SVC"; The substream id could be either a
layer-id or a [dependency-ID, temporal_ID, quality-ID] combination,
which comes from an operation-point-description vector.
When the media stream is an MVC stream as defined in
[I-D.ietf-payload-rtp-mvc], the substream type shall be "MVC".
For MVC, substream id is...
editor's note: substream id for MVC is pending on the complement of
draft-ietf-payload-rtp-mvc-00.
A client should not perform substream play if the server has not
indicated support of substream control in an ealier message exchange.
Upon receiving a PLAY request with a "SubstreamCtrl" header, the
server SHALL identify the substream(s) according to the id(s) and
Request-URI(s) in the request, and then provides the indicated
substream(s) after sending a 200 OK response.
If the server doesn't support substream control, it should respond a
551 "Option not supported" response as defined in RTSP
2.0[I-D.ietf-mmusic-rfc2326bis].
If the server supports substream control but the substream type
indicated in the "SubstreamCtrl" header is not recognized, it shall
response wth a 552 "Substream Type Not Recognizable" response, see
Section 5.3.1.
If the server supports substream control but the substream type
indicated in the "SubstreamCtrl" header is not recognized, it shall
response wth 552 "Substream Type Not Recognizable", see
Section 5.3.1.
If a requested media is not allowed to be played on substream basis
as requested, the server SHALL respond with a 553 "Substream Control
Not Allowed" response, see Section 5.3.2.
If the requested substream id is not valid, the server shall response
with 554 "Substream id not valid", see Section 5.3.3.
Yue Expires April 23, 2012 [Page 6]
Internet-Draft RTSP Extension for Substream Control October 2011
4.3.2. Pause a Substream
The pause operation of a substream is identical to the pause
operation of a normal session. It is not necessary for the client to
include a "SubstreamCtrl" header in the pause request message.
However, if the request includes a "SubstreamCtrl" header, it shall
list all the substreams are currently played.
If aggregated control is used, it is not allowed to pause only a part
of a session. It is also not allowed to pause only a specific
substream from a media stream.
5. RTSP Extensions
This section documentsthe extension to the RTSP 2.0 specification.
Specifically Section 5.1 specifies the SubstreamCtrl header,
Section 5.2 specifies the substream control feature tag, Section 5.3
specifies the status codes extentions for the substream control
feature.
5.1. Substream Header
SustreamCtrl header is used to indicate the substream(s) of a media
stream that the client intends to play. It contains one or more
[stream uri, substream type, substream id] triple.
The syntax is:
substream = "substream:" substream-id * (";" sustream-id)
substream-id = stream-uri "," substream-type "," substream_id
stream-uri = RTSP-URI
substream-type = "SVC" / "MVC" / token
When the substream-type is SVC, the syntax of substream_id is:
substream_id = layer-id
/dependency-id "," temporal-id "," quality-id
layer-id = "layer_id=" layer_id_value
layer_id_value = 1*4DIGIT; 0~2047
dependency-id = "dependency_id=" dependency_id_value
dependency_id_value = DIGIT ; 0~7
temporal-id = "temporal_id=" temporal_id_value
temporal_id_value = DIGIT ; 0~7
quality-id = "quality_id=" quality_id_value
quality_id_value = 1*2DIGIT; 0~15
DIGIT = %x30-39 ; any US-ASCII digit "0".."9"
Yue Expires April 23, 2012 [Page 7]
Internet-Draft RTSP Extension for Substream Control October 2011
An example of Substream header is: substream:
rtsp://example.com/svc.mp4, SVC, lay-id=1
For the MVC case, the syntax of substream_id is:
editor's notes: pending on the complement of mvc-operation-point-id
HCOLON = *( SP / HT ) ":" SWS
SEMI = SWS ";" SVS ; semicolon
SWS = [LWS] ; Separating White Space
DIGIT = %x30-39 ; any US-ASCII digit "0".."9"
COMMA = SWS "," SWS ; comma
EQUAL = SWS "=" SWS ; equal
SubstreamCtrl header can be used in PLAY and PAUSE request. Proxies
shall not modify this header and pass through to the server.
5.2. Play.substream Feature Tag
The following feature-tag is defined in this specification and hereby
registered. The change control belongs to the IETF. play.substream:
Support of substream control operations for media playback. Applies
only for servers.
5.3. Status Code Extension
This clause defines the status code extended for the substream
control feature. They are:
o 552 Substream Type Not Recognized
o 553 Substream Control Not Allowed
o 554 Substream Id Not Valid
5.3.1. 552 Substream Type Not Recognized
The server can not understand the substream type.
5.3.2. 553 Substream Control Not Allowed
The substream specified in the request is not allowed for the media
identified by the Request-URI. The response shall include a xxxx
header to indicate the substream information.
Editor notes: whether there is a need to return substream information
is pending for discussion.
Yue Expires April 23, 2012 [Page 8]
Internet-Draft RTSP Extension for Substream Control October 2011
5.3.3. 554 Substream Id Not Valid
The substream id specified in the request is not valid for the media
identified by the Request-URI. The response shall include a xxxx
header to indicate the substream information.
Editor notes: whether there is a need to return substream information
is pending for discussion.
6. Security Considerations
Editor notes: pending for more discussion.
7. IANA Considerations
Registration is requested for the newly defined RTSP header
extensions, RTSP status code extensions and RTSP feature tag
extensions, according to the instructions in section 22 of the base
specification [I-D.ietf-mmusic-rfc2326bis].
This section also sets up a registry for substream type that should
be maintained by IANA.
7.1. RTSP Feature-tag Extensions
The following feature-tag is defined in this specification and hereby
registered according to the section 22.1.2 of the base specification
[I-D.ietf-mmusic-rfc2326bis]. The change control belongs to the
IETF.
o Feature tag: substream.control
o Description:Support of control the media playback on substream
basis.Applies for both clients, servers and proxies.
o Contact person: Peiyu YUE
o Change control: IETF
o Reference specification: present document.
7.2. RTSP Status Code Extension
The following RTSP status codes are in defined this specification and
hereby registered according to section 22.3.2 of the base
specification [I-D.ietf-mmusic-rfc2326bis]. The change control
belongs to the IETF.
Yue Expires April 23, 2012 [Page 9]
Internet-Draft RTSP Extension for Substream Control October 2011
o Request number: 552
o Description: as described in Section 5.3.1
o Request number: 553
o Description: as described in Section 5.3.2
o Request number: 554
o Description: as described in Section 5.3.3
7.3. RTSP Header Extensions
The following RTSP header is defined in this specification and hereby
registered according to section 22.4.2 of the base specification
[I-D.ietf-mmusic-rfc2326bis]. The change control belongs to the
IETF.
o The name of the header: SubstreamCtrl
o Description:
o The syntax of the header: as described in Section 5.1.
o Where to use: as described in Section 5.1.
o Handle by proxy: as described in Section 5.1.
7.4. Hold of Substream Type Registration
7.4.1. Guidance of Substream Type Registration
IANA should take the responsibility for the registration of the
substream type. A new substream type MUST be registered through an
IETF Standards Action. A specification for a new substream type MUST
consist of the following items:
o A substream type;
o A description of the substream type;
o A substream id definition
7.4.2. Registration of Substream Types
This specification registers two substream types: SVC and MVC:
o Substream Type: SVC
o Description: Scalable Video Codec stream as defined in [RFC6190].
o Substream id definition: could be layer-id or [dependency-ID,
temporal_ID, quality-ID] combination, as described in Section 4.1.
o Substream Type: MVC
o Description: Multiview Video Codec stream as defined in
[I-D.ietf-payload-rtp-mvc].
Yue Expires April 23, 2012 [Page 10]
Internet-Draft RTSP Extension for Substream Control October 2011
o Substream id definition: as described in Section 4.1.
8. References
8.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-27 (work in
progress), March 2011.
[I-D.ietf-payload-rtp-mvc]
Wang, Y. and T. Schierl, "RTP Payload Format for MVC
Video", draft-ietf-payload-rtp-mvc-00 (work in progress),
March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
"RTP Payload Format for Scalable Video Coding", RFC 6190,
May 2011.
8.2. Informative References
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Author's Address
Peiyu Yue
Huawei Technologies
Huawei Base
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Phone: +86-25-56620258
Email: yuepeiyu@huawei.com
Yue Expires April 23, 2012 [Page 11]