mmusic P. Yue
Internet-Draft Huawei Technologies
Intended status: Standards Track March 2, 2012
Expires: September 3, 2012
RTSP Extension for Substream Control
draft-yue-mmusic-rtsp-substream-control-extension-01
Abstract
This document defines extensions to RTSP 2.0 protocol, including
header "SubstreamCtrl", 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 September 3, 2012.
Copyright Notice
Copyright (c) 2012 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 September 3, 2012 [Page 1]
Internet-Draft RTSP Extension for Substream Control March 2012
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. Substream Play/Resume . . . . . . . . . . . . . . . . . . 5
4.3.2. Substream Pause . . . . . . . . . . . . . . . . . . . . . 6
5. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . 6
5.1. Play.substream Feature Tag . . . . . . . . . . . . . . . . 7
5.2. Substream Header . . . . . . . . . . . . . . . . . . . . . 7
5.3. Status Code Extension . . . . . . . . . . . . . . . . . . 7
5.3.1. 552 Substream Type Not Recognized . . . . . . . . . . . . 7
5.3.2. 553 Substream Control Not Allowed . . . . . . . . . . . . 8
5.3.3. 554 Substream Id Not Valid . . . . . . . . . . . . . . . . 8
6. SVC and MVC Substream Type . . . . . . . . . . . . . . . . 8
6.1. SVC Substream Type . . . . . . . . . . . . . . . . . . . . 8
6.2. MVC Substream Type . . . . . . . . . . . . . . . . . . . . 9
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . 12
9.1. RTSP Feature-tag Extensions . . . . . . . . . . . . . . . 12
9.2. RTSP Header Extensions . . . . . . . . . . . . . . . . . . 13
9.3. RTSP Status Code Extension . . . . . . . . . . . . . . . . 13
9.4. Hold of Substream Type Registration . . . . . . . . . . . 13
9.4.1. Guidance of Substream Type Registration . . . . . . . . . 13
9.4.2. Registration of Substream Types . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . 14
Yue Expires September 3, 2012 [Page 2]
Internet-Draft RTSP Extension for Substream Control March 2012
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. Here these bitstream component(s) combinations are here
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 a SST session. However, in the current RTSP 2.0 protocol, the
control of the media is on basis of media stream i.e. an RTP session
when RTP is used as transport protocol. This prevents a client to
receive only certain substream(s) of 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 September 3, 2012 [Page 3]
Internet-Draft RTSP Extension for Substream Control March 2012
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 a single operation point.
o Substream type: the compound mode of the bitstream components in a
media stream, 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 three parts: substream annotation,
capability negotiation and substream playback control. This section
provides an overview of substream control framework.
CLIENT SERVER
| |
| <------ substream annotation ------- |
| |
| |
| |
| <---- RTSP Session Setup(Capability Negotiation) ----> |
| |
| |
| <---- RTSP media playback control(play/pause) ----> |
| |
| |
Figure 1: Substream Control Framework Overview
4.1. Substream Annotation
Substream annotation is used to announce all substreams available in
a media stream, which can be retrieved selectively. This is done
through a presentation description, typically using SDP description.
Substream annotation SHALL signal the substream type and substream id
for each substream.
Substrean type is the compound mode of the bitstream components in a
media stream, e.g. SVC, MVC, etc. Here a media stream with SVC
substream type, means comforming to [RFC6190]. A media stream with
MVC substream type, means comforming to [I-D.ietf-payload-rtp-mvc].
More specification of SVC and MVC substream type is defined at
Yue Expires September 3, 2012 [Page 4]
Internet-Draft RTSP Extension for Substream Control March 2012
Section 6.
Substream id is the identifier for a substream. The actual
definition of the substream id is defined by each substream type.
4.2. Capability Negotiation
Capability negotiation is 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.1 of this document.
If received a media presentation with substream annotation, a
substream control capable RTSP client SHALL include play.substream in
the REQUIRE 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 will retrieve the media as a whole.
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/resume a substream
o pause a substream. Note that this means pause the play back of
the whole session.
4.3.1. Substream Play/Resume
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 to signal the substream(s)
that the client intends to play.
The SubstreamCtrl header, as defined in Section 5.2, SHALL contain at
least the substream type and the substream id of each substream. In
the case of aggregate control, the header SHALL further contain
Request-URIs for each of the the substreams.
Yue Expires September 3, 2012 [Page 5]
Internet-Draft RTSP Extension for Substream Control March 2012
A client SHOULD NOT perform substream play if the server has not
indicated support of substream control during session setup.
Upon receiving a PLAY request with a "SubstreamCtrl" header, the
server SHALL identify the substream(s) according to the substream
type. substream id and optional Request-URI combination(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 SHALL respond
with 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
respond with a 552 "Substream Type Not Recognizable" response, 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 respond
with a 554 "Substream id not valid", see Section 5.3.3.
4.3.2. Substream Pause
The pause operation of a substream is identical to the pause
operation of a normal RTSP 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.
Upon receiving a PAUSE request without a SubstreamCtrl header, the
server SHALL pause the stream(s) according to RTSP
2.0[I-D.ietf-mmusic-rfc2326bis].
Upon receiving a PAUSE request with a SubstreamCtrl header, the
server SHALL check the substream list contained. If the substream
list is not identical to the ones that is in the play status, the
server SHALL respond with a 553 "Substream Control Not Allowed"
response, see Section 5.3.2. Otherwise, the server SHALL respond
with 2xx message and pause the stream(s) properly.
5. RTSP Extensions
This section documents the extension to the RTSP 2.0 specification.
Yue Expires September 3, 2012 [Page 6]
Internet-Draft RTSP Extension for Substream Control March 2012
Specifically Section 5.2 specifies the SubstreamCtrl header,
Section 5.1 specifies the substream control feature tag, Section 5.3
specifies the status codes extentions for the substream control
feature.
5.1. 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 for both clients and servers.
Notes that this feature is based the play.basic therefore spport of
this feature inheritly means support of play.basic.
5.2. Substream Header
SubstreamCtrl header is used to indicate the substream(s) of media
stream(s) that the client intends to play.
SubstreamCtrl header can be used in PLAY and PAUSE request. Proxies
shall not modify this header and pass through to the server.
SubstreamCtrl header contains one or more [stream uri, substream
type, substream id] triple. The syntax is:
SubstreamCtrl = "SubstreamCtrl:"
substream-id * (";" sustream-id)
substream-id = [stream-uri ","]
substream-type "," substream_id
stream-uri = RTSP-URI
substream-type= "SVC" / "MVC" / token
5.3. Status Code Extension
This clause defines the status codes 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 recognize one or more substream type(s) in the
SubstreamCtrl header of the request.
Yue Expires September 3, 2012 [Page 7]
Internet-Draft RTSP Extension for Substream Control March 2012
5.3.2. 553 Substream Control Not Allowed
One or more media streams identified by the Request-URI in the
request is not allowed for the substream control.
5.3.3. 554 Substream Id Not Valid
One or more substream id(s) specified in the request are not valid
for the media identified by the Request-URI.
6. SVC and MVC Substream Type
6.1. SVC Substream Type
This section provides the specification of substream type for SVC
Stream: Substream Type: "SVC" Substream annotation:
In SVC, a substream is identical to an operation point, which
consists of the bitstream components required to be decoded
independently.
Operation points are signalled in SDP, by ether of the following two
parameters :
o sprop-operation-point-info: According to [RFC6190], this parameter
consists of a comma-separated list of operation-point-description
vectors, including ayer-ID, dependency-ID, temporal_ID,
quality-ID. Among them, the value of layer-ID specifies the layer
identifier of the operation point, which is identical to the
layer_id that would be indicated (for the same values of
dependency_id, quality_id, and temporal_id) in the scalability
information SEI message.
o sprop-scalability-info: According to [RFC6190], This parameter is
used to convey the NAL unit containing the scalability information
SEI message as specified in Annex G of [H.264]. Within the
scalability information SEI message, layer information of the SVC
stream is signalled, including layer_id, dependency_id,
quality_id, and temporal_id.
Therefore, substreams in a SVC stream is identified by either
layer-ID or a [dependency-ID, temporal_ID, quality-ID] combination.
The syntax of substream_id is:
Yue Expires September 3, 2012 [Page 8]
Internet-Draft RTSP Extension for Substream Control March 2012
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"
An example of Substream header is:
SubstreamCtrl: rtsp://example.com/svc.mp4, SVC, lay-id=1
6.2. MVC Substream Type
This section provides the specification of substream type for SVC
Stream: Substream Type: "SVC" Substream annotation: Annocation of MVC
substreams is specified in [I-D.ietf-payload-rtp-mvc].
editor notes: pending on the complement of
[I-D.ietf-payload-rtp-mvc].
Substream_id:
For the MVC case, the syntax of substream_id is:
editor's notes: pending on the complement of mvc-operation-point-id
7. Examples
The following takes substream control of a SVC stream as an example.
Step 1: Client C requests a presentation from media server S. The
media is a video encoded by SVC and transported by SST.
Yue Expires September 3, 2012 [Page 9]
Internet-Draft RTSP Extension for Substream Control March 2012
C->S: DESCRIBE rtsp://example.com/BreakingDawn.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: Wed, 22 Feb 2012 15:20:29 GMT
Content-Type: application/sdp
Content-Length: 407
Content-Base: rtsp://example.com/BreakingDawn.3gp/
Expires: 22 Feb 2012 15:20:29 GMT
v=0
o=- 2890844256 2890842807 IN IP4 198.51.100.5
s=RTSP Session
i=An Example of substream control usage
e=adm@example.com
c=IN IP4 0.0.0.0
a=control: *
a=range: npt=0-0:10:34.10
t=0 0
m=video 20000 RTP/AVP 97
a=rtpmap:97 H264-SVC/90000
a=fmtp:97 profile-level-id=53000c; packetization-mode=1;
sprop-parameter-sets={sps0},{sps1},{pps0},{pps1};
sprop-operation-point-info=<1,0,0,0,4de00a,3200,176,144,128,
256>,<2,1,1,0,53000c,6400,352,288,256,512>;
Step 2: The client setup the RTSP session with play.substream feature
tag.
Yue Expires September 3, 2012 [Page 10]
Internet-Draft RTSP Extension for Substream Control March 2012
C->S: SETUP rtsp://example.com/BreakingDawn.3gp RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.substream
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: NPT, SMPTE, UTC
S->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; ssrc=AABBCCDD;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003";
src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
Session: 12345678
Expires: 22 Feb 2012 15:22:09 GMT
Date: 22 Feb 2012 15:22:09 GMT
Accept-Range: NPT
Media-Properties: Random-Access=0.8, Immutable, Unlimited
Step 3: The client starts the playout of the component layer 1.
C->S: PLAY rtsp://example.com/BreakingDawn.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=0-
Seek-Style: RAP
Session: 12345678
SubstreamCtrl: SVC, layer_id=1
S->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: 22 Feb 2012 15:22:52 GMT
Session: 12345678
Range: npt=0-634.10
Seek-Style: RAP
RTP-Info: url="rtsp://example.com/BreakingDawn.3gp"
ssrc=0D12F123:seq=12345;rtptime=3450012,
Step 4: The client requests to pause the session.
Yue Expires September 3, 2012 [Page 11]
Internet-Draft RTSP Extension for Substream Control March 2012
C->S: PAUSE rtsp://example.com/BreakingDawn.3gp/ RTSP/2.0
CSeq: 5
User-Agent: PhonyClient/1.2
Session: 12345678
SubstreamCtrl: SVC, layer_id=1
S->C: RTSP/2.0 200 OK
CSeq: 5
Server: PhonyServer/1.0
Date: 22 Feb 2012 15:22:58 GMT
Session: 12345678
Range: npt=5.66-634.10
8. Security Considerations
Considerations outlined in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]
apply here as well. It is believed that no special security risk is
led by this document.
9. IANA Considerations
Registration is requested for the newly defined RTSP feature tag
extension, RTSP header extensions and RTSP status code 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.
9.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: Play.substream
o Description: Support of control the media playback on substream
basis. Applies for clients, servers and proxies.
o Contact person: Peiyu YUE
o Change control: IETF
o Reference specification: present document.
Yue Expires September 3, 2012 [Page 12]
Internet-Draft RTSP Extension for Substream Control March 2012
9.2. 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: SubstreamCtrl is used to indicate the substreams RTSP
client wants to control(i.e. play or pause).
o The syntax of the header: as described in Section 5.2.
o Where to use: as described in Section 5.2.
o Handle by proxy: default.
9.3. 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.
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
9.4. Hold of Substream Type Registration
9.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
9.4.2. Registration of Substream Types
This specification registers two substream types: SVC and MVC:
Yue Expires September 3, 2012 [Page 13]
Internet-Draft RTSP Extension for Substream Control March 2012
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].
o Substream id definition: as described in Section 4.1.
10. References
10.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.
10.2. Informative References
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Yue Expires September 3, 2012 [Page 14]
Internet-Draft RTSP Extension for Substream Control March 2012
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 September 3, 2012 [Page 15]