Using RTX with Privacy Enhanced RTP Conferencing (PERC)

In multi-endpoint RTP conferences it is desired for middleboxes (e.g. Selecting Forwarding Units (SFUs), or in the case of PERC Media Distributors (MDs)) to terminate RTP packet retransmission, because this can reduce the retransmission delay and the unnecessary retransmission of packets. In the context of PERC, if RTX is handled as a regular media stream, then an MD can not terminate packet retransmission.

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 RTX format (RFC 4588) uses the first two bytes of the RTP payload (the Original Sequence Number field (OSN)) to transport the RTP sequence number of the retransmitted packet. If the procedure used for regular media streams is also used for RTX, the MD does not have access to the OSN field, because it is E2E encrypted as part of the RTP payload, and this prevents it from terminating retransmissions. In the context of PERC, RTX should be performed only HBH. That is, the payload of the RTX packet must be encrypted with the HBH context, but not with the E2E context. Specifically, when an entity retransmits a packet using RTX it: Takes an E2E encrypted packet to be retransmitted. Applies the RTX transformation (replaces the SSRC, payload type and sequence number, and inserts the OSN field in the payload. Performs the HBH SRTP transformation.

RFC3550 allows an RTP packet to contain only padding, and no payload. The number of padding bytes is contained in the last byte of the payload, and it is encrypted by SRTP. In the context of PERC, an MD does not have access to the padding length field of an RTX packet, and therefore it can not determine whether the packet contains non-padding payload or not. RTX packets with padding only are currently used by some bandwidth estimation algorithms when probing for additional bandwidth availability. Bandwidth estimations have a strictly hop-by-hop context, so MDs therefore usually terminate them by recognizing and dropping all incoming probe packets. They then generate new ones for their own estimations. In order to recognize an incoming packet as a probe-only one, an MD needs to inspect its last octet and compare it to the overall length of the payload. Yet, in a PERC scenario this last octet is protected by PERC's end-to-end encryption and will hence be unreadable to the MD. The MD will therefore have no choice but to treat this as a regular RTX packet: replace its sequence number, payload type, and SSRC and forward it to receivers that would likely fail in unpredictable ways (e.g., either failing SRTP authentication or maybe even feeding garbage data to their decoders). A similar problem also exists for probe packets the the MD generates and that receivers have no way to reliably recognize. In order for MDs and receivers to properly terminate bandwidth estimation, it is therefore necessary for an MD to reliably recognize such padding-only packets. The use of a single "padding-only" bit in any new or existing RTP header extension is ony way to achieve this. PERC MDs are already likely to rely on the framemarking header extension and we propose transporting this bit there. We propose to use the first bit of the unused bits in the format for non-scalable streams, which is marked as the P bit in the diagram below.