RFC 9605: Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media
In plain English — editorial summary, not part of the RFC
This document describes the Secure Frame (SFrame) end-to-end encryption and authentication mechanism for media frames in a multiparty conference call, in which central media servers (Selective Forwarding Units or SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media. This mechanism differs from the Secure Real-Time Protocol (SRTP) in that it is independent of RTP (thus compatible with non-RTP media transport) and can be applied to whole media frames in order to be more bandwidth efficient.
Document record
- Document ID
- RFC9605
- Published
- August 2024
- Authors
- E. Omara; J. Uberti; S. G. Murillo; R. Barnes; Y. Fablet
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- art
- Pages
- 68
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 9750The Messaging Layer Security (MLS) ArchitectureCurrent
April 2025
- RFC 9185DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key ExchangeCurrent
April 2022
- RFC 8862Best Practices for Securing RTP Media Signaled with SIPCurrent
January 2021
- RFC 7712Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)Current
November 2015
- RFC 7293The Require-Recipient-Valid-Since Header Field and SMTP Service ExtensionCurrent
July 2014
- RFC 5672RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- UpdateObsoleted
August 2009
- RFC 9635Grant Negotiation and Authorization Protocol (GNAP)Current
October 2024
- RFC 9668Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE)Current
November 2024
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?