Atlassian

303 Colorado Street, #1600 Austin 78701 USA +1-512-640-3000 bgrozev@atlassian.com

Atlassian

303 Colorado Street, #1600 Austin 78701 USA +1-512-640-3000 eivov@atlassian.com

CoSMo Software Consulting

28 Bukit Pasoh Rd Singapore 089842 Singapore +65-9270-9152 alex.gouaillard@cosmosoftware.io

Privacy Enhanced RTP Conferenceing allows middle boxes (MDs) to overwrite a certain set of fields in RTP packets, as long as they preserve their original values in the Original Header Block (OHB). This draft discusses the option of extending the OHB so that it would also include the RTP timestamp and Synchornization Source identifier (SSRC) within the set of fields an SSRC can modify.

In multi-endpoint RTP conferences, packet forwarding middleboxes (e.g. Selecting Forwarding Units (SFUs)) adapt to variable bandwidth conditions by selectively dropping a subset of the packets when forwarding traffic to some or all recipients. These dropped packets may correspond to certain participants, but more importantly simulcast layers. A common model for implementing simulcast consists in having senders send multiple resolutions to the middlebox, each with its own SSRC, as well as distinct sequence number and timestamp spaces. Middleboxes on the other hand, often choose to only make receivers aware of a single SSRC, timestamp and sequence number space, as shown on the figure below.

| | | | |Sender|--SSRC2 Timestamp2-->| SFU |--SSRC4 Timestamp4-->|Receiver| | |--SSRC3 Timestamp3-->| | | | +------+ +-----+ +--------+ ]]>

The advantage of this model consists in the fact that receivers require no custom logic to support it as all they ever see is a single incoming video stream. In its current state the PERC double specification does not allow for SSRC and timestamps to be overwritten, which makes it impossible for SFUs to continue operating in this manner. This document therefore defines an extended OHB format and explains the specifics of implementing SSRC and timestamp rewriting within a PERC environment.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The OHB header extension is defined in the ”double” draft . The current version defines a structure which can contain atmost the original RTP Payload Type (PT) and SEQ fields, and this restricts the MD to only modifying thesetwo fields, while, as explained before, for the simulcast usecase the MD may also need to modify the SSRC and the timestamp. This specification extends the OBH structure so that it can contain the additional fields needed for the WebRTC 1.0 simulcast use case. It still uses the 4-bit length field of the header extension header to encode the structure of the remainingbytes. Specifically, it encodes which of these four fields will be present in the following bytes: Payload Type (PT, 1 byte, including an extra R-bit), Sequence Number (SEQ, 2 bytes), SSRC(4 bytes), Timestamp (TS, 4 bytes). If the length field has a value of 0, 1 or 2 (indicating that there are respectively 1, 2 or 3 more bytes), then the format is exactly the same as in the current draft. This means that an endpoint which implements the extended format can workwith the current format without modification. The following table lists the fields which are encoded (and the order in which they are included) for the different values of the length field and the R-bit. The R-bit is the most significant bit (MSB) of the PT field, and is present if and only if the PT field is present. If the extension includes the PT field, it consists of an R-bit (MSB) and 7 bits for the original RTP Payload Type. The R-bit is used to encode which fields are included, when there is ambiguity.

The fields encoded in the OHB header extension, for different values of the length field and the R-bit.

In the context of SVC an MD might need to modify the M bit of RTP packets (for example when the higher layers of a frame are dropped, and the frame terminates "early"). The original format from the "double" draft , as well as the format described above don't allow for the M bit to be modified. One more bit of information which may be desired to be transported from a PERC sender to an MD is whether a packet contains actual payload, or consists only of padding (i.e. discardable data). These two bits can be transported with the following alternative format for the OHB header extension:

Where: P specifies the presence of a Payload Type byte. S specifies the presence of a Sequence Number field (2 bytes). s specifies the presence of a SSRC field (4 bytes). T specifies the presence of a Timestamp field (4 bytes). M contains the original value of the M bit. p is a padding-only bit, which indicates that the packet contains only padding and can be discarded.

Sergio Garcia Murillo raised the need for MDs to overwrite the M-bit and suggested the alternative extra-byte encoding described in .

In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some RTP parameters, while still providing strong end-to-end security guarantees. This document defines SRTP procedures that use two separate but related cryptographic contexts to provide "hop-by-hop" and "end-to-end" security guarantees. Both the end-to-end and hop-by-hop cryptographic transforms can utilize an authenticated encryption with associated data scheme or take advantage of future SRTP transforms with different properties.