Network Working Group B. Grozev
Internet-Draft E. Ivov
Intended status: Standards Track Atlassian
Expires: September 29, 2017 A. Gouaillard
March 28, 2017

Allowing Synchronisation Source (SSRC) and Timestamp Rewriting in Privacy Enhanced RTP Conferencing (PERC)


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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 29, 2017.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

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.

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


Figure 1: Trickle State Updates

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.

2. Terminology

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 [RFC2119].

3. Extended Original Header Block (OHB) Format

The OHB header extension is defined in the ”double” draft [I-D.ietf-perc-double]. 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 [RFC5285] 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.

      |len| R-bit set       |R-bit not set |
      | 0 |PT               |              |
      | 1 |SEQ              |              |
      | 2 |PT, SEQ          |              | 
      | 3 |SSRC             |              |
      | 4 |PT, SSRC         | PT, TS       |
      | 5 |SEQ, SSRC        |              |
      | 6 |PT, SEQ, SSRC    | PT, SEQ, TS  |
      | 7 |SSRC, TS         |              |
      | 8 |PT, SSRC, TS     |              |
      | 9 |SEQ, SSRC, TS    |              |
      | 10|PT, SEQ, SSRC, TS|              |


Figure 2: OHB Fields

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

4. Alternative format

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 [I-D.ietf-perc-double], 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).

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
      |   ID  |  len  |P|S|s|T|M|p|0 0|


Figure 3: Alternative OHB format

These two bits can be transported with the following alternative format for the OHB header extension:


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.

5. Security Considerations

6. Acknowledgements

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

7. References

7.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

7.2. Informative References

[I-D.ietf-perc-double] Jennings, C., Jones, P. and A. Roach, "SRTP Double Encryption Procedures", Internet-Draft draft-ietf-perc-double-03, March 2017.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008.

Authors' Addresses

Boris Grozev Atlassian 303 Colorado Street, #1600 Austin, 78701 USA Phone: +1-512-640-3000 EMail:
Emil Ivov Atlassian 303 Colorado Street, #1600 Austin, 78701 USA Phone: +1-512-640-3000 EMail:
Alexandre Gouaillard CoSMo Software Consulting 28 Bukit Pasoh Rd Singapore, 089842 Singapore Phone: +65-9270-9152 EMail: