draft-ietf-mmusic-decoding-dependency-03.txt   draft-ietf-mmusic-decoding-dependency-04.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: March 24, 2009 Nokia Expires: April 20, 2009 Nokia
September 25, 2008 October 21, 2008
Signaling media decoding dependency in Session Description Protocol Signaling media decoding dependency in Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-decoding-dependency-03 draft-ietf-mmusic-decoding-dependency-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 March 24, 2009. This Internet-Draft will expire on April 20, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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,
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Introduction .................................................. 4 1. Introduction .................................................. 4
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. Attribute for dependency signaling per media-stream ....... 9 5.2.2. "depend" attribute for dependency signaling per media-stream
................................................................... 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 .......................................... 11
6.3. Usage with Capability Negotiation .......................... 11 6.3. Usage with Capability Negotiation .......................... 11
6.4. Examples ................................................... 11 6.4. Examples ................................................... 12
7. Security Considerations ...................................... 14 7. Security Considerations ...................................... 14
8. IANA Considerations .......................................... 14 8. IANA Considerations .......................................... 14
9. Informative note on RFC 3388bis .............................. 15 9. Informative note on RFC 3388bis .............................. 15
10. References ................................................... 15 10. References ................................................... 15
10.1. Normative References ....................................... 15 10.1. Normative References ....................................... 15
10.2. Informative References ..................................... 15 10.2. Informative References ..................................... 16
Appendix A. Changes From Earlier Versions........................ 16 Appendix A. Acknowledgements..................................... 16
Authors' Addresses................................................ 17 Authors' Addresses................................................ 17
Full Copyright Statement.......................................... 18 Full Copyright Statement.......................................... 18
Intellectual Property Statement................................... 18 Intellectual Property Statement................................... 18
Acknowledgements.................................................. 19
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 9, line 30 skipping to change at page 9, line 30
same type of decoding dependency (as signaled by the attribute same type of decoding dependency (as signaled by the attribute
defined in 5.2.2). All media streams MUST contain at least one defined in 5.2.2). All media streams MUST contain at least one
Operation Point. The DDP group type informs a receiver about the Operation Point. The DDP group type informs a receiver about the
requirement for handling the media streams of the group according to requirement for handling the media streams of the group according to
the new media level attribute "depend", as defined in 5.2.2. . the new media level attribute "depend", as defined in 5.2.2. .
When using multiple codecs, e.g. for Offer/Answer model, the media When using multiple codecs, e.g. for Offer/Answer model, the media
streams MUST have the same dependency structure, regardless which streams MUST have the same dependency structure, regardless which
media format description (RTP payload type number) is used. media format description (RTP payload type number) is used.
5.2.2. Attribute for dependency signaling per media-stream - "depend" 5.2.2. "depend" attribute for dependency signaling per media-stream
This memo defines a new media-level attribute, "depend", with the This memo defines a new media-level attribute, "depend", with the
following ABNF [RFC5234]. The identification-tag is defined in following ABNF [RFC5234]. The identification-tag is defined in
[RFC3388]. In the following ABNF, fmt, token, SP, and CRLF are used [RFC3388]. In the following ABNF, fmt, token, SP, and CRLF are used
as defined in [RFC4566]. as defined in [RFC4566].
depend-attribute = depend-attribute =
"a=depend:" dependent-fmt SP dependency-tag "a=depend:" dependent-fmt SP dependency-tag
*(";" SP dependent-fmt SP dependency-tag) CRLF *(";" SP dependent-fmt SP dependency-tag) CRLF
skipping to change at page 10, line 21 skipping to change at page 10, line 21
exactly one dependency-tag indicated per dependent-fmt. exactly one dependency-tag indicated per dependent-fmt.
dependent-fmt, indicates the media format description, as defined in dependent-fmt, indicates the media format description, as defined in
[RFC4566], that depends on one or more media format description in [RFC4566], that depends on one or more media format description in
the media description indicated by the value of identification-tag the media description indicated by the value of identification-tag
within the dependency-tag. within the dependency-tag.
fmt-dependency, indicates the media format description in the media fmt-dependency, indicates the media format description in the media
description identified by the identification-tag within the description identified by the identification-tag within the
dependency-tag, which the dependent-fmt of the dependent media dependency-tag, which the dependent-fmt of the dependent media
description depends on. description depends on. In case a list of fmt-dependency values is
given, any element of the list is sufficient to satisfy the
dependency, at the choice of the decoding entity.
The depend-attribute describes the decoding dependency. The depend- The depend-attribute describes the decoding dependency. The depend-
attribute MUST be followed by a sequence of dependent-fmt and the attribute MUST be followed by a sequence of dependent-fmt and the
corresponding dependency-tag fields which identify all related media corresponding dependency-tag fields which identify all related media
format description in all related media descriptions of the format descriptions in all related media descriptions of the
dependent-fmt. The attribute MAY be used with multicast as well as dependent-fmt. The attribute MAY be used with multicast as well as
with unicast transport addresses. The following dependency-types with unicast transport addresses. The following dependency-types
values are defined in this memo: values are defined in this memo:
o lay: Layered decoding dependency -- identifies the described media o lay: Layered decoding dependency -- identifies the described media
stream as one or more Media Partitions of a layered Media stream as one or more Media Partitions of a layered Media
Bitstream. When "lay" is used, all media streams required for Bitstream. When "lay" is used, all media streams required for
decoding the Operation Point MUST be identified by identification- decoding the Operation Point MUST be identified by identification-
tag and fmt-dependency following the "lay" string. tag and fmt-dependency following the "lay" string.
skipping to change at page 12, line 4 skipping to change at page 12, line 6
for setup, as usual. (2) If none of the media type included in the for setup, as usual. (2) If none of the media type included in the
SDP can be processed, then obviously no setup can occur. SDP can be processed, then obviously no setup can occur.
6.3. Usage with Capability Negotiation 6.3. Usage with Capability Negotiation
This memo does not cover the interaction with Capability Negotiation This memo does not cover the interaction with Capability Negotiation
[I-D.ietf-mmusic-sdp-capability-negotiation]. This issue is for [I-D.ietf-mmusic-sdp-capability-negotiation]. This issue is for
further study and will be addressed in a different memo. further study and will be addressed in a different memo.
6.4. Examples 6.4. Examples
a.) Example for signaling layered decoding dependency: a.) Example for signaling layered decoding dependency:
The example shows a session description with three media The example below shows a session description with three media
descriptions, all of type video and with layered decoding descriptions, all of type video and with layered decoding
dependency ("lay"). Each of the media description includes two dependency ("lay"). Each of the media description includes two
possible media format descriptions with different encoding possible media format descriptions with different encoding
parameters as, e.g. "packetization-mode" for the media subtypes parameters as, e.g. "packetization-mode" (not shown in the
H264 and H264-SVC given by the "a=rtpmap:"-line (not shown in example) for the media subtypes "H264" and "H264-SVC" given by
the example below). The first media description includes two the "a=rtpmap:"-line. The first media description includes two
H264 payload types, 96 and 97, as defined by [RFC3984] and H264 payload types as media format descriptions, "96" and "97",
represents the base layer operation point. Payload type 96 and as defined in [RFC3984] and represents the base layer operation
97 may differ, e.g. in the used H264 packetization modes (not point (identified by "mid:L1"). The two other media
shown in this example). The other media descriptions include descriptions (identified by "mid:L2" and "mid:L3") include H264-
H264-SVC payload types as defined by [I-D.ietf-avt-rtp-svc], SVC payload types as defined in [I-D.ietf-avt-rtp-svc], which
which contain enhancements to other layers. The example shows contain enhancements to the base layer operation point or the
the dependencies of the RTP payload types of the different media first enhancement layer operation point (media description
identified by "mid:L2"). The example shows the dependencies of
the media format descriptions of the different media
descriptions indicated by "DDP" grouping, "mid" and "depend" descriptions indicated by "DDP" grouping, "mid" and "depend"
attributes. The "depend" attribute is used with the decoding attributes. The "depend" attribute is used with the decoding
dependency type "lay" indicating layered decoding dependency. dependency type "lay" indicating layered decoding dependency.
For example, the third media description ("m=video 40004...") For example, the third media description ("m=video 40004...")
with "mid:L3" has different dependencies to the media format indentified by "mid:L3" has different dependencies on the media
descriptions of the two other media descriptions: Media format format descriptions of the two other media descriptions:
description "100" depends on media format description "96" of Media format description "100" depends on media format
the media description indentified by "mid:L1". The media format description "96" or "97" of the media description indentified by
description "101" of the media description indentified by "mid:L1". This is an exclusive-OR, i.e. payload type "100" may
"mid:L3" depends on two of the other media descriptions. This be used with payload type "96" or with "97", but one of the two
media format description depends on media format description combinations is required for decoding payload type "100".
"97" of the media description indentified by "mid:L1" and also For media format description "101", it is different. This one
depends on media format description "99" of the media depends on two of the other media descriptions at the same time,
description indentified by "mid:L2". For decoding media format i.e. it depends on media format description "97" of the media
description "101" both media format description "97" and media description indentified by "mid:L1" and it also depends on media
format description "99" are required by definition. format description "99" of the media description indentified by
"mid:L2". For decoding media format description "101" both
media format description "97" and media format description "99"
are required by definition.
v=0 v=0
o=svcsrv 289083124 289083124 IN IP4 host.example.com o=svcsrv 289083124 289083124 IN IP4 host.example.com
s=LAYERED VIDEO SIGNALING Seminar s=LAYERED VIDEO SIGNALING Seminar
t=0 0 t=0 0
c=IN IP4 192.0.2.1/127 c=IN IP4 192.0.2.1/127
a=group:DDP L1 L2 L3 a=group:DDP L1 L2 L3
m=video 40000 RTP/AVP 96 97 m=video 40000 RTP/AVP 96 97
b=AS:90 b=AS:90
a=framerate:15 a=framerate:15
skipping to change at page 16, line 8 skipping to change at page 16, line 18
[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-13 (work in progress), July 2008. draft-ietf-avt-rtp-svc-14 (work in progress), September
2008.
[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-01 (work in progress), July draft-ietf-mmusic-rfc3388bis-01 (work in progress), July
2008. 2008.
[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 2009. 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-02 (work in for MVC Video", draft-wang-avt-rtp-mvc-02 (work in
progress), August 2008. progress), August 2008.
[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
Description Coding: an IETF proposal", Packet Video Description Coding: an IETF proposal", Packet Video
Workshop, April 2006, Hangzhou, China. Workshop, April 2006, Hangzhou, China.
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,M., [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,M.,
and Singer, D., "RTP Payload Format for H.264 Video", RFC and Singer, D., "RTP Payload Format for H.264 Video", RFC
3984, February 2005. 3984, February 2005.
Appendix A. Changes From Earlier Versions Appendix A. Acknowledgements
A.1 Changes from individual submission
19Dec06 / TS:
removed SSRC multiplexing and with that various information about RTP
draft title correction
corrected SDP reference
editorial modifications throughout the document
added Stephan Wenger to the list of authors
removed section "network elements not supporting dependency
signaling"
20-28Dec06 / TS, StW: Editorial improvements
3Mar07 / TS: adjustment for new I-D style, added Offer/Answer text,
corrected ABNF reference, added Security and IANA considerations,
added section Usage with existing entities not supporting new
signaling, added text for Declarative usage section, added Open
issues section.
21-Jun07: Numerous editorial changes and reworked section 6.
11-Nov07: Added Payload Type of media stream in question to
dependency signaling. Note on usage with Cap. Negotiation. Added
multi view coding (MVC) dependency as part of 'lay'-dependency. Added
ref. to MVC activity at ITU-T/MPEG.
A.2 Changes from draft-ietf-mmusic-decoding-dependency-00 to
draft-ietf-mmusic-decoding-dependency-01:
21-Feb08: Enhanced mechanism by multiple "payload-type-dependencies"
for the same "mid". Typically the case, when using different
packetization modes as defined in RFC3984.
25-Feb08: Modification throughout informative part of definition
section
Different codecs may be present within the same DDP group.
A.3 Changes from draft-ietf-mmusic-decoding-dependency-01 to
draft-ietf-mmusic-decoding-dependency-02:
19-Mar08: Fixed PT# in example, removed unused references, updated
ABNF reference in text, IANA section updates, require std. track doc
for new dependencies, editorial changes
23-May08: Replacing payload-type with media format description/fmt,
renaming of dependent-payload-type to dependent-fmt, renaming
payload-type-dependency to fmt-dependency, editorial changes.
A.4 Changes from draft-ietf-mmusic-decoding-dependency-02 to
draft-ietf-mmusic-decoding-dependency-03:
09-July08: Incorporated comments from Ali, Dan and Jean-Francois sent
to the mailing list on June 23rd, June 24th and July 4th
respectively.
15-August08: Constraint for media description to be part of not more Funding for the RFC Editor function is currently provided by the
than one DDP group. Informative note on RFC3388bis. Internet Society. Further, the author Thomas Schierl of Fraunhofer
10-September08: Added text on dependency-tag to section 5.2.2. In HHI is sponsored by the European Commission under the contract number
5.2.2, "depend:" attribute MUST be followed by sequence of FP7-ICT-214063, project SEA.
identifications-tags + dependency-tags (before it was MAY). Text on We want to also thank Magnus Westerlund, Joerg Ott, Ali Begen, Dan
example a) in 6.4 improved. Wing, Helmut Burklin, and Jean-Francois Mule for their valuable and
constructive comments to this memo.
Authors' Addresses Authors' Addresses
Thomas Schierl Thomas Schierl
Fraunhofer HHI Fraunhofer HHI
Einsteinufer 37 Einsteinufer 37
D-10587 Berlin D-10587 Berlin
Germany Germany
Phone: +49-30-31002-227 Phone: +49-30-31002-227
skipping to change at page 19, line 13 skipping to change at line 732
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgements
Funding for the RFC Editor function is currently provided by the
Internet Society. Further, the author Thomas Schierl of Fraunhofer
HHI is sponsored by the European Commission under the contract number
FP7-ICT-214063, project SEA.
We want to also thank Magnus Westerlund, Joerg Ott, Ali Begen, Dan
Wing, and Jean-Francois Mule for their valuable and constructive
comments to this memo.
 End of changes. 20 change blocks. 
95 lines changed or deleted 55 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/