RFC 4796

The Session Description Protocol (SDP) Content Attribute

📅 published February 2007, from ietf

RFC 4796: The Session Description Protocol (SDP) Content Attribute 💖

Title block: the deets 🎀

  • Number: RFC 4796
  • Authors: J. Hautakorpi and G. Camarillo, both from Ericsson
  • Category: Standards Track
  • Date: February 2007
  • Obsoletes/Updates: The title block doesn't list anything it obsoletes or updates

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright (C) The IETF Trust (2007).

Abstract 💅

This document defines a new Session Description Protocol (SDP) media-level attribute, content. The content attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the content attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content.

Table of Contents 🧚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  2
3.  Related Techniques . . . . . . . . . . . . . . . . . . . . . .  2
4.  Motivation for the New Content Attribute . . . . . . . . . . .  3
5.  The Content Attribute  . . . . . . . . . . . . . . . . . . . .  4
6.  The Content Attribute in the Offer/Answer Model  . . . . . . .  5
7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
8.  Operation with SMIL  . . . . . . . . . . . . . . . . . . . . .  7
9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  12.1.  Normative References  . . . . . . . . . . . . . . . . . .  9
  12.2.  Informational References  . . . . . . . . . . . . . . . .  9

1. Introduction 🦋

Okay so, the Session Description Protocol (SDP) [1] is basically the protocol that describes multimedia sessions. It's built for session announcements, session invitations, and all the other ways multimedia sessions get started. The most typical use case is pairing it with the Session Initiation Protocol (SIP) [5], and that combo is everywhere ✨

Here's the thing: sometimes an application gets a bunch of similar media streams, all described in one SDP session description. "Similar" means you literally can't tell them apart just by looking at their media description lines. Think two video streams, both labeled the same way. The content attribute is what saves the day, so the receiving app can handle each stream properly based on what it actually contains 🎀

This spec defines the SDP content media-level attribute. It gives you way more info about a media stream than the m line in an SDP session description does 💖

The main goal is to let applications take automated actions based on the content attributes. BUT this spec does NOT define what those actions are. So yeah, two implementations can totally behave differently when they get the exact same content attribute 💀

2. Terminology 🌈

In this document, 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 [3], and indicate requirement levels for compliant implementations.

Translation: those capitalized key words are the official requirement-level words, and they're read the way BCP 14 and RFC 2119 [3] say. They tell you how strict a compliant implementation has to be 🫶

The label attribute [10] lets a sender attach a pointer to a particular media stream. Its namespace is totally unrestricted, so technically you could use it to share info about what a stream contains. In practice though, that's a no-go, because of backward compatibility. Existing implementations of label already use values from that unrestricted namespace in their own application-specific ways. So you can't reserve chunks of that namespace without risking conflicts with labels people are already using 🙈

Another option is an external document that uses label as a pointer to give a stream its meaning. The catch is that you need that external document, which is a pain. So this approach only really works for special cases where those documents already exist, like centralized conferencing 🧚

You can also attach semantics using the i SDP attribute, defined in [1]. But heads up: i values are meant for humans, not for automata (aka machines) 🤖

4. Motivation for the New Content Attribute 💜

