]> Microsoft

pthatcher@microsoft.com

Apple

youenn@apple.com

Applications and Real-Time Audio/Video Transport Core Maintenance Internet-Draft This document describes the RTP payload format of SFrame. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Audio/Video Transport Core Maintenance Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction SFrame describes an end-to-end encryption and authentication mechanism for media data in a multiparty conference call, in which central media servers (SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media. This document describes how to packetize a media frame encrypted using SFrame into RTP packets.

Terminology and Notation 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 when, and only when, they appear in all capitals, as shown here.

SFrame format An SFrame ciphertext comprises a header and encrypted data. The SFrame header has a size varying between 1 to 17 bytes. The encrypted data can be of arbitrary length and is larger than the unencrypted data by a fixed overhead that depends on the encryption algorithm. The overhead can be up to 16 bytes. An SFrame ciphertext having an arbitrary long length, an application may decide to partition the data encrypted with SFrame small enough so that the SFrame ciphertext fits in a single RTP packet. We call this per-packet SFrame. This has the advantage of allowing to decrypt the content as soon as received. An alternative is to encrypt the data, a media frame typically, and send the SFrame ciphertext over several RTP packets. We call this per-frame SFrame. This has the advantage of limiting the SFrame overhead, especially for video frames. This alternative is also compatible with , which is important for backward compatibility of existing services. The RTP format presented in this document supports both alternatives.

RTP Header Usage The general RTP payload format for SFrame is depicted below. The first byte of the RTP payload is the SFrame RTP header. The S bit of the SFrame RTP header MUST be 0 for all fragments except for the first one of the SFrame frame. The E bit of the SFrame RTP header MUST be 0 for all fragments except for the last one of the SFrame frame. The 6 remaining bits of the SFrame RTP header are reserved for future use. The payload type (PT) identifies the format of the media encrypted with SFrame. The SSRC, timestamp, marker bit, and CSRCs of the SFrame RTP packets MUST be the same as those of the output of the media-format-specific packetization. The header extensions of the SFrame RTP packets SHOULD be the same as those of the output of the media-format-specific packetization, but some may be omitted if it is known that the omitted header extensions do not need to be duplicated on each SFrame RTP packet.

RTP Packetization of SFrame SFrame packets can be generated either from RTP media packets or from media frames as defined by . For per-packet SFrame, the following processing is done, with a media frame as input:

1. Generate a group of RTP media packets from the media frame using a media-format-specific packetizer. The media-format-specific packetizer needs to be made aware of the SFrame overhead that happens to each RTP packet.
2. For each RTP packet of the group, encrypt its payload with SFrame.
3. Prepend to each RTP packet payload a SFrame RTP header with the S and E bits set to 1.
4. Send each RTP packet of the group.

For per-frame SFrame, the following processing is done, with a media frame as input:

1. Generate a SFrame ciphertext from the media frame data.
2. Fragment the SFrame ciphertext in a group of payloads so that RTP packets generated from them do not exceed the network maximum transmission unit size.
3. Prepend a zero byte as the SFrame RTP header to all payloads of the group.
4. Set the first bit S of the SFrame RTP header of the first packet to 1.
5. Set the second bit E of the SFrame RTP header of the last packet to 1.
6. Generate a group of RTP packets from the group of payloads, using the media frame to generate the RTP header, including RTP header extensions.
7. Send each RTP packet of the RTP packet group.

RTP depacketization of SFrame Reception of SFrame packets is done as follows:

1. The fragments of a given SFrame ciphertext are grouped together in order of the RTP sequence number, the first packet of the group having its S bit set to 1 and the last packet of the group havint its E bit set to 1. All packets in between the first and last needs to be in the group.
2. Concatenate the payloads of all packets of the group to form the SFrame ciphertext.
3. Decrypt the SFrame ciphertext to obtain the media decrypted data.
4. If per-packet SFrame is being used, the following processing is done:
   1. assert that the group of packets consist of a single packet.
   2. Set the media decrypted data as the payload of the packet and send the packet to the media-format-specific RTP depacketizer.
   3. If the depacketizer cannot generate a media frame yet, abort these steps. Otherwise, generate a media frame from the depacketizer.
5. If per-frame SFrame is being used, the following processing is done:
   1. assert that the group of packets all have the same payload type.
   2. Extract the media metadata from the group of packets.
   3. Generate a media frame from the media decrypted data and the media metadata.
6. Send the media frame to the receiving pipeline.

SFrame SDP negotiation SFrame packetization is indicated via a new "a=sframe" SDP attribute defined in this specification. This attribute is used at media level, it does not appear at session level. The presence of the "a=sframe" attribute in a media section (in either an offer or an answer) indicates that the endpoint is expecting to receive RTP packets encrypted with SFrame for that media section, as defined below. Once each peer has verified that the other party expects to receive SFrame RTP packets, senders are expected to send SFrame encrypted RTP packets. If one peer expects to use SFrame for a media section and identifies that the other peer does not support it, the peer is expected to stop the transceiver associated to the media section, which will generate a zero port for that m-section. When SFrame is in use for that media section, it will apply to the relevant media encodings defined for that media section. This includes RTP payload types bound to media packetizers and media depacketizers as defined in , typically audio formats such as Opus and RTP video formats such as H264. This notably includes RTP payload types representing encoded video frame formats and encoded audio frame formats. This does not include RTP-Based Redundancy mechanisms as defined in {!RFC7656}}. For instance, RTX defined in will retransmit SFrame based packets. Forward error correction formats as defined in will protect the encrypted content. For Redundant Audio Data, known as RED, as defined in , a RED packetizer will take as input SFrame encrypted media data instead of unencrypted media data. If BUNDLE is in use and the "a=sframe" attribute is present for a media section but not for another media section of the same BUNDLE, payload types for media encodings that are relevant for SFrame MUST not be reused between the two media sections. Questions:

1. Should we precise how RTX/FEC works with SFrame packetization? No impact AFAIK since RTX/FEC would work on packets (whether SFramed or not).
2. Is RED current proposal (transmit SFrame ciphertext blocks) good enough? An alternative is to have SFrame being applied on the entire RED packet payload.
3. Should we allow a=sframe at session level to mean that all media sections want sframe?

Here is an example of SFrame being negotiated for audio (opus and CN) and for video (H264 and VP8):

Security Considerations This document is subject to the security considerations of SFrame.

IANA Considerations None

Normative References World Wide Web Consortium 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. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The terminology about, and associations among, Real-time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed properties and relationships among RTP sources and defines common terminology for discussing protocol entities and their relationships. RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo. [STANDARDS-TRACK] This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009. [STANDARDS-TRACK] This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. [STANDARDS-TRACK]