RFC 4574

RFC 4574: The Session Description Protocol (SDP) Label Attribute 🎀

Okay bestie, this one is the RFC 4574 glow-up. It's a Standards Track spec from August 2006, and it's written by Orit Levin (Microsoft Corporation) and Gonzalo Camarillo (Ericsson). It's published in the Network Working Group stream, and its header doesn't list anything it obsoletes or updates. 💖

Status of This Memo ✨

This document is an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. 💅 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🌸

Copyright Notice 🦋

Copyright (C) The Internet Society (2006).

Abstract 🧚

This doc defines a brand new Session Description Protocol (SDP) media-level attribute called "label" 🏷️ The label attribute carries a pointer to a media stream, in the context of any network application that uses SDP. The sender of the SDP document can attach label to one media stream or several. Then the application can use that pointer to refer to each specific media stream in its own context. It's giving pointer, it's giving precision. 🎯

Table of Contents 📋

1. Introduction ....................................................2
2. Terminology .....................................................2
3. Motivation for the New label Attribute ..........................2
4. The Label Attribute .............................................3
5. The Label Attribute in the Offer/Answer Model ...................4
6. Example .........................................................4
7. Security Considerations .........................................4
8. IANA Considerations .............................................5
9. Acknowledgements ................................................5
10. References .....................................................6
   10.1. Normative References ......................................6
   10.2. Informative References ....................................6

1. Introduction 🌈

Okay so SDP is showing up everywhere in distributed-over-the-network apps 🌐 These apps deal with multiple sessions that get described by SDP [4], and they serve multiple users or services inside one single application instance. Apps like that need a way to identify a particular media stream across multiple SDP descriptions that get swapped with different users. Literally a must-have. 🙌

The XCON framework is a great example of a centralized conference architecture. It uses SDP with the offer/answer mechanism defined in [3] to set up media streams with each conference participant. XCON also needs to uniquely identify a media stream by its role in the conference, no matter the media type, transport protocol, or media format. ✨ That can be done with an external document that points to the right media stream and gives info about it (e.g., the stream's role in the conference). The SIP Event Package for Conference State [7] defines and uses a concrete format for those external documents. Iconic. 👑

This spec defines the SDP [4] "label" media-level attribute. It gives you a pointer to a media stream that's described by an m line in an SDP session description. 🎀

2. Terminology 🫶

Here's where we get formal. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1]. They show the requirement levels for compliant implementations. 📜 Read them as written, no vibes-based interpretation, periodt. 💀

3. Motivation for the New label Attribute 💭

Even though SDP and its extensions already have a few ways to refer to a media stream, none of them fits external documents. Those documents might get created before the session description even exists, and they need to be handled by automata (machines, not humans). 🤖

The i SDP attribute, defined in RFC 2327 [4], can label media streams. But its values are meant for human users, not for automata, so it's not the one. 🙅‍♀️

The mid SDP attribute, defined in RFC 3388 [6], can identify media streams too. The problem is that its scope is way too limited for apps dealing with multiple SDP sessions. That's because mid values only mean something inside one single SDP session, not across a broader application (like a multiparty app). 😤

Another option is to refer to a stream by its position in the m lines of the SDP session document (e.g., "the 5th media stream in the session description"). That's the mechanism used in the offer/answer model [3]. 🔢

The catch is that this only works for session descriptions that already exist. Some scenarios need a static document to point at a media stream that hasn't been negotiated with SDP yet and doesn't exist until later. Once the stream is finally created, the application has to label it, so the pointer in the static document lands on the right media stream in the session description. Main character problem, solved. 🎬

4. The Label Attribute 🏷️

This spec defines a new media-level value attribute called label. Its formatting in SDP is described by the following ABNF [2]:

   label-attribute    = "a=label:" pointer

   pointer            = token

   token              = 1*(token-char)

   token-char         = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                        / %x41-5A / %x5E-7E

The token-char and token elements are defined in [4], but they're repeated here so implementers of this SDP feature have what they need. 🧩

The label attribute holds a token that the application defines and uses in its own context. The new attribute can be attached to m lines in multiple SDP documents, so the application can logically group media streams across SDP sessions when it needs to. Grouping is so satisfying. 🦋✨

5. The Label Attribute in the Offer/Answer Model 📞

This spec doesn't define a way to find out whether the peer endpoint understands the label attribute. Why? Because label values are informative only at the offer/answer model level. 🤷‍♀️

So at the offer/answer level: an offer that has no label attributes does not mean the answer should not have them. Also, an offer that does have label attributes doesn't mean the answer should have them too. Basically, no automatic mirroring, bestie. 🪞

On top of that basic offer/answer rule, applications that use label as a pointer to media streams MUST specify their usage constraints. 📝 For example, those applications MAY mandate support for label. If they do, the application has to define how negotiation of label attribute support happens, as part of its own specification. 💜

Intellectual Property 💅

Okay so the IETF is not taking a side on whether any intellectual property rights (IPR) claimed to apply to the tech in this doc are valid or how far they reach, and it's not saying whether you can even get a license for them 🙈 It also hasn't gone digging for those rights on its own. If you want the rules on rights for RFC docs, check out BCP 78 and BCP 79. 🎀

Copies of IPR disclosures sent to the IETF Secretariat, any licensing assurances, and the results of trying to get a general license or permission for implementers or users to use proprietary rights in this spec can all be found in the IETF online IPR repository at http://www.ietf.org/ipr. 📚

The IETF is inviting anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to speak up. Send that info to ietf-ipr@ietf.org 💌

Acknowledgement 🫶

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) ✨💖