draft-westerlund-avtcore-transport-multiplexing-06.txt   draft-westerlund-avtcore-transport-multiplexing-07.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track C. S. Perkins Intended status: Standards Track C. S. Perkins
Expires: March 01, 2014 University of Glasgow Expires: April 24, 2014 University of Glasgow
August 28, 2013 October 21, 2013
Multiple RTP Sessions on a Single Lower-Layer Transport Multiplexing Multiple RTP Sessions onto a Single Lower-Layer Transport
draft-westerlund-avtcore-transport-multiplexing-06 draft-westerlund-avtcore-transport-multiplexing-07
Abstract Abstract
This memo defines a mechanism to allow multiple RTP sessions to be This memo defines a mechanism to allow multiple RTP sessions to be
multiplexed onto a single lower-layer transport flow (e.g., onto a multiplexed onto a single lower-layer transport flow (e.g., onto a
single UDP 5-tuple). Requirements for multiplexing RTP sessions are single UDP 5-tuple). Requirements for multiplexing RTP sessions are
discussed, along with the trade-off between the different options. A discussed, along with the trade-off between the different options. A
shim-based multiplexing layer is proposed, along with associated shim-based multiplexing layer is proposed, along with associated
signalling. signalling.
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 March 01, 2014. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 4
3.2. No Transport Level QoS . . . . . . . . . . . . . . . . . 5
3.3. Multiple RTP sessions . . . . . . . . . . . . . . . . . . 5
3.4. Usage of RTP Extensions . . . . . . . . . . . . . . . . . 5
3.5. Incremental Deployment . . . . . . . . . . . . . . . . . 6
3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Support Use of Multiple RTP Sessions . . . . . . . . . . 7 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 8
4.2. Same SSRC Value in Multiple RTP Sessions . . . . . . . . 7 5.1. Location of Multiplexing Shim Header . . . . . . . . . . 9
4.3. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. ICE and DTLS-SRTP Integration . . . . . . . . . . . . . . 10
4.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . 8 5.3. Signalling Fall Back . . . . . . . . . . . . . . . . . . 10
4.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 9 6. Specification . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Monitoring and Reporting . . . . . . . . . . . . . . . . 9 6.1. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Usable Also Over Multicast . . . . . . . . . . . . . . . 9 6.2. Signalling . . . . . . . . . . . . . . . . . . . . . . . 15
4.8. Incremental Deployment . . . . . . . . . . . . . . . . . 9 6.3. SRTP Key Management . . . . . . . . . . . . . . . . . . . 16
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 9 6.3.1. Security Description . . . . . . . . . . . . . . . . 16
5.1. Location of SHIM . . . . . . . . . . . . . . . . . . . . 10 6.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 17
5.2. ICE and DTLS-SRTP Integration . . . . . . . . . . . . . . 11 6.3.3. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Signalling Fall Back . . . . . . . . . . . . . . . . . . 12 6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Specification . . . . . . . . . . . . . . . . . . . . . . . . 13 6.4.1. Secure RTP Packet with Multiplexing Shim . . . . . . 18
6.1. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . 13 6.4.2. Basic RTP Multiplex Negotiation in SDP . . . . . . . 19
6.2. Signalling . . . . . . . . . . . . . . . . . . . . . . . 16 6.4.3. Advanced RTP Multiplex Negotiation in SDP . . . . . . 20
6.3. SRTP Key Management . . . . . . . . . . . . . . . . . . . 18 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3.1. Security Description . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
6.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6.3.3. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.4.1. RTP Packet with Transport Header . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
6.4.2. SDP Offer/Answer example . . . . . . . . . . . . . . 20 11.2. Informational References . . . . . . . . . . . . . . . . 22
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Possible Solutions . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 A.1. Header Extension . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 A.2. Multiplexing Shim . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 A.3. Single Session . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.4. Use the SRTP MKI field . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 26 A.5. Use an Octet in the Padding . . . . . . . . . . . . . . . 28
11.2. Informational References . . . . . . . . . . . . . . . . 27 A.6. Redefine the SSRC field . . . . . . . . . . . . . . . . . 28
Appendix A. Possible Solutions . . . . . . . . . . . . . . . . . 28 Appendix B. Comparison . . . . . . . . . . . . . . . . . . . . . 29
A.1. Header Extension . . . . . . . . . . . . . . . . . . . . 28 B.1. Support of Multiple RTP Sessions Over Single Transport . 29
A.2. Multiplexing Shim . . . . . . . . . . . . . . . . . . . . 30 B.2. Enable Same SSRC Value in Multiple RTP Sessions . . . . . 29
A.3. Single Session . . . . . . . . . . . . . . . . . . . . . 30 B.2.1. Avoid SSRC Translation in Gateways/Translation . . . 29
A.4. Use the SRTP MKI field . . . . . . . . . . . . . . . . . 32 B.2.2. Support Existing Extensions . . . . . . . . . . . . . 30
A.5. Use an Octet in the Padding . . . . . . . . . . . . . . . 32 B.3. Ensure SRTP Functions . . . . . . . . . . . . . . . . . . 30
A.6. Redefine the SSRC field . . . . . . . . . . . . . . . . . 33 B.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . 31
Appendix B. Comparison . . . . . . . . . . . . . . . . . . . . . 33 B.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 32
B.1. Support of Multiple RTP Sessions Over Single Transport . 33 B.6. Monitoring and Reporting . . . . . . . . . . . . . . . . 33
B.2. Enable Same SSRC Value in Multiple RTP Sessions . . . . . 34 B.7. Usable over Multicast . . . . . . . . . . . . . . . . . . 34
B.2.1. Avoid SSRC Translation in Gateways/Translation . . . 34 B.8. Incremental Deployment . . . . . . . . . . . . . . . . . 34
B.2.2. Support Existing Extensions . . . . . . . . . . . . . 34 B.9. Summary and Conclusion . . . . . . . . . . . . . . . . . 36
B.3. Ensure SRTP Functions . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
B.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . 35
B.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 36
B.6. Monitoring and Reporting . . . . . . . . . . . . . . . . 37
B.7. Usable over Multicast . . . . . . . . . . . . . . . . . . 38
B.8. Incremental Deployment . . . . . . . . . . . . . . . . . 38
B.9. Summary and Conclusion . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
With the ongoing development of the WebRTC conferencing and CLUE With the ongoing development of the WebRTC conferencing and CLUE
telepresence standards, there is renewed interest in defining a telepresence standards, there is renewed interest in defining a
mechanism that allows multiple RTP sessions [RFC3550] to share a mechanism that allows multiple RTP sessions [RFC3550] to share a
single lower layer transport, such as a bi-directional UDP flow. The single lower layer transport, such as a bi-directional UDP flow. The
main problem driving this is the cost of doing NAT/firewall traversal main problem driving this is the cost of doing NAT/firewall traversal
for each individual RTP flow. ICE and other NAT/firewall traversal for each individual RTP flow. ICE and other NAT/firewall traversal
solutions are clearly capable of attempting to open multiple flows. solutions are clearly capable of attempting to open multiple flows.
skipping to change at page 3, line 45 skipping to change at page 3, line 32
There is ongoing work on specifying how and when one RTP session can There is ongoing work on specifying how and when one RTP session can
contain multiple media types contain multiple media types
[I-D.ietf-avtcore-multi-media-rtp-session]. That addresses certain [I-D.ietf-avtcore-multi-media-rtp-session]. That addresses certain
use cases, while this proposal addresses a different set of use cases use cases, while this proposal addresses a different set of use cases
and motivations (discussed further in Section 3). The classical and motivations (discussed further in Section 3). The classical
method of having each RTP session run over a specific transport flow method of having each RTP session run over a specific transport flow
is still motivated for a number of use cases, especially when flow is still motivated for a number of use cases, especially when flow
based QoS is to be used for some media streams. based QoS is to be used for some media streams.
This document draws up some requirements for consideration on how to This memo 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 have to be weighted carefully, as no known These requirements have to be weighted carefully, as no known
solution exists that can fulfil the combined set of requirements solution exists that can fulfil the combined set of requirements
completely. A number of possible solutions where considered and completely. A number of possible solutions where considered and
discussed with respect to their properties. Based on that, this memo discussed with respect to their properties. Based on that, this memo
defines a multiplexing shim, along with SDP signalling, and examples. defines a multiplexing shim, along with SDP signalling, and examples.
The other considered proposals and the comparison is available as The other considered proposals and the comparison is available as
appendices. appendices.
2. Conventions 2. Terminology
The following terminology is used in this document.
Multiplexing: Unless specifically noted, all mentioning of Unless specifically noted, all mentioning of multiplexing in this
multiplexing in this document refer to the multiplexing of memo refer to the multiplexing of multiple RTP Sessions onto the same
multiple RTP Sessions on the same lower layer transport. It is lower layer transport. It is important to make this distinction as
important to make this distinction as RTP does contain a number of RTP contains a number of multiplexing points for various purposes,
multiplexing points for various purposes, such as media formats such as media formats (Payload Type), media sources (SSRC), and RTP
(Payload Type), media sources (SSRC), and RTP sessions. sessions.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Motivations 3. Motivation
This section looks at the motivations why an additional solution is RTP has always allowed applications to use of multiple RTP sessions,
needed, assuming that you can do both the classical method of having by using different transport-layer flows for each session [RFC3550].
one RTP session per transport flow [RFC3550], and when you have The primary motivation was to support differential quality of service
multiple media types within one RTP session per session, using flow-level differentiated services mechanisms, but
it also lets applications separate flows into several RTP sessions to
better reflect application-level semantics where appropriate.
More recently, there has been a desire to send multiple types of
media in a single RTP session. This uses one RTP session instead of
several RTP sessions, giving up flow-level quality of service, and
semantic separation of traffic, but reducing the number of transport
level flows to ease NAT and firewall traversal. Clarifications to
the RTP specification to support this can be found in
[I-D.ietf-avtcore-multi-media-rtp-session]. [I-D.ietf-avtcore-multi-media-rtp-session].
3.1. NAT and Firewalls There is also a third option that can be useful in some cases. This
is to somehow multiplex several RTP sessions onto a single transport
layer flow. The motivations for why this alternative is needed are
as follows.
The existence of NATs and Firewalls on almost all Internet access has To Ease NAT and Firewall Traversal: The existence of network address
implications for protocols, like RTP, that were designed to use translation (NAT/NAPT) and firewalls on almost all Internet access
multiple transport-layer flows. The NAT/firewall traversal solution has implications for protocols, such as RTP, that were designed to
has to to ensure that all these transport flows are established. use multiple transport-layer flows. Any NAT or firewall traversal
This has three different impacts: solution has to to ensure that all the necessary transport-layer
flows are established. This has three impacts:
1. Increased delay to perform the transport flow establishment 1. Increased delay to perform the transport flow establishment
2. The more transport flows, the more state and the more resource 2. The more transport flows, the more state and the more resource
consumption in the NAT and Firewalls. When the resource consumption in the NAT and Firewalls. When the resource
consumption in NAT/firewalls reaches their limits, unexpected consumption in NAT/firewalls reaches their limits, unexpected
behaviours usually occur. Commonly resulting in service behaviours usually occur. Commonly resulting in service
disruptions. disruptions.
3. More transport flows means a higher risk that some transport flow 3. More transport flows means a higher risk that some transport
fails to be established, thus preventing the application to flow fails to be established, thus preventing the application
communicate. to communicate.
Using fewer transport-layer flows reduces the risk of communication
failure, improves establishment behaviour, and causes less load on
NATs 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 use of multiple RTP sessions allows separation of media streams
that have different usages or purposes in an RTP based application,
for example to separate the video of a presenter or most important
current talker from those of the listeners that not all end-points
receive. Separation of flows into different RTP sessions also allows
different processing based on media types, such as audio and video,
in end-points and middleboxes. This can give middleboxes the
knowledge that any SSRC within the session is supposed to be
processed in a similar way.
For simpler cases, where the streams within each media type need the
same processing, it is clearly possible to find other multiplex
solutions, for example based on the Payload Type and the differences
in encoding that the payload type allows to describe. This can
anyhow be insufficient when you get into more advanced usages where
you have multiple sources of the same media type, but for different
usages or as alternatives. For example when you have one set of
video sources that shows session participants and another set of
video sources that shares an application or presentation slides, you
likely want to separate those streams for various reasons such as
control, prioritization, QoS, methods for robustness, etc. In those
cases, using the RTP session for separation of properties is a
powerful tool. A tool with properties that need to be preserved when
providing a solution for how to use only a single lower-layer
transport.
For more discussion of the usage of RTP sessions verses other
multiplexing we recommend RTP Multiplexing Architecture
[I-D.westerlund-avtcore-multiplex-architecture].
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.ietf-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 Using fewer transport-layer flows, by multiplexing several RTP
sessions onto a single transport-layer flow, reduces the risk of
communication failure, improves establishment behaviour, and
reduces the load on NATs and firewalls.
A developed solution needs to minimize the number of RTP/RTCP To Support Application-level Session-layer Semantics: Applications
extension and mechanisms that can't be used. can use multiple RTP sessions to separate media streams that have
different uses or purposes. For example, a group conferencing
application might use one RTP session to distribute high-quality
video of the active speaker, switching the source of that video as
the conversation progresses, coupled with a second RTP session to
send always-on low-quality views of the inactive speakers, making
it easier of the MCU to manage the traffic. Separation of flows
into different RTP sessions also allows different processing based
on the media type, such as audio and video, in end-points and
middleboxes. This can give middleboxes the knowledge that any
SSRC within the session is supposed to be processed in a similar
way, saving them the need to perform differential processing on a
per-SSRC basis.
3.5. Incremental Deployment Not all applications need to separate their traffic into different
semantic classes. And, for those that do, it is clearly possible
to find other multiplexing solutions for many simpler cases, for
example based on signalled semantics for SSRC, or looking at the
payload type and differences in encoding. This lack of semantic
separation for some flows becomes more critical as the application
semantics get more complex. For example, an application that has
one set of video streams showing session participants, and another
set that shares an application or presentation slides, would
likely want to separate those streams for reasons such as control,
prioritization, QoS, methods for robustness, etc. In those cases,
using the RTP session for separation of flows with different
semantics is a powerful tool that can ease the application design,
and something that we would like to preserve when providing a
solution for how to use only a single lower-layer transport.
In various multi-party communication scenarios deployment can become Multiplexing and the use of different RTP session is discussed
an issue if all session participants need to have the functionality further in [I-D.ietf-avtcore-multiplex-guidelines].
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 translation
functionality in any central node.
3.6. Summary To Allow Use of Certain RTP Extensions: Different applications use
different sets of RTP extensions. Several of these extensions are
known to have limitations that prevent them from being used in RTP
sessions that carry different types of media. This is discussed
more in [I-D.ietf-avtcore-multi-media-rtp-session]. The
extensions that are known to be problematic include parity FEC
[RFC5109], RTP Retransmission in session mode [RFC4588], and some
forms of layered coding. This prevents some applications from
sending multiple types of media in a single RTP session, forcing
them to use multiple RTP sessions. To prevent those applications
from having to use several transport-layer flows for the different
RTP sessions, it is desirable to have a way of multiplexing
several RTP sessions on a single transport-layer flow.
The centre of the motivation is to ensure that the RTP session is a The centre of the motivation is to ensure that the use of multiple
available and usable tool also for applications that has no need for RTP sessions is available, and usable, for applications that have no
network level separation of its media streams and wants to reduce its need for transport-layer separation of their media streams and want
exposure to any NAT or Firewall inconsistencies and minimize the to reduce their exposure to any NAT or Firewall inconsistencies and
resource consumption. As a benefit a well designed solution will minimize the resource consumption. As a benefit, a well designed
enable incremental deployment and minimal limitations in what solution will remove the limitations on what existing RTP mechanisms
existing RTP mechanisms or extensions that can be used by the RTP or extensions that can be used by the application, when compared to
using application. sending multiple media types in a single RTP session.
4. Requirements 4. Requirements
This section lists and discusses a number of potential requirements. This section lists and discusses a number of potential requirements.
However, it is not difficult to realize that it is in fact possible However, it is not difficult to realize that it is in fact possible
to put requirements that makes the set of feasible solutions an empty to put requirements that makes the set of feasible solutions an empty
set. It is thus necessary to consider which requirements that are set. It is thus necessary to consider which requirements that are
essential to fulfil and which can be compromised on to arrive at a essential to fulfil and which can be compromised on to arrive at a
solution. solution.
4.1. Support Use of Multiple RTP Sessions Support Use of Multiple RTP Sessions: As stated in the RTP
specification [RFC3550], "The distinguishing feature of an RTP
Section 3.3 discusses a number of reasons why an application might session is that each maintains a full, separate space of SSRC
like to have multiple RTP sessions. Considering the motivations for identifiers [...]. The set of participants included in one RTP
this work this is an absolute requirement. We also are of the session consists of those that can receive an SSRC identifier
opinion that the session provided by the solution needs to fulfil the transmitted by any one of the participants either in RTP as the
definition in the RTP [RFC3550] specification: SSRC or a CSRC [...] or in RTCP". Accordingly, any mechanism to
multiplex several RTP sessions onto a single transport-layer flow
"The distinguishing feature of an RTP session is that each needs to allow each RTP session to use the complete SSRC space,
maintains a full, separate space of SSRC identifiers (defined independent of any other RTP sessions multiplexed onto that
next). The set of participants included in one RTP session transport-layer flow.
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
transport need to be able to use the same SSRC value. This is a
absolute requirement, for two reasons:
1. To avoid mandating SSRC assignment rules that are coordinated As a corollary of the above, two different RTP sessions that are
between the sessions. If the RTP sessions multiplexed together being multiplexed onto the same transport-layer flow need to be
need to have unique SSRC values, then additional code that works able to use the same SSRC value. This is a absolute requirement,
between RTP Sessions is needed in the implementations. Thus for two reasons. Firstly, to avoid mandating SSRC assignment
raising the bar for implementing this solution. In addition, if rules that are coordinated between the sessions. If the RTP
one gateways between parts of a system using this multiplexing sessions multiplexed together need to have unique SSRC values,
and parts that aren't multiplexing, the part that isn't then additional code that works between RTP Sessions is needed in
multiplexing also needs to fulfil the requirements on how SSRC is the implementations. Thus raising the bar for implementing this
assigned or force the gateway to translate SSRCs. Translating solution. In addition, if one gateways between parts of a system
SSRC is actually hard as it requires one to understand the using this multiplexing and parts that aren't multiplexing, the
semantics of all current and future RTP and RTCP extensions. part that isn't multiplexing also needs to fulfil the requirements
on how SSRC is assigned or force the gateway to translate SSRCs.
Translating SSRC is actually hard as it requires one to understand
the semantics of all current and future RTP and RTCP extensions.
Otherwise a barrier for deploying new extensions is created. Otherwise a barrier for deploying new extensions is created.
Second, there are some few RTP extensions that currently rely on
being able to use the same SSRC in different RTP sessions,
including parity FEC [RFC5109], RTP Retransmission in session mode
[RFC4588], and some forms of layered coding.
2. There are some few RTP extensions that currently rely on being Support the Secure RTP (SRTP) Profile: SRTP [RFC3711] is one of the
able to use the same SSRC in different RTP sessions: most commonly used security solutions for RTP. In addition, it is
the only one defined by IETF that is integrated into RTP. This
* XOR FEC (RFC5109) integration has several aspects that needs to be considered when
designing a solution for multiplexing RTP sessions on the same
* RTP Retransmission in session mode (RFC4588) lower layer transport.
* Certain Layered Coding
4.3. SRTP
SRTP [RFC3711] is one of the most commonly used security solutions
for RTP. In addition, it is the only one defined by IETF that is
integrated into RTP. This integration has several aspects that needs
to be considered when designing a solution for multiplexing RTP
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.
also normally relies on the lower layer transport to identify the It also normally relies on the lower layer transport to
session. It uses the Master Key Indicator (MKI), if present, to identify the session. It uses the Master Key Indicator
determine which key set is to be used. Then the SSRC and sequence (MKI), if present, to determine which key set is to be used.
number are used by most crypto suites, including the most common Then the SSRC and sequence number are used by most crypto
use of AES Counter Mode, to actually generate the correct cipher suites, including the most common use of AES Counter Mode,
stream. to actually generate the correct cipher stream.
Unencrypted Headers: SRTP has chosen to leave the RTP headers and Unencrypted Headers: SRTP has chosen to leave the RTP headers and
the first two 32-bit words of the first RTCP header unencrypted, the first two 32-bit words of the first RTCP header
to allow for both header compression and monitoring to work also unencrypted, to allow for both header compression and
in the presence of encryption. As these fields are in clear text monitoring to work also in the presence of encryption. As
they are used in most crypto suites for SRTP to determine how to these fields are in clear text they are used in most crypto
protect or recover the plain text. suites for SRTP to determine how to protect or recover the
plain text.
It is here important to contrast SRTP against a set of other possible
protection mechanisms. DTLS, TLS, and IPsec are all protecting and
encapsulating the entire RTP and RTCP packets. They don't perform
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
them, but possibly not to SRTP. Thus the impact on SRTP operations
has to be considered when defining a mechanism.
4.4. Don't Redefine Used Bits
As the core of RTP is in use in many systems and has a really large It is here important to contrast SRTP against a set of other
deployment story and numerous implementations, changing any of the possible protection mechanisms. DTLS, TLS, and IPsec are all
field definitions is highly problematic. First of all, the protecting and encapsulating the entire RTP and RTCP packets.
implementations need to change to support this new semantics. They don't perform any partial operations on the RTP and RTCP
Secondly, you get a large transition issue when you have some session packets. Any change that is considered to be part of the RTP and
participants that support the new semantics and some that don't. RTCP packet is transparent to them, but possibly not to SRTP.
Combing the two behaviours in the same session can force the Thus the impact on SRTP operations has to be considered when
deployment of costly and less than perfect translation devices. defining a mechanism.
4.5. Firewall Friendly Support Legacy Implementations of RTP and RTCP: The core of RTP is
in use in many systems, and has an extremely large deployed base
with numerous implementations. Changing any of the RTP or RTCP
packet definitions, outside of defined extension points, is highly
problematic. First of all, the implementations need to change to
support this new semantics. Secondly, you get a large transition
period when you have some session participants that support the
new semantics and some that don't. Combing the two behaviours in
the same session can force the deployment of costly and less than
perfect translation devices.
It is desirable that current Firewalls will accept the solutions as Support NAT and Firewall Traversal: It is desirable that current NAT
devices, firewalls, and application level gateways will accept
multiplexed packets from several RTP sessions as they accept
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
also necessary to be aware that a change that will make most deep is also necessary to be aware that a change that will make most
inspecting firewall consider the packet as not valid RTP/RTCP will deep inspecting firewall consider the packet as not valid RTP/RTCP
have a more difficult deployment story. will have a more difficult deployment story.
4.6. Monitoring and Reporting
It is desirable that a third party monitor can still operate on the Support Monitors and Reporting Tools: It is desirable that a third
multiplexed RTP Sessions. It is however likely that they will party monitor can still operate on the multiplexed RTP Sessions.
require an update to correctly monitor and report on multiplexed RTP It is however likely that they will require an update to correctly
Sessions. monitor and report on multiplexed RTP 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 can be impacted by a change of the fields. selector filters. These can be impacted by a change of the
An observation is that many such systems are usually quite rapidly fields. An observation is that many such systems are usually
updated to consider new types of standardized or simply common packet quite rapidly updated to consider new types of standardized or
formats. simply common packet formats.
4.7. Usable Also Over Multicast
It is desirable that a solution can be used if RTP and RTCP packets
are sent over multicast, both Any Source Multicast (ASM) and Single
Source Multicast (SSM). The reason for this requirement is to allow
a system using RTP to use the same configuration regardless of the
transport being done over unicast or multicast. In addition,
multicast can't be claimed to have an issue with using multiple
ports, as each multicast group has a complete port space scoped by
address.
4.8. Incremental Deployment Support Use of IP Multicast: It is desirable that a solution can be
used if RTP and RTCP packets are sent over multicast, both Any
Source Multicast (ASM) and Single Source Multicast (SSM). The
reason for this requirement is to allow a system using RTP to use
the same configuration regardless of the transport being done over
unicast or multicast. In addition, multicast can't be claimed to
have an issue with using multiple ports, as each multicast group
has a complete port space scoped by address.
A good solution has the property that in topologies that contains RTP Support Incremental Deployment: A good solution has the property
mixers or Translators, a single session participant can enable that in topologies that contains RTP mixers or Translators, a
multiplexing without having any impact on any other session single session participant can enable multiplexing without having
participants. Thus a node ought to be able to take a multiplexed any impact on any other session participants. Thus a node ought
packet and then easily send it out with minimal or no modification on to be able to take a multiplexed packet and then easily send it
another leg of the session, where each RTP session is transported out with minimal or no modification on another leg of the session,
over its own lower-layer transport. It also needs to be as easy to where each RTP session is transported over its own lower-layer
do the reverse forwarding operation. transport. It also needs to be as easy to do the reverse
forwarding operation.
5. Design Considerations 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 We propose a solution based around a shim layer, inserted between the
transport layer headers and the RTP layer headers, to demultiplex
separate RTP sessions. The design rationale for using a shim layer
header, as opposed to other demultiplexing points, is discussed in
Appendix A. In the following we discuss design considerations
regarding placement and use of the shim layer header.
5.1. Location of Multiplexing Shim Header
A major question affecting the SHIM is the location of the SHIM A major question affecting the SHIM is the location of the SHIM
header providing the Identifier of the session the packet relate to. header providing the Identifier of the session the packet relate to.
This section will discuss in detail about the impact of making the This section will discuss in detail about the impact of making the
different choices. different choices.
Identified aspects to consider are: Identified aspects to consider are:
Possibility to Process: A prefixed shim header, i.e. between the Possibility to Process: A prefixed shim header, i.e. between the
transport protocol and the RTP/RTCP packet header has the transport protocol and the RTP/RTCP packet header has the
skipping to change at page 10, line 36 skipping to change at page 9, line 35
c. Monitoring c. Monitoring
Many routers or similar devices can only read and process the Many routers or similar devices can only read and process the
first N bytes of the whole packet, where N is commonly on the first N bytes of the whole packet, where N is commonly on the
order of 64-128 bytes. Any other type of processing means putting order of 64-128 bytes. Any other type of processing means putting
the packet on the slow path. Thus a prefixed solution enables the packet on the slow path. Thus a prefixed solution enables
this processing while a postfixed solution will most likely this processing while a postfixed solution will most likely
forever prevent this type of devices to process it. forever prevent this type of devices to process it.
Legacy Processing: Packets or at least flows of the type IP/UDP/RTP Legacy Processing: RTP packets contain very few fixed bits and are
can in many cases be identified in Deep Packet Inspection, difficult to distinguish using deep packet inspection without
Firewalls or other network entities that concern themselves with access to the signalling channel, or without keeping per-flow
trying determine what traffic that flows in a particular packet. state to correlate changes in the (presumed) RTP headers across
These nodes can clearly be updated but until they can create a packets to gain confidence that the flow is of the expected type.
barrier to deployment. Thus a post fix gives likely the least Firewalls, application-level gateways, and other network entities
resistance for initial deployment. However, also for postfix that concern themselves with trying to track RTP flows will need
location the deployment can be hindered in cases multiple RTP to be updated. This can create a barrier to deployment. Using a
sessions using the same SSRC values due to irregular behaviour of postfix shim likely gives the least resistance for initial
the fields for what the third party believes is one media stream deployment. However, even with a postfix shim, deployment can be
rather than multiple ones. The prefixed will however maintain the hindered when multiple RTP sessions using the same SSRC values,
long-term capabilities of such devices assuming they can be since this will appear to give irregular behaviour of the fields
updated to include the SHIM header as part of the classification. for what the third party believes is one media stream, when it is
actually several multiple streams. The use of a prefixed shim
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 Header Compression: The different header compression techniques that
has been developed compresses IP/UDP/RTP as complete combination. has been developed compresses IP/UDP/RTP as complete combination.
If one instead have a IP/UDP/SHIM/RTP then the compression for the If one instead have a IP/UDP/SHIM/RTP then the compression for the
full set might not work or poorly. Instead only IP/UDP header full set might not work or poorly. Instead only IP/UDP header
compression is likely to be applied. Thus a prefix will loose compression is likely to be applied. Thus a prefix will loose
some compression efficiency until compression profiles for IP/UDP/ some compression efficiency until compression profiles for IP/UDP/
SHIM/RTP has been developed, implemented and deployed. Postfix SHIM/RTP has been developed, implemented and deployed. Postfix
don't have that issue, but nor can it ever gain anything from don't have that issue, but nor can it ever gain anything from
header compression which an prefixed solution could once an header compression which an prefixed solution could once an
updated profile is deployed. Postfix also will have reduced updated profile is deployed. Postfix also will have reduced
efficiency compressing sessions when the same SSRC is used in two efficiency compressing sessions when the same SSRC is used in two
different RTP sessions as the RTP header fields like sequence different RTP sessions as the RTP header fields like sequence
skipping to change at page 11, line 18 skipping to change at page 10, line 20
some compression efficiency until compression profiles for IP/UDP/ some compression efficiency until compression profiles for IP/UDP/
SHIM/RTP has been developed, implemented and deployed. Postfix SHIM/RTP has been developed, implemented and deployed. Postfix
don't have that issue, but nor can it ever gain anything from don't have that issue, but nor can it ever gain anything from
header compression which an prefixed solution could once an header compression which an prefixed solution could once an
updated profile is deployed. Postfix also will have reduced updated profile is deployed. Postfix also will have reduced
efficiency compressing sessions when the same SSRC is used in two efficiency compressing sessions when the same SSRC is used in two
different RTP sessions as the RTP header fields like sequence different RTP sessions as the RTP header fields like sequence
number, etc., will not behave as expected and need frequent number, etc., will not behave as expected and need frequent
explicit updates. explicit updates.
The question of a prefixed or a postfixed header comes down to a The question of a prefixed or a postfixed shim header comes down to a
trade-off between long term usability and deployment issues: trade-off between long term usability and deployment issues. A
prefixed shim offers a good long term possibility to adapt any
Prefixed: Long term good possibility to adapt any network function network function that needs to take the shim header into account, but
that needs to take the SHIM header into account. At the same time at the same time any function that tries to analyse packets might
any function that tries to analyse packets and because of that block the packets and hinder deployment. A postfixed shim will
might block the packets will be a hinder to deployment. likely have the best short-term deployment possibilities, but long
term this choice will likely prevent many network nodes that like to
Postfixed: This solution will likely short term have the best be capable of separating the RTP sessions being multiplexed together
possibilities to deploy successfully. However, long term this from successfully doing that. After discussion in the working group
choice will likely prevent many network nodes that like to be it has been determined that a prefixed shim is the preferred
capable of separating the RTP sessions being multiplexed together solution.
from successfully doing that.
After discussion in the working group it has been determined that
prefixed is the preferred solution.
5.2. ICE and DTLS-SRTP Integration 5.2. ICE and DTLS-SRTP Integration
When using ICE [RFC5245] or DTLS-SRTP [RFC5764] or both with RTP When using ICE [RFC5245] or DTLS-SRTP [RFC5764] or both with RTP
there exist the issue that RTP, STUN [RFC5389] and DTLS-SRTP are there exist the issue that RTP, STUN [RFC5389] and DTLS-SRTP are
simultaneously in use over the same lower layer transport flow, like simultaneously in use over the same lower layer transport flow, like
UDP. This multiplexing is based on the value of the first byte of UDP. This multiplexing is based on the value of the first byte of
the lower layer transport payload as discussed in Section 5.1.2 of the lower layer transport payload as discussed in Section 5.1.2 of
DTLS-SRTP [RFC5764]. DTLS-SRTP [RFC5764].
The replacement of a single RTP session with the multiple RTP The replacement of a single RTP session with the multiple RTP
sessions identified by a SHIM ought not be misidentified to be either sessions identified by a SHIM ought not be misidentified to be either
STUN or DTLS-SRTP or any other protocol intending to take the STUN or DTLS-SRTP or any other protocol intending to take the
available free code-points in the range 193-255 (Decimal). Thus a available free code-points in the range 193-255 (Decimal). Thus a
prefixed SHIM needs to have its first byte have the two first bits prefixed SHIM needs to have its first byte have the two first bits
set to 10 (Binary). Having the SHIM share the identity of RTP is not set to 10 (Binary). Having the SHIM share the identity of RTP is not
an issue as there has to be mutual agreement that the SHIM is used an issue as there has to be mutual agreement that the SHIM is used
instead of RTP. instead of RTP.
Note: This limits a single byte SHIM to only allow a maximum of 64
RTP sessions over a single transport flow.
5.3. Signalling Fall Back 5.3. Signalling Fall Back
Both SIP and WebRTC applications use SDP signalling to describe the
RTP sessions and transport layer connections used in a call. It is
therefore necessary to consider how to signal multiple RTP sessions
multiplexed onto a single lower layer transport within SDP. It is
also important to consider backwards compatibility with any legacy
applications that do not understand any proposed SDP extension.
There exist an important aspect in how the SDP signalling functions, An SDP session description is built up using media ("m=") lines
especially Offer/Answer [RFC3264]. The initial idea for the describing media flows, with associated connection ("c=") lines
signalling was to build on top of bundle describing the transport layer flows. In the usual offer/answer use
[I-D.ietf-mmusic-sdp-bundle-negotiation] which in its default of SDP the communicating parties use a single c= line to represent
function negotiate multiple media types over one RTP session the IP-layer path, with one m= line per type of media, running each
[I-D.ietf-avtcore-multi-media-rtp-session]. If the signalling for type of media on a separate transport layer port, and hence a
the solution that main purpose is to enable multiple RTP sessions separate RTP session. This gives a clean separation of RTP sessions,
results in those cases the peer doesn't support this specification but requires multiple transport layer flows to be used, complicating
the communicating peer can end up in single RTP session if the peer NAT/firewall traversal.
supports that.
We consider it important that in the signalling design that the
application developer can decide what type of fall back 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 has to 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 fall back to independent transports
4. Like 2, but where the peer doesn't support SHIM and wants to fall
back to multiple BUNDLED sessions over independent transports.
In addition it needs to be possible to have multiple different
transports where each is a SHIM multiplex. This is to support
decomposed end-points or cases where certain media traffic has to go
to a central processing node while others goes directly to a peer.
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 fall back is indicated by providing explicit BUNDLE The SDP bundle extension [I-D.ietf-mmusic-sdp-bundle-negotiation]
grouping in addition to the SHIM when the fall back from SHIM is to provides a way to signal that several m= lines are to be bundled
BUNDLE. together into a single RTP session running on a single transport
layer port. This is essentially the opposite semantic to the one we
want: it combines seemingly disparate RTP sessions into one using a
single transport layer flow, while we seek to use a single transport
layer flow, but keep the sessions separate. Accordingly, we do not
re-use the bundle mechanism.
Note: Signalling solution is awaiting resolution of design path for We do, however, want to allow the case where an application would
bundle and will then consider that solution and issues raised. prefer to use separate RTP sessions multiplexed over a single lower
layer transport, because that simplifies processing, but fall back to
using the bundle mechanism if necessary. Similarly, fall back to
using separate RTP sessions on separate transport layer flows needs
to be supported.
6. Specification 6. Specification
This section contains the specification of the RTP session This section contains the specification of the RTP session
multiplexing SHIM, using an explicit session identifier of the multiplexing SHIM, using an explicit session identifier of the
encapsulated payload. encapsulated payload.
6.1. Shim Layer 6.1. Shim Layer
This solution is based on a shim layer that is inserted in the stack 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 between the RTP and RTCP packets and the transport layer being used
being used by the RTP sessions. Thus the layering looks like the by the RTP sessions. Thus the layering is as shown in Figure 1.
following:
+---------------------+ +-------------------------+
| RTP / RTCP Packet | | RTP / RTCP Packet |
+---------------------+ +-------------------------+
| Session ID Layer | | Session ID Layer |
+---------------------+ +-------------------------+
| Transport layer | | Transport Layer Header |
+---------------------+ +-------------------------+
| Network Layer Header |
+-------------------------+
Stack View with Session ID SHIM Figure 1: Stack view with session ID layer shim
The above stack is in fact a layered one as it does allow multiple 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. RTP Sessions to be multiplexed on top of the Session ID shim layer.
This enables the example presented in Figure 1 where four sessions, 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 S1-S4, are sent over the same Transport layer, and where the Session
layer will combine and encapsulate them with the session ID on ID layer will combine and encapsulate them with the session ID on
transmission and separate and decapsulate them on reception. transmission and separate and decapsulate them on reception.
+-------------------+ +-------------------------+
| S1 | S2 | S3 | S4 | | S1 | S2 | S3 | S4 |
+-------------------+ +-------------------------+
| Session ID Layer | | Session ID Layer |
+-------------------+ +-------------------------+
| Transport layer | | Transport Layer Header |
+-------------------+ +-------------------------+
Figure 1: Multiple RTP Session On Top of Session ID Layer | Network Layer Header |
+-------------------------+
Figure 2: Example with four RTP sessions on top of session ID layer
The Session ID layer encapsulates one RTP or RTCP packet from a given The Session ID layer encapsulates one RTP or RTCP packet from a given
RTP session and prefixes the 2-byte Session ID layer to the packet. RTP session and prefixes a 4-octet Session ID layer shim header to
The Session ID layer is depicted below (Figure 2) and consists of the packet. The Session ID layer shim header is depicted in Figure 3
first 2 fixed bit values (10b) followed by a 14 bits unsigned integer and comprises a 2 bit fixed header (10b), 14 reserved bits, and a 16
field with the Session ID (SID) value. bits unsigned integer field with the Session ID (SID) value.
0 1 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0| Session ID (SID) | |1 0| reserved | Session ID (SID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Session ID layer Figure 3: Session ID layer shim header
Each RTP session being multiplexed on top of a given transport layer Each RTP session being multiplexed on top of a given transport layer
is assigned either a single or a pair of unique SID in the range is assigned either a single or a pair of unique SID in the range
0-16383. The reason for assigning a pair of SIDs to a given RTP 0-65535. The reason for assigning a pair of SIDs to a given RTP
session are for RTP Sessions that doesn't support "Multiplexing RTP session are for RTP Sessions that doesn't support "Multiplexing RTP
Data and Control Packets on a Single Port" [RFC5761] to still be able Data and Control Packets on a Single Port" [RFC5761] to still be able
to use a single 5-tuple. The reasons for supporting this extra to use a single 5-tuple. The reasons for supporting this extra
functionality is that RTP and RTCP multiplexing based on the payload functionality is that RTP and RTCP multiplexing based on the payload
type/packet type fields enforces certain restrictions on the RTP type/packet type fields enforces certain restrictions on the RTP
sessions. These restrictions might not be acceptable. As this sessions. These restrictions might not be acceptable. As this
solution does not have these restrictions, performing RTP and RTCP solution does not have these restrictions, performing RTP and RTCP
multiplexing in this way has benefits. multiplexing in this way has benefits.
Each Session ID value space is scoped by the underlying transport Each Session ID value space is scoped by the underlying transport
protocol. Common transport protocols like UDP [RFC0768], DCCP protocol. Common transport protocols like UDP [RFC0768], DCCP
[RFC4340], TCP [RFC0793], and SCTP [RFC4960] can all be scoped by one [RFC4340], TCP [RFC0793], and SCTP [RFC4960] can all be scoped by one
or more 5-tuple (Transport protocol, source address and port, or more 5-tuple (Transport protocol, source address and port,
destination address and port). The case of multiple 5-tuples occur destination address and port). The case of multiple 5-tuples occur
in the case of multi-unicast topologies, also called meshed in the case of multi-unicast topologies, also called meshed
multiparty RTP sessions or in case any application would need more multiparty RTP sessions or in case any application would need more
than 8192 RTP sessions. than 32768 RTP sessions.
0 1 2 3 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 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
+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0| Session ID | |1 0| reserved | Session ID (SID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | | |V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | | | timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | | | synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | | | contributing source (CSRC) identifiers | |
| .... | | | .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
skipping to change at page 15, line 19 skipping to change at page 13, line 45
| | payload ... | | | | payload ... | |
| | +-------------------------------+ | | | +-------------------------------+ |
| | | RTP padding | RTP pad count | | | | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ | | ~ SRTP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : | | : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+- Encrypted Portion* Authenticated Portion ---+ +- Encrypted Portion* Authenticated Portion ---+
Figure 3: SRTP Packet encapsulated by Session ID Layer Figure 4: SRTP Packet encapsulated by Session ID Layer
0 1 2 3 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 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
+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0| Session ID | |1 0| reserved | Session ID (SID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P| RC | PT=SR or RR | length | | |V=2|P| RC | PT=SR or RR | length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| SSRC of sender | | | SSRC of sender | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| ~ sender info ~ | | ~ sender info ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ report block 1 ~ | | ~ report block 1 ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ report block 2 ~ | | ~ report block 2 ~ |
skipping to change at page 16, line 6 skipping to change at page 14, line 32
| ~ ... ~ | | ~ ... ~ |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| |E| SRTCP index | | | |E| SRTCP index | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTCP MKI (OPTIONAL) ~ | | ~ SRTCP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag : | | : authentication tag : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+-- Encrypted Portion Authenticated Portion -----+ +-- Encrypted Portion Authenticated Portion -----+
Figure 4: SRTCP packet encapsulated by Session ID layer Figure 5: SRTCP packet encapsulated by Session ID layer
The processing in a receiver when the Session ID layer is present The processing in a receiver when the Session ID layer is present
will be to will be to
1. Pick up the packet from the lower layer transport 1. Pick up the packet from the lower layer transport
2. Inspect the SID field value 2. Inspect the SID field value
3. Strip the SID field from the packet 3. Strip the SID field from the packet
4. Forward it to the (S)RTP Session context identified by the SID 4. Forward it to the (S)RTP Session context identified by the SID
value value
6.2. Signalling 6.2. Signalling
Note: This section might need updating as the direction of the There are several aspects to negotiating the use of multiple RTP
solution for Bundle has settled and the impact of the raised issues sessions multiplexing onto a single transport layer flow within SDP.
has been analysed. Firstly, the SDP offer needs to indicate the desire the use the shim-
based multiplexing scheme and suggest a transport layer port for the
The use of the Session ID layer needs to be explicitly agreed on multiplex. Then, if the answering party agrees to use the shim, they
between the communicating parties. Each RTP Session the application need to agree on the transport layer port to use, and assign session
uses needs, in addition to the regular configuration such as payload ID values for the individual RTP sessions. This all needs to be done
types, RTCP extension, etc., have both the underlying 5-tuple (source in a manner that allows graceful fall back to separate RTP sessions,
address and port, destination address and port, and transport or a single bundled RTP session.
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 This section defines how to negotiate the use of the Session ID shim
layer, using the Session Description Protocol (SDP) Offer/Answer layer, using the SDP [RFC4566] offer/answer model [RFC3264]. A new
mechanism [RFC3264]. A new SDP grouping semantics is defined "SHIM" SDP grouping semantics is defined, "SHIM", along with a new media
and a new media-level SDP attribute, 'session-mux-id. The attribute type to represent the shim layer. The grouping semantics allow each
allows each media description ("m=" line) associated with a 'SHIM' media description ("m=" line) associated with a 'SHIM' group to be
group to be identified in which RTP session it belongs. identified, and associated with the multiplexed transport flow.
The 'session-mux-id' attribute is included for a media description, When it is desired to use multiple RTP sessions multiplexed over a
in order to indicate the Session ID for that particular media single lower layer transport flow, the SDP offer will contain one
description. Every media description that shares a common attribute "m=" line for each RTP session, plus one additional "m=" line
value is assumed to be part of a single RTP session. An SDP Offerer representing the transport layer flow to be used for the multiplex.
MUST include the 'session-mux-id' attribute for every media The "m=" lines that represent the media will flows be created as-if
description associated with a 'SHIM' group. If the SDP Answer does the multiplex was not present, with transport layer ports assigned in
not contain the SHIM group, the SDP Offerer MUST NOT use SHIM based the usual manner. The "m=" line representing the multiplex will also
layering. However, if that is separate RTP sessions or BUNDLE is have a transport layer port assigned, and will use the "application/
determined on what was present in the offer and answer. This will rtp-shim" media type running over UDP (i.e., it will be signalled as
depend on what the offering party likes to happen. If they want a "m=application <port> udp rtp-shim" in the SDP). All the "m=" lines
failure to negotiate a SHIM, instead can be one or more bundle groups representing the media flows and the multiplexing shim will be part
then also the BUNDLE grouping is included in the offer. If the SDP of an SDP group, with "SHIM" semantics.
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- There MUST be exactly one "m=" line representing an RTP multiplex in
id' attribute in an SDP Answer, unless they where included in the SDP each "SHIM" group in the SDP offer. If the offer contains more than
Offer. one "m=" line representing an RTP multiplex in a single "SHIM" group,
then the answering party MUST reject all the RTP multiplexes in that
"SHIM" group. A "SHIM" group that does not include any "m=" line
representing an RTP multiplex is malformed; the answering party MUST
reject all "m=" lines in that "SHIM" group.
The attribute has the following ABNF [RFC5234] definition. If the answering party does not understand, or does not want to use,
the RTP multiplexing shim, it will reject the "m=" line for the flow
representing the multiplex. This is be done by setting the port for
that "m=" line to zero in the answer. The endpoints will then fall
back to using separate RTP sessions for each "m=" line, with separate
transport layer flows for each on the assigned ports.
Session-mux-id-attr = "a=session-mux-id:" SID *SID-prop If the answering party chooses to use the multiplexing shim, it will
SID = SID-value / SID-pairs return an answer that includes a valid port for the multiplex. The
SID-value = 1*3DIGIT / "NoN" ports for the other media lines in the SHIM group that the answering
SID-pairs = SID-value "/" SID-value ; RTP/RTCP SIDs party wants to accept MUST be set to port 9 (the discard port) to
SID-prop = SP assignment-policy / prop-ext indicate that the media for those ports is to be sent as part of the
prop-ext = token "=" value multiplex (the intuition is that the separate port is discarded, and
assignment-policy = "policy=" ("tentative" / "fixed") only the multiplex remains). Ports for some "m=" lines in the SHIM
group MAY be set to zero to reject some or all of the flows in the
group.
The SHIM group SHALL contain all media descriptions that are intended (tbd: it is an open issue whether the answering party is allowed
to be sent over the same transport flow, independent of Session ID. to accept some "m=" lines from the SHIM group into the multiplex
For all media descriptions part of the same SHIM group the transport while sending others as separate flows on their own ports)
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 If the multiplex was accepted, multiplexed media corresponding to the
SHALL be treated the same way as if they where part of a BUNDLE "m=" lines whose port was set to 9 in the answer will start to flow.
group, independently if that is indicated or not in the SDP. This multiplexed media MUST use the shim on the transport layer ports
corresponding to the "m=" line of the multiplexing shim. The session
identifiers used in the shim MUST match the ports that were included
in the "m=" lines in the offer. The transport layer ports included
in those "m=" lines MUST NOT be used for media, and the offering
party SHOULD issue a follow-up offer closing down the "m=" lines used
for those ports (i.e., setting the ports in their "m=" line to 9) and
keeping just the multiplex.
The SID property "policy" is used in negotiation by an end-point to (tbd: an alternative would be for the answer to reject all except
indicate if the session ID values are merely a tentative suggestion the multiplex stream by setting their ports to zero, but include
or if they need to have these values. This is used when negotiating an attribute for each rejected "m=" line to indicate that if it is
SID for multi-party RTP sessions to support shared transports such as to form part of the multiplex. This can perhaps be expected to
multicast or RTP translators that are unable to produce renumbered work better with middleboxes, but is a more significant change to
SIDs on a per end-point basis. The normal behaviour is that the offer/answer processing at the endpoints.)
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 behaviours, both offerer and
answerer will indicate the tentative policy.
6.3. SRTP Key Management 6.3. SRTP Key Management
Key management for SRTP do needs discussion as we do cause multiple Key management for SRTP do needs discussion as we do cause multiple
SRTP sessions to exist on the same underlying transport flow. Thus SRTP sessions to exist on the same underlying transport flow. Thus
we need to ensure that the key management mechanism still are we need to ensure that the key management mechanism still are
properly associated with the SRTP session context it intends to key. properly associated with the SRTP session context it intends to key.
To ensure that we do look at the three SRTP key management mechanism To ensure that we do look at the three SRTP key management mechanism
that IETF has specified, one after another. that IETF has specified, one after another.
skipping to change at page 19, line 30 skipping to change at page 18, line 7
properties with Security Description in that is can be associated properties with Security Description in that is can be associated
with a particular media description in a SDP. As long as one avoids with a particular media description in a SDP. As long as one avoids
using the session level attribute one can be certain to correctly using the session level attribute one can be certain to correctly
associate the key exchange with a given SRTP/SRTCP context. associate the key exchange with a given SRTP/SRTCP context.
It does appear that MIKEY directly over a lower layer transport It does appear that MIKEY directly over a lower layer transport
protocol will have similar issues as DTLS. protocol will have similar issues as DTLS.
6.4. Examples 6.4. Examples
6.4.1. RTP Packet with Transport Header 6.4.1. Secure RTP Packet with Multiplexing Shim
The below figure contains an RTP packet with SID field encapsulated The figure below contains an example Secure RTP packet with the RTP
by a UDP packet (added UDP header). multiplexing shim header, encapsulated by a UDP packet. The RTP
multiplexing shim immediately follows the UDP header, and is followed
by the encapsulated secure RTP packet. The Secure RTP authentication
tag protects the RTP packet only; it does not authenticate the RTP
multiplexing shim or the UDP headers.
0 1 2 3 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 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 | | Source Port | Destination Port | U
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D
| Length | Checksum | | Length | Checksum | P
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0| Session ID | |1 0| reserved | Session ID (SID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | | |V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | | | timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | | | synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | | | contributing source (CSRC) identifiers | |
| .... | | | .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
skipping to change at page 20, line 19 skipping to change at page 19, line 5
| | | RTP padding | RTP pad count | | | | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ | | ~ SRTP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : | | : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+- Encrypted Portion* Authenticated Portion ---+ +- Encrypted Portion* Authenticated Portion ---+
SRTP Packet Encapsulated by Session ID Layer SRTP Packet Encapsulated by Session ID Layer
6.4.2. SDP Offer/Answer example 6.4.2. Basic RTP Multiplex Negotiation in SDP
6.4.2.1. Basic Example
This section contains SDP offer/answer examples. First one example
of a successful SHIM, and then two where fall back occurs. The fall
back option here is to fall back to individual transports, thus no
BUNDLE group.
In the below SDP offer, one audio and one video is being offered. This section contains SDP offer/answer examples. In the below SDP
The audio is using SID 0, and the video is using SID 1 to indicate offer, one audio and one video is being offered. The audio is using
that they are different RTP sessions despite being offered over the session identifier 10000, and the video is using session identifier
same 5-tuple. 10002. If the answer were to reject the "m=application...rtp-shim"
line, then separate RTP sessions would be set up for the audio and
video on ports 10000 and 10002 respectively.
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=group:SHIM foo bar a=group:SHIM foo bar baz
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=session-mux-id:0 policy=tentative
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=session-mux-id:1 policy=tentative
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=application 10004 udp rtp-shim
a=mid:baz
The SDP answer from an end-point that supports this BUNDLEing: The SDP answer from an end-point that supports the RTP multiplexing
shim follows. Note that the ports on the audio and video lines are
set to 9, to indicate that these flows are included in the multiplex.
The port of the m= line corresponding to the multiplex is set to the
transport port used for the multiplex.
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:SHIM foo bar a=group:SHIM foo bar baz
m=audio 20000 RTP/AVP 0 m=audio 9 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=session-mux-id:0 policy=tentative
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32 m=video 9 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=session-mux-id:1 policy=tentative
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=application 10004 udp rtp-shim
a=mid:baz
The SDP answer from an end-point that does not support this SHIM. The SDP answer from an end-point that does not support this SHIM.
The ports for the audio and video lines are kept, and the port is set
to 0 in the "m=" line corresponding to the multiplex.
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
m=audio 20000 RTP/AVP 0 a=group:SHIM foo bar baz
b=AS:200 m=audio 10000 RTP/AVP 0
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 b=AS:200
a=mid:foo a=mid:foo
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 m=video 10002 RTP/AVP 32
a=rtpmap:97 iLBC/8000
m=video 20000 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=audio 20002 RTP/AVP 100 m=application 0 udp rtp-shim
b=AS:100 a=mid:baz
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 6.4.3. Advanced RTP Multiplex Negotiation in SDP
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 (tbd: add more examples)
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 7. Open Issues
This work is still at a relatively early phase. This section This work is still at a relatively early phase. This section
contains a list of open issues where the author desires some input. contains a list of open issues where the author desires some input.
1. In Section 6.2 there is a discussion of which parameters that 1. In Section 6.2 there is a discussion of which parameters that
need to be configured. The scope of these rules and if they do need to be configured. The scope of these rules and if they do
make sense needs additional discussion. make sense needs additional discussion.
skipping to change at page 25, line 29 skipping to change at page 21, line 4
contains a list of open issues where the author desires some input. contains a list of open issues where the author desires some input.
1. In Section 6.2 there is a discussion of which parameters that 1. In Section 6.2 there is a discussion of which parameters that
need to be configured. The scope of these rules and if they do need to be configured. The scope of these rules and if they do
make sense needs additional discussion. make sense needs additional discussion.
2. Can we provide better control so that applications that doesn't 2. Can we provide better control so that applications that doesn't
desire fall back to single RTP session when Multiplexing shim desire fall back to single RTP session when Multiplexing shim
fails to be supported but Bundle is supported ends up with a fails to be supported but Bundle is supported ends up with a
better alternative? better alternative?
3. The details for how to do key-derivation, preferably in such a 3. The details for how to do key-derivation, preferably in such a
way that it can be reused by multiple key-management solutions way that it can be reused by multiple key-management solutions
like MIKEY and DTLS-SRTP like MIKEY and DTLS-SRTP
4. The signalling solution will be revisited when the BUNDLE 4. The signalling solution will be revisited when the BUNDLE
solution discussion has yield some result. solution discussion has yield some result.
8. IANA Considerations 8. IANA Considerations
(tbd: complete the details of the IANA registration for the SDP (tbd: register the application/rtp-shim media type)
attribute)
(tbd: register the "SHIM" semantics for the RTP grouping framework
9. Security Considerations 9. Security Considerations
The security properties of the Session ID layer is depending on what The security properties of the Session ID layer is depending on what
mechanism is used to protect the RTP and RTCP packets of a given RTP mechanism is used to protect the RTP and RTCP packets of a given RTP
session. If IPsec or transport layer security solutions such as DTLS session. If IPsec or transport layer security solutions such as DTLS
or TLS are being used then both the encapsulated RTP/RTCP packets and or TLS are being used then both the encapsulated RTP/RTCP packets and
the session ID layer will be protected by that security mechanism. the session ID layer will be protected by that security mechanism.
Thus potentially providing both confidentiality, integrity and source Thus potentially providing both confidentiality, integrity and source
authentication. If SRTP is used, the session ID layer will not be authentication. If SRTP is used, the session ID layer will not be
directly protected by SRTP. However, it will be implicitly integrity directly protected by SRTP. However, it will be implicitly integrity
protected (assuming the RTP/RTCP packet is integrity protected) as protected (assuming the RTP/RTCP packet is integrity protected) as
the only function of the field is to identify the session context. the only function of the field is to identify the session context.
Thus any modification of the SID field will attempt to retrieve the Thus any modification of the SID field will attempt to retrieve the
wrong SRTP crypto context. If that retrieval fails, the packet will wrong SRTP crypto context. If that retrieval fails, the packet will
be anyway be discarded. If it is successful, the context will not be anyway be discarded. If it is successful, the context will not
lead to successful verification of the packet. lead to successful verification of the packet.
10. Acknowledgements 10. Acknowledgements
This document is based on the input from various people, especially This memo is based on the input from various people, especially in
in the context of the RTCWEB discussion of how to use only a single the context of the RTCWEB discussion of how to use only a single
lower layer transport. The RTP and RTCP packet figures are borrowed lower layer transport. The RTP and RTCP packet figures are borrowed
from RFC3711. The SDP example is extended from the one present in from RFC3711. The SDP example is extended from the one present in
[I-D.ietf-mmusic-sdp-bundle-negotiation]. Eric Rescorla contributed [I-D.ietf-mmusic-sdp-bundle-negotiation]. Eric Rescorla contributed
the basic idea of optimizing the DTLS-SRTP key-management by the basic idea of optimizing the DTLS-SRTP key-management by
modifying the key derivation process. modifying the key derivation process.
The proposal in Appendix A.5 is original suggested by Colin Perkins. The proposal in Appendix A.5 is original suggested by Colin Perkins.
The idea in Appendix A.6 is from an Internet Draft The idea in Appendix A.6 is from an Internet Draft
[I-D.rosenberg-rtcweb-rtpmux] written by Jonathan Rosenberg et. al. [I-D.rosenberg-rtcweb-rtpmux] written by Jonathan Rosenberg et. al.
The proposal in Appendix A.3 is a result of discussion by a group of The proposal in Appendix A.3 is a result of discussion by a group of
people at IETF meeting #81 in Quebec. people at IETF meeting #81 in Quebec.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Multiplexing Negotiation Using Session Description "Multiplexing Negotiation Using Session Description
Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-
bundle-negotiation-04 (work in progress), June 2013. bundle-negotiation-05 (work in progress), October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
11.2. Informational References 11.2. Informational References
[I-D.ietf-avtcore-multi-media-rtp-session] [I-D.ietf-avtcore-multi-media-rtp-session]
Westerlund, M., Perkins, C., and J. Lennox, "Sending Westerlund, M., Perkins, C., and J. Lennox, "Sending
Multiple Types of Media in a Single RTP Session", draft- Multiple Types of Media in a Single RTP Session", draft-
ietf-avtcore-multi-media-rtp-session-03 (work in ietf-avtcore-multi-media-rtp-session-03 (work in
progress), July 2013. progress), July 2013.
[I-D.ietf-avtcore-multiplex-guidelines]
Westerlund, M., Perkins, C., and H. Alvestrand,
"Guidelines for using the Multiplexing Features of RTP to
Support Multiple Media Streams", draft-ietf-avtcore-
multiplex-guidelines-01 (work in progress), July 2013.
[I-D.lennox-rtcweb-rtp-media-type-mux] [I-D.lennox-rtcweb-rtp-media-type-mux]
Rosenberg, J. and J. Lennox, "Multiplexing Multiple Media Rosenberg, J. and J. Lennox, "Multiplexing Multiple Media
Types In a Single Real-Time Transport Protocol (RTP) Types In a Single Real-Time Transport Protocol (RTP)
Session", draft-lennox-rtcweb-rtp-media-type-mux-00 (work Session", draft-lennox-rtcweb-rtp-media-type-mux-00 (work
in progress), October 2011. in progress), October 2011.
[I-D.rosenberg-rtcweb-rtpmux] [I-D.rosenberg-rtcweb-rtpmux]
Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M., Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M.,
Rescorla, E., and T. Terriberry, "Multiplexing of Real- Rescorla, E., and T. Terriberry, "Multiplexing of Real-
Time Transport Protocol (RTP) Traffic for Browser based Time Transport Protocol (RTP) Traffic for Browser based
Real-Time Communications (RTC)", draft-rosenberg-rtcweb- Real-Time Communications (RTC)", draft-rosenberg-rtcweb-
rtpmux-00 (work in progress), July 2011. rtpmux-00 (work in progress), July 2011.
[I-D.westerlund-avtcore-multiplex-architecture]
Westerlund, M., Perkins, C., and H. Alvestrand,
"Guidelines for using the Multiplexing Features of RTP",
draft-westerlund-avtcore-multiplex-architecture-03 (work
in progress), February 2013.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[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. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007. 4960, September 2007.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, December 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
2010. 2010.
skipping to change at page 31, line 18 skipping to change at page 27, line 7
purpose would be an minor issue if the only difference between the purpose would be an minor issue if the only difference between the
RTP sessions is the media type. In this case, the application could RTP sessions is the media type. In this case, the application could
use the Payload Type field to identify the media type. The loss of use the Payload Type field to identify the media type. The loss of
the RTP Session functionality is however severe, if the application the RTP Session functionality is however severe, if the application
uses the RTP Session for separating different treatments, contexts uses the RTP Session for separating different treatments, contexts
etc. Then you would need additional signalling to bind the different etc. Then you would need additional signalling to bind the different
sources to groups which can help make the necessary distinctions. sources to groups which can help make the necessary distinctions.
However, the loss of the RTP session as separator is not the only However, the loss of the RTP session as separator is not the only
issue with this approach. The RTP Multiplexing Architecture issue with this approach. The RTP Multiplexing Architecture
[I-D.westerlund-avtcore-multiplex-architecture] discusses a number of [I-D.ietf-avtcore-multiplex-guidelines] discusses a number of issues
issues in Section 6.7. These include RTCP bandwidth differences, in Section 6.7. These include RTCP bandwidth differences,
limitations in the number of payload types, media aware RTP mixers limitations in the number of payload types, media aware RTP mixers
and interactions with Legacy end-points. and interactions with Legacy end-points.
Additional attention needs to be placed on this important aspect. In Additional attention needs to be placed on this important aspect. In
multi-party situations using central nodes there exist some multi-party situations using central nodes there exist some
difficulties in having a legacy implementation using multiple RTP difficulties in having a legacy implementation using multiple RTP
sessions interworking with an end-point having only a single RTP sessions interworking with an end-point having only a single RTP
session across the central node. The main reason is the fact that session across the central node. The main reason is the fact that
the one using single session with multiple media types has only one the one using single session with multiple media types has only one
SSRC space, while the other end-points have multiple spaces. Thus SSRC space, while the other end-points have multiple spaces. Thus
skipping to change at page 31, line 41 skipping to change at page 27, line 30
using the same SSRC value. This has both limitations, processing using the same SSRC value. This has both limitations, processing
overhead and the possibility of becoming an deployment obstacle for overhead and the possibility of becoming an deployment obstacle for
new RTP/RTCP extensions. new RTP/RTCP extensions.
This approach has been proposed in the RTCWeb context in This approach has been proposed in the RTCWeb context in
[I-D.lennox-rtcweb-rtp-media-type-mux] and [I-D.lennox-rtcweb-rtp-media-type-mux] and
[I-D.ietf-mmusic-sdp-bundle-negotiation]. These drafts describe how [I-D.ietf-mmusic-sdp-bundle-negotiation]. These drafts describe how
to signal multiple media streams multiplexed into a single RTP to signal multiple media streams multiplexed into a single RTP
session, and address some of the issues raised here and in session, and address some of the issues raised here and in
Section 6.7 of the RTP Multiplexing Architecture Section 6.7 of the RTP Multiplexing Architecture
[I-D.westerlund-avtcore-multiplex-architecture] draft. [I-D.ietf-avtcore-multiplex-guidelines] draft.
This method has several limitations that limits its usage as solution This method has several limitations that limits its usage as solution
in providing multiple RTP sessions on the same lower layer transport. in providing multiple RTP sessions on the same lower layer transport.
However, we acknowledge that there are some uses for which this However, we acknowledge that there are some uses for which this
method can be sufficient and which can accept the methods limitations method can be sufficient and which can accept the methods limitations
and downsides. The RTCWEB WG has a working assumption to support and downsides. The RTCWEB WG has a working assumption to support
this method. For more details of this method, see the relevant this method. For more details of this method, see the relevant
drafts under development. We do include this method in the drafts under development. We do include this method in the
comparison to provide a more complete picture of the pro and cons of comparison to provide a more complete picture of the pro and cons of
this method. this method.
skipping to change at page 33, line 46 skipping to change at page 29, line 35
encryption and finally generation of authentication tags are needed. encryption and finally generation of authentication tags are needed.
In addition the translator has to be part of the security context. In addition the translator has to be part of the security context.
This solution has no per packet overhead. This solution has no per packet overhead.
Appendix B. Comparison Appendix B. Comparison
This section compares the above potential solutions with the This section compares the above potential solutions with the
requirements. Motivations are provided in addition to a high level requirements. Motivations are provided in addition to a high level
metric of successfully, partially and failing to meet requirement. metric of successfully, partially and failing to meet requirement.
In the end a summary table (Figure 5) of the high level value are In the end a summary table (Figure 6) of the high level value are
provided. provided.
B.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.
requirement is how important it is to have as discussed in
Section 4.1.
B.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 4.2 two sub-requirements have been Based on the discussion in Section 4 two sub-requirements have been
derived. derived.
B.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 successful in Redefine the SSRC field. The other proposals are all successful in
meeting this requirement. meeting this requirement.
skipping to change at page 41, line 8 skipping to change at page 36, line 46
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 5: Summary Table of Evaluation (Successfully (S), Partially Figure 6: 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 post or prefixed multiplexing standardize a solution based on a post or prefixed multiplexing
field, i.e. a shim approach combined with the appropriate signalling field, i.e. a shim approach combined with the appropriate signalling
as described in Appendix A.2. as described in Appendix A.2.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
skipping to change at line 1875 skipping to change at page 37, line 23
Phone: +46 10 714 82 87 Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
URI: http://csperkins.org/
 End of changes. 114 change blocks. 
644 lines changed or deleted 484 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/