Allowing Synchronisation Source (SSRC) and Timestamp
Rewriting in Privacy Enhanced RTP Conferencing (PERC)
Atlassian303 Colorado Street, #1600Austin78701USA+1-512-640-3000bgrozev@atlassian.comAtlassian303 Colorado Street, #1600Austin78701USA+1-512-640-3000eivov@atlassian.comCoSMo Software Consulting28 Bukit Pasoh RdSingapore089842Singapore+65-9270-9152alex.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.
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
.
SRTP Double Encryption Procedures
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.