| Network Working Group | B. Grozev |
| Internet-Draft | E. Ivov |
| Intended status: Standards Track | Atlassian |
| Expires: September 29, 2017 | A. Gouaillard |
| CoSMo | |
| March 28, 2017 |
Allowing Synchronisation Source (SSRC) and Timestamp Rewriting in Privacy Enhanced RTP Conferencing (PERC)
draft-grozev-perc-ssrc-00
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.
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 http://datatracker.ietf.org/drafts/current/.
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 (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 (http://trustee.ietf.org/license-info) 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.
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.
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].
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.
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:
Where:
Sergio Garcia Murillo raised the need for MDs to overwrite the M-bit and suggested the alternative extra-byte encoding described in Section 4.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [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. |