diff options
Diffstat (limited to 'doc/rfc/rfc8848.txt')
| -rw-r--r-- | doc/rfc/rfc8848.txt | 1482 |
1 files changed, 1482 insertions, 0 deletions
diff --git a/doc/rfc/rfc8848.txt b/doc/rfc/rfc8848.txt new file mode 100644 index 0000000..c9173f3 --- /dev/null +++ b/doc/rfc/rfc8848.txt @@ -0,0 +1,1482 @@ + + + + +Internet Engineering Task Force (IETF) R. Hanton +Request for Comments: 8848 Cisco Systems +Category: Experimental P. Kyzivat +ISSN: 2070-1721 + L. Xiao + Beijing Chuangshiyoulian + C. Groves + January 2021 + + + Session Signaling for Controlling Multiple Streams for Telepresence + (CLUE) + +Abstract + + This document is about Controlling Multiple Streams for Telepresence + (CLUE) signaling. It specifies how the CLUE protocol and the CLUE + data channel are used in conjunction with each other and with + existing signaling mechanisms, such as SIP and the Session + Description Protocol (SDP), to produce a telepresence call. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are candidates for any level of + Internet Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +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' Addresses + +1. Introduction + + To enable devices to participate in a telepresence call, where they + select the sources they wish to view, receive those media sources, + and display them in an optimal fashion, Controlling Multiple Streams + for Telepresence (CLUE) employs two principal and interrelated + protocol negotiations. SDP [RFC4566], conveyed via SIP [RFC3261], is + used to negotiate the specific media capabilities that can be + delivered to specific addresses on a device. Meanwhile, CLUE + protocol messages [RFC8847], transported via a CLUE data channel + [RFC8850], are used to negotiate the Capture Sources available, their + attributes, and any constraints in their use. They also allow the + far-end device to specify which Captures they wish to receive. It is + recommended that those documents be read prior to this one as this + document assumes familiarity with those protocols and hence uses + terminology from each with limited introduction. + + Beyond negotiating the CLUE channel, SDP is also used to negotiate + the details of supported media streams and the maximum capability of + each of those streams. As the CLUE Framework [RFC8845] defines a + manner in which the Media Provider expresses their maximum Encoding + Group capabilities, SDP is also used to express the encoding limits + for each potential Encoding. + + Backwards compatibility is an important consideration of the + protocol: it is vital that a CLUE-capable device contacting a device + that does not support CLUE is able to fall back to a fully functional + non-CLUE call. The document also defines how a non-CLUE call may be + upgraded to CLUE mid-call and, similarly, how CLUE functionality can + be removed mid-call to return 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. + + This document uses terminology defined in the CLUE Framework + [RFC8845]. + + A few additional terms specific to this document are defined as + follows: + + 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 details on how this control + is signaled in SDP. There is a corresponding "non-CLUE- + controlled" media term. + + non-CLUE device: A device that supports standard SIP and SDP but + either does not support CLUE or does support CLUE but does not + currently wish to invoke 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] indicates 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. + + Presence of the media feature tag in the contact field of a request + or response can be used to determine that 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 can be indicated using an SDP session-level + 'group' attribute. Each SDP media "m=" line that is included in this + group, using SDP media-level mid attributes, is CLUE controlled by a + CLUE data channel that is also included in this CLUE group. + + Currently, only support for a single CLUE group is specified; support + for multiple CLUE groups in a single session is outside the scope of + this document. A device MUST NOT include more than one CLUE group in + its SDP message unless it is following a specification that defines + how multiple CLUE channels are signaled and is able to either + determine that the other side of the SDP exchange supports multiple + CLUE channels or fail gracefully in the event it does not. + +4.2. The CLUE Data Channel and the CLUE Grouping Semantic + + The CLUE data channel [RFC8850] is a bidirectional data channel + [RFC8831] used for the transport of CLUE messages, conveyed 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 is negotiated over SDP as described in [RFC8864]. A + CLUE-capable device wishing to negotiate CLUE MUST also include a + CLUE group in their 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. + + Presence of the data channel in the CLUE group in an SDP Offer or + Answer also serves, along with the "sip.clue" media feature tag, as + an indication that the device supports CLUE and wishes 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 in which the + content of the media streams to be sent is negotiated via 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 not specified as being under CLUE control follow normal + rules for media streams negotiated in SDP as defined in documents + such as [RFC3264]. + + The restrictions on CLUE-controlled media that are defined below + always apply to "m=" lines in an SDP Offer or Answer, even if + negotiation of the data channel in SDP failed due to lack of CLUE + support by the remote device or for any other reason, or in an offer + if the recipient does not include the "mid" of the corresponding "m=" + line in their CLUE group. + +4.4. SDP Semantics for CLUE-Controlled Media + +4.4.1. Signaling CLUE Encodings + + The CLUE Framework [RFC8845] defines the concept of "Encodings", + which represent the sender's encode ability. Each Encoding the Media + Provider wishes to signal is done so via an "m=" line of the + appropriate media type, which 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 then + be expressed using existing SDP syntax. For instance, for H.264, see + Table 6 in Section 8.2.2 of [RFC6184] for a list of valid parameters + for representing encoder sender stream limits. + + These Encodings are CLUE controlled and hence MUST include a "mid" in + the CLUE group as defined above. + + In addition to the normal restrictions defined in [RFC3264], the + stream MUST be treated as if the "m=" line direction attribute had + been set to "a=inactive" until the Media Provider has received a + valid CLUE 'configure' message specifying the Capture to be used for + this stream. This means that RTP packets MUST NOT be sent until + configuration is complete, while 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]. This label is used to identify + the Encoding by the sender in CLUE 'advertisement' messages and by + the receiver 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 which case it MUST have the same + label value as the "m=" line on which it depends. + +4.4.1.1. Referencing Encodings in the CLUE Protocol + + CLUE Encodings are defined in SDP but can be referenced from CLUE + protocol messages -- this is how the protocol defines which Encodings + are a 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 that are used in the CLUE protocol. + + 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 corresponding to the text content of the + <encID>. If the <encID> is not defined in SDP, it MUST be one it + 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 corresponding to the text content of the + <encodingID>. + + Note that the non-atomic nature of SDP/CLUE protocol interaction may + mean that there are temporary periods where an <encID>/<encodingID> + in a CLUE message does not reference an SDP "m=" line, or where an + Encoding represented in SDP is not referenced in a CLUE protocol + message. See Section 5 for specifics. + +4.4.2. Negotiating Receipt of CLUE Capture Encodings in SDP + + A receiver who wishes to receive a CLUE stream via a specific + Encoding requires an "a=recvonly" "m=" line that matches the + "a=sendonly" Encoding. + + These "m=" lines are CLUE controlled and hence MUST include their + "mid" in the CLUE group. They MAY include a "label" attribute, but + this is not required by CLUE, as only label values associated with + "a=sendonly" Encodings are referenced by CLUE protocol messages. + +4.5. SDP Offer/Answer Procedures + +4.5.1. Generating the Initial Offer + + A CLUE-capable device sending an initial SDP Offer of a SIP session + and wishing to negotiate CLUE will include an "m=" line for the data + channel to convey the CLUE protocol, along with a CLUE group + containing the "mid" of the 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, + and it SHOULD include at least one non-CLUE-controlled media "m=" + line. + + If the device has evidence that the receiver is also CLUE capable, + for instance, due to receiving an initial INVITE with no SDP but + including a "sip.clue" media feature tag, the above recommendation is + waived, and the initial offer MAY 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. 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 and include the "mid" of that "m=" + line in a corresponding CLUE group. + + A CLUE-capable recipient that receives 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 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, + transitioning to CLUE-controlled media once that has been negotiated. + Alternatively, 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 by 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 addresses 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 + + In the event of successful CLUE enablement of the call, devices MUST + now begin negotiation of the CLUE channel; see [RFC8850] for + 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 during the period in which control of the CLUE- + controlled media lines is being negotiated (though RTCP MUST still be + sent and received as normal). 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 wishes to add additional CLUE-controlled + "m=" lines to send or receive CLUE-controlled media, they MAY now + send a SIP request with a new SDP Offer following the normal rules of + SDP Offer/Answer and any negotiated extensions. + +4.5.3.2. CLUE Negotiation Failure + + In the event that 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 before both sides have added + all the Encodings and the ability to receive Encodings that they + desire. 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 + ensure that non-CLUE-controlled media is deactivated by setting their + ports to 0 in cases where it corresponds to the media type of CLUE- + controlled media that has been successfully negotiated. This + deactivation may require an additional SDP exchange or may be + incorporated into one that is 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 + corresponding CLUE group in any subsequent offers it sends, to + indicate that it is CLUE capable. + + If, in an ongoing non-CLUE call, an SDP Offer/Answer exchange + completes with both sides having included 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 subsequently the CLUE protocol begins. + +4.5.4.3. Disabling CLUE Mid-Call + + If, during an ongoing CLUE-enabled call, a device wishes to disable + CLUE, it can do so by following the procedures for closing a data + channel as defined in Section 6.6.1 of [RFC8864]: sending a new SDP + Offer/Answer exchange and subsequent SCTP Stream Sequence Number + (SSN) reset for the CLUE channel. It MUST also remove the CLUE + group. Without the CLUE group, any "m=" lines that were previously + CLUE controlled no longer are; implementations MAY disable them by + setting their ports to 0 or MAY continue to use them -- in the latter + case, how they are used is outside the scope of this document. + + If a device follows the procedure above, or an SDP Offer/Answer + negotiation completes in a fashion in which either the "m=" CLUE data + channel line was not successfully negotiated and/or one side did not + include the data channel in the CLUE group, then CLUE for this call + is disabled. In the event that this occurs, CLUE is no longer + enabled. Any active "m=" lines still included in the CLUE group are + no longer CLUE controlled, and the implementation MAY either disable + them in a subsequent negotiation or continue to use them in some + other fashion. If the data channel is still present but not included + in the CLUE group semantic, CLUE protocol messages MUST no longer be + sent. + +4.5.4.4. CLUE Protocol Failure Mid-Call + + In contrast to the specific disablement of the use of CLUE described + above, the CLUE channel may fail unexpectedly. Two circumstances + where this can occur are: + + * The CLUE data channel terminates, either gracefully or + ungracefully, without any corresponding SDP renegotiation. + + * A channel error of the CLUE protocol causes it to return to the + IDLE state as defined in Section 6 of [RFC8847]. + + In this circumstance, implementations SHOULD continue to transmit and + receive CLUE-controlled media on the basis of the last negotiated + CLUE messages, until the CLUE protocol is re-established (in the + event of a channel error) or disabled mid-call by an SDP exchange as + defined in Section 4.5.4.3. Implementations MAY choose to send such + an SDP request to disable CLUE immediately or MAY continue on in a + call-preservation mode. + +5. Interaction of the CLUE Protocol and SDP Negotiations + + Information about media streams in CLUE is split between two message + types: SDP, which defines media addresses and limits, and the CLUE + channel, which defines properties of Capture Devices available, scene + information, and additional constraints. As a result, certain + operations, such as advertising support for a new transmissible + Capture with an associated stream, cannot be performed atomically, as + they require changes to both SDP and CLUE messaging. + + This section defines how the negotiation of the two protocols + interact, provides some recommendations on dealing with intermediate + stages in non-atomic operations, and mandates additional constraints + on when CLUE-configured media can be sent. + +5.1. Independence of SDP and CLUE Negotiation + + To avoid the need to implement interlocking state machines with the + potential to reach invalid states if messages were to be lost, or be + rewritten en route by middleboxes, the state machines in SDP and CLUE + operate independently. The state of the CLUE channel does not + restrict when an implementation may send a new SDP Offer or Answer; + likewise, the implementation's ability to send a new CLUE + 'advertisement' or 'configure' message is not restricted by the + results of or the state of the most recent SDP negotiation (unless + the SDP negotiation has removed the CLUE channel). + + The primary implication of this is that a device may receive an SDP + Offer/Answer message with a CLUE Encoding for which it does not yet + have Capture information or receive a CLUE 'configure' message + specifying a Capture Encoding for which the far end has not + negotiated a media stream in SDP. + + CLUE messages contain an <encID> (in encodingIDList) or <encodingID> + (in captureEncodingType), which is used to identify a specific + Encoding or captureEncoding in SDP; see [RFC8846] for specifics. The + non-atomic nature of CLUE negotiation means that a sender may wish to + send a new CLUE 'advertisement' message before the corresponding SDP + message. As such, the sender of the CLUE message MAY include an + <encID> that does not currently match a CLUE-controlled "m=" line + label in SDP; a CLUE-capable implementation MUST NOT reject a CLUE + protocol message solely because it contains <encID> elements that do + not match a label in SDP. + + The current state of the CLUE Participant or Media Provider/Consumer + state machines does not affect compliance with any of the normative + language of [RFC3264]. That is, they MUST NOT delay an ongoing SDP + exchange as part of a SIP server or client transaction; an + implementation MUST NOT delay an SDP exchange while waiting for CLUE + negotiation to complete or for a 'configure' message to arrive. + + Similarly, a device in a CLUE-enabled call MUST NOT delay any + mandatory state transitions in the CLUE Participant or Media + Provider/Consumer state machines due to the presence or absence of an + ongoing SDP exchange. + + 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. See [RFC8847] for + CLUE state machine specifics. Similarly, a device MAY choose to + delay initiating a new SDP exchange based on the state of their CLUE + state machines. + +5.2. Constraints on Sending Media + + While SDP and CLUE message states do not impose constraints on each + other, both impose constraints on the sending of media -- CLUE- + controlled media MUST NOT be sent unless it has been negotiated in + both CLUE and SDP: an implementation MUST NOT send a specific CLUE + Capture Encoding unless its most recent SDP exchange contains 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 in which CLUE + messages make reference to EncodingIDs that do not match the most + recently received SDP, irrespective of the order in which SDP and + CLUE messages are received. While these mismatches will usually be + transitory, a device MUST be able to cope with such mismatches + remaining indefinitely. However, this document makes some + recommendations on message ordering for these non-atomic transitions. + + CLUE-capable devices MUST ensure that any inconsistencies between SDP + and CLUE signaling are temporary by sending updated SDP or CLUE + messages as soon as the relevant state machines and other constraints + permit. + + Generally, implementations that receive messages with incomplete + information will be most efficient if they wait until they have the + corresponding information they lack before sending messages to make + changes related to that information. For example, an answerer that + receives a new SDP Offer with three new "a=sendonly" CLUE "m=" lines + for which it has received no CLUE 'advertisement' message providing + the corresponding capture information would typically include + corresponding "a=inactive" lines in its answer, and it would only + make a new SDP Offer with "a=recvonly" when and if a new + 'advertisement' message 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 needing to make changes to both channels + SHOULD prioritize sending the updated CLUE message over sending the + new SDP message. The aim is for the recipient to receive the CLUE + changes before the SDP changes, allowing the recipient to send their + SDP Answers without incomplete information and reducing the number of + new SDP Offers required. + +6. Interaction of the CLUE Protocol and RTP/RTCP CaptureID + + The CLUE Framework [RFC8845] allows for Multiple Content Captures + (MCCs): Captures that contain multiple source Captures, whether + composited into a single stream or switched based on some metric. + + The Captures that contribute to these MCCs may or may not be defined + in the 'advertisement' message. If they are defined and the MCC is + providing them in a switched format, the recipient may wish to + determine which originating source Capture is currently being + provided, so that they can apply geometric corrections based on that + Capture's geometry or take some other action based on the original + Capture information. + + To do this, [RFC8849] allows for the CaptureID of the originating + Capture to be conveyed 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 + + Because the RTP/RTCP CaptureID is delivered via a different channel + to the 'advertisement' message in which in the contents of the MCC + are defined, there is an intrinsic race condition in cases where the + contents of an MCC are redefined. + + When a Media Provider redefines an MCC that involves CaptureIDs, the + reception of the relevant CaptureIDs by the recipient will either + lead or lag reception and the processing of the new 'advertisement' + message by the recipient. As such, a Media Consumer MUST NOT be + disrupted by any of the following scenarios in any CLUE-controlled + media stream it is receiving, whether that stream is for a static + Capture or for an MCC (as any static Capture may be redefined to an + MCC in a later 'advertisement' message): + + * By receiving RTP or RTCP containing a CaptureID when the most + recently processed 'advertisement' message means that no media + CaptureIDs are expected. + + * By receiving RTP or RTCP without CaptureIDs when the most recently + processed 'advertisement' message means that media CaptureIDs are + expected. + + * By receiving a CaptureID in RTP or RTCP for a Capture defined in + the most recently processed 'advertisement' message, but which the + same 'advertisement' message does not include in the MCC. + + * By receiving a CaptureID in RTP or RTCP for a Capture not defined + in the most recently processed 'advertisement' message. + +7. Multiplexing of CLUE-Controlled Media Using BUNDLE + +7.1. Overview + + A CLUE call may involve sending and/or receiving significant numbers + of media streams. Conventionally, media streams are sent and + received on unique ports. However, each separate port used for this + purpose may impose costs that a device wishes to avoid, such as the + need to open that port on firewalls and NATs, the need to collect + Interactive Connectivity Establishment (ICE) candidates [RFC8445], + etc. + + The BUNDLE extension [RFC8843] can be used to negotiate the + multiplexing of multiple media lines onto a single 5-tuple for + sending and receiving media, allowing devices in calls to another + BUNDLE-supporting device to potentially avoid some of the above + costs. + + While CLUE-capable devices MAY support the BUNDLE extension for this + purpose, supporting the extension is not mandatory for a device to be + CLUE compliant. + + A CLUE-capable device that supports BUNDLE SHOULD also support rtcp- + mux [RFC5761]. However, a CLUE-capable device that supports rtcp-mux + may or may not support BUNDLE. + +7.2. Usage of BUNDLE with CLUE + + This specification imposes no additional requirements or restrictions + on the usage of BUNDLE when used with CLUE. There is no restriction + on combining CLUE-controlled media lines and non-CLUE-controlled + media lines in the same BUNDLE group or in multiple such groups. + However, there are several steps an implementation may wish to take + to ameliorate the cost and time requirements of extra SDP Offer/ + Answer exchanges between CLUE and BUNDLE. + +7.2.1. Generating the Initial Offer + + BUNDLE mandates that the initial SDP Offer MUST use a unique address + for each "m=" line with a non-zero port. Because CLUE + implementations generally will not include CLUE-controlled media + lines, with the exception of the data channel in the initial SDP + Offer, CLUE devices that support large numbers of streams can avoid + ever having to open large numbers of ports if they successfully + negotiate BUNDLE. + + An implementation that does include CLUE-controlled media lines in + its initial SDP Offer while also using BUNDLE must take care to avoid + rendering its CLUE-controlled media lines unusable in the event the + far end does not negotiate BUNDLE if it wishes to avoid the risk of + additional SDP exchanges to resolve this issue. This is best + achieved by not sending any CLUE-controlled media lines in an initial + offer with the 'bundle-only' attribute unless it has been established + via some other channel that the recipient supports and is able to use + BUNDLE. + +7.2.2. Multiplexing of the Data Channel and RTP Media + + BUNDLE-supporting CLUE-capable devices MAY include the data channel + in the same BUNDLE group as RTP media. In this case, the device MUST + be able to demultiplex the various transports -- see Section 9.2 of + the BUNDLE specification [RFC8843]. If the BUNDLE group includes + protocols other than the data channel transported via DTLS, the + device MUST also be able to differentiate the various protocols. + +8. Example: A Call between Two CLUE-Capable Endpoints + + This example illustrates a call between two CLUE-capable Endpoints. + Alice, initiating the call, is a system with three cameras and three + screens. Bob, receiving the call, is a system with two cameras and + two screens. A call-flow diagram is presented, followed by a summary + of each message. + + To manage the size of this section, the SDP snippets only illustrate + video "m=" lines. SIP ACKs are not always discussed. Note that + BUNDLE is not in use. + + +----------+ +-----------+ + | 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 v + + In SIP INVITE 1, Alice sends Bob a SIP INVITE with the basic audio + and video capabilities and data channel included in the SIP body as + per [RFC8841]. Alice also includes the "sip.clue" media feature tag + in the INVITE. A snippet of the SDP showing the grouping attribute + and the video "m=" line are shown below. Alice has included a "CLUE" + group and the mid corresponding to a data channel in the group (3). + Note that Alice has chosen not to include any CLUE-controlled media + in the initial offer -- the "mid" value of the video line is not + included in the "CLUE" group. + + ... + 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:3 + + Bob responds with a similar SDP in SIP 200 OK 1, which also has a + "CLUE" group including the "mid" value of a data channel; due to + their similarity, no SDP snippet is shown here. Bob wishes to + receive initial media and thus includes corresponding non-CLUE- + controlled audio and video lines. Bob also includes the "sip.clue" + media feature tag in the 200 OK. Alice and Bob are each now able to + send a single audio and video stream. This is illustrated as MEDIA + 1. + + With the successful initial SDP Offer/Answer exchange complete, Alice + and Bob are also free to negotiate the CLUE data channel. This is + illustrated as CLUE DATA CHANNEL ESTABLISHED. + + Once the data channel is established, CLUE protocol negotiation + begins. In this case, Bob was the DTLS client (sending "a=active" in + his SDP Answer) and hence is the CLUE Channel Initiator. He sends a + CLUE OPTIONS message describing his version support. On receiving + that message, Alice sends her corresponding CLUE OPTIONS RESPONSE. + + With the OPTIONS phase complete, Alice now sends her CLUE + 'advertisement' message (CLUE ADVERTISEMENT 1). She advertises three + static Captures representing her three cameras. She also includes + switched Captures suitable for systems with one or two screens. All + of these Captures are in a single Capture Scene, with suitable + Capture Scene Views that tell Bob he should subscribe to the three + static Captures, the two switched Captures, or the one switched + Capture. Alice has no simultaneity constraints, so all six Captures + are included in one simultaneous set. Finally, Alice includes an + Encoding Group with three Encoding IDs: "enc1", "enc2", and "enc3". + These Encoding IDs aren't currently valid but will match the next SDP + Offer she sends. + + Bob received CLUE ADVERTISEMENT 1 but does not yet send a 'configure' + message, because he has not yet received Alice's Encoding + information; thus, he does not know if she will have sufficient + resources in order to send him the two streams he ideally wants at a + quality he is happy with. Because Bob is not sending an immediate + 'configure' message with the "ack" element set, he must send an + explicit 'ack' message (CLUE ACK 1) to signal receipt of CLUE + ADVERTISEMENT 1. + + Bob also sends his CLUE 'advertisement' message (CLUE ADVERTISEMENT + 2) -- though the diagram shows that this occurs after Alice sends + CLUE ADVERTISEMENT 1, Bob sends his 'advertisement' message + independently and does not wait for CLUE ADVERTISEMENT 1 to arrive. + He advertises two static Captures representing his cameras. He also + includes a single composed Capture for single-screen systems, in + which he will composite the two camera views into a single video + stream. All three Captures are in a single Capture Scene, with + suitable Capture Scene Views that tell Alice she should subscribe to + either the two static Captures or the single composed Capture. Bob + also has no simultaneity constraints, so he includes all three + Captures in one simultaneous set. Bob also includes a single + Encoding Group with two Encoding IDs: "foo" and "bar". + + Similarly, Alice receives CLUE ADVERTISEMENT 2 but does not yet send + a 'configure' message, because she has not yet received Bob's + Encoding information; instead, she sends an 'ack' message (CLUE ACK + 2). + + Both sides have now sent their CLUE 'advertisement' messages, and an + SDP exchange is required to negotiate Encodings. For simplicity, in + this case, Alice is shown sending an INVITE with a new offer; in many + implementations, both sides might send an INVITE, which would be + resolved by use of the 491 Request Pending resolution mechanism from + [RFC3261]. + + Alice now sends SIP INVITE 2. She maintains the sendrecv audio, + video, and CLUE "m=" lines, and she adds three new sendonly "m=" + lines to represent the three CLUE-controlled Encodings she can send. + Each of these "m=" lines has a label corresponding to one of the + Encoding IDs from CLUE ADVERTISEMENT 1. Each also has its mid added + to the grouping attribute to show they are controlled by the CLUE + data channel. A snippet of the SDP showing the grouping attribute, + data channel, and video "m=" lines are shown below: + + ... + 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:enc3 + + Bob now has all the information he needs to decide which streams to + configure, allowing him to send both a CLUE 'configure' message and + his SDP Answer. As such, he now sends CLUE CONFIGURE 1. This + 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 includes three + additional "m=" lines corresponding to the three added by Alice: two + active recvonly "m= "lines and an inactive "m=" line for the third. + He adds their "mid" values to the grouping attribute to show they are + controlled by the CLUE data channel. A snippet of the SDP showing + the grouping attribute and the video "m=" lines are shown below (mid + 100 represents the CLUE data channel, which is not 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:13 + + Alice receives Bob's CLUE CONFIGURE 1 message and sends CLUE + CONFIGURE RESPONSE 1 to acknowledge its reception. She does not yet + send the Capture Encodings specified, because at this stage, she + hasn't processed Bob's answer SDP and thus hasn't negotiated the + ability for Bob to receive these streams. + + On receiving SIP 200 OK 2 from Bob, Alice sends her SIP ACK (SIP ACK + 2). She is now able to send the two streams of video Bob requested + -- this is illustrated as MEDIA 2. + + The constraints of offer/answer meant that Bob could not include his + Encoding information as new "m=" lines in SIP 200 OK 2. As such, Bob + now sends SIP INVITE 3 to generate a new offer. Along with all the + streams from SIP 200 OK 2, Bob also includes two new sendonly + streams. Each stream has a label corresponding to the Encoding IDs + in his CLUE ADVERTISEMENT 2 message. He also adds their "mid" values + to the grouping attribute to show they are controlled by the CLUE + data channel. A snippet of the SDP showing the grouping attribute + and the video "m=" lines are shown below (mid 100 represents the CLUE + data channel, which is not 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:15 + + Having received this, Alice now has all the information she needs to + send her CLUE 'configure' message and her SDP Answer. In CLUE + CONFIGURE 2, she requests the two static Captures from Bob to be sent + on Encodings "foo" and "bar". + + Alice also sends SIP 200 OK 3, matching two recvonly "m=" lines to + Bob's new sendonly lines. She includes their "mid" values in the + grouping attribute to show they are controlled by the CLUE data + channel. Alice then deactivates the initial non-CLUE-controlled + media, as bidirectional CLUE-controlled media is now available. A + snippet of the SDP showing the grouping attribute and the video "m=" + lines are shown below (mid 3 represents 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:8 + + Bob receives Alice's CLUE CONFIGURE 2 message and sends CLUE + CONFIGURE RESPONSE 2 to acknowledge its reception. Bob does not yet + send the Capture Encodings specified, because he hasn't yet received + and processed Alice's SDP Answer and negotiated the ability to send + these streams. + + Finally, on receiving SIP 200 OK 3, Bob is now able to send the two + streams of video Alice requested -- this is illustrated as MEDIA 3. + + Both sides of the call are now sending multiple video streams with + their sources defined via CLUE negotiation. As the call progresses, + either side can send a new 'advertisement' or 'configure' message or + the new SDP Offers/Answers to add, remove, or change what they have + available or want to receive. + +9. Example: A Call between a CLUE-Capable and Non-CLUE Endpoint + + In this brief example, Alice is a CLUE-capable Endpoint making a call + to Bob, who is not CLUE capable (i.e., is not able to use the CLUE + protocol). + + +----------+ +-----------+ + | Alice | | Bob | + | | | | + +----+-----+ +-----+-----+ + | | + | | + | SIP INVITE 1 | + |--------------------------------->| + | | + | | + | 200 0K 1 | + |<---------------------------------| + | | + | | + | SIP ACK 1 | + |--------------------------------->| + | | + | | + | | + |<########### MEDIA 1 ############>| + | 1 video A->B, 1 video B->A | + |<################################>| + | | + | | + | | + | | + v v + + In SIP INVITE 1, Alice sends Bob a SIP INVITE including the basic + audio and video capabilities and data channel in the SDP body as per + [RFC8841]. Alice also includes the "sip.clue" media feature tag in + the INVITE. A snippet of the SDP showing the grouping attribute and + the video "m=" line are shown below. Alice has included a "CLUE" + group and the mid corresponding to a data channel in the group (3). + Note that Alice has chosen not to include any CLUE-controlled media + in the initial offer -- the "mid" value of the video line is not + included in the "CLUE" group. + + ... + 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:3 + + Bob is not CLUE capable and hence does not recognize the "CLUE" + semantic for the grouping attribute, nor does he support the data + channel. IN SIP 200 OK 1, he responds with an answer that includes + audio and video, but with the data channel zeroed. + + From the lack of a CLUE group, Alice understands that Bob does not + support CLUE, or does not wish to use it. Both sides are now able to + send a single audio and video stream to each other. At this point, + Alice begins to send her fallback video: in this case, it's likely 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 the following semantics with IANA in the + "Semantics for the 'group' SDP Attribute" subregistry (under the + "Session Description Protocol (SDP) Parameters" registry) per + [RFC5888]: + + +===========================+=======+==============+===========+ + | Semantics | Token | Mux Category | Reference | + +===========================+=======+==============+===========+ + | CLUE-controlled "m=" line | CLUE | NORMAL | RFC 8848 | + +---------------------------+-------+--------------+-----------+ + + Table 1 + +10.2. New SIP Media Feature Tag + + This specification registers a new media feature tag in the SIP + [RFC3261] tree per the procedures defined in [RFC2506] and [RFC3840]. + + 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: COMMON + +11. Security Considerations + + CLUE makes use of a number of protocols and mechanisms, either + defined by CLUE or long-standing. The Security Considerations + section of the CLUE Framework document [RFC8845] addresses the need + to secure these mechanisms by following the recommendations of the + individual protocols. + + Beyond the need to secure the constituent protocols, the use of CLUE + does impose additional security concerns. One area of increased risk + involves the potential for a malicious party to subvert a CLUE- + capable device to attack a third party by driving large volumes of + media (particularly video) traffic at them by establishing a + connection to the CLUE-capable device and directing the media to the + victim. While this is a risk for all media devices, a CLUE-capable + device may allow the attacker to configure multiple media streams to + be sent, significantly increasing the volume of traffic directed at + the victim. + + This attack can be prevented by ensuring that the media recipient + intends to receive the media packets. As such, 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 provides 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 the use of SRTP to secure legacy (non-CLUE-controlled) + media for backwards compatibility with older SIP clients that are + incapable of supporting it. + + CLUE also defines a new media feature tag that indicates CLUE + support. This tag may be present even in non-CLUE calls, which + increases the metadata available about the sending device; this can + help an attacker differentiate between multiple devices and identify + otherwise anonymized users via 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 additional information that could be + used to help fingerprint a particular user or to identify the + specific version of software being used. The CLUE Framework + [RFC8847] provides details about 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 + + [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 + + Besides the authors, the team focusing on this document consists of: + Roni Even, Simon Pietro Romano, and Roberta Presta. + + Christian Groves, Jonathan Lennox, and Adam Roach have contributed + detailed comments and suggestions. + +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.com |