idnits 2.17.1 draft-ietf-mmusic-decoding-dependency-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 657 has weird spacing: '...endency mdc...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 3, 2009) is 5494 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3388 (Obsoleted by RFC 5888) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-27) exists of draft-ietf-avt-rtp-svc-18 == Outdated reference: A later version (-04) exists of draft-ietf-mmusic-rfc3388bis-02 == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-09 == Outdated reference: A later version (-05) exists of draft-wang-avt-rtp-mvc-03 -- Obsolete informational reference (is this intentional?): RFC 3984 (Obsoleted by RFC 6184) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Schierl 3 Internet-Draft Fraunhofer HHI 4 Intended status: Standards Track S. Wenger 5 Expires: October 2, 2009 Nokia 6 April 3, 2009 8 Signaling media decoding dependency in Session Description Protocol 9 (SDP) 10 draft-ietf-mmusic-decoding-dependency-08 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 2, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This memo defines semantics that allow for signaling the decoding 49 dependency of different media descriptions with the same media type in 50 the Session Description Protocol (SDP). This is required, for example, 51 if media data is separated and transported in different network streams 52 as a result of the use of a layered or multiple descriptive media coding 53 process. 54 A new grouping type "DDP" -- decoding dependency -- is defined, to be 55 used in conjunction with RFC 3388 entitled "Grouping of Media Lines in 56 the Session Description Protocol". In addition, an attribute is 57 specified describing the relationship of the media streams in a "DDP" 58 group indicated by media identification attribute(s) and media format 59 description(s). 61 Table of Contents 63 1. Introduction .................................................. 4 64 2. Terminology ................................................... 5 65 3. Definitions ................................................... 5 66 4. Motivation, Use Cases, and Architecture ....................... 6 67 4.1. Motivation .................................................. 6 68 4.2. Use cases ................................................... 8 69 5. Signaling Media Dependencies .................................. 8 70 5.1. Design Principles ........................................... 8 71 5.2. Semantics ................................................... 9 72 5.2.1. SDP grouping semantics for decoding dependency ............ 9 73 5.2.2. "depend" attribute for dependency signaling per media-stream 74 ................................................................... 9 75 6. Usage of new semantics in SDP ................................ 11 76 6.1. Usage with the SDP Offer/Answer Model ...................... 11 77 6.2. Declarative usage .......................................... 12 78 6.3. Usage with AVP and SAVP RTP profiles ....................... 12 79 6.4. Usage with Capability Negotiation .......................... 12 80 6.5. Examples ................................................... 13 81 7. Security Considerations ...................................... 15 82 8. IANA Considerations .......................................... 15 83 9. Informative note on RFC 3388bis .............................. 16 84 10. References ................................................... 16 85 10.1. Normative References ....................................... 16 86 10.2. Informative References ..................................... 17 87 Appendix A. Acknowledgements .................................... 18 88 Authors' Addresses ............................................... 18 90 1. Introduction 92 An SDP session description may contain one or more media 93 descriptions, each identifying a single media stream. A media 94 description is identified by one "m=" line. Today, if more than one 95 "m=" lines exist indicating the same media type, a receiver cannot 96 identify a specific relationship between those media. 98 A Multiple Description Coding (MDC) or layered Media Bitstream 99 contains, by definition, one or more Media Partitions that are 100 conveyed in their own media stream. The cases we are interested in 101 are layered and MDC Bitstreams with two or more Media Partitions. 102 Carrying more than one Media Partition in its own session is one of 103 the key use cases for employing layered or MDC coded media. Senders, 104 network elements, or receivers can suppress 105 sending/forwarding/subscribing/decoding individual Media Partitions 106 and still preserve perhaps suboptimal, but still useful media 107 quality. 109 One property of all Media Bitstreams relevant to this memo is that 110 their Media Partitions have a well-defined usage relationship. For 111 example, in layered coding, "higher" Media Partitions are useless 112 without "lower" ones. In MDC coding, Media Partitions are 113 complementary -- the more Media Partitions one receives, the better a 114 reproduced quality may be. This document defines an SDP extension to 115 indicate such a decoding dependency. 117 Trigger for the present memo has been the standardization process of 118 the RTP payload format for the Scalable Video Coding extension to 119 ITU-T Rec. H.264 / MPEG-4 AVC [I-D.ietf-avt-rtp-svc]. When drafting 120 [I-D.ietf-avt-rtp-svc], it was observed that the aforementioned lack 121 in signaling support is one that is not specific to SVC, but applies 122 to all layered or MDC codecs. Therefore, this memo presents a 123 generic solution. Likely, the second technology utilizing the 124 mechanisms of this memo will be Multi-View video coding. In Multi 125 View Coding (MVC) [I-D.wang-avt-rtp-mvc] layered dependencies between 126 views are used to increase the coding efficiency, and, therefore, the 127 properties of MVC with respect to the SDP signaling are comparable to 128 those of SVC. 130 The mechanisms defined herein are media transport protocol dependent, 131 and applicable only in conjunction with the use of RTP [RFC3550]. 133 The SDP grouping of Media Lines of different media types is out of 134 scope of this memo. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in BCP 14, RFC 2119 141 [RFC2119]. 143 3. Definitions 145 Media stream: 146 As per [RFC4566]. 148 Media Bitstream: 149 A valid, decodable stream, containing all media partitions generated 150 by the encoder. A Media Bitstream normally conforms to a media 151 coding standard. 153 Media Partition: 154 A subset of a Media Bitstream intended for independent 155 transportation. An integer number of Media Partitions forms a Media 156 Bitstream. In layered coding, a Media Partition represents one or 157 more layers that are handled as a unit. In MDC coding, a Media 158 Partition represents one or more descriptions that are handled as a 159 unit. 161 Decoding dependency: 162 The class of relationships media partitions have to each other. At 163 present, this memo defines two decoding dependencies: layered coding 164 and multiple description coding. 166 Layered coding dependency: 167 Each Media Partition is only useful (i.e. can be decoded) when all of 168 the Media Partitions it depends on are available. The dependencies 169 between the Media Partitions therefore create a directed graph. 170 Note: normally, in layered coding, the more Media Partitions are 171 employed (following the rule above), the better a reproduced quality 172 is possible. 174 Multi description coding (MDC) dependency: 175 N of M Media Partitions are required to form a Media Bitstream, but 176 there is no hierarchy between these Media Partitions. Most MDC 177 schemes aim at an increase of reproduced media quality when more 178 media partitions are decoded. Some MDC schemes require more than one 179 Media Partition to form an Operation Point. 181 Operation Point: 182 In layered coding, a subset of a layered Media Bitstream that 183 includes all Media Partitions required for reconstruction at a 184 certain point of quality, error resilience, or another property, and 185 does not include any other Media Partitions. In MDC coding, a subset 186 of an MDC Media Bitstream that is compliant with the MDC coding 187 standard in question. 189 4. Motivation, Use Cases, and Architecture 191 4.1. Motivation 193 This memo is concerned with two types of decoding dependencies: 194 layered and multi-description. The transport of layered and multi 195 description coding share as key motivators the desire for media 196 adaptation to network conditions, i.e., related to bandwidth, error 197 rates, connectivity of endpoints in multicast or broadcast scenarios, 198 and similar. 200 o Layered decoding dependency: 202 In layered coding, the partitions of a Media Bitstream are known as 203 media layers or simply layers. One or more layers may be 204 transported in different media streams in the sense of [RFC4566]. 205 A classic use case is known as receiver-driven layered multicast, 206 in which a receiver selects a combination of media streams in 207 response to quality or bit-rate requirements. 209 Back in the mid 1990s, the then available layered media formats and 210 codecs envisioned primarily (or even exclusively) a one-dimensional 211 hierarchy of layers. That is, each so-called enhancement layer 212 referred to exactly one layer "below". The single exception has 213 been the base layer, which is self-contained. Therefore, the 214 identification of one enhancement layer fully specifies the 215 Operation Point of a layered coding scheme, including knowledge 216 about all the other layers that need to be decoded. 218 SDP [RFC4566] contains rudimentary support for exactly this use 219 case and media formats, in that it allows for signaling a range of 220 transport addresses in a certain media description. By definition, 221 a higher transport address identifies a higher layer in the one- 222 dimensional hierarchy. A receiver needs only to decode data 223 conveyed over this transport address and lower transport addresses 224 to decode this Operation Point. 226 Newer media formats depart from this simple one-dimensional 227 hierarchy, in that highly complex (at least tree-shaped) dependency 228 hierarchies can be implemented. Compelling use cases for these 229 complex hierarchies have been identified by industry. Support for 230 it is therefore desirable. However, SDP, in its current form, does 231 not allow for the signaling of these complex relationships. 232 Therefore, receivers cannot make an informed decision on which 233 layers to subscribe (in case of layered multicast). 235 Layered decoding dependencies may also exist in a Multi View Coding 236 environment. Views may be coded using inter-view dependencies to 237 increase coding efficiency. This results in Media Bitstreams, 238 which logically may be separated into Media Partitions representing 239 different views of the reconstructed video signal. These Media 240 Partitions cannot be decoded independently, and, therefore, other 241 Media Partitions are required for reconstruction. To express this 242 relationship, the signaling needs to express the dependencies of 243 the views which in turn are Media Partitions in the sense of this 244 document. 246 o Multi descriptive decoding dependency: 248 In the most basic form of MDC, each Media Partition forms an 249 independent representation of the media. That is, decoding of any 250 of the Media Partitions yields useful reproduced media data. When 251 more than one Media Partition is available, then a decoder can 252 process them jointly, and the resulting media quality increases. 253 The highest reproduced quality is available if all original Media 254 Partitions are available for decoding. 256 More complex forms of multiple description coding can also be 257 envisioned, i.e. where, as a minimum, N out of M total Media 258 Partitions need to be available to allow meaningful decoding. 260 MDC has not yet been embraced heavily by the media standardization 261 community, though it is subject of a lot of academic research. As 262 an example, we refer to [MDC]. 264 In this memo, we cover MDC because we a) envision that MDC media 265 formats will come into practical use within the lifetime of this 266 memo, and b) the solution for its signaling is very similar to the 267 one of layered coding. 269 o Other decoding dependency relationships: 271 At the time of writing, no decoding dependency relationships beyond 272 the two mentioned above have been identified that would warrant 273 standardization. However, the mechanisms of this memo could be 274 extended by introducing new codepoints for new decoding dependency 275 types. If such an extension becomes necessary, as formally 276 required in section 5.2.2, the new decoding dependency type MUST be 277 documented in an IETF standard's track document. 279 4.2. Use cases 281 o Receiver driven layered multicast: 283 This technology is discussed in [RFC3550] and references therein. 284 We refrain from elaborating further; the subject is well known and 285 understood. 287 o Multiple end-to-end transmission with different properties: 289 Assume a unicast and point-to-point topology, wherein one endpoint 290 sends media to another. Assume further that different forms of 291 media transmission are available. The difference may lie in the 292 cost of the transmission (free, charged), in the available 293 protection (unprotected/secure), in the quality of service 294 (guaranteed quality / best effort), or other factors. 296 Layered and MDC coding allow to match the media characteristics to 297 the available transmission path(s). For example, in layered 298 coding, it makes sense to convey the base layer over high QoS. 299 Enhancement layers, on the other hand, can be conveyed over best 300 effort, as they are "optional" in their characteristic -- nice to 301 have, but non-essential for media consumption. In a different 302 scenario, the base layer may be offered in a non-encrypted session 303 as a free preview. An encrypted enhancement layer references this 304 base layer and allows optimal quality play-back; however, it is 305 only accessible to users who have the key, which may have been 306 distributed by a conditional access mechanism. 308 5. Signaling Media Dependencies 310 5.1. Design Principles 312 The dependency signaling is only feasible between media descriptions 313 described with an "m="-line and with an assigned media identification 314 attribute ("mid"), as defined in [RFC3388]. All media descriptions 315 grouped according to this specification MUST have the same media 316 type. Other dependencies relations expressed by SDP grouping have to 317 be addressed in other specifications. A media description MUST NOT 318 be part of more than one group of the grouping type defined in this 319 specification. 321 5.2. Semantics 323 5.2.1. SDP grouping semantics for decoding dependency 325 This specification defines a new grouping semantic 326 Decoding Dependency "DDP": 328 DDP associates a media stream, identified by its mid attribute, with 329 a DDP group. Each media stream MUST be composed of an integer number 330 of Media Partitions. A media stream is identified by a session- 331 unique media format description (RTP payload type number) within a 332 media description. In a DDP group, all media streams MUST have the 333 same type of decoding dependency (as signaled by the attribute 334 defined in 5.2.2). All media streams MUST contain at least one 335 Operation Point. The DDP group type informs a receiver about the 336 requirement for handling the media streams of the group according to 337 the new media level attribute "depend", as defined in 5.2.2. . 339 When using multiple codecs, e.g. for Offer/Answer model, the media 340 streams MUST have the same dependency structure, regardless which 341 media format description (RTP payload type number) is used. 343 5.2.2. "depend" attribute for dependency signaling per media-stream 345 This memo defines a new media-level attribute, "depend", with the 346 following ABNF [RFC5234]. The identification-tag is defined in 347 [RFC3388]. In the following ABNF, fmt, token, SP, and CRLF are used 348 as defined in [RFC4566]. 350 depend-attribute = 351 "a=depend:" dependent-fmt SP dependency-tag 352 *(";" SP dependent-fmt SP dependency-tag) CRLF 354 dependency-tag = 355 dependency-type *1( SP identification-tag ":" 356 fmt-dependency *("," fmt-dependency )) 358 dependency-type = "lay" 359 / "mdc" 360 / token 362 dependent-fmt = fmt 363 fmt-dependency = fmt 365 dependency-tag, indicates one or more dependencies of one dependent- 366 fmt in the media description. These dependencies are signaled as 367 fmt-dependency values, which indicate fmt values of other media 368 descriptions. These other media descriptions are identified by their 369 identification-tag values in the depend-attribute. There MUST be 370 exactly one dependency-tag indicated per dependent-fmt. 372 dependent-fmt, indicates the media format description, as defined in 373 [RFC4566], that depends on one or more media format description in 374 the media description indicated by the value of identification-tag 375 within the dependency-tag. 377 fmt-dependency, indicates the media format description in the media 378 description identified by the identification-tag within the 379 dependency-tag, which the dependent-fmt of the dependent media 380 description depends on. In case a list of fmt-dependency values is 381 given, any element of the list is sufficient to satisfy the 382 dependency, at the choice of the decoding entity. 384 The depend-attribute describes the decoding dependency. The depend- 385 attribute MUST be followed by a sequence of dependent-fmt and the 386 corresponding dependency-tag fields which identify all related media 387 format descriptions in all related media descriptions of the 388 dependent-fmt. The attribute MAY be used with multicast as well as 389 with unicast transport addresses. The following dependency-types 390 values are defined in this memo: 392 o lay: Layered decoding dependency -- identifies the described media 393 stream as one or more Media Partitions of a layered Media 394 Bitstream. When "lay" is used, all media streams required for 395 decoding the Operation Point MUST be identified by identification- 396 tag and fmt-dependency following the "lay" string. 398 o mdc: Multi descriptive decoding dependency -- signals that the 399 described media stream is part of a set of a MDC Media Bitstream. 400 By definition, at least N out of M media streams of the group need 401 to be available to from an Operation Point. The values of N and M 402 depend on the properties of the Media Bitstream and are not 403 signaled within this context. When "mdc" is used, all required 404 media streams for the Operation Point MUST be identified by 405 identification-tag and fmt-dependency following the "mdc" string. 407 Further dependency types MUST be defined in a standards-track 408 document. 410 6. Usage of new semantics in SDP 412 6.1. Usage with the SDP Offer/Answer Model 414 The backward compatibility in offer / answer is generally handled as 415 specified in [RFC3388], section 8.4, as summarized below. 417 Depending on the implementation, a node that does not understand DDP 418 grouping (either does not understand line grouping at all, or just 419 does not understand the DDP semantics) SHOULD respond to an offer 420 containing DDP grouping either (1) with an answer that ignores the 421 grouping attribute or (2) with a refusal to the request (e.g., 488 422 Not acceptable here or 606 Not acceptable in SIP). 424 In case (1), if the original sender of the offer still wishes to 425 establish communications, it SHOULD generate a new offer with a 426 single media stream that represents an Operation Point. 427 Note: in most cases, this will be the base layer of a layered Media 428 Bitstream, equally possible are Operation Points containing a set of 429 enhancement layers as long as all are part of a single media stream. 430 In case (2), if the sender of the original offer has identified that 431 the refusal to the request is caused by the use of DDP grouping, and 432 if the sender of the offer still wishes to establish the session, it 433 SHOULD re-try the request with an offer including only a single media 434 stream. 436 If the answerer understands the DDP semantics, it is necessary to 437 take the "depend" attribute into consideration in the offer/answer 438 procedure. The main rule for the "depend" attribute is that the 439 offerer decides the number of media streams and the dependency 440 between them. The answerer cannot change the dependency relations. 442 For unicast sessions where the answerer receives media, i.e. for 443 offers including media streams that have a directionality indicated 444 by "sendonly", "sendrecv" or have no directionality indicated, the 445 answerer MAY remove media operation points. The answerer MUST use the 446 dependency relations provided in the offer when sending media. The 447 answerer MAY send according to all of the operation points present in 448 the offer, even if the answerer has removed some of those operation 449 points. Thus an answerer can limit the number of operation points 450 being delivered to the answerer while the answerer can still send 451 media to the offerer using all of the operation points indicated in 452 the offer. 454 For multicast sessions, the answerer MUST accept all operation points 455 and their related decoding dependencies or MUST remove non-accepted 456 operation points completely. Due to the nature of multicast, the 457 receiver can select which operation points, it actually receives and 458 processes. For multicast sessions that allow the answerer to also 459 send data, the answerer MAY send all of the offered operations 460 points. 462 In any case, if the answerer cannot accept one or more offered 463 operation points and/or the media stream's dependencies, the answerer 464 MAY re-invite with an offer including acceptable operation points 465 and/or dependencies. 467 Note: Applications may limit the possibilities to perform a re- 468 invite. The previous offer is also a good hint to the capabilities of 469 the other agent. 471 6.2. Declarative usage 473 If an RTSP receiver understands signaling according to this memo, it 474 SHALL setup all media streams that are required to decode the 475 Operation Point of its choice. 477 If an RTSP receiver does not understand the signaling defined within 478 this memo, it falls back to normal SDP processing. Two likely cases 479 have to be distinguished: (1) if at least one of the media types 480 included in the SDP is within the receiver's capabilities, it selects 481 among those candidates according to implementation specific criteria 482 for setup, as usual. (2) If none of the media type included in the 483 SDP can be processed, then obviously no setup can occur. 485 6.3. Usage with AVP and SAVP RTP profiles 487 The signaling mechanisms defined in this draft MUST NOT be used to 488 negotiate between using AVP [RFC3551] and SAVP [RFC3711] profile for 489 RTP. But both profiles MAY be used separately or jointly with the 490 signaling mechanism defined in this draft. 492 6.4. Usage with Capability Negotiation 494 This memo does not cover the interaction with Capability Negotiation 495 [I-D.ietf-mmusic-sdp-capability-negotiation]. This issue is for 496 further study and will be addressed in a different memo. 498 6.5. Examples 500 a.) Example for signaling layered decoding dependency: 502 The example below shows a session description with three media 503 descriptions, all of type video and with layered decoding 504 dependency ("lay"). Each of the media description includes two 505 possible media format descriptions with different encoding 506 parameters as, e.g. "packetization-mode" (not shown in the 507 example) for the media subtypes "H264" and "H264-SVC" given by 508 the "a=rtpmap:"-line. The first media description includes two 509 H264 payload types as media format descriptions, "96" and "97", 510 as defined in [RFC3984] and represents the base layer operation 511 point (identified by "mid:L1"). The two other media 512 descriptions (identified by "mid:L2" and "mid:L3") include H264- 513 SVC payload types as defined in [I-D.ietf-avt-rtp-svc], which 514 contain enhancements to the base layer operation point or the 515 first enhancement layer operation point (media description 516 identified by "mid:L2"). 517 Note: The SDP examples in [I-D.ietf-avt-rtp-svc] use numbers for 518 the mid values instead of using tokens like "L1", "L2" and "L3". 519 The example shows the dependencies of the media format 520 descriptions of the different media descriptions indicated by 521 "DDP" grouping, "mid" and "depend" attributes. The "depend" 522 attribute is used with the decoding dependency type "lay" 523 indicating layered decoding dependency. For example, the third 524 media description ("m=video 40004...") indentified by "mid:L3" 525 has different dependencies on the media format descriptions of 526 the two other media descriptions: 527 Media format description "100" depends on media format 528 description "96" or "97" of the media description indentified by 529 "mid:L1". This is an exclusive-OR, i.e. payload type "100" may 530 be used with payload type "96" or with "97", but one of the two 531 combinations is required for decoding payload type "100". 532 For media format description "101", it is different. This one 533 depends on two of the other media descriptions at the same time, 534 i.e. it depends on media format description "97" of the media 535 description indentified by "mid:L1" and it also depends on media 536 format description "99" of the media description indentified by 537 "mid:L2". For decoding media format description "101" both 538 media format description "97" and media format description "99" 539 are required by definition. 541 v=0 542 o=svcsrv 289083124 289083124 IN IP4 host.example.com 543 s=LAYERED VIDEO SIGNALING Seminar 544 t=0 0 545 c=IN IP4 192.0.2.1/127 546 a=group:DDP L1 L2 L3 547 m=video 40000 RTP/AVP 96 97 548 b=AS:90 549 a=framerate:15 550 a=rtpmap:96 H264/90000 551 a=rtpmap:97 H264/90000 552 a=mid:L1 553 m=video 40002 RTP/AVP 98 99 554 b=AS:64 555 a=framerate:15 556 a=rtpmap:98 H264-SVC/90000 557 a=rtpmap:99 H264-SVC/90000 558 a=mid:L2 559 a=depend:98 lay L1:96,97; 99 lay L1:97 560 m=video 40004 RTP/AVP 100 101 561 b=AS:128 562 a=framerate:30 563 a=rtpmap:100 H264-SVC/90000 564 a=rtpmap:101 H264-SVC/90000 565 a=mid:L3 566 a=depend:100 lay L1:96,97; 101 lay L1:97 L2:99 568 b.) Example for signaling of multi descriptive decoding dependency: 570 The example shows a session description with three media 571 descriptions, all of type video and with multi descriptive 572 decoding dependency. Each of the media descriptions includes 573 one media format description. The example shows the 574 dependencies of the media format descriptions of the different 575 media descriptions indicated by "DDP" grouping, "mid" and 576 "depend" attributes. The "depend" attribute is used with the 577 decoding dependency type "mdc" indicating layered decoding 578 dependency. For example, media format description "104" in the 579 media description ("m=video 40000...") with "mid:M1" depends on 580 the two other media descriptions. It depends on media format 581 description "105" of media description with "mid:M2" and also 582 depends on media format description "106" of media description 583 with "mid:M3". In case of the multi descriptive decoding 584 dependency, media format description "105" and "106" can be used 585 by definition to enhance the decoding process of media format 586 description "104", but they are not required for decoding. 588 v=0 589 o=mdcsrv 289083124 289083124 IN IP4 host.example.com 590 s=MULTI DESCRIPTION VIDEO SIGNALING Seminar 591 t=0 0 592 c=IN IP4 192.0.2.1/127 593 a=group:DDP M1 M2 M3 594 m=video 40000 RTP/AVP 104 595 a=mid:M1 596 a=depend:104 mdc M2:105 M3:106 597 m=video 40002 RTP/AVP 105 598 a=mid:M2 599 a=depend:105 mdc M1:104 M3:106 600 m=video 40004 RTP/AVP 106 601 a=mid:M3 602 a=depend:106 mdc M1:104 M2:105 604 7. Security Considerations 606 All security implications of SDP apply. 608 There may be a risk of manipulation the dependency signaling of a 609 session description by an attacker. This may mislead a receiver or 610 middle box, e.g. a receiver may try to compose a media bitstream out 611 of several RTP packet streams that does not form an Operation Point, 612 although the signaling made it believe it would form a valid 613 Operation Point, with potential fatal consequences for the media 614 decoding process. It is recommended that the receiver SHOULD perform 615 an integrity check on SDP and follow the security considerations of 616 SDP to only trust SDP from trusted sources. 618 8. IANA Considerations 620 The following contact information shall be used for all registrations 621 included here: 623 Contact: Thomas Schierl 624 mailto:mail@thomas-schierl.de 625 tel:+49-30-31002-227 627 The following semantics have been registered by IANA in Semantics for 628 the "group" SDP Attribute under SDP Parameters 629 http://www.iana.org/assignments/sdp-parameters. 631 Semantics Token Reference 632 ------------------- ----- --------- 633 Decoding Dependency DDP RFC XXXX 634 The SDP media level attribute "depend" has been registered by IANA in 635 Semantics for "att-field (media level only)". The registration 636 procedure in section 8.2.4 of [RFC4566] applies. 638 SDP Attribute ("att-field (media level only)"): 640 Attribute name: depend 641 Long form: decoding dependency 642 Type of name: att-field 643 Type of attribute: media level only 644 Subject to charset: no 645 Purpose: RFC XXXX 646 Reference: RFC XXXX 647 Values: see this document and registrations below. 649 The following semantics have been registered by IANA in Semantics for 650 the "depend" SDP Attribute under SDP Parameters: 652 Semantics of the "depend" SDP attribute: 654 Semantics Token Reference 655 ---------------------------- ----- --------- 656 Layered decoding dependency lay RFC XXXX 657 Multi descriptive decoding dependency mdc RFC XXXX 659 New registrations for semantics of the "depend" SDP attribute are 660 added by the "Specification Required" policy as defined in [RFC5226]. 662 9. Informative note on RFC 3388bis 664 Currently, there is ongoing work on [I-D.ietf-mmusic-rfc3388bis]. In 665 [I-D.ietf-mmusic-rfc3388bis], the grouping mechanism is extended in a 666 way that a media description can be part of more than one group of 667 the same grouping type in the same session description. However, 668 media descriptions grouped by this draft must be at most part of one 669 group of the type "DDP" in the same session description. 671 10. References 673 10.1. Normative References 675 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 676 Requirement Levels", BCP 14, RFC 2119, March 1997. 678 [RFC3388] Camarillo, G., Holler, J., and H. Schulzrinne, "Grouping of 679 Media Lines in the Session Description Protocol (SDP)", 680 RFC 3388, December 2002. 681 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 682 Jacobson, "RTP: A Transport Protocol for Real-Time 683 Applications", STD 64, RFC 3550, July 2003. 684 [RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and 685 Video Conferences with Minimal Control", STD 65, RFC 3551, 686 July 2003. 687 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 688 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 689 RFC 3711, March 2004. 690 [RFC4566] Handley, M., Jacobson, V, and C. Perkins, "SDP: Session 691 Description Protocol", RFC 4566, July 2006. 692 [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for Writing an 693 IANA Considerations Section in RFCs", BCP26, RFC5226, May 694 2008 695 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 696 Specifications: ABNF", RFC 5234, January 2008. 698 10.2. Informative References 700 [I-D.ietf-avt-rtp-svc] 701 Wenger, S., Wang Y.-K., T. Schierl and A. Eleftheriadis, 702 "RTP Payload Format for SVC Video", 703 draft-ietf-avt-rtp-svc-18 (work in progress), March 704 2009. 705 [I-D.ietf-mmusic-rfc3388bis] 706 Camarillo, G "The SDP (Session Description Protocol) 707 Grouping Framework", 708 draft-ietf-mmusic-rfc3388bis-02 (work in progress), January 709 2009. 710 [I-D.ietf-mmusic-sdp-capability-negotiation] 711 Andreasen, F., "SDP Capability Negotiation", 712 draft-ietf-mmusic-sdp-capability-negotiation-09, (work in 713 progress), July 2008. 714 [I-D.wang-avt-rtp-mvc] 715 Wang, Y.-K. and T. Schierl, "RTP Payload Format 716 for MVC Video", draft-wang-avt-rtp-mvc-03 (work in 717 progress), February 2009. 718 [MDC] Vitali, A., Borneo, A., Fumagalli, M., and R. Rinaldo, 719 "Video over IP using Standard-Compatible Multiple 720 Description Coding: an IETF proposal", Packet Video 721 Workshop, April 2006, Hangzhou, China. 722 [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,M., 723 and Singer, D., "RTP Payload Format for H.264 Video", RFC 724 3984, February 2005. 726 Appendix A. Acknowledgements 728 Funding for the RFC Editor function is currently provided by the 729 Internet Society. Further, the author Thomas Schierl of Fraunhofer 730 HHI is sponsored by the European Commission under the contract number 731 FP7-ICT-214063, project SEA. 732 We want to also thank Magnus Westerlund, Joerg Ott, Ali Begen, Dan 733 Wing, Helmut Burklin, and Jean-Francois Mule for their valuable and 734 constructive comments to this memo. 736 Authors' Addresses 738 Thomas Schierl 739 Fraunhofer HHI 740 Einsteinufer 37 741 D-10587 Berlin 742 Germany 744 Phone: +49-30-31002-227 745 Email: mail@thomas-schierl.de 747 Stephan Wenger 748 Nokia 749 955 Page Mill Road 750 Palo Alto, CA, 94304 751 USA 753 Phone: +1-650-862-7368 754 Email: stewe@stewe.org 756 This document may contain material from IETF Documents or IETF 757 Contributions published or made publicly available before November 758 10, 2008. The person(s) controlling the copyright in some of this 759 material may not have granted the IETF Trust the right to allow 760 modifications of such material outside the IETF Standards Process. 761 Without obtaining an adequate license from the person(s) 762 controlling the copyright in such materials, this document may not 763 be modified outside the IETF Standards Process, and derivative 764 works of it may not be created outside the IETF Standards Process, 765 except to format it for publication as an RFC or to translate it 766 into languages other than English.