RFC 5583
Signaling Media Decoding Dependency in the Session Description Protocol (SDP)
RFC 5583: Signaling Media Decoding Dependency in the Session Description Protocol (SDP) 🎀
Okay bestie, let's get the title block out of the way first 💅 This one is from the Network Working Group. The authors are T. Schierl (Fraunhofer HHI) and S. Wenger (Independent). It's a Standards Track document, dated July 2009. The header doesn't list any RFCs that it obsoletes or updates 🦋
Abstract ✨
Okay so this memo defines semantics for signaling the decoding dependency between different media descriptions that have the same media type in SDP 🌸 This is literally required when media data gets split up and sent over different network streams, which happens when you use a layered or multiple descriptive media coding process 🧚
The memo adds a new grouping type called "DDP", which stands for decoding dependency 👑 You use it together with RFC 3388, "Grouping of Media Lines in the Session Description Protocol". It also adds an attribute that describes how the media streams in a "DDP" group relate to each other. You identify those streams using media identification attribute(s) and media format description(s) 💜
Status of This Memo
This document is a standards track protocol for the Internet community, and it's basically asking everyone to talk about it and suggest improvements 🫶 If you want to know where this protocol stands in standardization and status, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🌈
Copyright Notice
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, as they were in effect on the date this document was published (http://trustee.ietf.org/license-info). Please read these carefully, because they spell out your rights and restrictions for this document 🙈
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and you can't create derivative works of it outside that process. The one exception is formatting it for publication as an RFC, or translating it into languages other than English 💅
Table of Contents 🍓
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Definitions .....................................................4
4. Motivation, Use Cases, and Architecture .........................5
4.1. Motivation .................................................5
4.2. Use Cases ..................................................7
5. Signaling Media Dependencies ....................................7
5.1. Design Principles ..........................................7
5.2. Semantics ..................................................8
5.2.1. SDP Grouping Semantics for Decoding Dependency ......8
5.2.2. "depend" Attribute for Dependency Signaling
per Media-Stream ....................................8
6. Usage of New Semantics in SDP ..................................10
6.1. Usage with the SDP Offer/Answer Model .....................10
6.2. Declarative usage .........................................12
6.3. Usage with AVP and SAVP RTP Profiles ......................12
6.4. Usage with Capability Negotiation .........................12
6.5. Examples ..................................................12
7. Security Considerations ........................................15
8. IANA Considerations ............................................15
9. Informative Note on "The SDP (Session Description Protocol)
Grouping Framework" ............................................16
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................17
Appendix A. Acknowledgements .....................................181. Introduction 🦋
Okay so an SDP session description can hold one or more media descriptions, and each one identifies a single media stream 🌸 Each media description is identified by one "m=" line. Right now, if you've got more than one "m=" line for the same media type, a receiver can't figure out how those media are related to each other 😭
A Multiple Description Coding (MDC) or layered Media Bitstream, by definition, has one or more Media Partitions, and each one travels in its own media stream 🧚 We're specifically interested in layered and MDC Bitstreams that have two or more Media Partitions. Carrying more than one Media Partition in its own session is one of the big reasons anyone uses layered or MDC-coded media ✨ Senders, network elements, or receivers can hold back on sending, forwarding, subscribing to, or decoding individual Media Partitions, and the media still keeps a quality that's maybe not optimal, but is still useful 💖
Here's the thing: every Media Bitstream relevant to this memo has Media Partitions with a well-defined usage relationship 👑 In layered coding, "higher" Media Partitions are useless without the "lower" ones. In MDC coding, Media Partitions are complementary, so the more of them you receive, the better the reproduced quality may be 🔥 This document defines an SDP extension to signal that kind of decoding dependency 💅
The reason this memo exists is the standardization process for the RTP payload format for the Scalable Video Coding (SVC) extension to ITU-T Rec. H.264 / MPEG-4 AVC [AVT-RTP-SVC] 🎀 While drafting [AVT-RTP-SVC], people noticed that this lack of signaling support isn't specific to SVC. It applies to all layered or MDC codecs, so this memo presents a generic solution 🌈 The second technology that will probably use the mechanisms in this memo is Multi-View video coding. In Multi-View Coding (MVC) [AVT-RTP-MVC], layered dependencies between views are used to increase coding efficiency, so the properties of MVC with respect to SDP signaling are comparable to those of SVC 🦋
The mechanisms defined here depend on the media transport protocol, and they only apply when you're using RTP [RFC3550] 🍓
Grouping Media Lines of different media types in SDP is out of scope for this memo 🙈
2. Terminology 💜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] ✨
3. Definitions 🧚
Media stream: As per [RFC4566] 🌸
Media Bitstream: A valid, decodable stream that contains all Media Partitions generated by the encoder 💖 A Media Bitstream normally conforms to a media coding standard 📚
Media Partition: A subset of a Media Bitstream that's meant to be transported independently 🫶 An integer number of Media Partitions forms a Media Bitstream. In layered coding, a Media Partition represents one or more layers that get handled as a unit. In MDC coding, a Media Partition represents one or more descriptions that get handled as a unit 🎀
Decoding dependency: The class of relationships that Media Partitions have to each other 🔥 Right now, this memo defines two decoding dependencies: layered coding and Multiple Description Coding 👑
Layered coding dependency: Each Media Partition is only useful (meaning it can be decoded) when all of the Media Partitions it depends on are available 😭 The dependencies between Media Partitions therefore create a directed graph. Note: normally, in layered coding, the more Media Partitions you use (following the rule above), the better the reproduced quality can be ✨
Multiple Description Coding (MDC) dependency: N of M Media Partitions are required to form a Media Bitstream, but there's no hierarchy between these Media Partitions 🦋 Most MDC schemes aim to increase reproduced media quality when more Media Partitions get decoded. Some MDC schemes need more than one Media Partition to form an Operation Point 💜
Operation Point: In layered coding, a subset of a layered Media Bitstream that includes all the Media Partitions needed for reconstruction at a certain point of quality, error resilience, or some other property, and that doesn't include any other Media Partitions. In MDC coding, a subset of an MDC Media Bitstream that complies with the MDC coding standard in question 🌈
4. Motivation, Use Cases, and Architecture 🌸
4.1. Motivation ✨
okay so this memo is about two kinds of decoding dependencies 🧚: layered and multi-description. Both are about letting media bend to whatever the network is doing right now (bandwidth, error rates, endpoint connectivity in multicast or broadcast, and so on) 💅
- Layered decoding dependency:
In layered coding, the pieces of a Media Bitstream are called media layers, or just layers 🎀. One or more layers can ride in different media streams in the sense of [RFC4566]. The classic example is receiver-driven layered multicast, where a receiver picks a combo of media streams based on its quality or bit-rate needs 🦋
Back in the mid 1990s, the layered formats and codecs were giving one-dimensional hierarchy, or even exclusively that 😭. Each enhancement layer pointed at exactly one layer "below" it. The only exception was the base layer, which is self-contained. So naming one enhancement layer fully pins down the Operation Point of a layered coding scheme, including everything else that has to be decoded 🧠
SDP [RFC4566] has basic support for exactly this use case and these media formats, because it lets you signal a range of transport addresses in a media description. By definition, a higher transport address means a higher layer in that one-dimensional hierarchy. A receiver only needs to decode the data on this transport address and the lower ones to decode this Operation Point ✨
Newer media formats ditch that simple line, since highly complex (at least tree-shaped) dependency hierarchies can be implemented. Industry has identified compelling use cases for these, so support is desirable. BUT SDP, in its current form, can't signal these complex relationships, so receivers can't make an informed call on which layers to subscribe to (in case of layered multicast) 😤
Layered decoding dependencies may also show up in a Multi-View Coding environment 👑. Views can be coded using inter-view dependencies to increase coding efficiency. This results in Media Bitstreams that can logically be split into Media Partitions representing different views of the reconstructed video signal. These Media Partitions can't be decoded independently, so other Media Partitions are required for reconstruction. To express this, the signaling needs to show the dependencies of the views, which are Media Partitions in the sense of this document 🌈
- Multiple descriptive decoding dependency:
In the most basic form of MDC, each Media Partition is an independent representation of the media. Decoding any one of them gives you useful reproduced media data 🍓 When more than one Media Partition is available, a decoder can process them jointly, and the resulting media quality goes up. The highest reproduced quality is available when all original Media Partitions are available for decoding 💜
More complex forms of Multiple Description Coding can also be envisioned, where, as a minimum, N-out-of-M total Media Partitions need to be available to allow meaningful decoding 🧚
MDC hasn't been embraced heavily by the media standardization community yet, even though it's the subject of a lot of academic research. As an example, we refer to [MDC] 📚
In this memo, we cover MDC because we a) envision that MDC media formats will come into practical use within the lifetime of this memo, and b) the solution for its signaling is very similar to the one for layered coding 🫶
- Other decoding dependency relationships:
At the time of writing, no decoding dependency relationships beyond the two above have been identified that would warrant standardization 🙈 However, the mechanisms of this memo could be extended by introducing new codepoints for new decoding dependency types. If such an extension becomes necessary, as formally required in Section 5.2.2, the new decoding dependency type MUST be documented in an IETF Standards-Track document 🔥
the new decoding dependency type MUST be documented in an IETF Standards-Track document. no skipping this step, bestie 💀
4.2. Use Cases 🌸
- Receiver-driven layered multicast:
This technology is discussed in [RFC3550] and the references therein. We're not going to elaborate further, since the subject is well known and well understood 🙌
- Multiple end-to-end transmission with different properties:
Picture a unicast, point-to-point setup where one endpoint sends media to another 💌 Assume different forms of media transmission are available. The difference might be the cost of the transmission (free or charged), the available protection (unprotected or secure), the quality of service (QoS) (guaranteed quality or best effort), or other factors ✨
Layered and MDC coding lets you match the media characteristics to the available transmission path(s) 🎯 For example, in layered coding it makes sense to convey the base layer over high QoS. Enhancement layers, on the other hand, can be conveyed over best effort, since they're "optional" in their characteristic: nice to have, but non-essential for media consumption 🍒 In a different scenario, the base layer might be offered in a non-encrypted session as a free preview. An encrypted enhancement layer references this base layer and allows optimal quality play-back, but it's only accessible to users who have the key, which may have been distributed by a conditional access mechanism 🔐
5. Signaling Media Dependencies 🎀
5.1. Design Principles 🧁
The dependency signaling is only feasible between media descriptions described with an "m="-line and with an assigned media identification attribute ("mid"), as defined in [RFC3388] 🦋 All media descriptions grouped according to this specification MUST have the same media type. Other dependency relations expressed by SDP grouping have to be addressed in other specifications. A media description MUST NOT be part of more than one group of the grouping type defined in this specification 🙅♀️
5.2. Semantics 💖
5.2.1. SDP Grouping Semantics for Decoding Dependency 👑
This specification defines a new grouping semantic, Decoding Dependency "DDP" 🎉
DDP associates a media stream, identified by its mid attribute, with a DDP group. Each media stream MUST be composed of an integer number of Media Partitions. A media stream is identified by a session-unique media format description (RTP payload type number) within a media description. In a DDP group, all media streams MUST have the same type of decoding dependency (as signaled by the attribute defined in Section 5.2.2). All media streams MUST contain at least one Operation Point. The DDP group type informs a receiver about the requirement for handling the media streams of the group according to the new media level attribute "depend", as defined in Section 5.2.2 🫶
When using multiple codecs, e.g., for the Offer/Answer model, the media streams MUST have the same dependency structure, regardless of which media format description (RTP payload type number) is used 🔥
5.2.2. "depend" Attribute for Dependency Signaling per Media-Stream ✨
This memo defines a brand-new media-level attribute called "depend" 🦋. Its grammar is written in ABNF [RFC5234]. The identification-tag comes from [RFC3388], and fmt, token, SP, and CRLF all mean what they mean in [RFC4566]. Here's the grammar, copyright block and all 💅
Copyright (c) 2009 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the
distribution.
- Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
depend-attribute =
"a=depend:" dependent-fmt SP dependency-tag
*(";" SP dependent-fmt SP dependency-tag) CRLF
dependency-tag =
dependency-type *1( SP identification-tag ":"
fmt-dependency *("," fmt-dependency ))
dependency-type = "lay"
/ "mdc"
/ token
dependent-fmt = fmt
fmt-dependency = fmtSo a dependency-tag describes the dependencies of one dependent-fmt in the media description 🎀 Those dependencies are written as fmt-dependency values, which are the fmt values of other media descriptions. Those other descriptions are found by their identification-tag values in the depend-attribute. There MUST be exactly one dependency-tag per dependent-fmt, no exceptions bestie 🙈
dependent-fmt is the media format description (from [RFC4566]) that depends on one or more format descriptions in the media description named by the identification-tag inside the dependency-tag 🌸
fmt-dependency is the format description, inside the media description named by the identification-tag, that the dependent-fmt relies on 🧚 If you've got a list of fmt-dependency values, ANY one of them is enough to satisfy the dependency, and the decoding entity gets to pick which one 👑
The depend-attribute is what actually describes the decoding dependency ✨ It MUST be followed by a sequence of dependent-fmt and their matching dependency-tag fields, which together identify every related media format description in every related media description of the dependent-fmt. It MAY be used with multicast as well as unicast transport addresses 🌈 The dependency types defined in this memo are:
lay: layered decoding dependency 🍓 This means the stream is one or more Media Partitions of a layered Media Bitstream. When "lay" is used, every media stream needed to decode the Operation Point MUST be identified by identification-tag and fmt-dependency right after the "lay" string.mdc: multi-descriptive decoding dependency 💜 This means the stream is part of a set of MDC Media Bitstream. The rule is at least N-out-of-M media streams of the group have to be available from an Operation Point. The values of N and M depend on the properties of the Media Bitstream and aren't signaled in this context. When "mdc" is used, every required media stream for the Operation Point MUST be identified by identification-tag and fmt-dependency right after the "mdc" string.
Last but not least: dependency types MUST be defined in a Standards-Track document 📜 No freelancing new types, periodt 💅
6. Usage of New Semantics in SDP 🎀
6.1. Usage with the SDP Offer/Answer Model 🫶
Backward compatibility in Offer/Answer is mostly handled the way [RFC3388] describes in Section 8.4 of [RFC3388], so here's the quick version 💖
If a node doesn't understand DDP grouping (maybe it doesn't get line grouping at all, or it just doesn't get the DDP semantics), it SHOULD respond to an offer with DDP grouping in one of two ways: (1) with an answer that ignores the grouping attribute, or (2) with a refusal, like 488 Not acceptable here or 606 Not acceptable in SIP 😭
In case (1), if the original offerer still wants to connect, it SHOULD generate a new offer with a single media stream that represents an Operation Point. Note: most of the time this will be the base layer of a layered Media Bitstream, but Operation Points made of a set of enhancement layers are also possible, as long as they're all part of one single media stream 🧁 In case (2), if the offerer figures out that the refusal was caused by DDP grouping, and still wants the session, it SHOULD retry the request with an offer that includes just a single media stream 🔁
If the answerer does understand the DDP semantics, the "depend" attribute has to be considered during the Offer/Answer procedure 🧐 The main rule is that the offerer decides how many media streams there are and how they depend on each other. The answerer cannot change the dependency relations, babe 🚫
For unicast sessions where the answerer receives media (so offers with a directionality of "sendonly", "sendrecv", or no directionality at all), the answerer MAY remove media Operation Points 🦋 The answerer MUST use the dependency relations from the offer when it sends media. It MAY send according to all of the Operation Points in the offer, even if it removed some of them. So an answerer can limit how many Operation Points it receives, while still sending media to the offerer using every Operation Point in the offer. Main character move 👑
For multicast sessions, the answerer MUST accept all Operation Points and their related decoding dependencies, or MUST remove the non-accepted Operation Points completely. Because of how multicast works, the receiver gets to choose which Operation Points it actually receives and processes 🌊 For multicast sessions that also let the answerer send data, the answerer MAY send all of the offered Operation Points 🌸
In any case, if the answerer can't accept one or more offered Operation Points and/or the media stream's dependencies, the answerer MAY re-invite with an offer that includes acceptable Operation Points and/or dependencies ✨
Note: applications may limit the possibility of performing a re-invite. The previous offer is also a good hint about what the other agent can do 🍓
6.2. Declarative usage 🧚
If a Real Time Streaming Protocol (RTSP) receiver understands the signaling in this memo, it SHALL set up all of the media streams it needs to decode the Operation Point it picked 🥰
If an RTSP receiver doesn't understand the signaling defined in this memo, it falls back to normal SDP processing. There are two likely cases to tell apart: (1) if at least one of the media types in the SDP is within the receiver's capabilities, it picks among those candidates using implementation-specific criteria for setup, like usual. (2) If none of the media types in the SDP can be processed, then obviously no setup can happen 😭💀
6.3. Usage with AVP and SAVP RTP Profiles 💜
The signaling mechanisms in this document MUST NOT be used to negotiate between the attribute-value pair (AVP) [RFC3551] profile and the SAVP [RFC3711] profile for RTP. That said, both profiles MAY be used separately or together with the signaling mechanism defined in this document 🫶
6.4. Usage with Capability Negotiation 🔮
This memo doesn't cover how it interacts with Capability Negotiation [MMUSIC]. That's still for further study and will be addressed in a different memo, so stay tuned 👀
6.5. Examples ✨
okay so the examples are where it all clicks 🫶 a.) is a layered decoding dependency setup, which is basically a base layer plus enhancement layers stacked on top of each other. There are three video media descriptions here. Each one offers two media format descriptions with different encoding parameters (like "packetization-mode", which isn't shown in the example) for the subtypes "H264" and "H264-SVC", as set by the a=rtpmap: lines.
The first media description, mid:L1, has payload types "96" and "97" as defined in [RFC3984]. This is the base layer Operation Point 🧱. The other two, mid:L2 and mid:L3, use H264-SVC payload types defined in [AVT-RTP-SVC]. They add enhancements either to the base layer or to the first enhancement layer, which is mid:L2. 🌸
The depend attribute with the decoding dependency type "lay" is what tells you who depends on whom. Look at the third media description, mid:L3. Its format description "100" depends on "96" or "97" from mid:L1. That's an exclusive-OR, so "100" can pair with either one, but one of those two combos is required to decode "100". 💅
"101" is the more intense one. It depends on two other media descriptions at once: "97" from mid:L1 and "99" from mid:L2. Both "97" and "99" are required by definition to decode "101". Main character energy, honestly 👑
Here is the full session description:
v=0
o=svcsrv 289083124 289083124 IN IP4 host.example.com
s=LAYERED VIDEO SIGNALING Seminar
t=0 0
c=IN IP4 192.0.2.1/127
a=group:DDP L1 L2 L3
m=video 40000 RTP/AVP 96 97
b=AS:90
a=framerate:15
a=rtpmap:96 H264/90000
a=rtpmap:97 H264/90000
a=mid:L1
m=video 40002 RTP/AVP 98 99
b=AS:64
a=framerate:15
a=rtpmap:98 H264-SVC/90000
a=rtpmap:99 H264-SVC/90000
a=mid:L2
a=depend:98 lay L1:96,97; 99 lay L1:97
m=video 40004 RTP/AVP 100 101
b=AS:128
a=framerate:30
a=rtpmap:100 H264-SVC/90000
a=rtpmap:101 H264-SVC/90000
a=mid:L3
a=depend:100 lay L1:96,97; 101 lay L1:97 L2:99b.) is the multi-descriptive one (mdc), and it's a different vibe 🦋 There are three video media descriptions here too, but each has exactly one media format description. The depend attribute uses the decoding dependency type "mdc", which is multi-descriptive decoding dependency.
Here's the twist. Format description "104" in mid:M1 depends on both of the other media descriptions. It points at "105" from mid:M2 and "106" from mid:M3. Since this is multi-descriptive, "105" and "106" can enhance the decoding of "104", but they are not required for decoding. So it's more of a "the more the merrier" situation 🍓
The full session description, for the curious:
v=0
o=mdcsrv 289083124 289083124 IN IP4 host.example.com
s=MULTI DESCRIPTION VIDEO SIGNALING Seminar
t=0 0
c=IN IP4 192.0.2.1/127
a=group:DDP M1 M2 M3
m=video 40000 RTP/AVP 104
a=mid:M1
a=depend:104 mdc M2:105 M3:106
m=video 40002 RTP/AVP 105
a=mid:M2
a=depend:105 mdc M1:104 M3:106
m=video 40004 RTP/AVP 106
a=mid:M3
a=depend:106 mdc M1:104 M2:1057. Security Considerations 🔐
okay the security part is short but it's SERIOUS bestie 😭 All of the security implications of SDP apply here, full stop.
On top of that, there's a real risk that an attacker could mess with the dependency signaling in a session description. That could mislead a receiver or a middle box 🙈 For example, a receiver might try to stitch together a Media Bitstream from several RTP packet streams that doesn't actually form an Operation Point, even though the signaling convinced it that it would. The fallout for the media decoding process could be genuinely bad.
So the advice is that the receiver SHOULD run an integrity check on the SDP, and it should follow the SDP security considerations so it only trusts SDP from trusted sources 🛡️
8. IANA Considerations 📋
The following contact information shall be used for all registrations included here:
Contact: Thomas Schierl
email: ts@thomas-schierl.de
tel: +49-30-31002-227IANA has registered the following semantics in Semantics for the "group" SDP Attribute under SDP Parameters. ✨
Semantics Token Reference
------------------- ----- ---------
Decoding Dependency DDP RFC 5583The SDP media-level attribute "depend" has been registered by IANA in Semantics for "att-field (media level only)". The registration procedure in Section 8.2.4 of [RFC4566] applies here 💅
Here's the registration itself:
SDP Attribute ("att-field (media level only)"):
Attribute name: depend
Long form: decoding dependency
Type of name: att-field
Type of attribute: media level only
Subject to charset: no
Purpose: RFC 5583
Reference: RFC 5583
Values: see this document and registrations below.IANA has also registered the following semantics for the "depend" SDP Attribute under SDP Parameters:
Semantics of the "depend" SDP attribute:
Semantics Token Reference
---------------------------- ----- ---------
Layered decoding dependency lay RFC 5583
Multi-descriptive decoding dependency mdc RFC 5583Want to add new semantics for the "depend" attribute later? New registrations are added under the "Specification Required" policy as defined in [RFC5226] 📝
9. Informative Note on "The SDP (Session Description Protocol) Grouping Framework" 🧩
Heads up, there's ongoing work on [RFC3388bis] 👀 That work extends the grouping mechanism so that a media description can be part of more than one group of the same grouping type in the same session description.
This document is different, though. Media descriptions grouped by this document must be at most part of one group of the type "DDP" in the same session description.
10. References 📚
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
and Video Conferences with Minimal Control", STD 65,
RFC 3551, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
K. Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
5226, May 2008.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.10.2. Informative References
[AVT-RTP-SVC] Wenger, S., Wang Y.-K., Schierl, T. and A.
Eleftheriadis, "RTP Payload Format for SVC Video", Work
in Progress, March 2009.
[RFC3388bis] Camarillo, G "The SDP (Session Description Protocol)
Grouping Framework", Work in Progress, January 2009.
[MMUSIC] Andreasen, F., "SDP Capability Negotiation", Work in
Progress, May 2009.
[AVT-RTP-MVC] Wang, Y.-K. and T. Schierl, "RTP Payload Format for MVC
Video", Work in Progress, February 2009.
[MDC] Vitali, A., Borneo, A., Fumagalli, M., and R. Rinaldo,
"Video over IP using Standard-Compatible Multiple
Description Coding: an IETF proposal", Packet Video
Workshop, April 2006, Hangzhou, China.
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T.,
Westerlund, M., and D. Singer, "RTP Payload Format for
H.264 Video", RFC 3984, February 2005.Appendix A. Acknowledgements 🫶
Thomas Schierl of Fraunhofer HHI, the author, was sponsored by the European Commission under contract number FP7-ICT-214063, project SEA. ⭐
Big thanks as well to Magnus Westerlund, Joerg Ott, Ali Begen, Dan Wing, Helmut Burklin, and Jean-Francois Mule for their valuable and constructive comments on this memo 💜
Authors' Addresses 🎀
Thomas Schierl
Fraunhofer HHI
Einsteinufer 37
D-10587 Berlin
Germany
Phone: +49-30-31002-227
EMail: ts@thomas-schierl.de
Stephan Wenger
2400 Skyfarm Dr.
Hillsborough, CA 94010
USA
Phone: +1-415-713-5473
EMail: stewe@stewe.org📦 where this page comes from
- ietf: rfc5583 2009-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms