draft-westerlund-avtcore-transport-multiplexing-04.txt   draft-westerlund-avtcore-transport-multiplexing-05.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track C. Perkins Intended status: Standards Track C. Perkins
Expires: April 25, 2013 University of Glasgow Expires: August 29, 2013 University of Glasgow
October 22, 2012 February 25, 2013
Multiple RTP Sessions on a Single Lower-Layer Transport Multiple RTP Sessions on a Single Lower-Layer Transport
draft-westerlund-avtcore-transport-multiplexing-04 draft-westerlund-avtcore-transport-multiplexing-05
Abstract Abstract
This document specifies how multiple RTP sessions are to be This memo defines a mechanism to allow multiple RTP sessions to be
multiplexed on the same lower-layer transport, e.g. a UDP flow. It multiplexed onto a single lower-layer transport flow (e.g., onto a
discusses various requirements that have been raised and their single UDP 5-tuple). Requirements for multiplexing RTP sessions are
feasibility, which results in a solution with a certain discussed, along with the trade-off between the different options. A
applicability. A solution is recommended and that solution is shim-based multiplexing layer is proposed, along with associated
provided in more detail, including signalling and examples. signalling.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 5 3.1. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 5
3.2. No Transport Level QoS . . . . . . . . . . . . . . . . . . 5 3.2. No Transport Level QoS . . . . . . . . . . . . . . . . . . 5
3.3. Multiple RTP sessions . . . . . . . . . . . . . . . . . . 6 3.3. Multiple RTP sessions . . . . . . . . . . . . . . . . . . 5
3.4. Usage of RTP Extensions . . . . . . . . . . . . . . . . . 6 3.4. Usage of RTP Extensions . . . . . . . . . . . . . . . . . 6
3.5. Incremental Deployment . . . . . . . . . . . . . . . . . . 7 3.5. Incremental Deployment . . . . . . . . . . . . . . . . . . 7
3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Support Use of Multiple RTP Sessions . . . . . . . . . . . 7 4.1. Support Use of Multiple RTP Sessions . . . . . . . . . . . 7
4.2. Same SSRC Value in Multiple RTP Sessions . . . . . . . . . 8 4.2. Same SSRC Value in Multiple RTP Sessions . . . . . . . . . 8
4.3. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 9 4.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 9
4.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 9 4.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 9
4.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 9 4.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 9
4.7. Usable Also Over Multicast . . . . . . . . . . . . . . . . 10 4.7. Usable Also Over Multicast . . . . . . . . . . . . . . . . 10
4.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 10 4.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 10
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 10 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 10
5.1. Location of SHIM . . . . . . . . . . . . . . . . . . . . . 10 5.1. Location of SHIM . . . . . . . . . . . . . . . . . . . . . 10
5.2. ICE and DTLS-SRTP Integration . . . . . . . . . . . . . . 12 5.2. ICE and DTLS-SRTP Integration . . . . . . . . . . . . . . 12
5.3. Signalling Fallback . . . . . . . . . . . . . . . . . . . 12 5.3. Signalling Fall Back . . . . . . . . . . . . . . . . . . . 12
6. Specification . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Specification . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. SRTP Key Management . . . . . . . . . . . . . . . . . . . 18 6.3. SRTP Key Management . . . . . . . . . . . . . . . . . . . 18
6.3.1. Security Description . . . . . . . . . . . . . . . . . 19 6.3.1. Security Description . . . . . . . . . . . . . . . . . 19
6.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 19 6.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 19
6.3.3. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3.3. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4.1. RTP Packet with Transport Header . . . . . . . . . . . 20 6.4.1. RTP Packet with Transport Header . . . . . . . . . . . 20
6.4.2. SDP Offer/Answer example . . . . . . . . . . . . . . . 21 6.4.2. SDP Offer/Answer example . . . . . . . . . . . . . . . 21
skipping to change at page 4, line 7 skipping to change at page 4, line 7
B.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 36 B.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 36
B.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 37 B.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 37
B.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 38 B.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 38
B.7. Usable over Multicast . . . . . . . . . . . . . . . . . . 39 B.7. Usable over Multicast . . . . . . . . . . . . . . . . . . 39
B.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 39 B.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 39
B.9. Summary and Conclusion . . . . . . . . . . . . . . . . . . 40 B.9. Summary and Conclusion . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
There has been renewed interest for having a solution that allows With the ongoing development of the WebRTC conferencing and CLUE
multiple RTP sessions [RFC3550] to use a single lower layer telepresence standards, there is renewed interest in defining a
transport, such as a bi-directional UDP flow. The main reason is the mechanism that allows multiple RTP sessions [RFC3550] to share a
cost of doing NAT/FW traversal for each individual flow. ICE and single lower layer transport, such as a bi-directional UDP flow. The
other NAT/FW traversal solutions are clearly capable of attempting to main problem driving this is the cost of doing NAT/firewall traversal
open multiple flows. However, there is both increased risk for for each individual RTP flow. ICE and other NAT/firewall traversal
failure and an increased cost in the creation of multiple flows. The solutions are clearly capable of attempting to open multiple flows.
increased cost comes as slightly higher delay in establishing the However, there is both increased risk for failure, and an increased
traversal, and the amount of consumed NAT/FW resources. The latter cost in the creation of multiple flows. The increased cost comes as
might be an increasing problem in the IPv4 to IPv6 transition period. slightly higher delay in establishing the traversal, and the amount
of consumed NAT/firewall resources. The latter might be an
increasing problem in the IPv4 to IPv6 transition period.
There is ongoing work on specifying how and when one RTP session may There is ongoing work on specifying how and when one RTP session can
contain multiple media types contain multiple media types
[I-D.ietf-avtcore-multi-media-rtp-session]. That addresses certain [I-D.ietf-avtcore-multi-media-rtp-session]. That addresses certain
use cases, while this proposal addresses a different set of use cases use cases, while this proposal addresses a different set of use cases
and motivations. This is further discussed in the section on and motivations (discussed further in Section 3). The classical
Motivations (Section 3). The classical method of having one RTP method of having each RTP session run over a specific transport flow
session over a specific transport flow is still motivated for a is still motivated for a number of use cases, especially when flow
number of use cases, especially when flow based QoS is to be used for based QoS is to be used for some media streams.
some media streams.
This document draws up some requirements for consideration on how to This document draws up some requirements for consideration on how to
transport multiple RTP sessions over a single lower-layer transport. transport multiple RTP sessions over a single lower-layer transport.
These requirements had to be weighted as the combined set of These requirements have to be weighted carefully, as no known
requirements result in that no known solution exist that can fulfill solution exists that can fulfil the combined set of requirements
them completely. completely. A number of possible solutions where considered and
discussed with respect to their properties. Based on that, this memo
A number of possible solutions where considered and discussed with defines a multiplexing shim, along with SDP signalling, and examples.
respect to their properties. Based on that, the authors recommended The other considered proposals and the comparison is available as
a shim layer variant as single solution, which specified in detail appendices.
including signalling solution and examples. The other considered
proposals and the comparison is available as appendices.
2. Conventions 2. Conventions
2.1. Terminology The following terminology is used in this document.
Some terminology used in this document.
Multiplexing: Unless specifically noted, all mentioning of Multiplexing: Unless specifically noted, all mentioning of
multiplexing in this document refer to the multiplexing of multiplexing in this document refer to the multiplexing of
multiple RTP Sessions on the same lower layer transport. It is multiple RTP Sessions on the same lower layer transport. It is
important to make this distinction as RTP does contain a number of important to make this distinction as RTP does contain a number of
multiplexing points for various purposes, such as media formats multiplexing points for various purposes, such as media formats
(Payload Type), media sources (SSRC), and RTP sessions. (Payload Type), media sources (SSRC), and RTP sessions.
2.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Motivations 3. Motivations
This section looks at the motivations why an additional solution is This section looks at the motivations why an additional solution is
needed assuming that you can do both the classical method of having needed, assuming that you can do both the classical method of having
one RTP session per transport flow as defined by the RTP one RTP session per transport flow [RFC3550], and when you have
specification [RFC3550] and when you have multiple media types within multiple media types within one RTP session
one RTP session [I-D.ietf-avtcore-multi-media-rtp-session]. [I-D.ietf-avtcore-multi-media-rtp-session].
3.1. NAT and Firewalls 3.1. NAT and Firewalls
The existence of NATs and Firewalls at almost all Internet access has The existence of NATs and Firewalls on almost all Internet access has
had implications on protocols like RTP that were designed to use implications for protocols, like RTP, that were designed to use
multiple transport flows. First of all, the NAT/FW traversal multiple transport-layer flows. The NAT/firewall traversal solution
solution one uses needs to ensure that all these transport flows are has to to ensure that all these transport flows are established.
established. This has three different impacts: This has three different impacts:
1. Increased delay to perform the transport flow establishment 1. Increased delay to perform the transport flow establishment
2. The more transport flows, the more state and the more resource 2. The more transport flows, the more state and the more resource
consumption in the NAT and Firewalls. When the resource consumption in the NAT and Firewalls. When the resource
consumption in NAT/FWs reaches their limits, unexpected behaviors consumption in NAT/firewalls reaches their limits, unexpected
usually occur. Commonly resulting in service disruptions. behaviours usually occur. Commonly resulting in service
disruptions.
3. More transport flows means a higher risk that some transport flow 3. More transport flows means a higher risk that some transport flow
fails to be established, thus preventing the application to fails to be established, thus preventing the application to
communicate. communicate.
Using fewer transport flows reduces the risk of communication Using fewer transport-layer flows reduces the risk of communication
failure, improved establishment behavior and less load on NAT and failure, improves establishment behaviour, and causes less load on
Firewalls. NATs and firewalls.
3.2. No Transport Level QoS 3.2. No Transport Level QoS
Many RTP-using applications don't utilize any network level Quality Many RTP-using applications don't utilize any network level Quality
of Service functions. Nor do they expect or desire any separation in of Service functions. Nor do they expect or desire any separation in
network treatment of its media packets, independent of whether they network treatment of its media packets, independent of whether they
are audio, video or text. When an application has no such desire, it are audio, video or text. When an application has no such desire, it
doesn't need to provide a transport flow structure that simplifies doesn't need to provide a transport flow structure that simplifies
flow based QoS. flow based QoS.
3.3. Multiple RTP sessions 3.3. Multiple RTP sessions
The usage of multiple RTP sessions allow separation of media streams The use of multiple RTP sessions allows separation of media streams
that have different usages or purposes in an RTP based application, that have different usages or purposes in an RTP based application,
for example to separate the video of a presenter or most important for example to separate the video of a presenter or most important
current talker, from those of the listeners that not all end-points current talker from those of the listeners that not all end-points
receive. Also separation for different processing based on media receive. Separation of flows into different RTP sessions also allows
types such as audio and video in end-points and central nodes. Thus different processing based on media types, such as audio and video,
providing the node with the knowledge that any SSRC within the in end-points and middleboxes. This can give middleboxes the
session is supposed to be processed in a similar or same way. knowledge that any SSRC within the session is supposed to be
processed in a similar way.
For simpler cases, where the streams within each media type need the For simpler cases, where the streams within each media type need the
same processing, it is clearly possible to find other multiplex same processing, it is clearly possible to find other multiplex
solutions, for example based on the Payload Type and the differences solutions, for example based on the Payload Type and the differences
in encoding that the payload type allows to describe. This may in encoding that the payload type allows to describe. This can
anyhow be insufficient when you get into more advanced usages where anyhow be insufficient when you get into more advanced usages where
you have multiple sources of the same media type, but for different you have multiple sources of the same media type, but for different
usages or as alternatives. For example when you have one set of usages or as alternatives. For example when you have one set of
video sources that shows session participants and another set of video sources that shows session participants and another set of
video sources that shares an application or presentation slides, you video sources that shares an application or presentation slides, you
likely want to separate those streams for various reasons such as likely want to separate those streams for various reasons such as
control, prioritization, QoS, methods for robustification, etc. In control, prioritization, QoS, methods for robustness, etc. In those
those cases, using the RTP session for separation of properties is a cases, using the RTP session for separation of properties is a
powerful tool. A tool with properties that need to be preserved when powerful tool. A tool with properties that need to be preserved when
providing a solution for how to use only a single lower-layer providing a solution for how to use only a single lower-layer
transport. transport.
For more discussion of the usage of RTP sessions verses other For more discussion of the usage of RTP sessions verses other
multiplexing we recommend RTP Multiplexing Architecture multiplexing we recommend RTP Multiplexing Architecture
[I-D.westerlund-avtcore-multiplex-architecture]. [I-D.westerlund-avtcore-multiplex-architecture].
3.4. Usage of RTP Extensions 3.4. Usage of RTP Extensions
skipping to change at page 6, line 50 skipping to change at page 6, line 46
[I-D.ietf-avtcore-multi-media-rtp-session] is known to have [I-D.ietf-avtcore-multi-media-rtp-session] is known to have
limitations that prevent the usage of the following RTP mechanisms limitations that prevent the usage of the following RTP mechanisms
and extensions: and extensions:
o XOR FEC (RFC5109) o XOR FEC (RFC5109)
o RTP Retransmission in session mode (RFC4588) o RTP Retransmission in session mode (RFC4588)
o Certain Layered Coding o Certain Layered Coding
A developed solution should minimize the number of RTP/RTCP extension A developed solution needs to minimize the number of RTP/RTCP
and mechanism that can't be used. extension and mechanisms that can't be used.
3.5. Incremental Deployment 3.5. Incremental Deployment
In various multi-party communication scenarios deployment can become In various multi-party communication scenarios deployment can become
an issue if all session participants are required to have the an issue if all session participants need to have the functionality
functionality before enabling its usage. This is especially before enabling its usage. This is especially difficult in
difficult in communication scenarios where not all possible communication scenarios where not all possible participants and their
participants and their capabilities are know ahead of establishing capabilities are know ahead of establishing the communication session
the communication session with some sub-set of the participants. At with some sub-set of the participants. At least for centralized
least for centralized communication sessions it is desirable to have communication sessions it is desirable to have a solution that
a solution that enables allows the solution to be used on a single enables allows the solution to be used on a single leg without
leg without affecting any other leg, nor require advanced translation affecting any other leg, nor require advanced translation
functionality in any central node. functionality in any central node.
3.6. Summary 3.6. Summary
The center of the motivation is to ensure that the RTP session is a The centre of the motivation is to ensure that the RTP session is a
available and usable tool also for applications that has no need for available and usable tool also for applications that has no need for
network level separation of its media streams and wants to reduce its network level separation of its media streams and wants to reduce its
exposure to any NAT or Firewall inconsistencies and minimize the exposure to any NAT or Firewall inconsistencies and minimize the
resource consumption. As a benefit a well designed solution will resource consumption. As a benefit a well designed solution will
enable incremental deployment and minimal limitations in what enable incremental deployment and minimal limitations in what
existing RTP mechanisms or extensions that can be used by the RTP existing RTP mechanisms or extensions that can be used by the RTP
using application. using application.
4. Requirements 4. Requirements
This section lists and discusses a number of potential requirements. This section lists and discusses a number of potential requirements.
However, it is not difficult to realize that it is in fact possible However, it is not difficult to realize that it is in fact possible
to put requirements that makes the set of feasible solutions an empty to put requirements that makes the set of feasible solutions an empty
set. It is thus necessary to consider which requirements that are set. It is thus necessary to consider which requirements that are
essential to fulfill and which can be compromised on to arrive at a essential to fulfil and which can be compromised on to arrive at a
solution. solution.
4.1. Support Use of Multiple RTP Sessions 4.1. Support Use of Multiple RTP Sessions
Section 3.3 discusses a number of reasons why an application may like Section 3.3 discusses a number of reasons why an application might
to have multiple RTP sessions. Considering the motivations for this like to have multiple RTP sessions. Considering the motivations for
work this must be an absolute requirement. We also are of the this work this is an absolute requirement. We also are of the
opinion that the session provided by the solution must fulfill the opinion that the session provided by the solution needs to fulfil the
definition in the RTP [RFC3550] specification: definition in the RTP [RFC3550] specification:
"The distinguishing feature of an RTP session is that each "The distinguishing feature of an RTP session is that each
maintains a full, separate space of SSRC identifiers (defined maintains a full, separate space of SSRC identifiers (defined
next). The set of participants included in one RTP session next). The set of participants included in one RTP session
consists of those that can receive an SSRC identifier transmitted consists of those that can receive an SSRC identifier transmitted
by any one of the participants either in RTP as the SSRC or a CSRC by any one of the participants either in RTP as the SSRC or a CSRC
(also defined below) or in RTCP." (also defined below) or in RTCP."
4.2. Same SSRC Value in Multiple RTP Sessions 4.2. Same SSRC Value in Multiple RTP Sessions
Two different RTP sessions being multiplexed on the same lower layer Two different RTP sessions being multiplexed on the same lower layer
transport need to be able to use the same SSRC value. This is a transport need to be able to use the same SSRC value. This is a
absolute requirement, for two reasons: absolute requirement, for two reasons:
1. To avoid mandating SSRC assignment rules that are coordinated 1. To avoid mandating SSRC assignment rules that are coordinated
between the sessions. If the RTP sessions multiplexed together between the sessions. If the RTP sessions multiplexed together
must have unique SSRC values, then additional code that works need to have unique SSRC values, then additional code that works
between RTP Sessions is needed in the implementations. Thus between RTP Sessions is needed in the implementations. Thus
raising the bar for implementing this solution. In addition, if raising the bar for implementing this solution. In addition, if
one gateways between parts of a system using this multiplexing one gateways between parts of a system using this multiplexing
and parts that aren't multiplexing, the part that isn't and parts that aren't multiplexing, the part that isn't
multiplexing must also fulfill the requirements on how SSRC is multiplexing also needs to fulfil the requirements on how SSRC is
assigned or force the gateway to translate SSRCs. Translating assigned or force the gateway to translate SSRCs. Translating
SSRC is actually hard as it requires one to understand the SSRC is actually hard as it requires one to understand the
semantics of all current and future RTP and RTCP extensions. semantics of all current and future RTP and RTCP extensions.
Otherwise a barrier for deploying new extensions is created. Otherwise a barrier for deploying new extensions is created.
2. There are some few RTP extensions that currently rely on being 2. There are some few RTP extensions that currently rely on being
able to use the same SSRC in different RTP sessions: able to use the same SSRC in different RTP sessions:
* XOR FEC (RFC5109) * XOR FEC (RFC5109)
skipping to change at page 8, line 44 skipping to change at page 8, line 44
SRTP [RFC3711] is one of the most commonly used security solutions SRTP [RFC3711] is one of the most commonly used security solutions
for RTP. In addition, it is the only one defined by IETF that is for RTP. In addition, it is the only one defined by IETF that is
integrated into RTP. This integration has several aspects that needs integrated into RTP. This integration has several aspects that needs
to be considered when designing a solution for multiplexing RTP to be considered when designing a solution for multiplexing RTP
sessions on the same lower layer transport. sessions on the same lower layer transport.
Determining Crypto Context: SRTP first of all needs to know which Determining Crypto Context: SRTP first of all needs to know which
session context a received or to-be-sent packet relates to. It session context a received or to-be-sent packet relates to. It
also normally relies on the lower layer transport to identify the also normally relies on the lower layer transport to identify the
session. It uses the Master Key Indicatior (MKI), if present, to session. It uses the Master Key Indicator (MKI), if present, to
determine which key set is to be used. Then the SSRC and sequence determine which key set is to be used. Then the SSRC and sequence
number are used by most crypto suites, including the most common number are used by most crypto suites, including the most common
use of AES Counter Mode, to actually generate the correct cipher use of AES Counter Mode, to actually generate the correct cipher
stream. stream.
Unencrypted Headers: SRTP has chosen to leave the RTP headers and Unencrypted Headers: SRTP has chosen to leave the RTP headers and
the first two 32-bit words of the first RTCP header unencrypted, the first two 32-bit words of the first RTCP header unencrypted,
to allow for both header compression and monitoring to work also to allow for both header compression and monitoring to work also
in the presence of encryption. As these fields are in clear text in the presence of encryption. As these fields are in clear text
they are used in most crypto suites for SRTP to determine how to they are used in most crypto suites for SRTP to determine how to
protect or recover the plain text. protect or recover the plain text.
It is here important to contrast SRTP against a set of other possible It is here important to contrast SRTP against a set of other possible
protection mechanisms. DTLS, TLS, and IPsec are all protecting and protection mechanisms. DTLS, TLS, and IPsec are all protecting and
encapsulating the entire RTP and RTCP packets. They don't perform encapsulating the entire RTP and RTCP packets. They don't perform
any partial operations on the RTP and RTCP packets. Any change that any partial operations on the RTP and RTCP packets. Any change that
is considered to be part of the RTP and RTCP packet is transparent to is considered to be part of the RTP and RTCP packet is transparent to
them, but possibly not to SRTP. Thus the impact on SRTP operations them, but possibly not to SRTP. Thus the impact on SRTP operations
must be considered when defining a mechanism. has to be considered when defining a mechanism.
4.4. Don't Redefine Used Bits 4.4. Don't Redefine Used Bits
As the core of RTP is in use in many systems and has a really large As the core of RTP is in use in many systems and has a really large
deployment story and numerous implementations, changing any of the deployment story and numerous implementations, changing any of the
field definitions is highly problematic. First of all, the field definitions is highly problematic. First of all, the
implementations need to change to support this new semantics. implementations need to change to support this new semantics.
Secondly, you get a large transition issue when you have some session Secondly, you get a large transition issue when you have some session
participants that support the new semantics and some that don't. participants that support the new semantics and some that don't.
Combing the two behaviors in the same session can force the Combing the two behaviours in the same session can force the
deployment of costly and less than perfect translation devices. deployment of costly and less than perfect translation devices.
4.5. Firewall Friendly 4.5. Firewall Friendly
It is desirable that current Firewalls will accept the solutions as It is desirable that current Firewalls will accept the solutions as
normal RTP packets. However, in the authors' opinion we can't let normal RTP packets. However, in the authors' opinion we can't let
the firewall stifle invention and evolution of the protocol. It is the firewall stifle invention and evolution of the protocol. It is
also necessary to be aware that a change that will make most deep also necessary to be aware that a change that will make most deep
inspecting firewall consider the packet as not valid RTP/RTCP will inspecting firewall consider the packet as not valid RTP/RTCP will
have a more difficult deployment story. have a more difficult deployment story.
4.6. Monitoring and Reporting 4.6. Monitoring and Reporting
It is desirable that a third party monitor can still operate on the It is desirable that a third party monitor can still operate on the
multiplexed RTP Sessions. It is however likely that they will multiplexed RTP Sessions. It is however likely that they will
require an update to correctly monitor and report on multiplexed RTP require an update to correctly monitor and report on multiplexed RTP
Sessions. Sessions.
Another type of function to consider is packet sniffers and their Another type of function to consider is packet sniffers and their
selector filters. These may be impacted by a change of the fields. selector filters. These can be impacted by a change of the fields.
An observation is that many such systems are usually quite rapidly An observation is that many such systems are usually quite rapidly
updated to consider new types of standardized or simply common packet updated to consider new types of standardized or simply common packet
formats. formats.
4.7. Usable Also Over Multicast 4.7. Usable Also Over Multicast
It is desirable that a solution should be possible to use also when It is desirable that a solution can be used if RTP and RTCP packets
RTP and RTCP packets are sent over multicast, both Any Source are sent over multicast, both Any Source Multicast (ASM) and Single
Multicast (ASM) and Single Source Multicast (SSM). The reason for Source Multicast (SSM). The reason for this requirement is to allow
this requirement is to allow a system using RTP to use the same a system using RTP to use the same configuration regardless of the
configuration regardless of the transport being done over unicast or transport being done over unicast or multicast. In addition,
multicast. In addition, multicast can't be claimed to have an issue multicast can't be claimed to have an issue with using multiple
with using multiple ports, as each multicast group has a complete ports, as each multicast group has a complete port space scoped by
port space scoped by address. address.
4.8. Incremental Deployment 4.8. Incremental Deployment
A good solution has the property that in topologies that contains RTP A good solution has the property that in topologies that contains RTP
mixers or Translators, a single session participant can enable mixers or Translators, a single session participant can enable
multiplexing without having any impact on any other session multiplexing without having any impact on any other session
participants. Thus a node should be able to take a multiplexed participants. Thus a node ought to be able to take a multiplexed
packet and then easily send it out with minimal or no modification on packet and then easily send it out with minimal or no modification on
another leg of the session, where each RTP session is transported another leg of the session, where each RTP session is transported
over its own lower-layer transport. It should also be as easy to do over its own lower-layer transport. It also needs to be as easy to
the reverse forwarding operation. do the reverse forwarding operation.
5. Design Considerations 5. Design Considerations
When defining a SHIM solution for identifying RTP sessions over a When defining a SHIM solution for identifying RTP sessions over a
single transport layer there has been some special considerations single transport layer there has been some special considerations
that is discussed in this section. that is discussed in this section.
5.1. Location of SHIM 5.1. Location of SHIM
A major question affecting the SHIM is the location of the SHIM A major question affecting the SHIM is the location of the SHIM
skipping to change at page 11, line 17 skipping to change at page 11, line 17
first N bytes of the whole packet, where N is commonly on the first N bytes of the whole packet, where N is commonly on the
order of 64-128 bytes. Any other type of processing means putting order of 64-128 bytes. Any other type of processing means putting
the packet on the slow path. Thus a prefixed solution enables the packet on the slow path. Thus a prefixed solution enables
this processing while a post fixed solution will most likely this processing while a post fixed solution will most likely
forever prevent this type of devices to process it. forever prevent this type of devices to process it.
Legacy Processing: Packets or at least flows of the type IP/UDP/RTP Legacy Processing: Packets or at least flows of the type IP/UDP/RTP
can in many cases be identified in Deep Packet Inspection, can in many cases be identified in Deep Packet Inspection,
Firewalls or other network entities that concern themselves with Firewalls or other network entities that concern themselves with
trying determine what traffic that flows in a particular packet. trying determine what traffic that flows in a particular packet.
These nodes can clearly be updated but until they have they may These nodes can clearly be updated but until they can create a
create a hinder against deployment. Thus a post fix gives likely barrier to deployment. Thus a post fix gives likely the least
the least resistance for initial deployment. However, also for resistance for initial deployment. However, also for postfix
postfix location the deployment can be hindered in cases multiple location the deployment can be hindered in cases multiple RTP
RTP sessions using the same SSRC values due to irregular behavior sessions using the same SSRC values due to irregular behaviour of
of the fields for what the third party believes is one media the fields for what the third party believes is one media stream
stream rather than multiple ones. The prefixed will however rather than multiple ones. The prefixed will however maintain the
maintain the long-term capabilities of such devices assuming they long-term capabilities of such devices assuming they can be
can be updated to include the SHIM header as part of the updated to include the SHIM header as part of the classification.
classification.
Header Compression: The different header compression techniques that Header Compression: The different header compression techniques that
has been developed compresses IP/UDP/RTP as complete combination. has been developed compresses IP/UDP/RTP as complete combination.
If one instead have a IP/UDP/SHIM/RTP then the compression for the If one instead have a IP/UDP/SHIM/RTP then the compression for the
full set may not work or poorly. Instead only IP/UDP header full set might not work or poorly. Instead only IP/UDP header
compression is likely to be applied. Thus a prefix will loose compression is likely to be applied. Thus a prefix will loose
some compression efficiency until compression profiles for IP/UDP/ some compression efficiency until compression profiles for IP/UDP/
SHIM/RTP has been developed, implemented and deployed. Postfix SHIM/RTP has been developed, implemented and deployed. Postfix
don't have that issue, but nor can it ever gain anything from don't have that issue, but nor can it ever gain anything from
header compression which an prefixed solution could once an header compression which an prefixed solution could once an
updated profile is deployed. Postfix also will have reduced updated profile is deployed. Postfix also will have reduced
efficiency compressing sessions when the same SSRC is used in two efficiency compressing sessions when the same SSRC is used in two
different RTP sessions as the RTP header fields like sequence different RTP sessions as the RTP header fields like sequence
number etc will not behave as expected and need frequent explicit number, etc., will not behave as expected and need frequent
updates. explicit updates.
The question of a prefixed or a postfixed header comes down to a The question of a prefixed or a postfixed header comes down to a
trade-off between long term usability and deployment issues: trade-off between long term usability and deployment issues:
Prefixed: Long term good possibility to adapt any network function Prefixed: Long term good possibility to adapt any network function
that needs to take the SHIM header into account. At the same time that needs to take the SHIM header into account. At the same time
any function that tries to analyze packets and because of that may any function that tries to analyse packets and because of that
block the packets will be a hinder to deployment. might block the packets will be a hinder to deployment.
Postfixed: This solution will likely short term have the best Postfixed: This solution will likely short term have the best
possibilities to deploy successfully. However, long term this possibilities to deploy successfully. However, long term this
choice will likely prevent many network nodes that like to be choice will likely prevent many network nodes that like to be
capable of separating the RTP sessions being multiplexed together capable of separating the RTP sessions being multiplexed together
from successfully doing that. from successfully doing that.
After discussion in the WG it has been determined that prefixed is After discussion in the working group it has been determined that
the prefered solution. prefixed is the preferred solution.
5.2. ICE and DTLS-SRTP Integration 5.2. ICE and DTLS-SRTP Integration
When using ICE [RFC5245] or DTLS-SRTP [RFC5764] or both with RTP When using ICE [RFC5245] or DTLS-SRTP [RFC5764] or both with RTP
there exist the issue that RTP, STUN [RFC5389] and DTLS-SRTP are there exist the issue that RTP, STUN [RFC5389] and DTLS-SRTP are
simultanously in use over the same lower layer transport flow, like simultaneously in use over the same lower layer transport flow, like
UDP. This multiplexing is based on the value of the first byte of UDP. This multiplexing is based on the value of the first byte of
the lower layer transport payload as discussed in Section 5.1.2 of the lower layer transport payload as discussed in Section 5.1.2 of
DTLS-SRTP [RFC5764]. DTLS-SRTP [RFC5764].
The replacement of a single RTP session with the multiple RTP The replacement of a single RTP session with the multiple RTP
sessions idenfied by a SHIM must not be missidentified to be either sessions identified by a SHIM ought not be misidentified to be either
STUN or DTLS-SRTP or any other protocol intending to take the STUN or DTLS-SRTP or any other protocol intending to take the
available free code-points in the range 193-255 (Decimal). Thus a available free code-points in the range 193-255 (Decimal). Thus a
prefixed SHIM must have its first byte have the two first bits set to prefixed SHIM needs to have its first byte have the two first bits
10 (Binary). Having the SHIM share the identity of RTP is not an set to 10 (Binary). Having the SHIM share the identity of RTP is not
issue as one must have mutual agreement that the SHIM is used instead an issue as there has to be mutual agreement that the SHIM is used
of RTP. instead of RTP.
Note: This limits a single byte SHIM to only allow a maximum of 64 Note: This limits a single byte SHIM to only allow a maximum of 64
RTP sessions over a single transport flow. RTP sessions over a single transport flow.
5.3. Signalling Fallback 5.3. Signalling Fall Back
There exist an important aspect in how the SDP signalling functions, There exist an important aspect in how the SDP signalling functions,
especially Offer/Answer [RFC3264]. The initial idea for the especially Offer/Answer [RFC3264]. The initial idea for the
signalling was to build on top of bundle signalling was to build on top of bundle
[I-D.ietf-mmusic-sdp-bundle-negotiation] which in its default [I-D.ietf-mmusic-sdp-bundle-negotiation] which in its default
function negotiate multiple media types over one RTP session function negotiate multiple media types over one RTP session
[I-D.ietf-avtcore-multi-media-rtp-session]. If the signalling for [I-D.ietf-avtcore-multi-media-rtp-session]. If the signalling for
the solution that main purpose is to enable multiple RTP sessions the solution that main purpose is to enable multiple RTP sessions
results in those cases the peer doesn't support this specification results in those cases the peer doesn't support this specification
the communicating peer can end up in single RTP session if the peer the communicating peer can end up in single RTP session if the peer
supports that. supports that.
We consider it important that in the signalling design that the We consider it important that in the signalling design that the
application developer can decide what type of fallback that will application developer can decide what type of fallback that will
occur. It is also important to consider that one have to signal SHIM occur. It is also important to consider that one have to signal SHIM
based multiplexing of RTP sessions that are in fact of the type with based multiplexing of RTP sessions that are in fact of the type with
multiple media types. Thus the signalling for SHIM must be able to multiple media types. Thus the signalling for SHIM has to be able to
describe multiple different scenarios: describe multiple different scenarios:
1. Multiple RTP sessions multiplexed together using SHIM over one 1. Multiple RTP sessions multiplexed together using SHIM over one
transport transport
2. Like 1 but where at least one RTP session is containing multiple 2. Like 1 but where at least one RTP session is containing multiple
media types media types
3. Like 1, but where the peer doesn't support SHIM and the initiator 3. Like 1, but where the peer doesn't support SHIM and the initiator
wants to fallback to independent transports wants to fallback to independent transports
4. Like 2, but where the peer doesn't support SHIM and wants to 4. Like 2, but where the peer doesn't support SHIM and wants to fall
fallback to multiple BUNDLED sessions over independent back to multiple BUNDLED sessions over independent transports.
transports.
In addition it must be possible to have multiple different transports In addition it needs to be possible to have multiple different
where each is a SHIM multiplex. This is to support decomposed end- transports where each is a SHIM multiplex. This is to support
points or cases where certain media traffic is required to go to a decomposed end-points or cases where certain media traffic has to go
central processing node while others goes directly to a peer. to a central processing node while others goes directly to a peer.
To enable all of these scenarios we propose a solution where each To enable all of these scenarios we propose a solution where each
indicates SHIM multiplex is indicated as its own grouping attribute indicates SHIM multiplex is indicated as its own grouping attribute
across all media blocks that are included in some form in the across all media blocks that are included in some form in the
multiplex. This resulting in that these media blocks fall under a multiplex. This resulting in that these media blocks fall under a
form of BUNDLE super set. This super set will also have some of form of BUNDLE super set. This super set will also have some of
bundles restrictions on the transport layer, but not on higher layer. bundles restrictions on the transport layer, but not on higher layer.
Which Session ID pair a particular media block is associated is Which Session ID pair a particular media block is associated is
signalled using a SDP attribute (a=session-mux-id) in each media signalled using a SDP attribute (a=session-mux-id) in each media
block. When multiple media block are assigned the same session ID block. When multiple media block are assigned the same session ID
skipping to change at page 15, line 11 skipping to change at page 15, line 11
Figure 2: Session ID layer Figure 2: Session ID layer
Each RTP session being multiplexed on top of a given transport layer Each RTP session being multiplexed on top of a given transport layer
is assigned either a single or a pair of unique SID in the range is assigned either a single or a pair of unique SID in the range
0-16383. The reason for assigning a pair of SIDs to a given RTP 0-16383. The reason for assigning a pair of SIDs to a given RTP
session are for RTP Sessions that doesn't support "Multiplexing RTP session are for RTP Sessions that doesn't support "Multiplexing RTP
Data and Control Packets on a Single Port" [RFC5761] to still be able Data and Control Packets on a Single Port" [RFC5761] to still be able
to use a single 5-tuple. The reasons for supporting this extra to use a single 5-tuple. The reasons for supporting this extra
functionality is that RTP and RTCP multiplexing based on the payload functionality is that RTP and RTCP multiplexing based on the payload
type/packet type fields enforces certain restrictions on the RTP type/packet type fields enforces certain restrictions on the RTP
sessions. These restrictions may not be acceptable. As this sessions. These restrictions might not be acceptable. As this
solution does not have these restrictions, performing RTP and RTCP solution does not have these restrictions, performing RTP and RTCP
multiplexing in this way has benefits. multiplexing in this way has benefits.
Each Session ID value space is scoped by the underlying transport Each Session ID value space is scoped by the underlying transport
protocol. Common transport protocols like UDP [RFC0768], DCCP protocol. Common transport protocols like UDP [RFC0768], DCCP
[RFC4340], TCP [RFC0793], and SCTP [RFC4960] can all be scoped by one [RFC4340], TCP [RFC0793], and SCTP [RFC4960] can all be scoped by one
or more 5-tuple (Transport protocol, source address and port, or more 5-tuple (Transport protocol, source address and port,
destination address and port). The case of multiple 5-tuples occur destination address and port). The case of multiple 5-tuples occur
in the case of multi-unicast topologies, also called meshed in the case of multi-unicast topologies, also called meshed
multiparty RTP sessions or in case any application would need more multiparty RTP sessions or in case any application would need more
skipping to change at page 17, line 7 skipping to change at page 17, line 7
2. Inspect the SID field value 2. Inspect the SID field value
3. Strip the SID field from the packet 3. Strip the SID field from the packet
4. Forward it to the (S)RTP Session context identified by the SID 4. Forward it to the (S)RTP Session context identified by the SID
value value
6.2. Signalling 6.2. Signalling
Note: This section may need updating as the direction of the solution Note: This section might need updating as the direction of the
for Bundle has settled and the impact of the raised issues has been solution for Bundle has settled and the impact of the raised issues
analyzed. has been analysed.
The use of the Session ID layer needs to be explicitly agreed on The use of the Session ID layer needs to be explicitly agreed on
between the communicating parties. Each RTP Session the application between the communicating parties. Each RTP Session the application
uses must in addition to the regular configuration such as payload uses needs, in addition to the regular configuration such as payload
types, RTCP extension etc, have both the underlying 5-tuple (source types, RTCP extension, etc., have both the underlying 5-tuple (source
address and port, destination address and port, and transport address and port, destination address and port, and transport
protocol) and the Session ID used for the particular RTP session. protocol) and the Session ID used for the particular RTP session.
The signalling requirement is to assign unique Session ID values to The signalling requirement is to assign unique Session ID values to
all RTP Sessions being sent over the same 5-tuple. The same Session all RTP Sessions being sent over the same 5-tuple. The same Session
ID shall be used for an RTP session independently of the traffic ID SHALL be used for an RTP session independently of the traffic
direction. Note that nothing prevents a multi-media application from direction. Note that nothing prevents a multi-media application from
using multiple 5-tuples if desired for some reason, in which case using multiple 5-tuples if desired for some reason, in which case
each 5-tuple has its own session ID value space. each 5-tuple has its own session ID value space.
This section defines how to negotiate the use of the Session ID This section defines how to negotiate the use of the Session ID
layer, using the Session Description Protocol (SDP) Offer/Answer layer, using the Session Description Protocol (SDP) Offer/Answer
mechanism [RFC3264]. A new SDP grouping semantics is defined "SHIM" mechanism [RFC3264]. A new SDP grouping semantics is defined "SHIM"
and a new media-level SDP attribute, 'session-mux-id. The attribute and a new media-level SDP attribute, 'session-mux-id. The attribute
allows each media description ("m=" line) associated with a 'SHIM' allows each media description ("m=" line) associated with a 'SHIM'
group to be identified in which RTP session it belongs. group to be identified in which RTP session it belongs.
skipping to change at page 17, line 41 skipping to change at page 17, line 41
The 'session-mux-id' attribute is included for a media description, The 'session-mux-id' attribute is included for a media description,
in order to indicate the Session ID for that particular media in order to indicate the Session ID for that particular media
description. Every media description that shares a common attribute description. Every media description that shares a common attribute
value is assumed to be part of a single RTP session. An SDP Offerer value is assumed to be part of a single RTP session. An SDP Offerer
MUST include the 'session-mux-id' attribute for every media MUST include the 'session-mux-id' attribute for every media
description associated with a 'SHIM' group. If the SDP Answer does description associated with a 'SHIM' group. If the SDP Answer does
not contain the SHIM group, the SDP Offerer MUST NOT use SHIM based not contain the SHIM group, the SDP Offerer MUST NOT use SHIM based
layering. However, if that is separate RTP sessions or BUNDLE is layering. However, if that is separate RTP sessions or BUNDLE is
determined on what was present in the offer and answer. This will determined on what was present in the offer and answer. This will
depend on what the offering party likes to happen. If they want a depend on what the offering party likes to happen. If they want a
failure to negotiate a SHIM, instead may be one or more bundle groups failure to negotiate a SHIM, instead can be one or more bundle groups
then also the BUNDLE grouping is included in the offer. If the SDP then also the BUNDLE grouping is included in the offer. If the SDP
Answer still describes a 'BUNDLE' group, the procedures in Answer still describes a 'BUNDLE' group, the procedures in
[I-D.ietf-mmusic-sdp-bundle-negotiation] apply. If not independent [I-D.ietf-mmusic-sdp-bundle-negotiation] apply. If not independent
transports and sessions are used. transports and sessions are used.
An SDP Answerer MUST NOT include the 'SHIM' group and An SDP Answerer MUST NOT include the 'SHIM' group and
'session-mux-id' attribute in an SDP Answer, unless they where 'session-mux-id' attribute in an SDP Answer, unless they where
included in the SDP Offer. included in the SDP Offer.
The attribute has the following ABNF [RFC5234] definition. The attribute has the following ABNF [RFC5234] definition.
skipping to change at page 18, line 16 skipping to change at page 18, line 16
SID = SID-value / SID-pairs SID = SID-value / SID-pairs
SID-value = 1*3DIGIT / "NoN" SID-value = 1*3DIGIT / "NoN"
SID-pairs = SID-value "/" SID-value ; RTP/RTCP SIDs SID-pairs = SID-value "/" SID-value ; RTP/RTCP SIDs
SID-prop = SP assignment-policy / prop-ext SID-prop = SP assignment-policy / prop-ext
prop-ext = token "=" value prop-ext = token "=" value
assignment-policy = "policy=" ("tentative" / "fixed") assignment-policy = "policy=" ("tentative" / "fixed")
The SHIM group SHALL contain all media descriptions that are intended The SHIM group SHALL contain all media descriptions that are intended
to be sent over the same transport flow, independent of Session ID. to be sent over the same transport flow, independent of Session ID.
For all media descriptions part of the same SHIM group the transport For all media descriptions part of the same SHIM group the transport
parameters, i.e. ports, ICE-candidates etc MUST be the same and parameters, i.e. ports, ICE-candidates, etc., MUST be the same and
handled as described by BUNDLE. Note, the parameters related to the handled as described by BUNDLE. Note, the parameters related to the
RTP session does not need to be same. RTP session does not need to be same.
For media descriptions that have the same value of the Session ID For media descriptions that have the same value of the Session ID
SHALL be treated the same way as if they where part of a BUNDLE SHALL be treated the same way as if they where part of a BUNDLE
group, independently if that is indicated or not in the SDP. group, independently if that is indicated or not in the SDP.
The SID property "policy" is used in negotiation by an end-point to The SID property "policy" is used in negotiation by an end-point to
indicate if the session ID values are merely a tentative suggestion indicate if the session ID values are merely a tentative suggestion
or if they must have these values. This is used when negotiating SID or if they need to have these values. This is used when negotiating
for multi-party RTP sessions to support shared transports such as SID for multi-party RTP sessions to support shared transports such as
multicast or RTP translators that are unable to produce renumbered multicast or RTP translators that are unable to produce renumbered
SIDs on a per end-point basis. The normal behavior is that the offer SIDs on a per end-point basis. The normal behaviour is that the
suggest a tentative set of values, indicated by "policy=tentative". offer suggest a tentative set of values, indicated by
These SHOULD be accepted by the peer unless that peer negotiate "policy=tentative". These SHOULD be accepted by the peer unless that
session IDs on behalf of a centralized policy, in which case it MAY peer negotiate session IDs on behalf of a centralized policy, in
change the value(s) in the answer. If the offer represents a policy which case it MAY change the value(s) in the answer. If the offer
that does not allow changing the session ID values, it can indicate represents a policy that does not allow changing the session ID
that to the answerer by setting the policy to "fixed". This enables values, it can indicate that to the answerer by setting the policy to
the answering peer to either accept the value or indicate that there "fixed". This enables the answering peer to either accept the value
is a conflict in who is performing the assignment by setting the SID or indicate that there is a conflict in who is performing the
value to NoN (Not a Number). Offerer and answerer SHOULD always assignment by setting the SID value to NoN (Not a Number). Offerer
include the policy they are operating under. Thus, in case of no and answerer SHOULD always include the policy they are operating
centralized behaviors, both offerer and answerer will indicate the under. Thus, in case of no centralized behaviours, both offerer and
tentative policy. answerer will indicate the tentative policy.
6.3. SRTP Key Management 6.3. SRTP Key Management
Key management for SRTP do needs discussion as we do cause multiple Key management for SRTP do needs discussion as we do cause multiple
SRTP sessions to exist on the same underlying transport flow. Thus SRTP sessions to exist on the same underlying transport flow. Thus
we need to ensure that the key management mechanism still are we need to ensure that the key management mechanism still are
properly associated with the SRTP session context it intends to key. properly associated with the SRTP session context it intends to key.
To ensure that we do look at the three SRTP key management mechanism To ensure that we do look at the three SRTP key management mechanism
that IETF has specified, one after another. that IETF has specified, one after another.
skipping to change at page 19, line 29 skipping to change at page 19, line 29
for the Secure Real-time Transport Protocol (SRTP) [RFC5764] is a for the Secure Real-time Transport Protocol (SRTP) [RFC5764] is a
keying mechanism that works on the media plane on the same lower keying mechanism that works on the media plane on the same lower
layer transport that SRTP/SRTCP will be transported over. layer transport that SRTP/SRTCP will be transported over.
The most direct solution would be to use the SHIM and the SID context The most direct solution would be to use the SHIM and the SID context
identifier to be applied also on DTLS packets. Thus using the same identifier to be applied also on DTLS packets. Thus using the same
SID that is used with RTP and/or RTCP also for the DTLS message SID that is used with RTP and/or RTCP also for the DTLS message
intended to key that particular SRTP and/or SRTCP flow(s). This of intended to key that particular SRTP and/or SRTCP flow(s). This of
course requires independent usage of DTLS-SRTP for each RTP session. course requires independent usage of DTLS-SRTP for each RTP session.
In addition it requires changing the layering for DTLS-SRTP as well In addition it requires changing the layering for DTLS-SRTP as well
as RTP. Thus this behavior doesn't gain you anything in regards to as RTP. Thus this behaviour doesn't gain you anything in regards to
key-management when using SHIM and have some costs. key-management when using SHIM and have some costs.
Instead we propose that an DTLS-SRTP key-derivation change is Instead we propose that an DTLS-SRTP key-derivation change is
introduced. By including the Session ID value in the derivation of introduced. By including the Session ID value in the derivation of
the keying material a single DTLS-SRTP key-management operation could the keying material a single DTLS-SRTP key-management operation could
apply keys and parameters for all the RTP sessions in the same apply keys and parameters for all the RTP sessions in the same
transport flow. Thus the keying cost is significantly reduced, transport flow. Thus the keying cost is significantly reduced,
especially in regards to network communication and delay impact and especially in regards to network communication and delay impact and
vunerability to packet loss. vulnerability to packet loss.
Details to be written up. Details to be written up.
6.3.3. MIKEY 6.3.3. MIKEY
MIKEY: Multimedia Internet KEYing [RFC3830] is a key management MIKEY: Multimedia Internet KEYing [RFC3830] is a key management
protocol that has several transports. In some cases it is used protocol that has several transports. In some cases it is used
directly on a transport protocol such as UDP, but there is also a directly on a transport protocol such as UDP, but there is also a
specification for how MIKEY is used with SDP "Key Management specification for how MIKEY is used with SDP "Key Management
Extensions for Session Description Protocol (SDP) and Real Time Extensions for Session Description Protocol (SDP) and Real Time
skipping to change at page 21, line 10 skipping to change at page 21, line 10
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+- Encrypted Portion* Authenticated Portion ---+ +- Encrypted Portion* Authenticated Portion ---+
SRTP Packet Encapsulated by Session ID Layer SRTP Packet Encapsulated by Session ID Layer
6.4.2. SDP Offer/Answer example 6.4.2. SDP Offer/Answer example
6.4.2.1. Basic Example 6.4.2.1. Basic Example
This section contains SDP offer/answer examples. First one example This section contains SDP offer/answer examples. First one example
of successful SHIMing, and then two where fallback occurs. The of a successful SHIM, and then two where fall back occurs. The fall
fallback option here is to fallback to individual transports, thus no back option here is to fall back to individual transports, thus no
BUNDLE group. BUNDLE group.
In the below SDP offer, one audio and one video is being offered. In the below SDP offer, one audio and one video is being offered.
The audio is using SID 0, and the video is using SID 1 to indicate The audio is using SID 0, and the video is using SID 1 to indicate
that they are different RTP sessions despite being offered over the that they are different RTP sessions despite being offered over the
same 5-tuple. same 5-tuple.
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
skipping to change at page 22, line 22 skipping to change at page 22, line 22
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=session-mux-id:0 policy=tentative a=session-mux-id:0 policy=tentative
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=session-mux-id:1 policy=tentative a=session-mux-id:1 policy=tentative
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
The SDP answer from an end-point that does not support this SHIMing. The SDP answer from an end-point that does not support this SHIM.
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32 m=video 30000 RTP/AVP 32
b=AS:1000 b=AS:1000
skipping to change at page 25, line 39 skipping to change at page 25, line 39
a=mid:2 a=mid:2
a=rtpmap:101 ulpfec/90000 a=rtpmap:101 ulpfec/90000
In this case four different transport flows would be established for In this case four different transport flows would be established for
RTP, each with a different RTP session over them. The answer also RTP, each with a different RTP session over them. The answer also
knows the binding between the sessions with FEC and their source data knows the binding between the sessions with FEC and their source data
thanks to the FEC specification. thanks to the FEC specification.
7. Open Issues 7. Open Issues
This work is still in the early phase of specification. This section This work is still at a relatively early phase. This section
contains a list of open issues where the author desires some input. contains a list of open issues where the author desires some input.
1. In Section 6.2 there is a discussion of which parameters that 1. In Section 6.2 there is a discussion of which parameters that
must be configured. The scope of these rules and if they do make need to be configured. The scope of these rules and if they do
sense needs additional discussion. make sense needs additional discussion.
2. Can we provide better control so that applications that doesn't 2. Can we provide better control so that applications that doesn't
desire fallback to single RTP session when Multiplexing shim desire fallback to single RTP session when Multiplexing shim
fails to be supported but Bundle is supported ends up with a fails to be supported but Bundle is supported ends up with a
better alternative? better alternative?
3. The details for how to do key-derivation, preferably in such a 3. The details for how to do key-derivation, preferably in such a
way that it can be reused by multiple key-management solutions way that it can be reused by multiple key-management solutions
like MIKEY and DTLS-SRTP like MIKEY and DTLS-SRTP
4. The signalling solution will be revisited when the BUNDLE 4. The signalling solution will be revisited when the BUNDLE
solution discussion has yeild some result. solution discussion has yield some result.
8. IANA Considerations 8. IANA Considerations
This document request the registration of one SDP attribute. Details (tbd: complete the details of the IANA registration for the SDP
of the registration to be filled in. attribute)
9. Security Considerations 9. Security Considerations
The security properties of the Session ID layer is depending on what The security properties of the Session ID layer is depending on what
mechanism is used to protect the RTP and RTCP packets of a given RTP mechanism is used to protect the RTP and RTCP packets of a given RTP
session. If IPsec or transport layer security solutions such as DTLS session. If IPsec or transport layer security solutions such as DTLS
or TLS are being used then both the encapsulated RTP/RTCP packets and or TLS are being used then both the encapsulated RTP/RTCP packets and
the session ID layer will be protected by that security mechanism. the session ID layer will be protected by that security mechanism.
Thus potentially providing both confidentiality, integrity and source Thus potentially providing both confidentiality, integrity and source
authentication. If SRTP is used, the session ID layer will not be authentication. If SRTP is used, the session ID layer will not be
skipping to change at page 27, line 10 skipping to change at page 27, line 10
The idea in Appendix A.6 is from an Internet Draft The idea in Appendix A.6 is from an Internet Draft
[I-D.rosenberg-rtcweb-rtpmux] written by Jonathan Rosenberg et. al. [I-D.rosenberg-rtcweb-rtpmux] written by Jonathan Rosenberg et. al.
The proposal in Appendix A.3 is a result of discussion by a group of The proposal in Appendix A.3 is a result of discussion by a group of
people at IETF meeting #81 in Quebec. people at IETF meeting #81 in Quebec.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation Holmberg, C., Alvestrand, H., and C. Jennings,
Using Session Description Protocol (SDP) Port Numbers", "Multiplexing Negotiation Using Session Description
draft-ietf-mmusic-sdp-bundle-negotiation-01 (work in Protocol (SDP) Port Numbers",
progress), August 2012. draft-ietf-mmusic-sdp-bundle-negotiation-03 (work in
progress), February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
11.2. Informational References 11.2. Informational References
[I-D.ietf-avtcore-multi-media-rtp-session] [I-D.ietf-avtcore-multi-media-rtp-session]
Westerlund, M., Perkins, C., and J. Lennox, "Multiple Westerlund, M., Perkins, C., and J. Lennox, "Multiple
Media Types in an RTP Session", Media Types in an RTP Session",
draft-ietf-avtcore-multi-media-rtp-session-00 (work in draft-ietf-avtcore-multi-media-rtp-session-01 (work in
progress), October 2012. progress), October 2012.
[I-D.lennox-rtcweb-rtp-media-type-mux] [I-D.lennox-rtcweb-rtp-media-type-mux]
Rosenberg, J. and J. Lennox, "Multiplexing Multiple Media Rosenberg, J. and J. Lennox, "Multiplexing Multiple Media
Types In a Single Real-Time Transport Protocol (RTP) Types In a Single Real-Time Transport Protocol (RTP)
Session", draft-lennox-rtcweb-rtp-media-type-mux-00 (work Session", draft-lennox-rtcweb-rtp-media-type-mux-00 (work
in progress), October 2011. in progress), October 2011.
[I-D.rosenberg-rtcweb-rtpmux] [I-D.rosenberg-rtcweb-rtpmux]
Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M., Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M.,
skipping to change at page 30, line 13 skipping to change at page 30, line 14
functionality, with the receiving end-points. functionality, with the receiving end-points.
The biggest existing hurdle for this solution is that there exist no The biggest existing hurdle for this solution is that there exist no
header extension field in the RTCP packets. This requires defining a header extension field in the RTCP packets. This requires defining a
solution for RTCP that allows carrying the explicit indicator, solution for RTCP that allows carrying the explicit indicator,
preferably in a position that isn't encrypted by SRTCP. However, the preferably in a position that isn't encrypted by SRTCP. However, the
current SRTCP definition does not offer such a position in the current SRTCP definition does not offer such a position in the
packet. packet.
Modifying the RR or SR packets is possible using profile specific Modifying the RR or SR packets is possible using profile specific
extensions. However, that has issues when it comes to deployability extensions. However, that has issues when it comes to deployment and
and in addition any information placed there would end up in the in addition any information placed there would end up in the
encrypted part. encrypted part.
Another alternative could be to define another RTCP packet type that Another alternative could be to define another RTCP packet type that
only contains the common header, using the 5 bits in the first byte only contains the common header, using the 5 bits in the first byte
of the common header to carry a session id. That would allow SRTCP of the common header to carry a session id. That would allow SRTCP
to work correctly as long it accepts this new packet type being the to work correctly as long it accepts this new packet type being the
first in the packet. Allowing a non-SR/RR packet as the first packet first in the packet. Allowing a non-SR/RR packet as the first packet
in a compound RTCP packet is also needed if an implementation is to in a compound RTCP packet is also needed if an implementation is to
support Reduced Size RTCP packets [RFC5506]. The remaining downside support Reduced Size RTCP packets [RFC5506]. The remaining downside
with this is that all stack implementations supporting multiplexing with this is that all stack implementations supporting multiplexing
skipping to change at page 30, line 42 skipping to change at page 30, line 43
needed) padding to next 32-bits boundary if other header extensions needed) padding to next 32-bits boundary if other header extensions
are used. are used.
A.2. Multiplexing Shim A.2. Multiplexing Shim
This proposal is to prefix or postfix all RTP and RTCP packets with a This proposal is to prefix or postfix all RTP and RTCP packets with a
session ID field. This field would be outside of the normal RTP and session ID field. This field would be outside of the normal RTP and
RTCP packets, thus having no impact on the RTP and RTCP packets and RTCP packets, thus having no impact on the RTP and RTCP packets and
their processing. An additional step of demultiplexing processing their processing. An additional step of demultiplexing processing
would be added prior to RTP stack processing to determine in which would be added prior to RTP stack processing to determine in which
RTP session context the packet shall be included. This has also no RTP session context the packet is to be included. This has also no
impact on SRTP/SRTCP as the shim layer would be outside of its impact on SRTP/SRTCP as the shim layer would be outside of its
protection context. The shim layer's session ID is however protection context. The shim layer's session ID is however
implicitly integrity protected as any error in the field will result implicitly integrity protected as any error in the field will result
in the packet being placed in the wrong or non-existing context, thus in the packet being placed in the wrong or non-existing context, thus
resulting in a integrity failure if processed by SRTP/SRTCP. resulting in a integrity failure if processed by SRTP/SRTCP.
This proposal is quite simple to implement in any gateway or This proposal is quite simple to implement in any gateway or
translating device that goes from a multiplexed to a non-multiplexed translating device that goes from a multiplexed to a non-multiplexed
domain or vice versa, as only an additional field needs to be added domain or vice versa, as only an additional field needs to be added
to or removed from the packet. to or removed from the packet.
The main downside of this proposal is that it is very likely to The main downside of this proposal is that it is very likely to
trigger a firewall response from any deep packet inspection device. trigger a firewall response from any deep packet inspection device.
If the field is prefixed, the RTP fields are not matching the If the field is prefixed, the RTP fields are not matching the
heuristics field (unless the shim is designed to look like an RTP heuristics field (unless the shim is designed to look like an RTP
header, in which case the payload length is unlikely to match the header, in which case the payload length is unlikely to match the
expected value) and thus are likely preventing classification of the expected value) and thus are likely preventing classification of the
packet as an RTP packet. If it is postfixed, it is likely classified packet as an RTP packet. If it is postfixed, it is likely classified
as an RTP packet but may not correctly validate if the content as an RTP packet but might not correctly validate if the content
validation is such that the payload length is expected to match validation is such that the payload length is expected to match
certain values. It is expected that a postfixed shim will be less certain values. It is expected that a postfixed shim will be less
problematic than a prefixed shim in this regard, but we are lacking problematic than a prefixed shim in this regard, but we are lacking
hard data on this. hard data on this.
This solution's per packet overhead is 1 byte. This solution's per packet overhead is 1 byte.
A.3. Single Session A.3. Single Session
Given the difficulty of multiplexing several RTP sessions onto a Given the difficulty of multiplexing several RTP sessions onto a
single lower-layer transport, it's tempting to send multiple media single lower-layer transport, it's tempting to send multiple media
streams in a single RTP session. Doing this avoids the need to de- streams in a single RTP session. Doing this avoids the need to de-
multiplex several sessions on a single transport, but at the cost of multiplex several sessions on a single transport, but at the cost of
losing the RTP session as a separator for different type of streams. losing the RTP session as a separator for different type of streams.
Lacking different RTP sessions to demultiplex incoming packets, a Lacking different RTP sessions to demultiplex incoming packets, a
receiver will have to dig deeper into the packet before determining receiver will have to dig deeper into the packet before determining
what to do with it. Care must be taken in that inspection. For what to do with it. Care has to be taken in that inspection. For
example, you must be careful to ensure that each real media source example, it is important to be careful to ensure that each real media
uses its own SSRC in the session and that this SSRC doesn't change source uses its own SSRC in the session and that this SSRC doesn't
media type. change media type.
The loss of the RTP session as a separator for different usages or The loss of the RTP session as a separator for different usages or
purpose would be an minor issue if the only difference between the purpose would be an minor issue if the only difference between the
RTP sessions is the media type. In this case, the application could RTP sessions is the media type. In this case, the application could
use the Payload Type field to identify the media type. The loss of use the Payload Type field to identify the media type. The loss of
the RTP Session functionality is however severe, if the application the RTP Session functionality is however severe, if the application
uses the RTP Session for separating different treatments, contexts uses the RTP Session for separating different treatments, contexts
etc. Then you would need additional signalling to bind the different etc. Then you would need additional signalling to bind the different
sources to groups which can help make the necessary distinctions. sources to groups which can help make the necessary distinctions.
However, the loss of the RTP session as separator is not the only However, the loss of the RTP session as separator is not the only
issue with this approach. The RTP Multiplexing Architecture issue with this approach. The RTP Multiplexing Architecture
[I-D.westerlund-avtcore-multiplex-architecture] discusses a number of [I-D.westerlund-avtcore-multiplex-architecture] discusses a number of
issues in Section 6.7. These include RTCP bandwidth differences, issues in Section 6.7. These include RTCP bandwidth differences,
limitations in the number of payload types, media aware RTP mixers limitations in the number of payload types, media aware RTP mixers
and interactions with Legacy end-points. and interactions with Legacy end-points.
Additional attention should be place on this important aspect. In Additional attention needs to be placed on this important aspect. In
multi-party situations using central nodes there exist some multi-party situations using central nodes there exist some
difficulties in having a legacy implementation using multiple RTP difficulties in having a legacy implementation using multiple RTP
sessions interworking with an end-point having only a single RTP sessions interworking with an end-point having only a single RTP
session across the central node. The main reason is the fact that session across the central node. The main reason is the fact that
the one using single session with multiple media types has only one the one using single session with multiple media types has only one
SSRC space, while the other end-points have multiple spaces. Thus SSRC space, while the other end-points have multiple spaces. Thus
translation may have to occur because there is several RTP sessions translation might have to occur because there is several RTP sessions
using the same SSRC value. This has both limitations, processing using the same SSRC value. This has both limitations, processing
overhead and the possibility of becoming an deployment obstacle for overhead and the possibility of becoming an deployment obstacle for
new RTP/RTCP extensions. new RTP/RTCP extensions.
This approach has been proposed in the RTCWeb context in This approach has been proposed in the RTCWeb context in
[I-D.lennox-rtcweb-rtp-media-type-mux] and [I-D.lennox-rtcweb-rtp-media-type-mux] and
[I-D.ietf-mmusic-sdp-bundle-negotiation]. These drafts describe how [I-D.ietf-mmusic-sdp-bundle-negotiation]. These drafts describe how
to signal multiple media streams multiplexed into a single RTP to signal multiple media streams multiplexed into a single RTP
session, and address some of the issues raised here and in Section session, and address some of the issues raised here and in Section
6.7 of the RTP Multiplexing Architecture 6.7 of the RTP Multiplexing Architecture
[I-D.westerlund-avtcore-multiplex-architecture] draft. [I-D.westerlund-avtcore-multiplex-architecture] draft.
This method has several limitations that limits its usage as solution This method has several limitations that limits its usage as solution
in providing multiple RTP sessions on the same lower layer transport. in providing multiple RTP sessions on the same lower layer transport.
However, we acknowledge that there are some uses for which this However, we acknowledge that there are some uses for which this
method may be sufficient and which can accept the methods limitations method can be sufficient and which can accept the methods limitations
and downsides. The RTCWEB WG has a working assumption to support and downsides. The RTCWEB WG has a working assumption to support
this method. For more details of this method, see the relevant this method. For more details of this method, see the relevant
drafts under development. We do include this method in the drafts under development. We do include this method in the
comparison to provide a more complete picture of the pro and cons of comparison to provide a more complete picture of the pro and cons of
this method. this method.
This solution has no per packet overhead. The signalling overhead This solution has no per packet overhead. The signalling overhead
will be a different question. will be a different question.
A.4. Use the SRTP MKI field A.4. Use the SRTP MKI field
skipping to change at page 33, line 11 skipping to change at page 33, line 13
Considering that SRTP have at least 3 used keying mechanisms, DTLS- Considering that SRTP have at least 3 used keying mechanisms, DTLS-
SRTP [RFC5764], Security Descriptions [RFC4568], and MIKEY [RFC3830], SRTP [RFC5764], Security Descriptions [RFC4568], and MIKEY [RFC3830],
this is not an insignificant amount of work. this is not an insignificant amount of work.
This solution has 32-bit per packet overhead, but only if the MKI was This solution has 32-bit per packet overhead, but only if the MKI was
not already used. not already used.
A.5. Use an Octet in the Padding A.5. Use an Octet in the Padding
The basics of this proposal is to have the RTP packet and the last The basics of this proposal is to have the RTP packet and the last
(required by RFC3550) RTCP packet in a compound to include padding, (mandated by RFC3550) RTCP packet in a compound to include padding,
at least 2 bytes. One byte for the padding count (last byte) and one at least 2 bytes. One byte for the padding count (last byte) and one
byte just before the padding count containing the session ID. byte just before the padding count containing the session ID.
This proposal uses bytes to carry the session ID that have no defined This proposal uses bytes to carry the session ID that have no defined
value and is intended to be ignored by the receiver. From that value and is intended to be ignored by the receiver. From that
perspective it only causes packet expansion that is supported and perspective it only causes packet expansion that is supported and
handled by all existing equipment. If an implementation fails to handled by all existing equipment. If an implementation fails to
understand that it is required to interpret this padding byte to understand that it is needs to interpret this padding byte to learn
learn the session ID, it will see a mostly coherent RTP session the session ID, it will see a mostly coherent RTP session except
except where SSRCs overlap or where the payload types overlap. where SSRCs overlap or where the payload types overlap. However,
However, reporting on the individual sources or forwarding the RTCP reporting on the individual sources or forwarding the RTCP RR are not
RR are not completely without merit. completely without merit.
There is one downside of this proposal and that has to do with SRTP. There is one downside of this proposal and that has to do with SRTP.
To be able to determine the crypto context, it is necessary to access To be able to determine the crypto context, it is necessary to access
to the encrypted payload of the packet. Thus, the only mechanism to the encrypted payload of the packet. Thus, the only mechanism
available for a receiver to solve this issue is to try the existing available for a receiver to solve this issue is to try the existing
crypto contexts for any session on the same lower layer transport and crypto contexts for any session on the same lower layer transport and
then use the one where the packet decrypts and verifies correctly. then use the one where the packet decrypts and verifies correctly.
Thus for transport flows with many crypto contexts, an attacker could Thus for transport flows with many crypto contexts, an attacker could
simply generate packets that don't validate to force the receiver to simply generate packets that don't validate to force the receiver to
try all crypto contexts they have rather than immediately discard it try all crypto contexts they have rather than immediately discard it
skipping to change at page 34, line 4 skipping to change at page 34, line 7
The Rosenberg et. al. Internet draft "Multiplexing of Real-Time The Rosenberg et. al. Internet draft "Multiplexing of Real-Time
Transport Protocol (RTP) Traffic for Browser based Real-Time Transport Protocol (RTP) Traffic for Browser based Real-Time
Communications (RTC)" [I-D.rosenberg-rtcweb-rtpmux] proposed to Communications (RTC)" [I-D.rosenberg-rtcweb-rtpmux] proposed to
redefine the SSRC field. This has the advantage of no packet redefine the SSRC field. This has the advantage of no packet
expansion. It also looks like regular RTP. However, it has a number expansion. It also looks like regular RTP. However, it has a number
of implications. First of all it prevents any RTP functionality that of implications. First of all it prevents any RTP functionality that
require the same SSRC in multiple RTP sessions. require the same SSRC in multiple RTP sessions.
Secondly its interoperability with end-point using multiple RTP Secondly its interoperability with end-point using multiple RTP
sessions are problematic. Such interoperability will requires an sessions are problematic. Such interoperability will requires an
SSRC translator function in the gatewaying node to ensure that the SSRC translator function in the gateway node to ensure that the SSRCs
SSRCs fulfill the semantic rules of the different domains. That fulfil the semantic rules of the different domains. That translator
translator is actually far from easy as it needs to understand the is actually far from easy as it needs to understand the semantics of
semantics of all RTP and RTCP extensions that include SSRC/CSRC. all RTP and RTCP extensions that include SSRC/CSRC. This as it is
This as it is necessary to know when a particular matching 32-bit necessary to know when a particular matching 32-bit pattern is an
pattern is an SSRC field and when the field is just a combination of SSRC field and when the field is just a combination of other fields
other fields that create the same matching 32-bit pattern. Thus that create the same matching 32-bit pattern. Thus there is a
there is a possibility that such a translator becomes a obstacle in possibility that such a translator becomes a obstacle in deploying
deploying future RTP/RTCP extensions. In addition the translator future RTP/RTCP extensions. In addition the translator actually have
actually have significant overhead when SRTP are in use. This as a significant overhead when SRTP are in use. This as a verification
verification that the packet is authentic, decryption, SSRC that the packet is authentic, decryption, SSRC translation,
translation, encryption and finally generation of authentication tags encryption and finally generation of authentication tags are needed.
are required. In addition the translator must be part of the In addition the translator has to be part of the security context.
security context.
This solution has no per packet overhead. This solution has no per packet overhead.
Appendix B. Comparison Appendix B. Comparison
This section compares the above potential solutions with the This section compares the above potential solutions with the
requirements. Motivations are provided in addition to a high level requirements. Motivations are provided in addition to a high level
metric of successfully, partially and failing to meet requirement. metric of successfully, partially and failing to meet requirement.
In the end a summary table (Figure 5) of the high level value are In the end a summary table (Figure 5) of the high level value are
provided. provided.
skipping to change at page 35, line 49 skipping to change at page 35, line 50
session bindings to maintain secure and correct function. session bindings to maintain secure and correct function.
The Redefine the SSRC field gets a partial due to its need to modify The Redefine the SSRC field gets a partial due to its need to modify
the key-management mechanisms to correctly identify the partial SSRC the key-management mechanisms to correctly identify the partial SSRC
space the parameters applies to. Similarly, the SRTP implementation space the parameters applies to. Similarly, the SRTP implementation
also needs to be updated to correctly support this security context also needs to be updated to correctly support this security context
differentiation. differentiation.
The header extension based solution gets a less severe partial than The header extension based solution gets a less severe partial than
Redefine the SSRC and the MKI. It will however have an issue when Redefine the SSRC and the MKI. It will however have an issue when
being gatewayed to a domain that does not multiplex multiple RTP using a gateway to a domain that does not multiplex multiple RTP
sessions over the same transport. Then the gateway will require to sessions over the same transport. Then the gateway will require to
be in the security context to be able to add or remove the header be in the security context to be able to add or remove the header
extension as it is in the part of the packet that is integrity extension as it is in the part of the packet that is integrity
protected by SRTP. protected by SRTP.
The remaining two proposals do not affect SRTP mechanisms and thus The remaining two proposals do not affect SRTP mechanisms and thus
successfully meet this requirement. successfully meet this requirement.
B.4. Don't Redefine Used Bits B.4. Don't Redefine Used Bits
This requirement is all about RTP and RTCP header fields having a This requirement is all about RTP and RTCP header fields having a
given definition should not be changed as it can cause given definition ought not be changed as it can cause
interoperability problems between modified and non-modified interoperability problems between modified and non-modified
implementations. This becomes especially problematic in RTP sessions implementations. This becomes especially problematic in RTP sessions
used for multi-party sessions. used for multi-party sessions.
Redefine the SSRC field gets a big fail on this as it redefines the Redefine the SSRC field gets a big fail on this as it redefines the
SSRC field, a core field in RTP. It has been identified that such a SSRC field, a core field in RTP. It has been identified that such a
change will have issues since if it gets connected to a non-modified change will have issues since if it gets connected to a non-modified
end-point that randomly assigns the SSRC, as supposed by RFC 3550, end-point that randomly assigns the SSRC, as supposed by RFC 3550,
those SSRCs will be distributed over different RTP sessions at the those SSRCs will be distributed over different RTP sessions at the
modified end-point. Also other functions using the SSRC field, not modified end-point. Also other functions using the SSRC field, not
understanding the additional semantics of the SSRC field, is likely understanding the additional semantics of the SSRC field, is likely
to have issues. to have issues.
Using the SRTP MKI field to identify a session is overloading that Using the SRTP MKI field to identify a session is overloading that
field with double semantics. This likely has minimal negative impact field with double semantics. This likely has minimal negative impact
in RTP since it should be possible to have the SRTP stack use the MKI in RTP since it ought to be possible to have the SRTP stack use the
field to both look up the security context and which output RTP MKI field to both look up the security context and which output RTP
session the processed packet belongs to. However, this redefinition session the processed packet belongs to. However, this redefinition
clearly creates issues with the key-management scheme. That will clearly creates issues with the key-management scheme. That will
have to be modified to handle both this change and deal with the have to be modified to handle both this change and deal with the
interoperability issues when negotiating its usage. This gets a full interoperability issues when negotiating its usage. This gets a full
fail due to that it makes the problem someone else's, namely the RTP fail due to that it makes the problem someone else's, namely the RTP
implementors. implementers.
Defining an Octet in the Padding field redefines a field, whose Defining an Octet in the Padding field redefines a field, whose
definition is to have zero value and is expected to be ignored by the definition is to have zero value and is expected to be ignored by the
receiver according to the original semantics. Thus this is one of receiver according to the original semantics. Thus this is one of
the more benign modifications one can do, however this can still the more benign modifications one can do, however this can still
cause issues in implementations that unnecessarily check the field cause issues in implementations that unnecessarily check the field
values, or in Firewalls. This is judged to be partially meeting the values, or in Firewalls. This is judged to be partially meeting the
requirement. requirement.
The Header Extension proposal does in fact not redefine any currently The Header Extension proposal does in fact not redefine any currently
skipping to change at page 37, line 34 skipping to change at page 37, line 35
suspect solutions from a firewall perspective. However, as their suspect solutions from a firewall perspective. However, as their
transport flows contain multiple SSRCs with payloads that indicate transport flows contain multiple SSRCs with payloads that indicate
likely multiple different media types they are still likely to make a likely multiple different media types they are still likely to make a
picky firewall block the transport. This is especially true for picky firewall block the transport. This is especially true for
Firewalls that take signalling messages into account where it will Firewalls that take signalling messages into account where it will
expect a particular media type in a given context. A non upgraded expect a particular media type in a given context. A non upgraded
firewall might in fact produce two different contexts with firewall might in fact produce two different contexts with
overlapping transport parameters where both rules will receive media overlapping transport parameters where both rules will receive media
streams of the other media type that are outside of the allowed rule. streams of the other media type that are outside of the allowed rule.
However, to be clear if these proposals doesn't get through, none of However, to be clear if these proposals doesn't get through, none of
the other will either as they all will have this behavior. the other will either as they all will have this behaviour.
The header extension proposal is potentially problematic for two The header extension proposal is potentially problematic for two
reasons. The first reason, which also other proposals has, is reasons. The first reason, which also other proposals has, is
related to that the same SSRC value can exist in two RTP sessions related to that the same SSRC value can exist in two RTP sessions
over the same underlying flow. Anyone tracking the sequence number over the same underlying flow. Anyone tracking the sequence number
and timestamp will react badly as the second media stream with the and timestamp will react badly as the second media stream with the
same SSRC causes constant jumps back and forth in these fields same SSRC causes constant jumps back and forth in these fields
compared to the first stream, if packets are transmitted compared to the first stream, if packets are transmitted
simultaneously for both SSRCs. This issue can likely only be solved simultaneously for both SSRCs. This issue can likely only be solved
by having the Firewalls that like to track flows to also use the by having the Firewalls that like to track flows to also use the
session identifier to create context. This is possible as the header session identifier to create context. This is possible as the header
extension will be in the clear and in the front. The second issue is extension will be in the clear and in the front. The second issue is
that the header extension itself may get the firewall to react. that the header extension itself can get the firewall to react.
Especially very picky ones that expect packets with certain media Especially very picky ones that expect packets with certain media
types to have certain packet lengths. They are not compatible with a types to have certain packet lengths. They are not compatible with a
header extension. header extension.
The Multiplexing Shim shares the issue with multiple flows for the The Multiplexing Shim shares the issue with multiple flows for the
same SSRC. Firewalls and deep packet inspection cause the shim same SSRC. Firewalls and deep packet inspection cause the shim
placement to be in question. If it is a pre-fixed shim, it prevents placement to be in question. If it is a pre-fixed shim, it prevents
the packet from looking like regular IP/UDP/RTP packets and be the packet from looking like regular IP/UDP/RTP packets and be
correctly classified in Firewalls and DPI engines. However, if one correctly classified in Firewalls and DPI engines. However, if one
puts it last, it is unlikely that any firewall or DPI ever will be puts it last, it is unlikely that any firewall or DPI ever will be
able to take the session context into account as it is at the end of able to take the session context into account as it is at the end of
the packet. This as many line rate processing devices only take a the packet. This as many line rate processing devices only take a
certain amount of the headers into account. certain amount of the headers into account.
The SRTP MKI field is likely the solution that has least firewall and The SRTP MKI field is likely the solution that has least firewall and
DPI issues, after the single RTP session. There is no additional DPI issues, after the single RTP session. There is no additional
suspect field. The only difference from a single RTP session in the suspect field. The only difference from a single RTP session in the
transport flow is the fact that multiple MKI are guaranteed to be transport flow is the fact that multiple MKI are guaranteed to be
used. However, that may occur also in a single RTP session usage. used. However, that can occur also in a single RTP session usage.
Thus the only issues are the one shared with single session and the Thus the only issues are the one shared with single session and the
one that several RTP media streams may use the same SSRC. one that several RTP media streams can use the same SSRC.
The octet in the padding field has, in addition to the issues the The octet in the padding field has, in addition to the issues the
SRTP MKI field has, the single issue that it redefines something that SRTP MKI field has, the single issue that it redefines something that
is supposed to be zero into a value. Thus potentially causing a is supposed to be zero into a value. Thus potentially causing a
deeply inspecting firewall to clamp the flow in fear of covert deeply inspecting firewall to clamp the flow in fear of covert
channel or non-compliance. channel or non-compliance.
B.6. Monitoring and Reporting B.6. Monitoring and Reporting
The monitoring and reporting requirement considers several aspects. The monitoring and reporting requirement considers several aspects.
How useful monitoring can one get from an existing legacy monitor, How useful monitoring can one get from an existing legacy monitor,
and secondary any issues in upgrading them to handle the selected and secondary any issues in upgrading them to handle the selected
solution. Thirdly, packet selector filters and packet sniffers solution. Thirdly, packet selector filters and packet sniffers
concerns are considered. concerns are considered.
In general one can expect the proposals that have only a single SSRC In general one can expect the proposals that have only a single SSRC
space to work better with legacy. Thus both Single Session and space to work better with legacy. Thus both Single Session and
Redefine SSRC space can gather and report data on media flows most Redefine SSRC space can gather and report data on media flows most
likely. The only potential issue is that due to the different media likely. The only potential issue is that due to the different media
types and clock rates, some failure may occur. In particular a third types and clock rates, some failure can occur. In particular a third
party monitor may be targeted to a specific media type, like party monitor can be targeted to a specific media type, like
monitoring VoIP. That monitor will have problems processing any monitoring VoIP. That monitor will have problems processing any
video packets correctly and generate the VoIP specific metrics for video packets correctly and generate the VoIP specific metrics for
any video sending SSRC. In general, no legacy solution for any video sending SSRC. In general, no legacy solution for
monitoring will be able to correctly create the sub-contexts that monitoring will be able to correctly create the sub-contexts that
each RTP session has in the solutions, without update to handle the each RTP session has in the solutions, without update to handle the
new semantics. Also when it comes to the packet filtering and new semantics. Also when it comes to the packet filtering and
selector filters, fine grained control can only be accomplished selector filters, fine grained control can only be accomplished
implementing the new semantics. Therefore only the Single Session implementing the new semantics. Therefore only the Single Session
meets this requirement fully. meets this requirement fully.
skipping to change at page 40, line 17 skipping to change at page 40, line 17
translation, however this proposal does run into the problem that the translation, however this proposal does run into the problem that the
gateway needs to be in the security context to be able to add or gateway needs to be in the security context to be able to add or
remove the header extension when SRTP is used. In addition to the remove the header extension when SRTP is used. In addition to the
security implications of that, there is a complexity overhead due to security implications of that, there is a complexity overhead due to
the need to redo the authentication tags on all RTP/RTCP packets. the need to redo the authentication tags on all RTP/RTCP packets.
Thus it gets a partial. Thus it gets a partial.
The Octet in the Padding field share issues with the header extension The Octet in the Padding field share issues with the header extension
but have even higher complexities for this. The reason is that the but have even higher complexities for this. The reason is that the
padding field is also encrypted. Thus to add or remove it (although padding field is also encrypted. Thus to add or remove it (although
removing it may be unnecessary) forces the end-point to encrypt at removing it might be unnecessary) forces the end-point to encrypt at
least that byte also, and for ciphers that are not stream-ciphers, least that byte also, and for ciphers that are not stream-ciphers,
the whole packet needs to be re-encrypted. Thus this proposal gets a the whole packet needs to be re-encrypted. Thus this proposal gets a
very weak partially meeting the requirement. very weak partially meeting the requirement.
The Single Session and Redefine the SSRC field do not allow several The Single Session and Redefine the SSRC field do not allow several
vanilla RTP sessions to be connected to these proposals. The reason vanilla RTP sessions to be connected to these proposals. The reason
is the single 32-bit SSRC space they have. Single Session only has is the single 32-bit SSRC space they have. Single Session only has
one session and the Redefine the SSRC fields uses some of the bits as one session and the Redefine the SSRC fields uses some of the bits as
session identifier. This forces the gateway to translate the SSRC session identifier. This forces the gateway to translate the SSRC
whenever it does not fulfill the rules or semantics of the whenever it does not fulfil the rules or semantics of the multiplexed
multiplexed side. For Redefine SSRC field this becomes almost side. For Redefine SSRC field this becomes almost constant as the
constant as the session identifier part of the SSRC must be the same session identifier part of the SSRC has to be the same over all SSRCs
over all SSRCs from the same session. For Single Session it may only from the same session. For Single Session it might only be needed
be needed when there otherwise would be an SSRC collision between the when there otherwise would be an SSRC collision between the sessions.
sessions. This further assumes that the non-multiplexed side would This further assumes that the non-multiplexed side would never use
never use any of the RTP mechanisms that require the same SSRC in any of the RTP mechanisms that require the same SSRC in multiple RTP
multiple RTP sessions, as they cannot be gatewayed at all. When sessions, as they cannot be gatewayed at all. When translating an
translating an SSRC there is first of all an overhead, with SRTP that SSRC there is first of all an overhead, with SRTP that includes a
includes a complete authenticate, decrypt, encrypt and create a new complete authenticate, decrypt, encrypt and create a new
authentication tag cycle. In addition, the SSRC translation could authentication tag cycle. In addition, the SSRC translation could
potentially be a deployment obstacle for new RTP/RTCP extensions potentially be a deployment obstacle for new RTP/RTCP extensions that
required to be understood by the translator to be correctly has to be understood by the translator to be correctly translated.
translated. Therefore these two proposals gets a fail to meet the Therefore these two proposals gets a fail to meet the requirements.
requirements.
B.9. Summary and Conclusion B.9. Summary and Conclusion
This section contains a summary table of the high level outcome This section contains a summary table of the high level outcome
against the different requirements. against the different requirements.
A table mapping the requirements against the ID numbers used in the A table mapping the requirements against the ID numbers used in the
table is the following: table is the following:
1: Support multiple RTP sessions over one transport flow 1: Support multiple RTP sessions over one transport flow
skipping to change at page 41, line 19 skipping to change at page 41, line 19
2.1: Avoid SSRC translation in gateways/translators 2.1: Avoid SSRC translation in gateways/translators
2.2: Support existing extensions 2.2: Support existing extensions
3: Ensure SRTP functions 3: Ensure SRTP functions
4: Don't Redefine used bits 4: Don't Redefine used bits
5: Firewall Friendly 5: Firewall Friendly
6: Monitoring and Reporting should still function 6: Monitoring and Reporting still needs to function
7: Usable over Multicast 7: Usable over Multicast
8: Incremental deployment 8: Incremental deployment
OH: Overhead in Bytes. + means variable OH: Overhead in Bytes. + means variable
---------------+---+---+---+---+---+---+---+---+---+---- ---------------+---+---+---+---+---+---+---+---+---+----
Solution | 1 |2.1|2.2| 3 | 4 | 5 | 6 | 7 | 8 | OH Solution | 1 |2.1|2.2| 3 | 4 | 5 | 6 | 7 | 8 | OH
---------------+---+---+---+---+---+---+---+---+---+---- ---------------+---+---+---+---+---+---+---+---+---+----
 End of changes. 89 change blocks. 
231 lines changed or deleted 223 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/