Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures
Extracted elements (25)
The CaptureID is carried in both an RTP header extension and an RTCP SDES item because for switched captures, receivers need to know which original MC corresponds to the media being sent in an MCC in order to correctly apply geometric adjustments (e.g., scaling) to the received media. The original MC does not have its own Capture Encoding and cannot be associated with an 'm=' line label.
The single-dash '-' character was chosen as the sentinel value for 'no applicable captureID' because the CLUE captureID syntax (defined as 'xs:ID' in RFC 8846) makes a single dash an illegal captureID value, eliminating any ambiguity with actual captureID values.
If a composed capture includes CSRC information in the RTP header, the media provider MAY send captureID values in RTCP SDES packets for those CSRC SSRC values, providing MC identification in the composed (non-switched) case.
In a Point-to-Point CLUE session, an endpoint can produce composite or switched captures for receivers with fewer displays than the sender has cameras, which may require MCC semantics even though the topology is nominally peer-to-peer.
All CLUE implementations MUST support DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and P-256 curve. The DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported.
CLUE endpoints MAY also support sending some or all of the RTP streams in a single RTP session, using the mechanism described in RFC 8843 to relate RTP streams to SDP 'm=' lines.
CLUE endpoints MUST generate short-term persistent RTCP CNAMEs as specified in RFC 7022, so they cannot be used for long-term tracking of users.
CLUE endpoints MUST support RTP/SAVPF profiles and SRTP (RFC 3711). They MUST also support DTLS (RFC 6347) and DTLS-SRTP (RFC 5763, RFC 5764) for SRTP keying.
Each Capture Encoding MUST be sent as a separate RTP stream. CLUE endpoints MUST support sending each such RTP stream in a separate RTP session signaled by an SDP 'm=' line.
Encrypted SRTP header extensions (RFC 6904) MUST be supported. Encryption of header extensions is RECOMMENDED unless there are known reasons not to use it.
If more than one MC is composed into the MCC, the media provider MUST NOT send any of the MCs' captureIDs using the RTP header extension or RTCP SDES mechanism.
If there is only one MC in the MCC, the media provider MUST send the captureID of the current constituent MC in the RTP header extension and as an RTCP CaptureID SDES item. When the provider switches the MC it sends within an MCC, it MUST send the captureID value for the newly switched MC.
Implementations MUST favor cipher suites that support Perfect Forward Secrecy (PFS) over non-PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites. NULL Protection profiles MUST NOT be used for RTP or RTCP.
In multi-party communication using RTP middleboxes, the middleboxes are REQUIRED to not weaken the sessions' security; the middlebox SHOULD maintain confidentiality, integrity, and perform source authentication.
The RTCP CaptureID SDES item MUST be sent in an SDES packet within a compound RTCP packet unless Reduced-Size RTCP (RFC 5506) has been negotiated, in which case it can be sent in a noncompound RTCP packet.
When transitioning from a single switched MC to a composed stream of multiple MCs in the same MCC, the media provider MUST send the special value '-' (single-dash) as the captureID RTP header extension and RTCP CaptureID SDES item to indicate no applicable value.
Long-term persistent RTCP CNAME identifiers can be used to track users across multiple calls. The spec mandates short-term persistent RTCP CNAMEs per RFC 7022 to prevent such tracking.
The CaptureID RTP header extension and RTCP SDES item enable mapping of an MCC's RTP stream SSRC to the captureID of the single original MC currently switched into the MCC. The special value '-' (single-dash) indicates no applicable constituent captureID (e.g., composed multi-MC scenario).
The CaptureID RTP header extension is negotiated in SDP using the URN 'urn:ietf:params:rtp-hdrext:sdes:CaptureID' and is carried using the mechanism defined in RFC 7941. Senders MAY send it only when a new MC is switched, but SHOULD send it in the first few RTP packets to reduce risk of loss.
The Multiple Content Capture (MCC) is a special CLUE Media Capture composed of multiple Media Captures. An RTP stream conveying an MCC may switch between different constituent Media Captures over time, requiring the CaptureID mechanism to identify the current constituent MC.
This document registers a new extension URI 'urn:ietf:params:rtp-hdrext:sdes:CaptId' in the 'RTP SDES Compact Header Extensions' subregistry of the 'Real-Time Transport Protocol (RTP) Parameters' registry.
This document registers a new RTCP SDES item type (value 14, abbreviation CCID, name 'CLUE CaptId') in the 'RTCP SDES Item Types' registry.
Inappropriate configuration of the RTCP reporting interval—either too large (preventing effective congestion control) or too small (causing high-rate non-congestion-controlled RTCP traffic)—can lead to denial-of-service attacks. Endpoints SHOULD ignore parameters that configure the RTCP interval significantly longer than the default five-second interval or short enough that RTCP bandwidth would exceed media bandwidth.
The CaptureID SDES item should use at least similar protection profiles as the CLUE protocol messages carried in the CLUE data channel, since the CaptureID value is also carried in CLUE protocol messages.
The RTCP CaptureID SDES item (CaptId=14) uses an 8-bit type field set to 14, an 8-bit length field, followed by a variable-length UTF-8 string containing either a CLUE CaptureID or the single character '-'.