Right now SDP has no way to describe what a media stream contains (like a speaker's image, slides, or sign language) in a form an application can actually understand. The end user can totally see the content and read its title, but the app has no clue what the stream holds 👀

Some apps get several similar media streams (same type and format, say) and need to know what each one contains. That happens when slides, the speaker's image, and sign language all come in as separate streams. It'd be amazing if the receiving app could tell them apart and handle each one automatically 🔥

                +--------------------------------------+
                |+------------++----------------------+|
                ||            ||                      ||
                || speaker's  ||                      ||
                ||   image    ||                      ||
                ||            ||                      ||
                |+------------+|     presentation     ||
                |+------------+|        slides        ||
                ||            ||                      ||
                ||    sign    ||                      ||
                ||  language  ||                      ||
                ||            ||                      ||
                |+------------++----------------------+|
                +--------------------------------------+

                      Figure 1: Application's Screen

Figure 1 is a screen from a typical communication app. The content attribute lets the app decide where each stream goes. Honestly, the end user shouldn't have to rearrange every stream every single time a new session starts 😭

It gets even more useful in complex setups, like an app controlling the equipment in an auditorium. An auditorium can have lots of video outputs (a main screen and two smaller ones, for example) and audio outputs (main speakers and headsets for participants). Without cues from a controlling app, the person running it would need to do a ton of manual work. The content attribute would let that person set, just once, which output each stream in a given session should use. The app could then reuse the same layout for later sessions. So the content attribute can seriously cut down how much end-user interaction is needed ✨

5. The Content Attribute 🫧

This spec defines a new media-level value attribute, content. Its formatting in SDP is described by the following ABNF (Augmented Backus-Naur Form) [2]:

content-attribute   = "a=content:" mediacnt-tag
mediacnt-tag        = mediacnt *("," mediacnt)
mediacnt            = "slides" / "speaker" / "sl" / "main"
                      / "alt" / mediacnt-ext
mediacnt-ext        = token

The content attribute holds one or more tokens, which a sending app MAY attach to a media stream. An app MAY attach a content attribute to any media stream it describes. Both of those are optional, so the sender gets to decide ✨

This doc gives you a set of pre-defined content values. More values can be defined later on. Here are the pre-defined ones 💖

  • slides: the media stream includes presentation slides. The media type could be a video stream or a bunch of instant messages with pictures. The typical use cases are online seminars and courses. This is similar to the 'presentation' role in H.239 [12].
  • speaker: the media stream contains the image of the speaker. It could be a video stream or a still image. Typical use cases are online seminars and courses.
  • sl: the media stream contains sign language. A typical use case is an audio stream that gets translated into sign language, which then gets sent over a video stream 🤟
  • main: the media stream is taken from the main source. A typical use case is a concert where the camera is pointed at the performer 🎤
  • alt: the media stream is taken from the alternative source. A typical use case is an event where the ambient sound is separated from the main sound. The alternative audio stream could be, say, the sound of a jungle 🌿 Another example is the video of a conference room, while the main stream carries the video of the speaker. This is similar to the 'live' role in H.239.

All of these values can be used with any media type. We deliberately didn't restrict each value to certain media types, so apps can get creative and combine a given value with different media types 🌈

An app can decide how to handle a single media stream based on both the media type and the content attribute value. If the app doesn't have any special logic for a given media type and content value combo, it just uses its default handling for that media type.

Note that the same content attribute value can occur more than once in a single session description. So yes, you can have two slides streams in one session, and that's totally valid 👑

6. The Content Attribute in the Offer/Answer Model ✨

okay so this spec doesn't define a way to find out whether the peer endpoint even understands the 'content' attribute 🙈 because 'content' values are just informative at the offer/answer model [8] level. if the peer doesn't understand it, the media session still gets established 💖. the only fallout is that someone on the receiving side might have to step in and direct each media stream to the right place 🫶

the 'content' attribute describes the data that the application generating the SDP session description intends to send over a particular media stream 🎀. the 'content' values for the two directions of a media stream don't have to match 🦋. so an SDP answer MAY contain 'content' attributes even if none were in the offer 💅. and the answer MAY contain no 'content' attributes even if the offer had them 💀. also, the values of 'content' attributes don't need to match between an offer and an answer ✨

the 'content' attribute can also be used when SDP is used in a declarative style 🧚. for example, 'content' attributes can go in SDP session descriptors that get distributed with Session Announcement Protocol (SAP) [9] 📣

7. Examples 🎬

okay there are two examples in this section 🎀. the first one, below, uses a single 'content' attribute value per media stream:

    v=0
    o=Alice 292742730 29277831 IN IP4 131.163.72.4
    s=Second lecture from information technology
    c=IN IP4 131.164.74.2
    t=0 0
    m=video 52886 RTP/AVP 31
    a=rtpmap:31 H261/9000
    a=content:slides
    m=video 53334 RTP/AVP 31
    a=rtpmap:31 H261/9000
    a=content:speaker
    m=video 54132 RTP/AVP 31
    a=rtpmap:31 H261/9000
    a=content:sl

the second one is a case with more than one 'content' attribute value per media stream 🔥. the difference from the previous example is that now the conferencing system might automatically mix the video streams from the presenter and slides 🧠

    v=0
    o=Alice 292742730 29277831 IN IP4 131.163.72.4
    s=Second lecture from information technology
    c=IN IP4 131.164.74.2
    t=0 0
    m=video 52886 RTP/AVP 31
    a=rtpmap:31 H261/9000
    a=content:slides,speaker
    m=video 54132 RTP/AVP 31
    a=rtpmap:31 H261/9000
    a=content:sl

8. Operation with SMIL 🎞️

the values of the 'content' attribute, defined in Section 5, can also be used with Synchronized Multimedia Integration Language (SMIL) [11] 💜. SMIL has a 'param' element, which is used for describing the content of a media flow. but this 'param' element, like the 'content' attribute, gives an application-specific description of the media content 🫧

details on how to use the values of the 'content' attribute with SMIL's 'param' element are outside the scope of this specification 🙅‍♀️

9. Security Considerations 🚨

okay this part is serious bestie 😭. an attacker may try to add, modify, or remove 'content' attributes from a session description 👀. depending on how an implementation chooses to react to the presence or absence of a given 'content' attribute, that could make an application behave in an undesirable way 💀. so it is strongly RECOMMENDED that integrity protection be applied to the SDP session descriptions 🔐

integrity protection can be provided for a session description carried in an SIP [5], e.g., by using S/MIME [6] or Transport Layer Security (TLS) [7] 🛡️

it is assumed that values of 'content' attribute do not contain data that would be truly harmful if exposed to a possible attacker 🫶. it must be noted that the initial set of values does not contain any data that would require confidentiality protection. however, S/MIME and TLS can be used to protect confidentiality, if needed 🔒

10. IANA Considerations 📋

this document defines a new 'content' attribute for SDP 🎉. it also defines an initial set of values for it. here's some general info about the 'content' attribute:

Contact name:        Jani Hautakorpi <Jani.Hautakorpi@ericsson.com>.

Attribute name:      'content'.

Type of attribute    Media level.

Subject to charset:  No.

Purpose of attribute:  The 'content' attribute gives information from
   the content of the media stream to the receiving application.

Allowed attribute values: "slides", "speaker", "sl", "main", "alt",
   and any other registered values.

the IANA created a subregistry for 'content' attribute values under the Session Description Protocol (SDP) Parameters registry 🗂️. the initial values for the subregistry are below:

Value of 'content' attribute Reference Description
---------------------------- --------- -----------
slides                       RFC 4796  Presentation slides
speaker                      RFC 4796  Image from the speaker
sl                           RFC 4796  Sign language
main                         RFC 4796  Main media stream
alt                          RFC 4796  Alternative media stream

per the terminology in RFC 2434 [4], the registration policy for new values for the 'content' parameter shall be 'Specification Required' 📝

if new values for 'content' attributes are specified in the future, they should consist of a meta description of the contents of a media stream 💡. new values for 'content' attributes should not describe things like what to do in order to handle a stream 🙅‍♀️

11. Acknowledgements 🫶

the authors would like to thank Arnoud van Wijk and Roni Even, who gave valuable ideas for this document 🌸. they also want to thank Tom Taylor for his thorough review 💖

12. References 📚

12.1. Normative References

  • [1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
  • [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
  • [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

12.2. Informational References

  • [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
  • [6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
  • [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
  • [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
  • [9] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
  • [10] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
  • [11] Michel, T. and J. Ayars, "Synchronized Multimedia Integration Language (SMIL 2.0) - [Second Edition]", World Wide Web Consortium Recommendation REC-SMIL2-20050107, January 2005, <http://www.w3.org/TR/2005/REC-SMIL2-20050107>.
  • [12] ITU-T, "Infrastructure of audiovisual services - Systems aspects; Role management and additional media channels for H.300-series terminals", Series H H.239, July 2003.

Authors' Addresses 🏡

Jani Hautakorpi
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Jani.Hautakorpi@ericsson.com


Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Gonzalo.Camarillo@ericsson.com

Copyright (C) The IETF Trust (2007).

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 🧾

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. it also doesn't represent that it has made any independent effort to identify any such rights. info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 ✨

copies of IPR disclosures made to the IETF Secretariat, 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 required to implement this standard. please address that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society 💜

📦 where this page comes from