draft-ietf-mmusic-decoding-dependency-05.txt   draft-ietf-mmusic-decoding-dependency-06.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: May 19, 2009 Nokia
November 20, 2008 February 23, 2009
Signaling media decoding dependency in Session Description Protocol Signaling media decoding dependency in Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-decoding-dependency-05 draft-ietf-mmusic-decoding-dependency-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 May 19, 2009. This Internet-Draft will expire on August 23, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 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.
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
used in conjunction with RFC 3388 entitled "Grouping of Media Lines in used in conjunction with RFC 3388 entitled "Grouping of Media Lines in
the Session Description Protocol". In addition, an attribute is the Session Description Protocol". In addition, an attribute is
specified describing the relationship of the media streams in a "DDP" specified describing the relationship of the media streams in a "DDP"
group indicated by media identification attribute(s) and media format group indicated by media identification attribute(s) and media format
description(s). description(s).
Table of Contents Table of Contents
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 .......................................... 11
6.3. Usage with AVP and SAVP RTP profiles ....................... 11 6.3. Usage with AVP and SAVP RTP profiles ....................... 11
6.4. Usage with Capability Negotiation .......................... 12 6.4. Usage with Capability Negotiation .......................... 12
6.5. Examples ................................................... 12 6.5. 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 ................................................... 16
10.1. Normative References ....................................... 16 10.1. Normative References ....................................... 16
10.2. Informative References ..................................... 16 10.2. Informative References ..................................... 16
Appendix A. Acknowledgements..................................... 17 Appendix A. Acknowledgements .................................... 17
Authors' Addresses................................................ 17 Authors' Addresses ............................................... 17
Full Copyright Statement.......................................... 18
Intellectual Property Statement................................... 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 22 skipping to change at page 11, line 22
The backward compatibility in offer / answer is generally handled as The backward compatibility in offer / answer is generally handled as
specified in [RFC3388], section 8.4, as summarized below. specified in [RFC3388], section 8.4, as summarized below.
Depending on the implementation, a node that does not understand DDP Depending on the implementation, a node that does not understand DDP
grouping (either does not understand line grouping at all, or just grouping (either does not understand line grouping at all, or just
does not understand the DDP semantics) SHOULD respond to an offer does not understand the DDP semantics) SHOULD respond to an offer
containing DDP grouping either (1) with an answer that ignores the containing DDP grouping either (1) with an answer that ignores the
grouping attribute or (2) with a refusal to the request (e.g., 488 grouping attribute or (2) with a refusal to the request (e.g., 488
Not acceptable here or 606 Not acceptable in SIP). Not acceptable here or 606 Not acceptable in SIP).
In the first case, if the original sender of the offer still wishes In case (1), if the original sender of the offer still wishes to
to establish communications, it SHOULD generate a new offer with a establish communications, it SHOULD generate a new offer with a
single media stream that represents an Operation Point. Note: in single media stream that represents an Operation Point.
most cases, this will be the base layer of a layered Media Bitstream, Note: in most cases, this will be the base layer of a layered Media
equally possible are Operation Points containing a set of enhancement Bitstream, equally possible are Operation Points containing a set of
layers as long as all are part of a single media stream. In the enhancement layers as long as all are part of a single media stream.
second case, if the sender of the offer still wishes to establish the In case (2), if the sender of the original offer has identified that
session, it SHOULD re-try the request with an offer including only a the refusal to the request is caused by the use of DDP grouping, and
single media stream. 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
stream.
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
skipping to change at page 15, line 13 skipping to change at page 15, line 13
tel:+49-30-31002-227 tel:+49-30-31002-227
The following semantics have been registered by IANA in Semantics for The following semantics have been registered by IANA in Semantics for
the "group" SDP Attribute under SDP Parameters the "group" SDP Attribute under SDP Parameters
http://www.iana.org/assignments/sdp-parameters. http://www.iana.org/assignments/sdp-parameters.
Semantics Token Reference Semantics Token Reference
------------------- ----- --------- ------------------- ----- ---------
Decoding Dependency DDP RFC XXXX Decoding Dependency DDP RFC XXXX
The SDP media level attribute "depend" has been registered by IANA in The SDP media level attribute "depend" has been registered by IANA in
Semantics for "att-field (media level only)". Semantics for "att-field (media level only)". The registration
procedure in section 8.2.4 of [RFC4566] applies.
SDP Attribute ("att-field (media level only)"): SDP Attribute ("att-field (media level only)"):
Attribute name: depend Attribute name: depend
Long form: decoding dependency Long form: decoding dependency
Type of name: att-field Type of name: att-field
Type of attribute: media level only Type of attribute: media level only
Subject to charset: no Subject to charset: no
Purpose: RFC XXXX Purpose: RFC XXXX
Reference: RFC XXXX Reference: RFC XXXX
skipping to change at page 16, line 31 skipping to change at page 16, line 33
[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-15 (work in progress), November draft-ietf-avt-rtp-svc-16 (work in progress), December
2008. 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-02 (work in progress),
2008. January 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-02 (work in for MVC Video", draft-wang-avt-rtp-mvc-03 (work in
progress), August 2008. 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
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. Acknowledgements Appendix A. Acknowledgements
skipping to change at page 18, line 4 skipping to change at line 710
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
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 15 change blocks. 
30 lines changed or deleted 36 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/