RFC 8848
Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)
Session Signaling for Controlling Multiple Streams for Telepresence (CLUE) 📞✨
- RFC: 8848 🎀
- Category: Experimental 🧪
- Date: January 2021 📅
- ISSN: 2070-1721
- Published by: Internet Engineering Task Force (IETF) 🌐
- Authors: R. Hanton (Cisco Systems), P. Kyzivat, L. Xiao (Beijing Chuangshiyoulian), C. Groves 👯♀️
- Obsoletes / Updates: the title block doesn't list any, so this one doesn't obsolete or update anything 🙈
Abstract
okay so this doc is all about CLUE signaling, which stands for Controlling Multiple Streams for Telepresence 💖 It explains how the CLUE protocol and the CLUE data channel work together, and how they hook into existing signaling like SIP and SDP, to make a telepresence call. it's giving teamwork, no cap 🫶
Status of This Memo
this isn't an Internet Standards Track spec. it's published so people can look at it, try out experimental implementations, and evaluate it 🔬
it defines an Experimental Protocol for the Internet community. it's a product of the IETF and it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🤓
for the latest status, errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8848 🦋
Copyright Notice
Copyright (c) 2021 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 (https://trustee.ietf.org/license-info) as they stand on the publication date. please actually read those, because they spell out your rights and restrictions for this doc 📜 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💅
Table of Contents
1. Introduction
2. Terminology
3. Media Feature Tag Definition
4. SDP Grouping Framework CLUE Extension Semantics
4.1. General
4.2. The CLUE Data Channel and the CLUE Grouping Semantic
4.3. CLUE-Controlled Media and the CLUE Grouping Semantic
4.4. SDP Semantics for CLUE-Controlled Media
4.4.1. Signaling CLUE Encodings
4.4.1.1. Referencing Encodings in the CLUE Protocol
4.4.2. Negotiating Receipt of CLUE Capture Encodings in SDP
4.5. SDP Offer/Answer Procedures
4.5.1. Generating the Initial Offer
4.5.2. Generating the Answer
4.5.2.1. Negotiating Use of CLUE and the CLUE Data Channel
4.5.2.2. Negotiating CLUE-Controlled Media
4.5.2.3. Negotiating Non-CLUE-controlled Media
4.5.3. Processing the Initial Offer/Answer Negotiation
4.5.3.1. Successful CLUE Negotiation
4.5.3.2. CLUE Negotiation Failure
4.5.4. Modifying the Session
4.5.4.1. Adding and Removing CLUE-Controlled Media
4.5.4.2. Enabling CLUE Mid-Call
4.5.4.3. Disabling CLUE Mid-Call
4.5.4.4. CLUE Protocol Failure Mid-Call
5. Interaction of the CLUE Protocol and SDP Negotiations
5.1. Independence of SDP and CLUE Negotiation
5.2. Constraints on Sending Media
5.3. Recommendations for Operating with Non-atomic Operations
6. Interaction of the CLUE Protocol and RTP/RTCP CaptureID
6.1. CaptureID Reception during MCC Redefinition
7. Multiplexing of CLUE-Controlled Media Using BUNDLE
7.1. Overview
7.2. Usage of BUNDLE with CLUE
7.2.1. Generating the Initial Offer
7.2.2. Multiplexing of the Data Channel and RTP Media
8. Example: A Call between Two CLUE-Capable Endpoints
9. Example: A Call between a CLUE-Capable and Non-CLUE Endpoint
10. IANA Considerations
10.1. New SDP Grouping Framework Attribute
10.2. New SIP Media Feature Tag
11. Security Considerations
12. References
12.1. Normative References
12.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🌸
okay so picture this: devices need to join a telepresence call, pick the sources they want to see, receive those media sources, and show them in the most flattering way possible 💅 CLUE makes that happen with two main protocol negotiations that are tightly connected. first up, SDP [RFC4566], carried over SIP [RFC3261], negotiates which media capabilities can be delivered to which addresses on a device. then CLUE protocol messages [RFC8847], sent over a CLUE data channel [RFC8850], negotiate the Capture Sources that are available, their attributes, and any constraints on using them. the messages also let the far-end device say which Captures it wants to receive 🎀 it's recommended that you read those documents before this one, since this doc assumes you already know those protocols and only briefly reintroduces their terms.
on top of setting up the CLUE channel, SDP also negotiates the details of supported media streams and the maximum capability of each stream. the CLUE Framework [RFC8845] defines how a Media Provider expresses its maximum Encoding Group capabilities, so SDP is also used to express the encoding limits for each potential Encoding 🧚
backwards compatibility is a big deal here. it's vital that a CLUE-capable device calling a device that doesn't support CLUE can fall back to a fully functional non-CLUE call. no one wants a broken call 😭 this doc also covers how a non-CLUE call can be upgraded to CLUE mid-call and, similarly, how CLUE can be removed mid-call to go back to a standard non-CLUE call 🦋
2. Terminology 📖
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. ✨ bottom line: the caps are the important part.
this document uses terminology defined in the CLUE Framework [RFC8845].
a few extra terms are specific to this document:
- CLUE-controlled media: a media "m=" line that is under CLUE control. the Capture Source that provides the media on this "m=" line is negotiated in CLUE. see Section 4 for how this control is signaled in SDP. there's a matching "non-CLUE-controlled" media term too 💜
- non-CLUE device: a device that supports standard SIP and SDP but either doesn't support CLUE, or does support CLUE but doesn't currently want to use CLUE capabilities 🙈
- RTCP: RTP Control Protocol 🌈
- SCTP: Stream Control Transmission Protocol 🍓
- STUN: Session Traversal Utilities for NAT 🧚♀️
3. Media Feature Tag Definition 🏷️
the "sip.clue" media feature tag [RFC3840] shows support for CLUE in SIP [RFC3261] calls. a CLUE-capable device SHOULD include this media feature tag in its REGISTER requests and OPTION responses. it SHOULD also include the media feature tag in INVITE and UPDATE [RFC3311] requests and responses 👑
if the media feature tag shows up in the contact field of a request or response, you can use that to tell the far end supports CLUE 🔥
4. SDP Grouping Framework CLUE Extension Semantics 🎀
4.1. General
this section defines a new SDP Grouping Framework [RFC5888] extension called 'CLUE' 💖
the CLUE extension gets indicated using an SDP session-level 'group' attribute. every SDP media "m=" line in this group, identified with SDP media-level mid attributes, is CLUE controlled by a CLUE data channel that's also included in this CLUE group 🫶
right now only a single CLUE group is specified. support for multiple CLUE groups in one session is outside the scope of this document. a device MUST NOT include more than one CLUE group in its SDP message unless it's following a specification that defines how multiple CLUE channels are signaled, and it's able to either determine that the other side of the SDP exchange supports multiple CLUE channels or fail gracefully if it doesn't 🙅♀️
4.2. The CLUE Data Channel and the CLUE Grouping Semantic
the CLUE data channel [RFC8850] is a bidirectional data channel [RFC8831] used to transport CLUE messages, carried within an SCTP over DTLS connection. this channel must be established before CLUE protocol messages can be exchanged and CLUE-controlled media can be sent 🧃
the data channel gets negotiated over SDP as described in [RFC8864]. a CLUE-capable device that wants to negotiate CLUE MUST also include a CLUE group in its SDP Offer or Answer, and include the "mid" of the "m=" line for the data channel in that group. the CLUE group MUST include the "mid" of the "m=" line for one (and only one) data channel 🌟
having the data channel in the CLUE group of an SDP Offer or Answer, along with the "sip.clue" media feature tag, signals that the device supports CLUE and wants to upgrade the call to include CLUE-controlled media. a CLUE-capable device SHOULD include a data channel "m=" line in offers and, when allowed by [RFC3264], answers 🦋
4.3. CLUE-Controlled Media and the CLUE Grouping Semantic
CLUE-controlled media lines in an SDP are "m=" lines where the content of the media streams to be sent is negotiated through the CLUE protocol [RFC8847]. for an "m=" line to be CLUE controlled, its "mid" attribute value MUST be included in the CLUE group. CLUE-controlled media is controlled by the CLUE protocol as negotiated on the CLUE data channel, with a "mid" included in the CLUE group 🎯
"m=" lines that aren't specified as being under CLUE control follow the normal rules for media streams negotiated in SDP, as defined in documents such as [RFC3264] 🌸
the restrictions on CLUE-controlled media defined below always apply to "m=" lines in an SDP Offer or Answer. that's true even if negotiating the data channel in SDP failed because the remote device doesn't support CLUE, or for any other reason. it also applies to an offer when the recipient doesn't include the "mid" of the corresponding "m=" line in their CLUE group. no sneaky loopholes, bestie 🙈
4.4. SDP Semantics for CLUE-Controlled Media 💅
4.4.1. Signaling CLUE Encodings ✨
okay bestie, so the CLUE Framework [RFC8845] has this concept called "Encodings" 🎀, and they basically show what the sender is able to encode. 💅 Every Encoding the Media Provider wants to signal gets sent over an m= line of the right media type, and that line MUST be marked as sendonly with the a=sendonly attribute or as inactive with the a=inactive attribute. 🦋
The encoder limits of active (e.g., a=sendonly) Encodings can be expressed with the SDP syntax we already have, so no new drama needed 🙌 For example, for H.264, check Table 6 in Section 8.2.2 of [RFC6184] for the list of valid parameters for encoder sender stream limits.
These Encodings are CLUE controlled, so they MUST include a mid in the CLUE group, as defined above. 🫶
In addition to the normal restrictions in [RFC3264], the stream MUST be treated as if its m= line direction attribute had been set to a=inactive until the Media Provider has received a valid CLUE 'configure' message that specifies the Capture to be used for this stream. This means RTP packets MUST NOT be sent until configuration is complete. Meanwhile, non-media packets such as STUN, RTCP, and DTLS MUST be sent as per their relevant specifications, if negotiated. 💖
Every m= line representing a CLUE Encoding MUST contain a label attribute as defined in [RFC4574]. 🏷️ The sender uses this label to identify the Encoding in CLUE 'advertisement' messages, and the receiver uses it in CLUE 'configure' messages. Each label used for a CLUE-controlled m= line MUST be different from the label on all other m= lines in the CLUE group, unless an m= line represents a dependent stream related to another m= line (such as a Forward Error Correction (FEC) stream). In that case, it MUST have the same label value as the m= line it depends on. 👑
4.4.1.1. Referencing Encodings in the CLUE Protocol
okay so CLUE Encodings are defined in SDP, but CLUE protocol messages can reference them 🧚 This is how the protocol figures out which Encodings are part of an Encoding Group (in 'advertisement' messages) and which Encoding is used to encode a specific Capture (in 'configure' messages). The labels on the CLUE-controlled m= lines are the references the CLUE protocol uses.
Each <encID> (in encodingIDList) in a CLUE 'advertisement' message SHOULD represent an Encoding defined in SDP. The specific Encoding referenced is a CLUE-controlled m= line in the most recent SDP Offer/Answer message sent by the sender of the 'advertisement' message, with a label value that matches the text content of the <encID>. If the <encID> is not defined in SDP, it MUST be one the sender anticipates sending in a subsequent SDP Offer/Answer exchange. 🌸
Each <encodingID> (in captureEncodingType) in a CLUE 'configure' message MUST represent an Encoding defined in SDP. The specific Encoding referenced is a CLUE-controlled m= line in the most recent SDP Offer/Answer message received by the sender of the 'configure' message, with a label value that matches the text content of the <encodingID>. 🎀
Note that the non-atomic nature of SDP/CLUE protocol interaction may mean there are temporary periods where an <encID>/<encodingID> in a CLUE message does not reference an SDP m= line. It can also happen that an Encoding represented in SDP is not referenced in a CLUE protocol message. See Section 5 for the specifics. 🙈
4.4.2. Negotiating Receipt of CLUE Capture Encodings in SDP
ngl this one is so simple 💅 A receiver who wants to get a CLUE stream through a specific Encoding needs an a=recvonly m= line that matches the a=sendonly Encoding.
These m= lines are CLUE controlled, so they MUST include their mid in the CLUE group. They MAY include a label attribute, but CLUE doesn't require it. Only label values tied to a=sendonly Encodings get referenced by CLUE protocol messages, so it's not required here. 🦋
4.5. SDP Offer/Answer Procedures 🌈
4.5.1. Generating the Initial Offer
A CLUE-capable device that sends an initial SDP Offer for a SIP session and wants to negotiate CLUE will include an m= line for the data channel that carries the CLUE protocol. It will also include a CLUE group containing the mid of that data channel m= line. 🧚
For interoperability with non-CLUE devices, a CLUE-capable device sending an initial SDP Offer SHOULD NOT include any m= line for CLUE-controlled media beyond the m= line for the CLUE data channel. It SHOULD also include at least one non-CLUE-controlled media m= line. 🫶
If the device has evidence that the receiver is also CLUE capable (for instance, because it received an initial INVITE with no SDP but including a sip.clue media feature tag), the above recommendation is waived. The initial offer MAY then contain m= lines for CLUE-controlled media. ✨
With the same interoperability recommendations as for Encodings, the sender of the initial SDP Offer MAY also include a=recvonly media lines to preallocate m= lines to receive media. Or, alternatively, it MAY wait until CLUE protocol negotiation has completed before including these lines in a new offer/answer exchange -- see Section 5 for recommendations. 🌸
4.5.2. Generating the Answer
4.5.2.1. Negotiating Use of CLUE and the CLUE Data Channel
If the recipient of an initial offer is CLUE capable, and the offer contains both an m= line for a data channel and a CLUE group containing the mid for that m= line, they SHOULD negotiate data channel support for an m= line. They should also include the mid of that m= line in a corresponding CLUE group. 💜
A CLUE-capable recipient that gets an m= line for a data channel, but no corresponding CLUE group containing the mid of that m= line, MAY still include a corresponding data channel m= line. That's allowed if there are any other non-CLUE protocols it can convey over that channel. But the use of the CLUE protocol MUST NOT be negotiated on this channel. 🙅♀️
4.5.2.2. Negotiating CLUE-Controlled Media
If the initial offer contained a=recvonly CLUE-controlled media lines, the recipient SHOULD include corresponding a=sendonly CLUE-controlled media lines for accepted Encodings, up to the maximum number of Encodings it wishes to advertise. As CLUE-controlled media, the mid of these m= lines MUST be included in the corresponding CLUE group. The recipient MUST set the direction of the corresponding m= lines of any remaining a=recvonly CLUE-controlled media lines received in the offer to a=inactive. 🎀
If the initial offer contained a=sendonly CLUE-controlled media lines, the recipient MAY include corresponding a=recvonly CLUE-controlled media lines, up to the maximum number of Capture Encodings it wishes to receive. Alternatively, it MAY wait until CLUE protocol negotiation has completed before including these lines in a new offer/answer exchange -- see Section 5 for recommendations. The recipient MUST set the direction of the corresponding m= lines of any remaining a=sendonly CLUE-controlled media lines received in the offer to a=inactive. 💅
4.5.2.3. Negotiating Non-CLUE-controlled Media
A CLUE-controlled device implementation MAY prefer to render initial, single-stream audio and/or video for the user as rapidly as possible, and then transition to CLUE-controlled media once that has been negotiated. Or an implementation MAY wish to suppress initial media, only providing media once the final, CLUE-controlled streams have been negotiated. 🔥
The receiver of the initial offer, if making the call CLUE-enabled with their SDP Answer, can make their preference clear through their action in accepting or rejecting non-CLUE-controlled media lines. Rejecting these m= lines will ensure that no non-CLUE-controlled media flows before the CLUE-controlled media is negotiated. In contrast, accepting one or more non-CLUE-controlled m= lines in this initial answer will enable initial media to flow. 🌈
If the answerer chooses to send initial non-CLUE-controlled media in a CLUE-enabled call, Section 4.5.4.1 covers the need to disable it once the CLUE-controlled media is fully negotiated. ⭐
4.5.3. Processing the Initial Offer/Answer Negotiation
In the event that both the offer and answer include a data channel m= line with a mid value included in corresponding CLUE groups, CLUE has been successfully negotiated and the call is now CLUE enabled. If not, then the call is not CLUE enabled. 👑
4.5.3.1. Successful CLUE Negotiation
If the call is successfully CLUE enabled, devices MUST now begin negotiating the CLUE channel. See [RFC8850] for the negotiation details. If negotiation is successful, the sending of CLUE protocol messages [RFC8847] can begin. 🦋
A CLUE-capable device MAY choose not to send RTP on the non-CLUE-controlled channels while control of the CLUE-controlled media lines is being negotiated. (RTCP MUST still be sent and received as normal, though!) However, a CLUE-capable device MUST still be prepared to receive media on non-CLUE-controlled media lines that have been successfully negotiated as defined in [RFC3264]. 🌸
If either side of the call wants to add more CLUE-controlled m= lines to send or receive CLUE-controlled media, they MAY now send a SIP request with a new SDP Offer. They follow the normal rules of SDP Offer/Answer and any negotiated extensions. 💖
4.5.3.2. CLUE Negotiation Failure
If the negotiation of CLUE fails and the call is not CLUE enabled once the initial offer/answer negotiation completes, then CLUE is not in use in the call. CLUE-capable devices MUST either revert to non-CLUE behavior or terminate the call. 😭
4.5.4. Modifying the Session
4.5.4.1. Adding and Removing CLUE-Controlled Media
Subsequent offer/answer exchanges MAY add additional m= lines for CLUE-controlled media, or activate or deactivate existing m= lines per the standard SDP mechanisms. 🧚
In most cases, at least one additional exchange after the initial offer/answer exchange will be required. That's how both sides add all the Encodings and get the ability to receive the Encodings they want. Devices MAY delay adding a=recvonly CLUE-controlled m= lines until after CLUE protocol negotiation completes -- see Section 5 for recommendations. 🍓
Once CLUE media has been successfully negotiated, devices SHOULD make sure non-CLUE-controlled media is deactivated, by setting its ports to 0 where it corresponds to the media type of the CLUE-controlled media that was successfully negotiated. This deactivation may need an additional SDP exchange, or it may be folded into one that's already part of the CLUE negotiation. 🫶
4.5.4.2. Enabling CLUE Mid-Call
A CLUE-capable device that receives an initial SDP Offer from a non-CLUE device SHOULD include a new data channel m= line and a corresponding CLUE group in any subsequent offers it sends. That's how it signals that it's CLUE capable. 🌈
If, in an ongoing non-CLUE call, an SDP Offer/Answer exchange completes with both sides including a data channel m= line in their SDP, and with the mid for that channel in a corresponding CLUE group, then the call is now CLUE enabled. Negotiation of the data channel, and then the CLUE protocol, begins. 🎀✨
4.5.4.3. Disabling CLUE Mid-Call
okay so bestie, this is the part where a device decides it's done with CLUE for the call 💅 and honestly the way it has to shut things down properly is so iconic 🎀 first it follows the closing-a-data-channel steps from Section 6.6.1 of [RFC8864] 🦋, which means sending a fresh SDP Offer/Answer exchange and then doing an SCTP Stream Sequence Number (SSN) reset for the CLUE channel ✨. And it MUST also remove the CLUE group 🫶. Once that group is gone, any "m=" lines that used to be CLUE controlled just aren't anymore 🙈. Then the device can MAY disable those lines by setting their ports to 0 💜, or it MAY keep using them 🌸, and if it keeps them, what happens next is totally outside what this document covers 🧚.
If a device follows that procedure, or the SDP Offer/Answer negotiation wraps up in a way where the "m=" CLUE data channel line didn't get successfully negotiated and/or one side didn't put the data channel in the CLUE group 💀, then CLUE for this call is disabled 🔥. Like, CLUE is no longer enabled, period 🙅♀️. Any active "m=" lines still in the CLUE group stop being CLUE controlled 🌈, and the device MAY either disable them in a later negotiation or keep using them some other way 👑. And if the data channel is still hanging around but isn't in the CLUE group semantic anymore, CLUE protocol messages MUST no longer be sent 😭✨.
4.5.4.4. CLUE Protocol Failure Mid-Call
ngl this one is the drama 😭 because CLUE can fail unexpectedly, unlike the planned shutdown above 💅. There are two ways it can happen 🎀:
- The CLUE data channel terminates, either gracefully or ungracefully 🦋, without any matching SDP renegotiation 🥀.
- A channel error of the CLUE protocol makes it drop back to the IDLE state, as defined in Section 6 of [RFC8847] 💔.
When that happens, implementations SHOULD keep sending and receiving CLUE-controlled media based on the last CLUE messages that were negotiated ✨. They keep doing that until CLUE is re-established (if it was a channel error) or it gets turned off mid-call through an SDP exchange as described in Section 4.5.4.3 🌸. A device MAY send that SDP request to disable CLUE right away 🧚, or it MAY stay in a call-preservation mode and just keep going 💜🫶.
- Interaction of the CLUE Protocol and SDP Negotiations
okay this section is all about how the two protocols play together 🎀. Info about media streams is split up: SDP handles media addresses and limits 🦋, and the CLUE channel handles the Capture Devices that exist, scene information, and extra constraints ✨. Because of that split, some stuff like advertising a new transmissible Capture with its stream can't happen all in one go ⭐, since both SDP and CLUE messages need changing 💅.
This section explains how the two negotiations interact 🫶, gives some tips for those in-between moments in non-atomic operations 🌸, and sets extra rules for when CLUE-configured media is allowed to be sent 🔥.
5.1. Independence of SDP and CLUE Negotiation
so the whole point here is that SDP and CLUE run as independent state machines 💖. Why? Because interlocking ones could land in invalid states if messages got lost or rewritten by middleboxes en route 💀. So the CLUE channel state doesn't stop a device from sending a new SDP Offer or Answer 🦋, and a new CLUE 'advertisement' or 'configure' message isn't blocked by the state of the latest SDP negotiation either 🌈, unless that negotiation removed the CLUE channel 🙈.
The big takeaway is that a device might get an SDP Offer/Answer with a CLUE Encoding it doesn't have Capture info for yet ✨, or receive a CLUE 'configure' message naming a Capture Encoding the far end never negotiated in SDP 😭.
CLUE messages carry an <encID> (in encodingIDList) or <encodingID> (in captureEncodingType) 🎀, which identifies a specific Encoding or captureEncoding in SDP; check [RFC8846] for the specifics 💜. Since CLUE negotiation is non-atomic, a sender might want to send a new CLUE 'advertisement' before the matching SDP message 🧚. So the sender MAY include an <encID> that doesn't currently match a CLUE-controlled "m=" line label in SDP 🌸, and a CLUE-capable implementation MUST NOT reject a CLUE protocol message just because its <encID> elements don't match a label in SDP 🙌.
The state of the CLUE Participant or Media Provider/Consumer state machines doesn't affect compliance with any of the normative language of [RFC3264] 🫶. So they MUST NOT delay an ongoing SDP exchange as part of a SIP server or client transaction 💅, and an implementation MUST NOT hold up an SDP exchange waiting for CLUE negotiation to finish or for a 'configure' message to show up ⏳.
Same vibe the other way: a device in a CLUE-enabled call MUST NOT delay any mandatory state transitions in the CLUE Participant or Media Provider/Consumer state machines because of whether an SDP exchange is happening 🔥.
A device with the CLUE Participant state machine in the ACTIVE state MAY choose to delay moving from ESTABLISHED to ADV (Media Provider state machine) or from ESTABLISHED to WAIT FOR CONF RESPONSE (Media Consumer state machine) based on the SDP state 🦋. Check [RFC8847] for the CLUE state machine details 🌈. And a device MAY choose to hold off starting a new SDP exchange based on where its CLUE state machines are 💖.
5.2. Constraints on Sending Media
SDP and CLUE message states don't put limits on each other 🙈, but both do limit when media can be sent 🔒. CLUE-controlled media MUST NOT be sent unless it's been negotiated in both CLUE and SDP 🚫: an implementation MUST NOT send a specific CLUE Capture Encoding unless its most recent SDP exchange includes an active media channel for that Encoding AND it has received a CLUE 'configure' message specifying a valid Capture for that Encoding 💅✨.
5.3. Recommendations for Operating with Non-atomic Operations
CLUE-capable devices MUST be able to handle states where CLUE messages reference EncodingIDs that don't match the most recently received SDP 🎀, no matter what order the SDP and CLUE messages arrive in 🌀. These mismatches are usually temporary 🦋, but a device MUST be able to cope even if they stick around indefinitely 😭. This document still makes some recommendations on message ordering for these non-atomic transitions 💜.
CLUE-capable devices MUST make sure any inconsistencies between SDP and CLUE signaling are temporary 🫶, by sending updated SDP or CLUE messages as soon as their state machines and other constraints allow ⭐.
Generally, implementations that receive messages with incomplete info are most efficient if they wait until they have the missing info before sending messages that change things related to it 🧠. For example, an answerer that gets a new SDP Offer with three new "a=sendonly" CLUE "m=" lines, but has no CLUE 'advertisement' message with the matching capture info 🙈, would typically include corresponding "a=inactive" lines in its answer 🌸. It would only make a new SDP Offer with "a=recvonly" when and if a new 'advertisement' arrives with Captures relevant to those Encodings 🎀.
Because of the constraints of SDP Offer/Answer, and because new SDP negotiations are generally more 'costly' than sending a new CLUE message 💸, implementations that need to change both channels SHOULD prioritize sending the updated CLUE message over the new SDP message 🔥. The goal is for the recipient to get the CLUE changes before the SDP changes 🧚, so they can send their SDP Answers without incomplete info and need fewer new SDP Offers overall ✨👑.
- Interaction of the CLUE Protocol and RTP/RTCP CaptureID
the CLUE Framework [RFC8845] allows for Multiple Content Captures (MCCs) 🌈: Captures that hold multiple source Captures, either composited into one stream or switched based on some metric 🎬.
The Captures that feed into these MCCs might or might not be defined in the 'advertisement' message 🤷♀️. If they are defined and the MCC is providing them in a switched format, the recipient may want to figure out which originating source Capture is currently being provided 🔍, so they can apply geometric corrections based on that Capture's geometry or do something else based on the original Capture info 💅.
To make that possible, [RFC8849] lets the CaptureID of the originating Capture be sent via RTP or RTCP 🦋. A Media Provider sending switched media for an MCC with defined originating sources MUST send the CaptureID in both RTP and RTCP, as described in the mapping document 🫶.
6.1. CaptureID Reception during MCC Redefinition
okay the race condition here is real 😭. The RTP/RTCP CaptureID comes through a different channel than the 'advertisement' message that defines the MCC contents 💀, so when an MCC gets redefined, the CaptureIDs can arrive either before or after the recipient processes the new 'advertisement' 🌀.
So when a Media Provider redefines an MCC that involves CaptureIDs, the recipient might get the relevant CaptureIDs earlier or later than the new 'advertisement' 🦋. That's why a Media Consumer MUST NOT be disrupted by any of the following in any CLUE-controlled media stream it's receiving 🛡️, whether it's for a static Capture or for an MCC (since any static Capture might be redefined into an MCC in a later 'advertisement') 💖:
- Receiving RTP or RTCP with a CaptureID when the most recently processed 'advertisement' means no media CaptureIDs are expected 🙅♀️.
- Receiving RTP or RTCP without CaptureIDs when the most recently processed 'advertisement' means media CaptureIDs are expected 🫠.
- Receiving a CaptureID in RTP or RTCP for a Capture defined in the most recently processed 'advertisement', but which that same 'advertisement' doesn't include in the MCC 🙈.
- Receiving a CaptureID in RTP or RTCP for a Capture that isn't defined in the most recently processed 'advertisement' 🌫️.
- Multiplexing of CLUE-Controlled Media Using BUNDLE
7.1. Overview
a CLUE call can involve sending and/or receiving a lot of media streams 📹. Normally, media streams go out and come in on unique ports 🔌. But each separate port can cost a device something it'd rather avoid 💸, like opening that port on firewalls and NATs 🧱, or collecting Interactive Connectivity Establishment (ICE) candidates [RFC8445] 🧊, and so on 🫠.
The BUNDLE extension [RFC8843] can be used to negotiate multiplexing several media lines onto a single 5-tuple for sending and receiving media 🎀. That lets devices in calls with another BUNDLE-supporting device potentially skip some of those costs 🦋.
CLUE-capable devices MAY support the BUNDLE extension for this purpose 💜, but supporting it isn't mandatory for a device to be CLUE compliant 🙌.
A CLUE-capable device that supports BUNDLE SHOULD also support rtcp-mux [RFC5761] 🫶. But a CLUE-capable device that supports rtcp-mux may or may not support BUNDLE 🤷♀️✨.
7.2. Usage of BUNDLE with CLUE ✨
okay so good news, bestie: this spec adds zero extra rules for BUNDLE when you're using CLUE 🫶 You can mix CLUE-controlled media lines and non-CLUE-controlled media lines in the same BUNDLE group, or spread them across several groups, and nobody's going to stop you 💅 The thing to watch is the extra SDP Offer/Answer rounds that show up when CLUE and BUNDLE have to sort themselves out. An implementation can take a few steps to keep that cost and wait time down, so it doesn't feel like a whole chore 🌸
7.2.1. Generating the Initial Offer 🎀
BUNDLE is strict here: the initial SDP Offer MUST use a unique address for each "m=" line with a non-zero port 🙈 Most CLUE implementations won't put CLUE-controlled media lines in that first offer (the data channel is the one exception). So a CLUE device that wants to handle a big pile of streams can skip opening a huge number of ports, as long as the BUNDLE negotiation goes through 🧚
Now, if an implementation does put CLUE-controlled media lines in its initial offer while also using BUNDLE, it has to be careful. If the far end doesn't negotiate BUNDLE, those lines could end up unusable, and nobody wants that drama 💀 The safest move is to avoid sending any CLUE-controlled media lines in an initial offer that carries the 'bundle-only' attribute, unless some other channel has already confirmed that the recipient supports BUNDLE and can use it 🦋 That way you dodge the risk of extra SDP exchanges to fix it.
7.2.2. Multiplexing of the Data Channel and RTP Media 💜
BUNDLE-supporting, CLUE-capable devices MAY put the data channel in the same BUNDLE group as their RTP media 🌈 If they do, the device MUST be able to demultiplex the various transports. Check Section 9.2 of the BUNDLE specification [RFC8843] for the details 📖 And if that BUNDLE group has protocols other than the data channel (the one carried over DTLS), the device MUST also be able to tell those protocols apart. No mixing up your streams, periodt 🔥
8. Example: A Call between Two CLUE-Capable Endpoints 🍓
okay, this section is my favorite because we get to watch a whole call happen between two CLUE-capable Endpoints ✨ Alice is starting the call and has three cameras and three screens. Bob is picking up and has two cameras and two screens. There's a call-flow diagram first, then a quick summary of each message 🎬
To keep this section from getting too long, the SDP snippets only show video "m=" lines. We also skip some SIP ACKs here and there. And heads up: BUNDLE is not in use in this example 🙈
+----------+ +-----------+
| Alice | | Bob |
| | | |
+----+-----+ +-----+-----+
| |
| |
| SIP INVITE 1 |
|--------------------------------->|
| |
| |
| SIP 200 OK 1 |
|<---------------------------------|
| |
| |
| SIP ACK 1 |
|--------------------------------->|
| |
| |
| |
|<########### MEDIA 1 ############>|
| 1 video A->B, 1 video B->A |
|<################################>|
| |
| |
| |
|<================================>|
| CLUE DATA CHANNEL ESTABLISHED |
|<================================>|
| |
| |
| CLUE OPTIONS |
|<*********************************|
| |
| |
| CLUE OPTIONS RESPONSE |
|*********************************>|
| |
| |
| CLUE ADVERTISEMENT 1 |
|*********************************>|
| |
| |
| CLUE ADVERTISEMENT 2 |
|<*********************************|
| |
| |
| CLUE ACK 1 |
|<*********************************|
| |
| |
| CLUE ACK 2 |
|*********************************>|
| |
| |
| SIP INVITE 2 (+3 sendonly) |
|--------------------------------->|
| |
| |
| CLUE CONFIGURE 1 |
|<*********************************|
| |
| |
| SIP 200 OK 2 (+2 recvonly) |
|<---------------------------------|
| |
| |
| CLUE CONFIGURE RESPONSE 1 |
|*********************************>|
| |
| |
| SIP ACK 2 |
|--------------------------------->|
| |
| |
| |
|<########### MEDIA 2 ############>|
| 2 video A->B, 1 video B->A |
|<################################>|
| |
| |
| SIP INVITE 3 (+2 sendonly) |
|<---------------------------------|
| |
| |
| CLUE CONFIGURE 2 |
|*********************************>|
| |
| |
| SIP 200 OK 3 (+2 recvonly) |
|--------------------------------->|
| |
| |
| CLUE CONFIGURE RESPONSE 2 |
|<*********************************|
| |
| |
| SIP ACK 3 |
|<---------------------------------|
| |
| |
| |
|<########### MEDIA 3 ############>|
| 2 video A->B, 2 video B->A |
|<################################>|
| |
| |
| |
v vSo in SIP INVITE 1, Alice sends Bob a SIP INVITE with basic audio and video capabilities plus a data channel in the SIP body, following [RFC8841] ✨ She also tosses the "sip.clue" media feature tag into the INVITE 🎀 Her SDP has a "CLUE" group that includes the mid for the data channel (3). Alice keeps all CLUE-controlled media out of the initial offer, so the video line's "mid" value isn't in the "CLUE" group. Here's the snippet:
...
a=group:CLUE 3
...
m=video 6002 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=sendrecv
a=mid:2
...
m=application 6100 UDP/DTLS/SCTP webrtc-datachannel
a=setup:actpass
a=sctp-port: 5000
a=dcmap:2 subprotocol="CLUE";ordered=true
a=mid:3Bob answers with SIP 200 OK 1, and his SDP is basically a mirror image: it also has a "CLUE" group with the data channel's "mid" value. Since it looks so similar, I'm not pasting it here 🙈 Bob wants to get initial media, so he includes the matching non-CLUE-controlled audio and video lines. He also adds the "sip.clue" media feature tag to the 200 OK ✨ Now Alice and Bob can each send one audio stream and one video stream. That's MEDIA 1 in the diagram 🦋
Once the initial SDP Offer/Answer is done, Alice and Bob can go ahead and negotiate the CLUE data channel. That's the CLUE DATA CHANNEL ESTABLISHED step 🫶
Next up is CLUE protocol negotiation. Bob sent a=active in his SDP Answer, which makes him the DTLS client, and that makes him the CLUE Channel Initiator 👑 He kicks things off with a CLUE OPTIONS message that describes which version of CLUE he supports. When Alice gets that, she replies with her CLUE OPTIONS RESPONSE 💅
With OPTIONS done, Alice sends her CLUE 'advertisement' message (CLUE ADVERTISEMENT 1) 🎀 She advertises three static Captures, one for each of her cameras. She also includes switched Captures that work for systems with one or two screens. All of these Captures live in one Capture Scene, and the Capture Scene Views tell Bob he can subscribe to the three static Captures, the two switched Captures, or just the one switched Capture 🌸 Alice has no simultaneity constraints, so all six Captures go into one simultaneous set. Last but not least, she includes an Encoding Group with three Encoding IDs: "enc1", "enc2", and "enc3". These Encoding IDs aren't valid yet, but they'll line up with the next SDP Offer she sends 🧚
Okay so, Bob got CLUE ADVERTISEMENT 1 but he's not sending a 'configure' yet 🙈 because he still needs Alice's Encoding information. Until he has that, he has no idea whether she's got enough resources to send the two streams he really wants at a quality he's happy with 💅. Since he isn't sending an immediate 'configure' with the "ack" element set, he has to send an explicit 'ack' message (CLUE ACK 1) to say "got it, bestie" ✨
Bob also sends his own CLUE 'advertisement' (CLUE ADVERTISEMENT 2). The diagram puts this after Alice's CLUE ADVERTISEMENT 1, but Bob sends his independently and doesn't wait for CLUE ADVERTISEMENT 1 to show up 🦋 He advertises two static Captures, one for each of his cameras 🎀 He also adds a single composed Capture for single-screen systems, where he composites the two camera views into one video stream. All three Captures live in one Capture Scene, with suitable Capture Scene Views that tell Alice she can subscribe to either the two static Captures or the single composed Capture 👑 Bob has no simultaneity constraints, so all three Captures go in one simultaneous set. He also includes one Encoding Group with two Encoding IDs: "foo" and "bar" 🌸
Alice is in the same boat 🚣♀️ She gets CLUE ADVERTISEMENT 2 but doesn't send a 'configure' yet, because she hasn't received Bob's Encoding information. Instead she sends an 'ack' message (CLUE ACK 2) ✨
Okay, now both sides have sent their CLUE 'advertisement' messages, and an SDP exchange is needed to negotiate Encodings 💖 For simplicity, Alice is the one sending an INVITE with a new offer here. In lots of implementations, both sides might send an INVITE, and that gets sorted out with the 491 Request Pending resolution mechanism from [RFC3261] 🙄 (classic, but it works)
Alice now sends SIP INVITE 2 🧚 She keeps her sendrecv audio, video, and CLUE "m=" lines, and then adds three new sendonly "m=" lines to represent the three CLUE-controlled Encodings she can send. Each of these "m=" lines has a label matching one of the Encoding IDs from CLUE ADVERTISEMENT 1. Each one also gets its mid added to the grouping attribute, so everyone can see they're controlled by the CLUE data channel 🫶 Here's a snippet showing the grouping attribute, the data channel, and the video "m=" lines:
...
a=group:CLUE 3 4 5 6
...
m=video 6002 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=sendrecv
a=mid:2
...
m=application 6100 UDP/DTLS/SCTP webrtc-datachannel
a=sctp-port: 5000
a=dcmap:2 subprotocol="CLUE";ordered=true
a=mid:3
...
m=video 6004 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016
a=sendonly
a=mid:4
a=label:enc1
m=video 6006 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016
a=sendonly
a=mid:5
a=label:enc2
m=video 6008 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016
a=sendonly
a=mid:6
a=label:enc3Now Bob has everything he needs to decide which streams to configure 🔥 so he can send both a CLUE 'configure' message and his SDP Answer. He sends CLUE CONFIGURE 1, which requests the pair of switched Captures that represent Alice's scene, and he configures them with encoder IDs "enc1" and "enc2" 👑
Bob also sends his SDP Answer as part of SIP 200 OK 2 ✨ Alongside his original audio, video, and CLUE "m=" lines, he adds three more "m=" lines to match the three Alice added: two active recvonly "m=" lines, and an inactive one for the third 🌈 He adds their "mid" values to the grouping attribute too, to show they're controlled by the CLUE data channel. Here's the grouping attribute and the video "m=" lines (mid 100 is the CLUE data channel, which isn't shown):
...
a=group:CLUE 11 12 13 100
...
m=video 58722 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=sendrecv
a=mid:10
...
m=video 58724 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=recvonly
a=mid:11
m=video 58726 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=recvonly
a=mid:12
m=video 58728 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=inactive
a=mid:13Alice gets Bob's CLUE CONFIGURE 1 and sends CLUE CONFIGURE RESPONSE 1 to confirm she received it 🎀 She doesn't send the Capture Encodings specified yet, though, because at this stage she hasn't processed Bob's answer SDP. That means she hasn't negotiated the ability for Bob to receive these streams yet 🙈
Once Alice gets SIP 200 OK 2 from Bob, she sends her SIP ACK (SIP ACK 2) 💅 Now she's able to send the two video streams Bob asked for. This is shown as MEDIA 2 ✨
The constraints of offer/answer meant Bob couldn't put his Encoding information in as new "m=" lines inside SIP 200 OK 2 🙄 So Bob sends SIP INVITE 3 to generate a new offer. Along with all the streams from SIP 200 OK 2, he adds two new sendonly streams 🦋 Each one has a label matching the Encoding IDs in his CLUE ADVERTISEMENT 2 message, and their "mid" values go into the grouping attribute so they're controlled by the CLUE data channel. Here's the snippet (mid 100 is the CLUE data channel, which isn't shown):
...
a=group:CLUE 11 12 14 15 100
...
m=video 58722 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=sendrecv
a=mid:10
...
m=video 58724 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=recvonly
a=mid:11
m=video 58726 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=recvonly
a=mid:12
m=video 0 RTP/AVP 96
a=mid:13
m=video 58728 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016
a=sendonly
a=label:foo
a=mid:14
m=video 58730 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016
a=sendonly
a=label:bar
a=mid:15Now Alice has all the info she needs to send her CLUE 'configure' message and her SDP Answer 🧚 In CLUE CONFIGURE 2, she asks Bob to send the two static Captures on Encodings "foo" and "bar" 💖
Alice also sends SIP 200 OK 3, matching two recvonly "m=" lines to Bob's new sendonly lines 🌸 She puts their "mid" values in the grouping attribute to show they're controlled by the CLUE data channel. Then she deactivates the initial non-CLUE-controlled media, because bidirectional CLUE-controlled media is now available ✨ Here's the grouping attribute and the video "m=" lines (mid 3 is the data channel, not shown):
...
a=group:CLUE 3 4 5 7 8
...
m=video 0 RTP/AVP 96
a=mid:2
...
m=video 6004 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016
a=sendonly
a=mid:4
a=label:enc1
m=video 6006 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016
a=sendonly
a=mid:5
a=label:enc2
m=video 0 RTP/AVP 96
a=mid:6
m=video 6010 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=recvonly
a=mid:7
m=video 6012 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=recvonly
a=mid:8Bob gets Alice's CLUE CONFIGURE 2 and sends CLUE CONFIGURE RESPONSE 2 to acknowledge it 🫶 He doesn't send the Capture Encodings specified yet, because he hasn't received and processed Alice's SDP Answer, so he hasn't negotiated the ability to send these streams 🙈
Finally, once Bob receives SIP 200 OK 3, he's able to send the two video streams Alice asked for. This is shown as MEDIA 3 🎀✨
Okay, so now both sides are sending multiple video streams, with their sources defined through CLUE negotiation 🌈 As the call goes on, either side can send a new 'advertisement' or 'configure' message, or new SDP Offers and Answers, to add, remove, or change what they have available or want to receive 💜
Keep scrolling, there's more to come! 👀
9. Example: A Call between a CLUE-Capable and Non-CLUE Endpoint ✨
okay so this one is a quick little call 📞 Alice is a CLUE-capable Endpoint calling Bob, who is not CLUE capable (aka he can't use the CLUE protocol at all) 🙈
+----------+ +-----------+
| Alice | | Bob |
| | | |
+----+-----+ +-----+-----+
| |
| |
| SIP INVITE 1 |
|--------------------------------->|
| |
| |
| 200 0K 1 |
|<---------------------------------|
| |
| |
| SIP ACK 1 |
|--------------------------------->|
| |
| |
| |
|<########### MEDIA 1 ############>|
| 1 video A->B, 1 video B->A |
|<################################>|
| |
| |
| |
| |
v vSo in SIP INVITE 1, Alice sends Bob a SIP INVITE with the basic audio and video capabilities and the data channel in the SDP body, as per [RFC8841] 💖 She also adds the "sip.clue" media feature tag to the INVITE. Alice has put a "CLUE" group in the SDP, and it contains the mid for the data channel (3). Here's a snippet showing the grouping attribute and the video "m=" line:
...
a=group:CLUE 3
...
m=video 6002 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=sendrecv
a=mid:2
...
m=application 6100 UDP/DTLS/SCTP webrtc-datachannel
a=sctp-port: 5000
a=dcmap:2 subprotocol="CLUE";ordered=true
a=mid:3Notice that Alice did not put any CLUE-controlled media in the initial offer 🦋 The video line's mid (mid:2) is not in the "CLUE" group. That's on purpose!
Bob isn't CLUE capable, so he doesn't recognize the "CLUE" semantic for the grouping attribute, and he doesn't support the data channel either 😭 In SIP 200 OK 1, he answers with audio and video, but the data channel is zeroed out.
Alice notices there's no CLUE group in the answer, so she figures Bob doesn't support CLUE, or just doesn't want to use it 🤷♀️ Either way, they're both good to send one audio and one video stream to each other now. Alice starts sending her fallback video, which is probably a switched view from whichever camera shows the current loudest participant on her side 🎥✨
10. IANA Considerations 📋
10.1. New SDP Grouping Framework Attribute
This document registers a new semantic with IANA in the Semantics for the 'group' SDP Attribute subregistry (under the Session Description Protocol (SDP) Parameters registry), following [RFC5888] 🌸 Here's the table:
+===========================+=======+==============+===========+
| Semantics | Token | Mux Category | Reference |
+===========================+=======+==============+===========+
| CLUE-controlled "m=" line | CLUE | NORMAL | RFC 8848 |
+---------------------------+-------+--------------+-----------+
Table 110.2. New SIP Media Feature Tag 🏷️
This specification adds a new media feature tag to the SIP [RFC3261] tree, using the procedures in [RFC2506] and [RFC3840] 💜 Here are the registration details:
Media feature tag name: sip.clue
ASN.1 Identifier: 30
Summary of the media feature indicated by this tag: This feature tag
indicates that the device supports CLUE-controlled media.
Values appropriate for use with this feature tag: Boolean.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms:
This feature tag is most useful in a communications application
for describing the capabilities of a device to use the CLUE
control protocol to negotiate the use of multiple media streams.
Related standards or documents: RFC 8848
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11 of RFC 8848.
Name(s) & email address(es) of person(s) to contact for further
information: Internet Engineering Steering Group <iesg@ietf.org>
Intended usage: COMMON11. Security Considerations 🔐
CLUE uses a bunch of protocols and mechanisms, some defined by CLUE and some that have been around forever 🍓 The Security Considerations section of the CLUE Framework document [RFC8845] covers how to secure all of these, by following the recommendations of each individual protocol. Super important, bestie 💅
Beyond securing those underlying protocols, using CLUE does add some extra security worries. The big one is a malicious party taking over a CLUE-capable device and using it to attack a third party. They do this by connecting to the device and pointing a huge flood of media (especially video) at the victim 😱 Every media device has this risk, but a CLUE-capable device might let the attacker set up multiple media streams, which makes the amount of traffic aimed at the victim way bigger. Not okay!
This attack can be prevented by making sure the media recipient actually wants to receive the media packets. That's the whole trick. ⚠️
So all CLUE-capable devices MUST support key negotiation and receiver intent assurance via DTLS / Secure Real-time Transport Protocol (SRTP) [RFC5763] on CLUE-controlled RTP "m=" lines, and they MUST use it, or some other mechanism that gives receiver intent assurance 🔥 All CLUE-controlled RTP "m" lines must be secured and implemented using mechanisms such as SRTP [RFC3711]. CLUE implementations MAY choose not to require SRTP for legacy (non-CLUE-controlled) media, so they can stay backwards compatible with older SIP clients that can't support it 🦋
CLUE also defines a new media feature tag that says the device supports CLUE 🎀 That tag can show up even in non-CLUE calls, which gives more metadata about the sending device. That can help an attacker tell devices apart and identify otherwise anonymized users through the fingerprint of features their device supports 🙈 To prevent this, SIP signaling used to set up CLUE sessions SHOULD always be encrypted using TLS [RFC5630].
The CLUE protocol also carries extra info that could be used to fingerprint a particular user, or to figure out exactly which software version they're running. The CLUE Framework [RFC8847] has the details on these issues and how to mitigate them 🧚
12. References 📚
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004,
<https://www.rfc-editor.org/info/rfc3840>.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574,
DOI 10.17487/RFC4574, August 2006,
<https://www.rfc-editor.org/info/rfc4574>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010,
<https://www.rfc-editor.org/info/rfc5888>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
<https://www.rfc-editor.org/info/rfc8831>.
[RFC8841] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo,
"Session Description Protocol (SDP) Offer/Answer
Procedures for Stream Control Transmission Protocol (SCTP)
over Datagram Transport Layer Security (DTLS) Transport",
RFC 8841, DOI 10.17487/RFC8841, January 2021,
<https://www.rfc-editor.org/info/rfc8841>.
[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", RFC 8843,
DOI 10.17487/RFC8843, January 2021,
<https://www.rfc-editor.org/info/rfc8843>.
[RFC8845] Duckworth, M., Ed., Pepperell, A., and S. Wenger,
"Framework for Telepresence Multi-Streams", RFC 8845,
DOI 10.17487/RFC8845, January 2021,
<https://www.rfc-editor.org/info/rfc8845>.
[RFC8846] Presta, R. and S P. Romano, "An XML Schema for the
Controlling Multiple Streams for Telepresence (CLUE) Data
Model", RFC 8846, DOI 10.17487/RFC8846, January 2021,
<http://www.rfc-editor.org/info/rfc8846>.
[RFC8847] Presta, R. and S P. Romano, "Protocol for Controlling
Multiple Streams for Telepresence (CLUE)", RFC 8847,
DOI 10.17487/RFC8847, January 2021,
<https://www.rfc-editor.org/info/rfc8847>.
[RFC8849] Even, R. and J. Lennox, "Mapping RTP Streams to
Controlling Multiple Streams for Telepresence (CLUE) Media
Captures", RFC 8849, DOI 10.17487/RFC8849, January 2021,
<https://www.rfc-editor.org/info/rfc8849>.
[RFC8850] Holmberg, C., "Controlling Multiple Streams for
Telepresence (CLUE) Protocol Data Channel", RFC 8850,
DOI 10.17487/RFC8850, January 2021,
<https://www.rfc-editor.org/info/rfc8850>.
[RFC8864] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R.
Even, Ed., "Negotiation Data Channels Using the Session
Description Protocol (SDP)", RFC 8864,
DOI 10.17487/RFC8864, January 2021,
<https://www.rfc-editor.org/info/rfc8864>.12.2. Informative References 📚✨
These are the extra reads that help you understand the bigger picture. They're not required reading, but they're definitely worth a look, bestie 💖
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506,
DOI 10.17487/RFC2506, March 1999,
<https://www.rfc-editor.org/info/rfc2506>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
2002, <https://www.rfc-editor.org/info/rfc3311>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630,
DOI 10.17487/RFC5630, October 2009,
<https://www.rfc-editor.org/info/rfc5630>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010,
<https://www.rfc-editor.org/info/rfc5761>.
[RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP
Payload Format for H.264 Video", RFC 6184,
DOI 10.17487/RFC6184, May 2011,
<https://www.rfc-editor.org/info/rfc6184>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.Acknowledgements 🫶
Huge shoutout to the authors, plus the team that was super focused on this document: Roni Even, Simon Pietro Romano, and Roberta Presta. 💅
Also a massive thank you to Christian Groves, Jonathan Lennox, and Adam Roach, who gave really detailed comments and suggestions. They literally made this document better, no cap 🌸
Authors' Addresses 💌
Robert Hanton
Cisco Systems
Email: rohanse2@cisco.com
Paul Kyzivat
Email: pkyzivat@alum.mit.edu
Lennard Xiao
Beijing Chuangshiyoulian
Email: lennard.xiao@outlook.com
Christian Groves
Email: cngroves.std@gmail.comThat's the whole RFC, bestie!! 🦋🎀🌈
📦 where this page comes from
- ietf: rfc8848 2021-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms