draft-ietf-mmusic-decoding-dependency-06.txt   draft-ietf-mmusic-decoding-dependency-07.txt 
Network Working Group T. Schierl Network Working Group T. Schierl
Internet-Draft Fraunhofer HHI Internet-Draft Fraunhofer HHI
Intended status: Standards Track S. Wenger Intended status: Standards Track S. Wenger
Expires: May 19, 2009 Nokia Expires: October 1, 2009 Nokia
February 23, 2009 April 2, 2009
Signaling media decoding dependency in Session Description Protocol Signaling media decoding dependency in Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-decoding-dependency-06 draft-ietf-mmusic-decoding-dependency-07
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 23, 2009. This Internet-Draft will expire on October 1, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This memo defines semantics that allow for signaling the decoding This memo defines semantics that allow for signaling the decoding
dependency of different media descriptions with the same media type in dependency of different media descriptions with the same media type in
the Session Description Protocol (SDP). This is required, for example, the Session Description Protocol (SDP). This is required, for example,
if media data is separated and transported in different network streams if media data is separated and transported in different network streams
as a result of the use of a layered or multiple descriptive media coding as a result of the use of a layered or multiple descriptive media coding
process. process.
A new grouping type "DDP" -- decoding dependency -- is defined, to be A new grouping type "DDP" -- decoding dependency -- is defined, to be
skipping to change at page 3, line 18 skipping to change at page 3, line 18
2. Terminology ................................................... 5 2. Terminology ................................................... 5
3. Definitions ................................................... 5 3. Definitions ................................................... 5
4. Motivation, Use Cases, and Architecture ....................... 6 4. Motivation, Use Cases, and Architecture ....................... 6
4.1. Motivation .................................................. 6 4.1. Motivation .................................................. 6
4.2. Use cases ................................................... 8 4.2. Use cases ................................................... 8
5. Signaling Media Dependencies .................................. 8 5. Signaling Media Dependencies .................................. 8
5.1. Design Principles ........................................... 8 5.1. Design Principles ........................................... 8
5.2. Semantics ................................................... 9 5.2. Semantics ................................................... 9
5.2.1. SDP grouping semantics for decoding dependency ............ 9 5.2.1. SDP grouping semantics for decoding dependency ............ 9
5.2.2. "depend" attribute for dependency signaling per media-stream 5.2.2. "depend" attribute for dependency signaling per media-stream
....................................................................9 ................................................................... 9
6. Usage of new semantics in SDP ................................ 11 6. Usage of new semantics in SDP ................................ 11
6.1. Usage with the SDP Offer/Answer Model ...................... 11 6.1. Usage with the SDP Offer/Answer Model ...................... 11
6.2. Declarative usage .......................................... 11 6.2. Declarative usage .......................................... 12
6.3. Usage with AVP and SAVP RTP profiles ....................... 11 6.3. Usage with AVP and SAVP RTP profiles ....................... 12
6.4. Usage with Capability Negotiation .......................... 12 6.4. Usage with Capability Negotiation .......................... 12
6.5. Examples ................................................... 12 6.5. Examples ................................................... 13
7. Security Considerations ...................................... 14 7. Security Considerations ...................................... 15
8. IANA Considerations .......................................... 14 8. IANA Considerations .......................................... 15
9. Informative note on RFC 3388bis .............................. 15 9. Informative note on RFC 3388bis .............................. 16
10. References ................................................... 16 10. References ................................................... 16
10.1. Normative References ....................................... 16 10.1. Normative References ....................................... 16
10.2. Informative References ..................................... 16 10.2. Informative References ..................................... 17
Appendix A. Acknowledgements .................................... 17 Appendix A. Acknowledgements .................................... 17
Authors' Addresses ............................................... 17 Authors' Addresses ............................................... 18
1. Introduction 1. Introduction
An SDP session description may contain one or more media An SDP session description may contain one or more media
descriptions, each identifying a single media stream. A media descriptions, each identifying a single media stream. A media
description is identified by one "m=" line. Today, if more than one description is identified by one "m=" line. Today, if more than one
"m=" lines exist indicating the same media type, a receiver cannot "m=" lines exist indicating the same media type, a receiver cannot
identify a specific relationship between those media. identify a specific relationship between those media.
A Multiple Description Coding (MDC) or layered Media Bitstream A Multiple Description Coding (MDC) or layered Media Bitstream
skipping to change at page 11, line 34 skipping to change at page 11, line 34
single media stream that represents an Operation Point. single media stream that represents an Operation Point.
Note: in most cases, this will be the base layer of a layered Media Note: in most cases, this will be the base layer of a layered Media
Bitstream, equally possible are Operation Points containing a set of Bitstream, equally possible are Operation Points containing a set of
enhancement layers as long as all are part of a single media stream. enhancement layers as long as all are part of a single media stream.
In case (2), if the sender of the original offer has identified that In case (2), if the sender of the original offer has identified that
the refusal to the request is caused by the use of DDP grouping, and the refusal to the request is caused by the use of DDP grouping, and
if the sender of the offer still wishes to establish the session, it if the sender of the offer still wishes to establish the session, it
SHOULD re-try the request with an offer including only a single media SHOULD re-try the request with an offer including only a single media
stream. stream.
If the answerer understands the DDP semantics, it is necessary to
take the "depend" attribute into consideration in the offer/answer
procedure. The main rule for the "depend" attribute is that the
offerer decides the number of media streams and the dependency
between them. The answerer cannot change the dependency relations.
For unicast sessions where the answerer receives media, i.e. for
offers including media streams that have a directionality indicated
by "sendonly", "sendrecv" or have no directionality indicated, the
answerer MAY remove media operation points. The answerer MUST use the
dependency relations provided in the offer when sending media. The
answerer MAY send according to all of the operation points present in
the offer, even if the answerer has removed some of those operation
points. Thus an answerer can limit the number of operation points
being delivered to the answerer while the answerer can still send
media to the offerer using all of the operation points indicated in
the offer.
For multicast sessions, the answerer MUST accept all operation points
and their related decoding dependencies or MUST remove non-accepted
operation points completely. Due to the nature of multicast, the
receiver can select which operation points, it actually receives and
processes. For multicast sessions that allow the answerer to also
send data, the answerer MAY send all of the offered operations
points.
In any case, if the answerer cannot accept one or more offered
operation points and/or the media stream's dependencies, the answerer
MAY re-invite with an offer including acceptable operation points
and/or dependencies.
Note: Applications may limit the possibilities to perform a re-
invite. The previous offer is also a good hint to the capabilities of
the other agent.
6.2. Declarative usage 6.2. Declarative usage
If an RTSP receiver understands signaling according to this memo, it If an RTSP receiver understands signaling according to this memo, it
SHALL setup all media streams that are required to decode the SHALL setup all media streams that are required to decode the
Operation Point of its choice. Operation Point of its choice.
If an RTSP receiver does not understand the signaling defined within If an RTSP receiver does not understand the signaling defined within
this memo, it falls back to normal SDP processing. Two likely cases this memo, it falls back to normal SDP processing. Two likely cases
have to be distinguished: (1) if at least one of the media types have to be distinguished: (1) if at least one of the media types
included in the SDP is within the receiver's capabilities, it selects included in the SDP is within the receiver's capabilities, it selects
skipping to change at page 12, line 33 skipping to change at page 13, line 23
parameters as, e.g. "packetization-mode" (not shown in the parameters as, e.g. "packetization-mode" (not shown in the
example) for the media subtypes "H264" and "H264-SVC" given by example) for the media subtypes "H264" and "H264-SVC" given by
the "a=rtpmap:"-line. The first media description includes two the "a=rtpmap:"-line. The first media description includes two
H264 payload types as media format descriptions, "96" and "97", H264 payload types as media format descriptions, "96" and "97",
as defined in [RFC3984] and represents the base layer operation as defined in [RFC3984] and represents the base layer operation
point (identified by "mid:L1"). The two other media point (identified by "mid:L1"). The two other media
descriptions (identified by "mid:L2" and "mid:L3") include H264- descriptions (identified by "mid:L2" and "mid:L3") include H264-
SVC payload types as defined in [I-D.ietf-avt-rtp-svc], which SVC payload types as defined in [I-D.ietf-avt-rtp-svc], which
contain enhancements to the base layer operation point or the contain enhancements to the base layer operation point or the
first enhancement layer operation point (media description first enhancement layer operation point (media description
identified by "mid:L2"). The example shows the dependencies of identified by "mid:L2").
the media format descriptions of the different media Note: The SDP examples in [I-D.ietf-avt-rtp-svc] use numbers for
descriptions indicated by "DDP" grouping, "mid" and "depend" the mid values instead of using tokens like "L1", "L2" and "L3".
attributes. The "depend" attribute is used with the decoding The example shows the dependencies of the media format
dependency type "lay" indicating layered decoding dependency. descriptions of the different media descriptions indicated by
For example, the third media description ("m=video 40004...") "DDP" grouping, "mid" and "depend" attributes. The "depend"
indentified by "mid:L3" has different dependencies on the media attribute is used with the decoding dependency type "lay"
format descriptions of the two other media descriptions: indicating layered decoding dependency. For example, the third
media description ("m=video 40004...") indentified by "mid:L3"
has different dependencies on the media format descriptions of
the two other media descriptions:
Media format description "100" depends on media format Media format description "100" depends on media format
description "96" or "97" of the media description indentified by description "96" or "97" of the media description indentified by
"mid:L1". This is an exclusive-OR, i.e. payload type "100" may "mid:L1". This is an exclusive-OR, i.e. payload type "100" may
be used with payload type "96" or with "97", but one of the two be used with payload type "96" or with "97", but one of the two
combinations is required for decoding payload type "100". combinations is required for decoding payload type "100".
For media format description "101", it is different. This one For media format description "101", it is different. This one
depends on two of the other media descriptions at the same time, depends on two of the other media descriptions at the same time,
i.e. it depends on media format description "97" of the media i.e. it depends on media format description "97" of the media
description indentified by "mid:L1" and it also depends on media description indentified by "mid:L1" and it also depends on media
format description "99" of the media description indentified by format description "99" of the media description indentified by
skipping to change at page 16, line 33 skipping to change at page 17, line 24
[RFC4566] Handley, M., Jacobson, V, and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V, and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008. Specifications: ABNF", RFC 5234, January 2008.
10.2. Informative References 10.2. Informative References
[I-D.ietf-avt-rtp-svc] [I-D.ietf-avt-rtp-svc]
Wenger, S., Wang Y.-K., T. Schierl and A. Eleftheriadis, Wenger, S., Wang Y.-K., T. Schierl and A. Eleftheriadis,
"RTP Payload Format for SVC Video", "RTP Payload Format for SVC Video",
draft-ietf-avt-rtp-svc-16 (work in progress), December draft-ietf-avt-rtp-svc-18 (work in progress), March
2008. 2009.
[I-D.ietf-mmusic-rfc3388bis] [I-D.ietf-mmusic-rfc3388bis]
Camarillo, G "The SDP (Session Description Protocol) Camarillo, G "The SDP (Session Description Protocol)
Grouping Framework", Grouping Framework",
draft-ietf-mmusic-rfc3388bis-02 (work in progress), draft-ietf-mmusic-rfc3388bis-02 (work in progress), January
January 2009. 2009.
[I-D.ietf-mmusic-sdp-capability-negotiation] [I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation", Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-09, (work in draft-ietf-mmusic-sdp-capability-negotiation-09, (work in
progress), July 2008. progress), July 2008.
[I-D.wang-avt-rtp-mvc] [I-D.wang-avt-rtp-mvc]
Wang, Y.-K. and T. Schierl, "RTP Payload Format Wang, Y.-K. and T. Schierl, "RTP Payload Format
for MVC Video", draft-wang-avt-rtp-mvc-03 (work in for MVC Video", draft-wang-avt-rtp-mvc-03 (work in
progress), February 2009. progress), February 2009.
[MDC] Vitali, A., Borneo, A., Fumagalli, M., and R. Rinaldo, [MDC] Vitali, A., Borneo, A., Fumagalli, M., and R. Rinaldo,
"Video over IP using Standard-Compatible Multiple "Video over IP using Standard-Compatible Multiple
skipping to change at line 710 skipping to change at page 18, line 31
Email: mail@thomas-schierl.de Email: mail@thomas-schierl.de
Stephan Wenger Stephan Wenger
Nokia Nokia
955 Page Mill Road 955 Page Mill Road
Palo Alto, CA, 94304 Palo Alto, CA, 94304
USA USA
Phone: +1-650-862-7368 Phone: +1-650-862-7368
Email: stewe@stewe.org Email: stewe@stewe.org
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
 End of changes. 14 change blocks. 
30 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/