draft-westerlund-avtcore-transport-multiplexing-02.txt   draft-westerlund-avtcore-transport-multiplexing-03.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: September 13, 2012 University of Glasgow Expires: January 14, 2013 University of Glasgow
March 12, 2012 July 13, 2012
Multiple RTP Sessions on a Single Lower-Layer Transport Multiple RTP Sessions on a Single Lower-Layer Transport
draft-westerlund-avtcore-transport-multiplexing-02 draft-westerlund-avtcore-transport-multiplexing-03
Abstract Abstract
This document specifies how multiple RTP sessions are to be This document specifies how multiple RTP sessions are to be
multiplexed on the same lower-layer transport, e.g. a UDP flow. It multiplexed on the same lower-layer transport, e.g. a UDP flow. It
discusses various requirements that have been raised and their discusses various requirements that have been raised and their
feasibility, which results in a solution with a certain feasibility, which results in a solution with a certain
applicability. A solution is recommended and that solution is applicability. A solution is recommended and that solution is
provided in more detail, including signalling and examples. provided in more detail, including signalling and examples.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 September 13, 2012. This Internet-Draft will expire on January 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Support Use of Multiple RTP Sessions . . . . . . . . . . . 5 3.1. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 5
3.2. Same SSRC Value in Multiple RTP Sessions . . . . . . . . . 5 3.2. No Transport Level QoS . . . . . . . . . . . . . . . . . . 5
3.3. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Multiple RTP sessions . . . . . . . . . . . . . . . . . . 6
3.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 7 3.4. Usage of RTP Extensions . . . . . . . . . . . . . . . . . 6
3.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 7 3.5. Incremental Deployment . . . . . . . . . . . . . . . . . . 7
3.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 7 3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.7. Usable Also Over Multicast . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 8 4.1. Support Use of Multiple RTP Sessions . . . . . . . . . . . 7
4. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Same SSRC Value in Multiple RTP Sessions . . . . . . . . . 8
4.1. Header Extension . . . . . . . . . . . . . . . . . . . . . 8 4.3. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Multiplexing Shim . . . . . . . . . . . . . . . . . . . . 9 4.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 9
4.3. Single Session . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 9
4.4. Use the SRTP MKI field . . . . . . . . . . . . . . . . . . 11 4.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 9
4.5. Use an Octet in the Padding . . . . . . . . . . . . . . . 12 4.7. Usable Also Over Multicast . . . . . . . . . . . . . . . . 10
4.6. Redefine the SSRC field . . . . . . . . . . . . . . . . . 12 4.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 10
5. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 10
5.1. Support of Multiple RTP Sessions Over Single Transport . . 13 5.1. Location of SHIM . . . . . . . . . . . . . . . . . . . . . 10
5.2. Enable Same SSRC Value in Multiple RTP Sessions . . . . . 13 5.2. Signalling Fallback . . . . . . . . . . . . . . . . . . . 12
5.2.1. Avoid SSRC Translation in Gateways/Translation . . . . 13 6. Specification . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.2. Support Existing Extensions . . . . . . . . . . . . . 14 6.1. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Ensure SRTP Functions . . . . . . . . . . . . . . . . . . 14 6.2. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 15 6.3. SRTP Key Management . . . . . . . . . . . . . . . . . . . 17
5.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 16 6.3.1. Security Description . . . . . . . . . . . . . . . . . 18
5.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 17 6.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 18
5.7. Usable over Multicast . . . . . . . . . . . . . . . . . . 18 6.3.3. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . 18
5.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 18 6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.9. Summary and Conclusion . . . . . . . . . . . . . . . . . . 19 6.4.1. RTP Packet with Transport Header . . . . . . . . . . . 19
6. Specification . . . . . . . . . . . . . . . . . . . . . . . . 20 6.4.2. SDP Offer/Answer example . . . . . . . . . . . . . . . 19
6.1. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
6.3. SRTP Key Management . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6.3.1. Security Description . . . . . . . . . . . . . . . . . 25 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
6.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.3.3. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.2. Informational References . . . . . . . . . . . . . . . . . 26
6.4.1. RTP Packet with Transport Header . . . . . . . . . . . 26 Appendix A. Possible Solutions . . . . . . . . . . . . . . . . . 27
6.4.2. SDP Offer/Answer example . . . . . . . . . . . . . . . 27 A.1. Header Extension . . . . . . . . . . . . . . . . . . . . . 27
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 29 A.2. Multiplexing Shim . . . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 A.3. Single Session . . . . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 A.4. Use the SRTP MKI field . . . . . . . . . . . . . . . . . . 31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 A.5. Use an Octet in the Padding . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 A.6. Redefine the SSRC field . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 Appendix B. Comparison . . . . . . . . . . . . . . . . . . . . . 33
11.2. Informational References . . . . . . . . . . . . . . . . . 31 B.1. Support of Multiple RTP Sessions Over Single Transport . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 B.2. Enable Same SSRC Value in Multiple RTP Sessions . . . . . 33
B.2.1. Avoid SSRC Translation in Gateways/Translation . . . . 33
B.2.2. Support Existing Extensions . . . . . . . . . . . . . 33
B.3. Ensure SRTP Functions . . . . . . . . . . . . . . . . . . 34
B.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 34
B.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 35
B.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 37
B.7. Usable over Multicast . . . . . . . . . . . . . . . . . . 37
B.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 38
B.9. Summary and Conclusion . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
There has been renewed interest for having a solution that allows There has been renewed interest for having a solution that allows
multiple RTP sessions [RFC3550] to use a single lower layer multiple RTP sessions [RFC3550] to use a single lower layer
transport, such as a bi-directional UDP flow. The main reason is the transport, such as a bi-directional UDP flow. The main reason is the
cost of doing NAT/FW traversal for each individual flow. ICE and cost of doing NAT/FW traversal for each individual flow. ICE and
other NAT/FW traversal solutions are clearly capable of attempting to other NAT/FW traversal solutions are clearly capable of attempting to
open multiple flows. However, there is both increased risk for open multiple flows. However, there is both increased risk for
failure and an increased cost in the creation of multiple flows. The failure and an increased cost in the creation of multiple flows. The
increased cost comes as slightly higher delay in establishing the increased cost comes as slightly higher delay in establishing the
traversal, and the amount of consumed NAT/FW resources. The latter traversal, and the amount of consumed NAT/FW resources. The latter
might be an increasing problem in the IPv4 to IPv6 transition period. 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
contain multiple media types
[I-D.westerlund-avtcore-multi-media-rtp-session]. That addresses
certain use cases, while this proposal addresses a different set of
use cases and motivations. This is further discussed in the section
on Motivations (Section 3). The classical method of having one RTP
session over a specific transport flow is still motivated for a
number of use cases, especially when flow based QoS is to be used for
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 will have to be weighted as the combined set of These requirements will have to be weighted as the combined set of
requirements result in that no known solution exist that can fulfill requirements result in that no known solution exist that can fulfill
them completely. them completely.
A number of possible solutions are then considered and discussed with A number of possible solutions where considered and discussed with
respect to their properties. Based on that, the authors recommends a respect to their properties. Based on that, the authors recommends a
shim layer variant as single solution, which is described in more shim layer variant as single solution, which is described in more
detail including signalling solution and examples. detail including signalling solution and examples. The proposals and
the comparison is available as appendices.
2. Conventions 2. Conventions
2.1. Terminology 2.1. Terminology
Some terminology 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 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. Requirements 3. Motivations
This section lists and discusses a number of potential requirements. This section looks at the motivations why an additional solution is
needed assuming that you can do both the classical method of having
one RTP session per transport flow as defined by the RTP
specification [RFC3550] and when you have multiple media types within
one RTP session [I-D.westerlund-avtcore-multi-media-rtp-session].
However, it is not difficult to realize that it is in fact possible First we look at the motivations why a single transport flow is of
to put requirements that makes the set of feasible solutions an empty sufficient interest, namely NATs and Firewalls. Then
set. It is thus necessary to consider which requirements that are
essential to fulfill and which can be compromised on to arrive at a
solution.
3.1. Support Use of Multiple RTP Sessions 3.1. NAT and Firewalls
This may at first glance appear to be an obvious requirement. The existence of NATs and Firewalls at almost all Internet access has
Although the authors are convinced it is a mandatory requirement for had implications on protocols like RTP that were designed to use
a solution, it warrants some discussion around the implications of multiple transport flows. First of all, the NAT/FW traversal
not having multiple RTP sessions and instead use a single RTP solution one uses needs to ensure that all these transport flows are
session. established. This has three different impacts:
1. Increased delay to perform the transport flow establishment
2. The more transport flows, the more state and the more resource
consumption in the NAT and Firewalls. When the resource
consumption in NAT/FWs reaches their limits, unexpected behaviors
usually occur.
3. More transport flows means a higher risk that some transport flow
fails to be established, thus preventing the application to
communicate.
Using fewer transport flows reduces the risk of communication
failure, improved establishment behavior and less load on NAT and
Firewalls.
3.2. No Transport Level QoS
Many RTP-using applications don't utilize any network level Quality
of Service functions. Nor do they expect or desire any separation in
network treatment of its media packets, independent of whether they
are audio, video or text. When an application has no such desire, it
doesn't need to provide a transport flow structure that simplifies
flow based QoS.
3.3. Multiple RTP sessions
The usage of multiple RTP sessions allow separation of media streams The usage of multiple RTP sessions allow 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
receiver. Also separation for different processing based on media receiver. Also separation for different processing based on media
types such as audio and video in end-points and central nodes. Thus types such as audio and video in end-points and central nodes. Thus
providing the node with the knowledge that any SSRC within the providing the node with the knowledge that any SSRC within the
session is supposed to be processed in a similar or same way. session is supposed to be processed in a similar or same way.
skipping to change at page 5, line 48 skipping to change at page 6, line 37
prioritization, QoS, methods for robustification, etc. In those prioritization, QoS, methods for robustification, etc. In 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.2. Same SSRC Value in Multiple RTP Sessions 3.4. Usage of RTP Extensions
Applications uses different sets of RTP extensions. The solution for
multiple media types in one RTP session
[I-D.westerlund-avtcore-multi-media-rtp-session] is known to have
limitations that prevent the usage of the following RTP mechanisms
and extensions:
o XOR FEC (RFC5109)
o RTP Retransmission in session mode (RFC4588)
o Certain Layered Coding
A developed solution should minimize the number of RTP/RTCP extension
and mechanism that can't be used.
3.5. Incremental Deployment
In various multi-party communication scenarios deployment can become
an issue if all session participants are required to have the
functionality before enabling its usage. This is especially
difficult in communication scenarios where not all possible
participants and their capabilities are know ahead of establishing
the communication session with some sub-set of the participants. At
least for centralized communication sessions it is desirable to have
a solution that enables allows the solution to be used on a single
leg without affecting any other leg, nor require advanced
functionality in any central node.
3.6. Summary
The center of the motivation is to ensure that the RTP session is a
available and usable tool also for applications that has no need for
network level separation of its media streams and wants to reduce its
exposure to any NAT or Firewall inconsistencies and minimize the
resource consumption. As a benefit a well designed solution will
enable incremental deployment and minimal limitations in what
existing RTP mechanisms or extensions that can be used by the RTP
using application.
4. Requirements
This section lists and discusses a number of potential requirements.
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
set. It is thus necessary to consider which requirements that are
essential to fulfill and which can be compromised on to arrive at a
solution.
4.1. Support Use of Multiple RTP Sessions
Section 3.3 discusses a number of reasons why an application may like
to have multiple RTP sessions. Considering the motivations for this
work this must be an absolute requirement. We also are of the
opinion that the session provided by the solution must fulfill the
definition in the RTP [RFC3550] specification:
"The distinguishing feature of an RTP session is that each
maintains a full, separate space of SSRC identifiers (defined
next). The set of participants included in one RTP session
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
(also defined below) or in RTCP."
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
strong requirement, for two reasons: strong 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 must 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
skipping to change at page 6, line 27 skipping to change at page 8, line 35
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)
* RTP Retransmission in session mode (RFC4588) * RTP Retransmission in session mode (RFC4588)
* Certain Layered Coding * Certain Layered Coding
3.3. SRTP 4.3. SRTP
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 recommended by IETF that is for RTP. In addition, it is the only one recommended 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
skipping to change at page 7, line 9 skipping to change at page 9, line 20
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. must be considered when defining a mechanism.
3.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 behaviors 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.
3.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 more difficult deployment story. have more difficult deployment story.
3.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 may 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.
3.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 should be possible to use also when
RTP and RTCP packets are sent over multicast, both Any Source RTP and RTCP packets are sent over multicast, both Any Source
Multicast (ASM) and Single Source Multicast (SSM). The reason for Multicast (ASM) and Single Source Multicast (SSM). The reason for
this requirement is to allow a system using RTP to use the same this requirement is to allow a system using RTP to use the same
configuration regardless of the transport being done over unicast or configuration regardless of the transport being done over unicast or
multicast. In addition, multicast can't be claimed to have an issue multicast. In addition, multicast can't be claimed to have an issue
with using multiple ports, as each multicast group has a complete with using multiple ports, as each multicast group has a complete
port space scoped by address. port space scoped by address.
3.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 should 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 should also be as easy to do
the reverse forwarding operation. the reverse forwarding operation.
4. Possible Solutions 5. Design Considerations
When defining a SHIM solution for identifying RTP sessions over a
single transport layer there has been some special considerations
that is discussed in this section.
5.1. Location of SHIM
A major question affecting the SHIM is the location of the SHIM
header providing the Identifier of the session the packet relate to.
This section will discuss in detail about the impact of making the
different choices.
Identified aspects to consider are:
Possibility to Process: A prefixed shim header, i.e. between the
transport protocol and the RTP/RTCP packet header has the
advantage that any node on the network that likes to include the
header in any per-packet processing can reach it. Reasons for
per-packet processing are:
A. Quality of Service classification
B. SHIM ingress or egress
C. Monitoring
Many routers or similar devices can only read and process 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
the packet on the slow path. Thus a prefixed solution enables
this processing while a post fixed solution will most likely
forever prevent this type of devices to process it.
Legacy Processing: Packets or at least flows of the type IP/UDP/RTP
can in many cases be identified in Deep Packet Inspection,
Firewalls or other network entities that concern themselves with
trying determine what traffic that flows in a particular packet.
These nodes can clearly be updated but until they have they may
create a hinder against deployment. Thus a post fix gives likely
the least resistance for initial deployment. However, also for
postfix location the deployment can be hindered in cases multiple
RTP sessions using the same SSRC values due to irregular behavior
of the fields for what the third party believes is one media
stream rather than multiple ones. The prefixed will however
maintain the long-term capabilities of such devices assuming they
can be updated to include the SHIM header as part of the
classification.
Header Compression: The different header compression techniques that
has been developed compresses IP/UDP/RTP as complete combination.
If one instead have a IP/UDP/SHIM/RTP then the compression for the
full set will not work. Instead only IP/UDP header compression
can be applied. Thus a prefix will loose some compression
efficiency until compression profiles for IP/UDP/SHIM/RTP has been
developed, implemented and deployed. Postfix don't have that
issue, but nor can it ever gain anything from header compression
which an prefixed solution could once an updated profile is
deployed.
The question of a prefixed or a postfixed header comes down to a
trade-off between long term usability and deployment issues:
Prefixed: Long term good possibility to adapt any network function
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
block the packets will be a hinder to deployment.
Postfixed: This solution will likely short term have the best
possibilities to deploy successfully. However, long term this
choice will likely prevent many network nodes that like to be
capable of separating the RTP sessions being multiplexed together
from successfully doing that.
Open Issue: Which should be chosen? The below specification uses
prefix but that can easily be changed. But appears to be the best
long term choice without to badly affecting deployability.
5.2. Signalling Fallback
There exist an important aspect in how the SDP signalling functions,
especially Offer/Answer [RFC3264]. The initial idea for the
signalling was to build on top of bundle
[I-D.ietf-mmusic-sdp-bundle-negotiation] which in its default
function negotiate multiple media types over one RTP session
[I-D.westerlund-avtcore-multi-media-rtp-session]. If the signalling
for the solution that main purpose is to enable multiple RTP sessions
results in those cases the peer doesn't support this specification
the communicating peer can end up in single RTP session if the peer
supports that.
We consider it important that in the signalling design that the
application developer can decide what type of fallback that will
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
multiple media types. Thus the signalling for SHIM must be able to
describe multiple different scenarios:
1. Multiple RTP sessions multiplexed together using SHIM over one
transport
2. Like 1 but where at least one RTP session is containing multiple
media types
3. Like 1, but where the peer doesn't support SHIM and the initiator
wants to fallback to independent transports
4. Like 2, but where the peer doesn't support SHIM and wants to
fallback to multiple BUNDLED sessions over independent
transports.
In addition it must be possible to have multiple different transports
where each is a SHIM multiplex.
To enable all of these scenarios we propose a solution where each
indicates SHIM multiplex is indicated as its own grouping attribute
across all media blocks that are included in some form in the
multiplex. This resulting in that these media blocks fall under a
form of BUNDLE super set. This super set will also have some of
bundles restrictions on the transport layer, but not on higher layer.
Which Session ID pair a particular media block is associated is
signalled using a SDP attribute (a=session-mux-id) in each media
block. When multiple media block are assigned the same session ID
pair, they form a RTP session with multiple media types and have the
full restriction of bundle between them.
The method of fallback is indicated by providing explicit BUNDLE
grouping in addition to the SHIM when the fallback from SHIM is to
BUNDLE.
6. Specification
This section contains the specification of the solution based on a
SHIM, with the explicit session identifier of the encapsulated
payload.
6.1. Shim Layer
This solution is based on a shim layer that is inserted in the stack
between the regular RTP and RTCP packets and the transport layer
being used by the RTP sessions. Thus the layering looks like the
following:
+---------------------+
| RTP / RTCP Packet |
+---------------------+
| Session ID Layer |
+---------------------+
| Transport layer |
+---------------------+
Stack View with Session ID SHIM
The above stack is in fact a layered one as it does allow multiple
RTP Sessions to be multiplexed on top of the Session ID shim layer.
This enables the example presented in Figure 1 where four sessions,
S1-S4 is sent over the same Transport layer and where the Session ID
layer will combine and encapsulate them with the session ID on
transmission and separate and decapsulate them on reception.
+-------------------+
| S1 | S2 | S3 | S4 |
+-------------------+
| Session ID Layer |
+-------------------+
| Transport layer |
+-------------------+
Figure 1: Multiple RTP Session On Top of Session ID Layer
The Session ID layer encapsulates one RTP or RTCP packet from a given
RTP session and prefixes a one byte Session ID (SID) field to the
packet. 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 0-255. The reason for assigning a pair of SIDs to a
given 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 to use a single 5-tuple. The reasons for
supporting this extra functionality is that RTP and RTCP multiplexing
based on the payload type/packet type fields enforces certain
restrictions on the RTP sessions. These restrictions may not be
acceptable. As this solution does not have these restrictions,
performing RTP and RTCP multiplexing in this way has benefits.
Each Session ID value space is scoped by the underlying transport
protocol. Common transport protocols like UDP, DCCP, TCP, and SCTP
can all be scoped by one or more 5-tuple (Transport protocol, source
address and port, destination address and port). The case of
multiple 5-tuples occur in the case of multi-unicast topologies, also
called meshed multiparty RTP sessions or in case any application
would need more than 128 RTP sessions.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | |
| .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| RTP extension (OPTIONAL) | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+- Encrypted Portion* Authenticated Portion ---+
Figure 2: SRTP Packet encapsulated by Session ID Layer
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P| RC | PT=SR or RR | length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| SSRC of sender | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| ~ sender info ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ report block 1 ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ report block 2 ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ ... ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |V=2|P| SC | PT=SDES=202 | length | |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| | SSRC/CSRC_1 | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ SDES items ~ |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| ~ ... ~ |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| |E| SRTCP index | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTCP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+-- Encrypted Portion Authenticated Portion -----+
Figure 3: SRTCP packet encapsulated by Session ID layer
The processing in a receiver when the Session ID layer is present
will be to
1. Pick up the packet from the lower layer transport
2. Inspect the SID field value
3. Strip the SID field from the packet
4. Forward it to the (S)RTP Session context identified by the SID
value
6.2. Signalling
The use of the Session ID layer needs to be explicitly agreed on
between the communicating parties. Each RTP Session the application
uses must in addition to the regular configuration such as payload
types, RTCP extension etc, have both the underlying 5-tuple (source
address and port, destination address and port, and transport
protocol) and the Session ID used for the particular RTP session.
The signalling requirement is to assign unique Session ID values to
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
direction. Note that nothing prevents a multi-media application from
using multiple 5-tuples if desired for some reason, in which case
each 5-tuple has its own session ID value space.
This section defines how to negotiate the use of the Session ID
layer, using the Session Description Protocol (SDP) Offer/Answer
mechanism [RFC3264]. A new SDP grouping semantics is defined "SHIM"
and a new media-level SDP attribute, 'session-mux-id. The attribute
allows each media description ("m=" line) associated with a 'SHIM'
group to be identified in which RTP session it belongs.
The 'session-mux-id' attribute is included for a media description,
in order to indicate the Session ID for that particular media
description. Every media description that shares a common attribute
value is assumed to be part of a single RTP session. An SDP Offerer
MUST include the 'session-mux-id' attribute for every media
description associated with a 'SHIM' group. If the SDP Answer does
not contain the SHIM group, the SDP Offerer MUST NOT use SHIM based
layering. However, if that is separate RTP sessions or BUNDLE is
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
failure to negotiate a SHIM, instead may be one or more bundle groups
then also the BUNDLE grouping is included in the offer. If the SDP
Answer still describes a 'BUNDLE' group, the procedures in
[I-D.ietf-mmusic-sdp-bundle-negotiation] apply. If not independent
transports and sessions are used.
An SDP Answerer MUST NOT include the 'SHIM' group and
'session-mux-id' attribute in an SDP Answer, unless they where
included in the SDP Offer.
The attribute has the following ABNF [RFC5234] definition.
Session-mux-id-attr = "a=session-mux-id:" SID *SID-prop
SID = SID-value / SID-pairs
SID-value = 1*3DIGIT / "NoN"
SID-pairs = SID-value "/" SID-value ; RTP/RTCP SIDs
SID-prop = SP assignment-policy / prop-ext
prop-ext = token "=" value
assignment-policy = "policy=" ("tentative" / "fixed")
The SHIM group SHALL contain all media descriptions that are intended
to be sent over the same transport flow, independent of Session ID.
For all media descriptions part of the same SHIM group the transport
parameters, i.e. ports, ICE-candidates etc MUST be the same and
handled as described by BUNDLE. Note, the parameters related to the
RTP session does not need to be same.
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
group, independently if that is indicated or not in the SDP.
The SID property "policy" is used in negotiation by an end-point to
indicate if the session ID values are merely a tentative suggestion
or if they must have these values. This is used when negotiating SID
for multi-party RTP sessions to support shared transports such as
multicast or RTP translators that are unable to produce renumbered
SIDs on a per end-point basis. The normal behavior is that the offer
suggest a tentative set of values, indicated by "policy=tentative".
These SHOULD be accepted by the peer unless that peer negotiate
session IDs on behalf of a centralized policy, in which case it MAY
change the value(s) in the answer. If the offer represents a policy
that does not allow changing the session ID values, it can indicate
that to the answerer by setting the policy to "fixed". This enables
the answering peer to either accept the value or indicate that there
is a conflict in who is performing the assignment by setting the SID
value to NoN (Not a Number). Offerer and answerer SHOULD always
include the policy they are operating under. Thus, in case of no
centralized behaviors, both offerer and answerer will indicate the
tentative policy.
6.3. SRTP Key Management
Key management for SRTP do needs discussion as we do cause multiple
SRTP sessions to exist on the same underlying transport flow. Thus
we need to ensure that the key management mechanism still are
properly associated with the SRTP session context it intends to key.
To ensure that we do look at the three SRTP key management mechanism
that IETF has specified, one after another.
6.3.1. Security Description
Session Description Protocol (SDP) Security Descriptions for Media
Streams [RFC4568] as being based on SDP has no issue with the RTP
session multiplexing on lower layer specified here. The reason is
that the actual keying is done using a media level SDP attribute.
Thus the attribute is already associated with a particular media
description. A media description that also will have an instance of
the "a=session-mux-id" attribute carrying the SID value/pair used
with this particular crypto parameters.
6.3.2. DTLS-SRTP
Datagram Transport Layer Security (DTLS) Extension to Establish Keys
for the Secure Real-time Transport Protocol (SRTP) [RFC5764] is a
keying mechanism that works on the media plane on the same lower
layer transport that SRTP/SRTCP will be transported over. Thus each
DTLS message must be associated with the SRTP and/or SRTCP flow it is
keying.
The most direct solution is to use the SHIM and the SID context
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
intended to key that particular SRTP and/or SRTCP flow(s). Thus this
behavior doesn't gain you anything in regards to key-management when
using SHIM.
6.3.3. MIKEY
MIKEY: Multimedia Internet KEYing [RFC3830] is a key management
protocol that has several transports. In some cases it is used
directly on a transport protocol such as UDP, but there is also a
specification for how MIKEY is used with SDP "Key Management
Extensions for Session Description Protocol (SDP) and Real Time
Streaming Protocol (RTSP)" [RFC4567].
Lets start with the later, i.e. the SDP transport, which shares the
properties with Security Description in that is can be associated
with a particular media description in a SDP. As long as one avoids
using the session level attribute one can be certain to correctly
associate the key exchange with a given SRTP/SRTCP context.
It does appear that MIKEY directly over a lower layer transport
protocol will have similar issues as DTLS.
6.4. Examples
6.4.1. RTP Packet with Transport Header
The below figure contains an RTP packet with SID field encapsulated
by a UDP packet (added UDP header).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | |
| .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| RTP extension (OPTIONAL) | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+- Encrypted Portion* Authenticated Portion ---+
SRTP Packet Encapsulated by Session ID Layer
6.4.2. SDP Offer/Answer example
6.4.2.1. Basic Example
This section contains SDP offer/answer examples. First one example
of successful SHIMing, and then two where fallback occurs. The
fallback option here is to fallback to individual transports, thus no
BUNDLE group.
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
that they are different RTP sessions despite being offered over the
same 5-tuple.
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:SHIM foo bar
m=audio 10000 RTP/AVP 0 8 97
b=AS:200
a=mid:foo
a=session-mux-id:0 policy=tentative
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
b=AS:1000
a=mid:bar
a=session-mux-id:1 policy=tentative
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
The SDP answer from an end-point that supports this BUNDLEing:
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
a=group:SHIM foo bar
m=audio 20000 RTP/AVP 0
b=AS:200
a=mid:foo
a=session-mux-id:0 policy=tentative
a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32
b=AS:1000
a=mid:bar
a=session-mux-id:1 policy=tentative
a=rtpmap:32 MPV/90000
The SDP answer from an end-point that does not support this SHIMing.
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 20000 RTP/AVP 0
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32
b=AS:1000
a=rtpmap:32 MPV/90000
6.4.2.2. Advanced Example
In this example we have two BUNDLED sessions, one with audio and
video and one with XOR based FEC [RFC5109] for the audio and the
video. These two RTP session are then SHIMed into a single transport
flow.
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:SHIM foo bar 1 2
a=group:BUNDLE 1 2
a=group:BUNDLE foo bar
a=group:FEC foo 1
a=group:FEC bar 2
m=audio 10000 RTP/AVP 0 8 97
b=AS:200
a=mid:foo
a=session-mux-id:0 policy=tentative
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
b=AS:1000
a=mid:bar
a=session-mux-id:0 policy=tentative
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
m=audio 10000 RTP/AVP 100
b=AS:100
a=rtpmap:100 ulpfec/8000
a=mid:1
a=session-mux-id:1 policy=tentative
m=video 10000 RTP/AVP 101
b=AS:500
a=mid:2
a=session-mux-id:1 policy=tentative
a=rtpmap:101 ulpfec/90000
The SDP answer of a client supporting
[I-D.ietf-mmusic-sdp-bundle-negotiation] but not this SHIMing would
look like this:
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
a=group:BUNDLE 1 2
a=group:BUNDLE foo bar
a=group:FEC foo 1
a=group:FEC bar 2
m=audio 20000 RTP/AVP 0 8 97
b=AS:200
a=mid:foo
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 20000 RTP/AVP 31 32
b=AS:1000
a=mid:bar
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
m=audio 20002 RTP/AVP 100
b=AS:100
a=rtpmap:100 ulpfec/8000
a=mid:1
m=video 20002 RTP/AVP 101
b=AS:500
a=mid:2
a=rtpmap:101 ulpfec/90000
In the above case two different RTP sessions, both being of a BUNDLE
type with multiple media types in each. The two established flows
will be Alice:10000<->Bob:20000, and Alice:10000<->Bob:20002.
If the peer did support neither of the SHIM or BUNDLE extension the
answer would look like this:
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
a=group:FEC foo 1
a=group:FEC bar 2
m=audio 20000 RTP/AVP 0 8 97
b=AS:200
a=mid:foo
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 20002 RTP/AVP 31 32
b=AS:1000
a=mid:bar
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
m=audio 20004 RTP/AVP 100
b=AS:100
a=rtpmap:100 ulpfec/8000
a=mid:1
m=video 20006 RTP/AVP 101
b=AS:500
a=mid:2
a=rtpmap:101 ulpfec/90000
In this case four different transport flows would be established for
RTP, each with a different RTP session over them. The answer also
knows the binding between the sessions with FEC and their source data
thanks to the FEC specification.
7. Open Issues
This work is still in the early phase of specification. This section
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
must be configured. The scope of these rules and if they do make
sense needs additional discussion.
2. Can we provide better control so that applications that doesn't
desire fallback to single RTP session when Multiplexing shim
fails to be supported but Bundle is supported ends up with a
better alternative?
3. Is there any issues with using DTLS-SRTP individually per RTP
session?
4. Shall the SHIM header be prefixed or postfixed in relation to the
RTP/RTCP packets?
8. IANA Considerations
This document request the registration of one SDP attribute. Details
of the registration to be filled in.
9. Security Considerations
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
session. If IPsec or transport layer security solutions such as DTLS
or TLS are being used then both the encapsulated RTP/RTCP packets and
the session ID layer will be protected by that security mechanism.
Thus potentially providing both confidentiality, integrity and source
authentication. If SRTP is used, the session ID layer will not be
directly protected by SRTP. However, it will be implicitly integrity
protected (assuming the RTP/RTCP packet is integrity protected) as
the only function of the field is to identify the session context.
Thus any modification of the SID field will attempt to retrieve the
wrong SRTP crypto context. If that retrieval fails, the packet will
be anyway be discarded. If it is successful, the context will not
lead to successful verification of the packet.
10. Acknowledgements
This document is based on the input from various people, especially
in the context of the RTCWEB discussion of how to use only a single
lower layer transport. The RTP and RTCP packet figures are borrowed
from RFC3711. The SDP example is extended from the one present in
[I-D.ietf-mmusic-sdp-bundle-negotiation]. The authors would like to
thank Christer Holmberg for assistance in utilizing the BUNDLE
grouping mechanism.
The proposal in Appendix A.5 is original suggested by Colin Perkins.
The idea in Appendix A.6 is from an Internet Draft
[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
people at IETF meeting #81 in Quebec.
11. References
11.1. Normative References
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation
Using Session Description Protocol (SDP) Port Numbers",
draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in
progress), February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
11.2. Informational References
[I-D.lennox-rtcweb-rtp-media-type-mux]
Rosenberg, J. and J. Lennox, "Multiplexing Multiple Media
Types In a Single Real-Time Transport Protocol (RTP)
Session", draft-lennox-rtcweb-rtp-media-type-mux-00 (work
in progress), October 2011.
[I-D.rosenberg-rtcweb-rtpmux]
Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M.,
Rescorla, E., and T. Terriberry, "Multiplexing of Real-
Time Transport Protocol (RTP) Traffic for Browser based
Real-Time Communications (RTC)",
draft-rosenberg-rtcweb-rtpmux-00 (work in progress),
July 2011.
[I-D.westerlund-avtcore-multi-media-rtp-session]
Westerlund, M., Perkins, C., and J. Lennox, "Multiple
Media Types in an RTP Session",
draft-westerlund-avtcore-multi-media-rtp-session-00 (work
in progress), July 2012.
[I-D.westerlund-avtcore-multiplex-architecture]
Westerlund, M., Burman, B., and C. Perkins, "RTP
Multiplexing Architecture",
draft-westerlund-avtcore-multiplex-architecture-01 (work
in progress), March 2012.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
Appendix A. Possible Solutions
This section looks at a few possible solutions and discusses their This section looks at a few possible solutions and discusses their
feasibility. feasibility.
4.1. Header Extension A.1. Header Extension
One proposal is to define an RTP header extension [RFC5285] that One proposal is to define an RTP header extension [RFC5285] that
explicitly enumerates the session identifier in each packet. This explicitly enumerates the session identifier in each packet. This
proposal has some merits regarding RTP, since it uses an existing proposal has some merits regarding RTP, since it uses an existing
extension mechanism; it explicitly enumerates the session allowing extension mechanism; it explicitly enumerates the session allowing
for third parties to associate the packet to a given RTP session; and for third parties to associate the packet to a given RTP session; and
it works with SRTP as currently defined since a header extension is it works with SRTP as currently defined since a header extension is
by default not encrypted, and is thus readable by the receiving stack by default not encrypted, and is thus readable by the receiving stack
without needing to guess which session it belongs to and attempt to without needing to guess which session it belongs to and attempt to
decrypt it. This approach does, however, conflict with the decrypt it. This approach does, however, conflict with the
skipping to change at page 9, line 35 skipping to change at page 29, line 13
would need to modify its RTCP compound packet rules to include this would need to modify its RTCP compound packet rules to include this
packet type first. Thus a translator box between supporting nodes packet type first. Thus a translator box between supporting nodes
and non-supporting nodes needs to be in the crypto context. and non-supporting nodes needs to be in the crypto context.
This solution's per packet overhead is expected to be 64-bits for This solution's per packet overhead is expected to be 64-bits for
RTCP. For RTP it is 64-bits if no header extension was otherwise RTCP. For RTP it is 64-bits if no header extension was otherwise
used, and an additional 16 bits (short header), or 24 bits plus (if used, and an additional 16 bits (short header), or 24 bits plus (if
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.
4.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 shall 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
skipping to change at page 10, line 20 skipping to change at page 29, line 47
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 may 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.
4.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 must be taken in that inspection. For
example, you must be careful to ensure that each real media source example, you must be careful to ensure that each real media source
skipping to change at page 11, line 34 skipping to change at page 31, line 14
method may be sufficient and which can accept the methods limitations method may 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.
4.4. Use the SRTP MKI field A.4. Use the SRTP MKI field
This proposal is to overload the MKI SRTP/SRTCP identifier to not This proposal is to overload the MKI SRTP/SRTCP identifier to not
only identify a particular crypto context, but also identify the only identify a particular crypto context, but also identify the
actual RTP Session. This clearly is a miss use of the MKI field, actual RTP Session. This clearly is a miss use of the MKI field,
however it appears to be with little negative implications. SRTP however it appears to be with little negative implications. SRTP
already supports handling of multiple crypto contexts. already supports handling of multiple crypto contexts.
The two major downsides with this proposal is first the fact that it The two major downsides with this proposal is first the fact that it
requires using SRTP/SRTCP to multiplex multiple sessions on a single requires using SRTP/SRTCP to multiplex multiple sessions on a single
lower layer transport. The second issue is that the session ID lower layer transport. The second issue is that the session ID
parameter needs to be put into the various key-management schemes and parameter needs to be put into the various key-management schemes and
to make them understand that the reason to establish multiple crypto to make them understand that the reason to establish multiple crypto
contexts is because they are connected to various RTP Sessions. contexts is because they are connected to various RTP Sessions.
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.
4.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, (required 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
skipping to change at page 12, line 41 skipping to change at page 32, line 21
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
as not matching a context. A receiver can mitigate this somewhat by as not matching a context. A receiver can mitigate this somewhat by
using heuristics based on the RTP header fields to determine which using heuristics based on the RTP header fields to determine which
context applies for a received packet, but this is not a complete context applies for a received packet, but this is not a complete
solution. solution.
This solution has a 16-bit per packet overhead. This solution has a 16-bit per packet overhead.
4.6. Redefine the SSRC field A.6. Redefine the SSRC field
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
skipping to change at page 13, line 21 skipping to change at page 33, line 5
there is a possibility that such a translator becomes a obstacle in there is a possibility that such a translator becomes a obstacle in
deploying future RTP/RTCP extensions. In addition the translator deploying future RTP/RTCP extensions. In addition the translator
actually have significant overhead when SRTP are in use. This as a actually have significant overhead when SRTP are in use. This as a
verification that the packet is authentic, decryption, SSRC verification that the packet is authentic, decryption, SSRC
translation, encryption and finally generation of authentication tags translation, encryption and finally generation of authentication tags
are required. In addition the translator must be part of the are required. In addition the translator must be part of the
security context. security context.
This solution has no per packet overhead. This solution has no per packet overhead.
5. 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 1) of the high level value are In the end a summary table (Figure 4) of the high level value are
provided. provided.
5.1. Support of Multiple RTP Sessions Over Single Transport B.1. Support of Multiple RTP Sessions Over Single Transport
This one is easy to determine. Only the single session proposal This one is easy to determine. Only the single session proposal
fails this requirement as it is not at all designed to meet it. The fails this requirement as it is not at all designed to meet it. The
rest fully support this requirement. The main question around this rest fully support this requirement. The main question around this
requirement is how important it is to have as discussed in requirement is how important it is to have as discussed in
Section 3.1. Section 4.1.
5.2. Enable Same SSRC Value in Multiple RTP Sessions B.2. Enable Same SSRC Value in Multiple RTP Sessions
Based on the discussion in Section 3.2 two sub-requirements have been Based on the discussion in Section 4.2 two sub-requirements have been
derived. derived.
5.2.1. Avoid SSRC Translation in Gateways/Translation B.2.1. Avoid SSRC Translation in Gateways/Translation
This sub-requirement is derived based on the desire to avoid having This sub-requirement is derived based on the desire to avoid having
gateways or translators perform full SSRC translation to minimize gateways or translators perform full SSRC translation to minimize
complexity, avoid the requirement to have gateways in security complexity, avoid the requirement to have gateways in security
context, and as a hinder to long-term evolution. Two of the context, and as a hinder to long-term evolution. Two of the
proposals have issues with this, due to their lack of support for proposals have issues with this, due to their lack of support for
multiple 32-bit SSRC spaces and lacking possibility to have the same multiple 32-bit SSRC spaces and lacking possibility to have the same
SSRC value in multiple RTP sessions. The proposals that have these SSRC value in multiple RTP sessions. The proposals that have these
properties and thus are marked as failing are the Single Session and properties and thus are marked as failing are the Single Session and
Redefine the SSRC field. The other proposals are all succcesful in Redefine the SSRC field. The other proposals are all successful in
meeting this requirement. meeting this requirement.
5.2.2. Support Existing Extensions B.2.2. Support Existing Extensions
The second sub-requirement is how well the proposals support using The second sub-requirement is how well the proposals support using
the existing RTP mechanisms. Here both Single Session and Redefine the existing RTP mechanisms. Here both Single Session and Redefine
the SSRC field will have clear issues as they cannot support the same the SSRC field will have clear issues as they cannot support the same
full 32-bit SSRC value in two different RTP sessions. This is full 32-bit SSRC value in two different RTP sessions. This is
clearly an issue for the XOR based FEC. RTP retransmission and clearly an issue for the XOR based FEC. RTP retransmission and
scalable encoding are minor issues as there exist alternatives to scalable encoding are minor issues as there exist alternatives to
those mechanisms that works with the structure of these two those mechanisms that works with the structure of these two
proposals. Thus we give them a fail. The Header Extension gets a proposals. Thus we give them a fail. The Header Extension gets a
partial due to unclear interaction between putting in an header partial due to unclear interaction between putting in an header
extension and these mechanisms. extension and these mechanisms.
5.3. Ensure SRTP Functions B.3. Ensure SRTP Functions
This requirement is about ensuring both secure and efficient usage of This requirement is about ensuring both secure and efficient usage of
SRTP. The Octet in Padding field proposal gets a fail as the SRTP. The Octet in Padding field proposal gets a fail as the
receiving end-point cannot determine the intended RTP session prior receiving end-point cannot determine the intended RTP session prior
to de-encryption of the padding field. Thus a catch-22 arises which to de-encryption of the padding field. Thus a catch-22 arises which
can only be resolved by trying all session contexts and see what can only be resolved by trying all session contexts and see what
decrypts. This causes a security vulnerability as an attacker can decrypts. This causes a security vulnerability as an attacker can
inject a packet which does not meet any of the session contexts. The inject a packet which does not meet any of the session contexts. The
receiver will then attempt decryption and authentication of it using receiver will then attempt decryption and authentication of it using
all its session contexts, increasing the amount of wasted resources all its session contexts, increasing the amount of wasted resources
skipping to change at page 15, line 10 skipping to change at page 34, line 42
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 being gatewayed 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.
5.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 should 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
skipping to change at page 15, line 43 skipping to change at page 35, line 26
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. implementors.
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
used bits in RTP. The header extension would be a correctly used bits in RTP. The header extension would be a correctly
identified extension with its own definition. However, it does identified extension with its own definition. However, it does
redefine a rule on what header extensions are for. The RTCP solution redefine a rule on what header extensions are for. The RTCP solution
however would have more severe impact as it would need to redefine however would have more severe impact as it would need to redefine
the standard meaning of an RTCP packet header in addition to the the standard meaning of an RTCP packet header in addition to the
default compound packet rules. Due to these issues the proposal default compound packet rules. Due to these issues the proposal
fails to meet this requirement. fails to meet this requirement.
The multiplexing shim and the single session both successfully meet The multiplexing shim and the single session both successfully meet
this requirement. this requirement.
5.5. Firewall Friendly B.5. Firewall Friendly
This requirement is clearly difficult to judge as firewall This requirement is clearly difficult to judge as firewall
implementations are highly different in both implementation, scope of implementations are highly different in both implementation, scope of
what it investigates in packets, and set policies. A reasonable goal what it investigates in packets, and set policies. A reasonable goal
is to minimize the likeliness that rules and policies intended to let is to minimize the likeliness that rules and policies intended to let
RTP media streams pass, will also let these streams through when RTP media streams pass, will also let these streams through when
multiplexing RTP sessions over a single transport. The below multiplexing RTP sessions over a single transport. The below
analysis shows that no solution is truly firewall friendly and all analysis shows that no solution is truly firewall friendly and all
are judged as being partially meeting this goal. However, the reason are judged as being partially meeting this goal. However, the reason
why it is believed that a firewall might react to the streams are why it is believed that a firewall might react to the streams are
quite different. quite different.
The Single Session and Redefine the SSRC field are likely the least The Single Session and Redefine the SSRC field are likely the least
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 behavior.
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 may 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 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 may 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 may 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.
5.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
skipping to change at page 18, line 17 skipping to change at page 37, line 47
anyone that is not upgraded to understand the semantics, this only anyone that is not upgraded to understand the semantics, this only
gets a partial. gets a partial.
The other proposals all can have multiple RTP sessions using the same The other proposals all can have multiple RTP sessions using the same
SSRC. This will create significant issues for any legacy third party SSRC. This will create significant issues for any legacy third party
monitor. Only an updated monitor, or for that matter packet monitor. Only an updated monitor, or for that matter packet
selector, can pick out the individual media streams and their selector, can pick out the individual media streams and their
associated RTCP traffic. Thus all these proposals gets a failure to associated RTCP traffic. Thus all these proposals gets a failure to
meet the requirement. meet the requirement.
5.7. Usable over Multicast B.7. Usable over Multicast
As discussed earlier the goal with having the option usable also over As discussed earlier the goal with having the option usable also over
multicast is to remove the need to produce different media streams multicast is to remove the need to produce different media streams
for transport over unicast and multicast. All of the proposals for transport over unicast and multicast. All of the proposals
successfully meet the requirement. successfully meet the requirement.
5.8. Incremental Deployment B.8. Incremental Deployment
The possibility to deploy the usage of the multiplexing of multiple The possibility to deploy the usage of the multiplexing of multiple
RTP sessions over a single transport, especially in the context of RTP sessions over a single transport, especially in the context of
multi-party sessions, is a great benefit for any of the proposals. multi-party sessions, is a great benefit for any of the proposals.
Thus not all end-point implementations needs to be upgraded before Thus not all end-point implementations needs to be upgraded before
one start enabling it in the central node and any signalling. one start enabling it in the central node and any signalling.
Considering a centralized multi-party application where some Considering a centralized multi-party application where some
participants are using multiple transport flows and you want to participants are using multiple transport flows and you want to
enable one particular participant to use the single transport to the enable one particular participant to use the single transport to the
skipping to change at page 19, line 17 skipping to change at page 38, line 47
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 unncessary) forces the end-point to encrypt at removing it may 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 fulfill the rules or semantics of the
multiplexed side. For Redefine SSRC field this becomes almost multiplexed side. For Redefine SSRC field this becomes almost
constant as the session identifier part of the SSRC must be the same constant as the session identifier part of the SSRC must be the same
over all SSRCs from the same session. For Single Session it may only over all SSRCs from the same session. For Single Session it may only
be needed when there otherwise would be an SSRC collision between the be needed when there otherwise would be an SSRC collision between the
sessions. This further assumes that the non-multiplexed side would sessions. This further assumes that the non-multiplexed side would
never use any of the RTP mechanisms that require the same SSRC in never use any of the RTP mechanisms that require the same SSRC in
multiple RTP sessions, as they cannot be gatewayed at all. When multiple RTP sessions, as they cannot be gatewayed at all. When
translating an SSRC there is first of all an overhead, with SRTP that translating an SSRC there is first of all an overhead, with SRTP that
includes a complete authenticate, decrypte, encrypt and create a new includes a 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
required to be understood by the translator to be correctly required to be understood by the translator to be correctly
translated. Therefore these two proposals gets a fail to meet the translated. Therefore these two proposals gets a fail to meet the
requirements. requirements.
5.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
2: Enable same SSRC value in multiple RTP sessions 2: Enable same SSRC value in multiple RTP sessions
skipping to change at page 20, line 38 skipping to change at page 40, line 19
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
---------------+---+---+---+---+---+---+---+---+---+---- ---------------+---+---+---+---+---+---+---+---+---+----
Header Ext. | S | S | P | P | F | P | F | S | P | 8+ Header Ext. | S | S | P | P | F | P | F | S | P | 8+
Multiplex Shim | S | S | S | S | S | P | F | S | S | 1 Multiplex Shim | S | S | S | S | S | P | F | S | S | 1
Single Session | F | F | F | S | S | P | S | S | F | 0 Single Session | F | F | F | S | S | P | S | S | F | 0
SRTP MKI Field | S | S | S | P | F | P | F | S | S | 4 SRTP MKI Field | S | S | S | P | F | P | F | S | S | 4
Padding Field | S | S | S | F | P | P | F | S | P | 2 Padding Field | S | S | S | F | P | P | F | S | P | 2
Redefine SSRC | S | F | F | P | F | P | P | S | S | 0 Redefine SSRC | S | F | F | P | F | P | P | S | S | 0
---------------+---+---+---+---+---+---+---+---+---+---- ---------------+---+---+---+---+---+---+---+---+---+----
Figure 1: Summary Table of Evaluation (Successfully (S), Partially Figure 4: Summary Table of Evaluation (Successfully (S), Partially
(P) or Fails (F) to meet requirement) (P) or Fails (F) to meet requirement)
Considering these options, the authors would recommend that AVTCORE Considering these options, the authors would recommend that AVTCORE
standardize a solution based on a postfixed multiplexing field, i.e. standardize a solution based on a post or prefixed multiplexing
a shim approach combined with the appropriate signalling as described field, i.e. a shim approach combined with the appropriate signalling
in Section 4.2. as described in Appendix A.2.
6. Specification
This section contains the specification of the solution based on a
SHIM, with the explicit session identifier at the end of the
encapsulated payload.
6.1. Shim Layer
This solution is based on a shim layer that is inserted in the stack
between the regular RTP and RTCP packets and the transport layer
being used by the RTP sessions. Thus the layering looks like the
following:
+---------------------+
| RTP / RTCP Packet |
+---------------------+
| Session ID Layer |
+---------------------+
| Transport layer |
+---------------------+
Stack View with Session ID SHIM
The above stack is in fact a layered one as it does allow multiple
RTP Sessions to be multiplexed on top of the Session ID shim layer.
This enables the example presented in Figure 2 where four sessions,
S1-S4 is sent over the same Transport layer and where the Session ID
layer will combine and encapsulate them with the session ID on
transmission and separate and decapsulate them on reception.
+-------------------+
| S1 | S2 | S3 | S4 |
+-------------------+
| Session ID Layer |
+-------------------+
| Transport layer |
+-------------------+
Figure 2: Multiple RTP Session On Top of Session ID Layer
The Session ID layer encapsulates one RTP or RTCP packet from a given
RTP session and postfixes a one byte Session ID (SID) field to the
packet. 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 0-255. The reason for assigning a pair of SIDs to a
given 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 to use a single 5-tuple. The reasons for
supporting this extra functionality is that RTP and RTCP multiplexing
based on the payload type/packet type fields enforces certain
restrictions on the RTP sessions. These restrictions may not be
acceptable. As this solution does not have these restrictions,
performing RTP and RTCP multiplexing in this way has benefits.
Each Session ID value space is scoped by the underlying transport
protocol. Common transport protocols like UDP, DCCP, TCP, and SCTP
can all be scoped by one or more 5-tuple (Transport protocol, source
address and port, destination address and port). The case of
multiple 5-tuples occur in the case of multi-unicast topologies, also
called meshed multiparty RTP sessions or in case any application
would need more than 128 RTP sessions.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | |
| .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| RTP extension (OPTIONAL) | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Session ID | |
| +---------------+ |
+- Encrypted Portion* Authenticated Portion ---+
Figure 3: SRTP Packet encapsulated by Session ID Layer
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P| RC | PT=SR or RR | length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| SSRC of sender | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| ~ sender info ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ report block 1 ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ report block 2 ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ ... ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |V=2|P| SC | PT=SDES=202 | length | |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| | SSRC/CSRC_1 | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ SDES items ~ |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| ~ ... ~ |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| |E| SRTCP index | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTCP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Session ID | |
| +---------------+ |
+-- Encrypted Portion Authenticated Portion -----+
Figure 4: SRTCP packet encapsulated by Session ID layer
The processing in a receiver when the Session ID layer is present
will be to
1. Pick up the packet from the lower layer transport
2. Inspect the SID field value
3. Strip the SID field from the packet
4. Forward it to the (S)RTP Session context identified by the SID
value
6.2. Signalling
The use of the Session ID layer needs to be explicitly agreed on
between the communicating parties. Each RTP Session the application
uses must in addition to the regular configuration such as payload
types, RTCP extension etc, have both the underlying 5-tuple (source
address and port, destination address and port, and transport
protocol) and the Session ID used for the particular RTP session.
The signalling requirement is to assign unique Session ID values to
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
direction. Note that nothing prevents a multi-media application from
using multiple 5-tuples if desired for some reason, in which case
each 5-tuple has its own session ID value space.
This section defines how to negotiate the use of the Session ID
layer, using the Session Description Protocol (SDP) Offer/Answer
mechanism [RFC3264]. A new media-level SDP attribute,
'session-mux-id', is defined, in order to be used with the media
BUNDLE mechanism defined in [I-D.ietf-mmusic-sdp-bundle-negotiation].
The attribute allows each media description ("m=" line) associated
with a 'BUNDLE' group to form separate RTP sessions.
The 'session-mux-id' attribute is included for a media description,
in order to indicate the Session ID for that particular media
description. Every media description that shares a common attribute
value is assumed to be part of a single RTP session. An SDP Offerer
MUST include the 'session-mux-id' attribute for every media
description associated with a 'BUNDLE' group. If the SDP Answer does
not contain 'session-mux-id' attributes, the SDP Offerer MUST NOT
assume that separate RTP sessions will be used. If the SDP Answer
still describes a 'BUNDLE' group, the procedures in
[I-D.ietf-mmusic-sdp-bundle-negotiation] apply.
An SDP Answerer MUST NOT include the 'session-mux-id' attribute in an
SDP Answer, unless included in the SDP Offer.
The attribute has the following ABNF [RFC5234] definition.
Session-mux-id-attr = "a=session-mux-id:" SID *SID-prop
SID = SID-value / SID-pairs
SID-value = 1*3DIGIT / "NoN"
SID-pairs = SID-value "/" SID-value ; RTP/RTCP SIDs
SID-prop = SP assignment-policy / prop-ext
prop-ext = token "=" value
assignment-policy = "policy=" ("tentative" / "fixed")
The following parameters MUST be configured as specified:
o RTP Profile SHOULD be the same, but MUST be compatible, like AVP
and AVPF.
o RTCP bandwidth parameters are the same
o RTP Payload type values are not overlapping
In declarative SDP usage, there is clearly no method for fallback
unless some other negotiation protocol is used.
The SID property "policy" is used in negotiation by an end-point to
indicate if the session ID values are merely a tentative suggestion
or if they must have these values. This is used when negotiating SID
for multi-party RTP sessions to support shared transports such as
multicast or RTP translators that are unable to produce renumbered
SIDs on a per end-point basis. The normal behavior is that the offer
suggest a tentative set of values, indicated by "policy=tentative".
These SHOULD be accepted by the peer unless that peer negotiate
session IDs on behalf of a centralized policy, in which case it MAY
change the value(s) in the answer. If the offer represents a policy
that does not allow changing the session ID values, it can indicate
that to the answerer by setting the policy to "fixed". This enables
the answering peer to either accept the value or indicate that there
is a conflict in who is performing the assignment by setting the SID
value to NoN (Not a Number). Offerer and answerer SHOULD always
include the policy they are operating under. Thus, in case of no
centralized behaviors, both offerer and answerer will indicate the
tentative policy.
6.3. SRTP Key Management
Key management for SRTP do needs discussion as we do cause multiple
SRTP sessions to exist on the same underlying transport flow. Thus
we need to ensure that the key management mechanism still are
properly associated with the SRTP session context it intends to key.
To ensure that we do look at the three SRTP key management mechanism
that IETF has specified, one after another.
6.3.1. Security Description
Session Description Protocol (SDP) Security Descriptions for Media
Streams [RFC4568] as being based on SDP has no issue with the RTP
session multiplexing on lower layer specified here. The reason is
that the actual keying is done using a media level SDP attribute.
Thus the attribute is already associated with a particular media
description. A media description that also will have an instance of
the "a=session-mux-id" attribute carrying the SID value/pair used
with this particular crypto parameters.
6.3.2. DTLS-SRTP
Datagram Transport Layer Security (DTLS) Extension to Establish Keys
for the Secure Real-time Transport Protocol (SRTP) [RFC5764] is a
keying mechanism that works on the media plane on the same lower
layer transport that SRTP/SRTCP will be transported over. Thus each
DTLS message must be associated with the SRTP and/or SRTCP flow it is
keying.
The most direct solution is to use the SHIM and the SID context
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
intended to key that particular SRTP and/or SRTCP flow(s).
6.3.3. MIKEY
MIKEY: Multimedia Internet KEYing [RFC3830] is a key management
protocol that has several transports. In some cases it is used
directly on a transport protocol such as UDP, but there is also a
specification for how MIKEY is used with SDP "Key Management
Extensions for Session Description Protocol (SDP) and Real Time
Streaming Protocol (RTSP)" [RFC4567].
Lets start with the later, i.e. the SDP transport, which shares the
properties with Security Description in that is can be associated
with a particular media description in a SDP. As long as one avoids
using the session level attribute one can be certain to correctly
associate the key exchange with a given SRTP/SRTCP context.
It does appear that MIKEY directly over a lower layer transport
protocol will have similar issues as DTLS.
6.4. Examples
6.4.1. RTP Packet with Transport Header
The below figure contains an RTP packet with SID field encapsulated
by a UDP packet (added UDP header).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | |
| .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| RTP extension (OPTIONAL) | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Session ID | |
| +---------------+ |
+- Encrypted Portion* Authenticated Portion ---+
SRTP Packet Encapsulated by Session ID Layer
6.4.2. SDP Offer/Answer example
This section contains SDP offer/answer examples. First one example
of successful BUNDLEing, and then two where fallback occurs.
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
that they are different RTP sessions despite being offered over the
same 5-tuple.
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
b=AS:200
a=mid:foo
a=session-mux-id:0 policy=tentative
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32
b=AS:1000
a=mid:bar
a=session-mux-id:1 policy=tentative
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
The SDP answer from an end-point that supports this BUNDLEing:
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0
b=AS:200
a=mid:foo
a=session-mux-id:0 policy=tentative
a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32
b=AS:1000
a=mid:bar
a=session-mux-id:1 policy=tentative
a=rtpmap:32 MPV/90000
The SDP answer from an end-point that does not support this BUNDLEing
or the general signalling of
[I-D.ietf-mmusic-sdp-bundle-negotiation].
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 20000 RTP/AVP 0
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32
b=AS:1000
a=rtpmap:32 MPV/90000
The SDP answer of a client supporting
[I-D.ietf-mmusic-sdp-bundle-negotiation] but not this BUNDLEing would
look like this:
v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32
a=mid:bar
b=AS:1000
a=rtpmap:32 MPV/90000
In this last case, the result is a sing RTP session with both media
types being established. If that isn't supported or desired, the
offerer will have to either re-invite without the BUNDLE grouping to
force different 5-tuples, or simply terminate the session.
7. Open Issues
This work is still in the early phase of specification. This section
contains a list of open issues where the author desires some input.
1. Should RTP and RTCP multiplexing without RFC 5761 support be
included?
2. 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
sense needs additional discussion.
3. Can we provide better control so that applications that doesn't
desire fallback to single RTP session when Multiplexing shim
fails to be supported but Bundle is supported ends up with a
better alternative?
8. IANA Considerations
This document request the registration of one SDP attribute. Details
of the registration to be filled in.
9. Security Considerations
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
session. If IPsec or transport layer security solutions such as DTLS
or TLS are being used then both the encapsulated RTP/RTCP packets and
the session ID layer will be protected by that security mechanism.
Thus potentially providing both confidentiality, integrity and source
authentication. If SRTP is used, the session ID layer will not be
directly protected by SRTP. However, it will be implicitly integrity
protected (assuming the RTP/RTCP packet is integrity protected) as
the only function of the field is to identify the session context.
Thus any modification of the SID field will attempt to retrieve the
wrong SRTP crypto context. If that retrieval fails, the packet will
be anyway be discarded. If it is successful, the context will not
lead to successful verification of the packet.
10. Acknowledgements
This document is based on the input from various people, especially
in the context of the RTCWEB discussion of how to use only a single
lower layer transport. The RTP and RTCP packet figures are borrowed
from RFC3711. The SDP example is extended from the one present in
[I-D.ietf-mmusic-sdp-bundle-negotiation]. The authors would like to
thank Christer Holmberg for assistance in utilizing the BUNDLE
grouping mechanism.
The proposal in Section 4.5 is original suggested by Colin Perkins.
The idea in Section 4.6 is from an Internet Draft
[I-D.rosenberg-rtcweb-rtpmux] written by Jonathan Rosenberg et. al.
The proposal in Section 4.3 is a result of discussion by a group of
people at IETF meeting #81 in Quebec.
11. References
11.1. Normative References
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation
Using Session Description Protocol (SDP) Port Numbers",
draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in
progress), February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
11.2. Informational References
[I-D.lennox-rtcweb-rtp-media-type-mux]
Rosenberg, J. and J. Lennox, "Multiplexing Multiple Media
Types In a Single Real-Time Transport Protocol (RTP)
Session", draft-lennox-rtcweb-rtp-media-type-mux-00 (work
in progress), October 2011.
[I-D.rosenberg-rtcweb-rtpmux]
Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M.,
Rescorla, E., and T. Terriberry, "Multiplexing of Real-
Time Transport Protocol (RTP) Traffic for Browser based
Real-Time Communications (RTC)",
draft-rosenberg-rtcweb-rtpmux-00 (work in progress),
July 2011.
[I-D.westerlund-avtcore-multiplex-architecture]
Westerlund, M., Burman, B., and C. Perkins, "RTP
Multiplexing Architecture",
draft-westerlund-avtcore-multiplex-architecture-01 (work
in progress), March 2012.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE-164 80 Kista SE-164 80 Kista
Sweden Sweden
Phone: +46 10 714 82 87 Phone: +46 10 714 82 87
 End of changes. 52 change blocks. 
632 lines changed or deleted 980 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/