| mmusic | P. Yue |
| Internet-Draft | Huawei Technologies |
| Intended status: Standards Track | March 02, 2012 |
| Expires: September 01, 2012 |
RTSP Extension for Substream Control
draft-yue-mmusic-rtsp-substream-control-extension-01
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.
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 01, 2012.
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.
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:
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.
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].
The following terms are used in this document and have specific meaning within the context of this document.
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
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 Section 6.
Substream id is the identifier for a substream. The actual definition of the substream id is defined by each substream type.
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.
In case the session is setup correctly, the client may control the play back on substream basis, including:
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.
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.
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.
This section documents the extension to the RTSP 2.0 specification. 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.
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.
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
This clause defines the status codes extended for the substream control feature. They are:
The server can not recognize one or more substream type(s) in the SubstreamCtrl header of the request.
One or more media streams identified by the Request-URI in the request is not allowed for the substream control.
One or more substream id(s) specified in the request are not valid for the media identified by the Request-URI.
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 :
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:
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
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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:
This specification registers two substream types: SVC and MVC:
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC6190] | Wenger, S., Wang, Y.-K., Schierl, T. and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, May 2011. |
| [I-D.ietf-mmusic-rfc2326bis] | Schulzrinne, H, Rao, A, Lanphier, R, Westerlund, M and M Stiemerling, "Real Time Streaming Protocol 2.0 (RTSP)", Internet-Draft draft-ietf-mmusic-rfc2326bis-27, March 2011. |
| [I-D.ietf-payload-rtp-mvc] | Wang, Y and T Schierl, "RTP Payload Format for MVC Video", Internet-Draft draft-ietf-payload-rtp-mvc-00, March 2011. |
| [RFC4566] | Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. |