Internet DRAFT - draft-grozev-perc-ssrc
draft-grozev-perc-ssrc
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
Abstract
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 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 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
(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
Grozev, et al. Expires September 29, 2017 [Page 1]
Internet-Draft SSRC rewrite March 2017
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extended Original Header Block (OHB) Format . . . . . . . . . 3
4. Alternative format . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
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.
Grozev, et al. Expires September 29, 2017 [Page 2]
Internet-Draft SSRC rewrite March 2017
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.
Grozev, et al. Expires September 29, 2017 [Page 3]
Internet-Draft SSRC rewrite March 2017
+---+-----------------+--------------+
|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).
These two bits can be transported with the following alternative
format for the OHB header extension:
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
Grozev, et al. Expires September 29, 2017 [Page 4]
Internet-Draft SSRC rewrite March 2017
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.
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,
<http://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References
[I-D.ietf-perc-double]
Jennings, C., Jones, P., and A. Roach, "SRTP Double
Encryption Procedures", draft-ietf-perc-double-03 (work in
progress), March 2017.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <http://www.rfc-editor.org/info/rfc5285>.
Authors' Addresses
Grozev, et al. Expires September 29, 2017 [Page 5]
Internet-Draft SSRC rewrite March 2017
Boris Grozev
Atlassian
303 Colorado Street, #1600
Austin 78701
USA
Phone: +1-512-640-3000
Email: bgrozev@atlassian.com
Emil Ivov
Atlassian
303 Colorado Street, #1600
Austin 78701
USA
Phone: +1-512-640-3000
Email: eivov@atlassian.com
Alexandre Gouaillard
CoSMo Software Consulting
28 Bukit Pasoh Rd
Singapore 089842
Singapore
Phone: +65-9270-9152
Email: alex.gouaillard@cosmosoftware.io
Grozev, et al. Expires September 29, 2017 [Page 6]
