draft-westerlund-avtcore-transport-multiplexing-01.txt   draft-westerlund-avtcore-transport-multiplexing-02.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track C. Perkins Intended status: Standards Track C. Perkins
Expires: May 3, 2012 University of Glasgow Expires: September 13, 2012 University of Glasgow
October 31, 2011 March 12, 2012
Multiple RTP Session on a Single Lower-Layer Transport Multiple RTP Sessions on a Single Lower-Layer Transport
draft-westerlund-avtcore-transport-multiplexing-01 draft-westerlund-avtcore-transport-multiplexing-02
Abstract Abstract
This document specifies how multiple RTP sessions are to be This document specifies how multiple RTP sessions are to be
multiplexed on the same lower-layer transport, e.g. a UDP flow. It multiplexed on the same lower-layer transport, e.g. a UDP flow. It
discusses various requirements that have been raised and their discusses various requirements that have been raised and their
feasibility, which results in a solution with a certain feasibility, which results in a solution with a certain
applicability. A solution is recommended and that solution is applicability. A solution is recommended and that solution is
provided in more detail, including signalling and examples. provided in more detail, including signalling and examples.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Support Use of Multiple RTP Sessions . . . . . . . . . . . 4 3.1. Support Use of Multiple RTP Sessions . . . . . . . . . . . 5
3.2. Same SSRC Value in Multiple RTP Sessions . . . . . . . . . 4 3.2. Same SSRC Value in Multiple RTP Sessions . . . . . . . . . 5
3.3. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 6 3.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 7
3.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 6 3.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 7
3.6. Monitioring and Reporting . . . . . . . . . . . . . . . . 6 3.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 7
3.7. Usable Also Over Multicast . . . . . . . . . . . . . . . . 6 3.7. Usable Also Over Multicast . . . . . . . . . . . . . . . . 7
3.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 7 3.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 8
4. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 7 4. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Header Extension . . . . . . . . . . . . . . . . . . . . . 7 4.1. Header Extension . . . . . . . . . . . . . . . . . . . . . 8
4.2. Multiplexing Shim . . . . . . . . . . . . . . . . . . . . 8 4.2. Multiplexing Shim . . . . . . . . . . . . . . . . . . . . 9
4.3. Single Session . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Single Session . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Use the SRTP MKI field . . . . . . . . . . . . . . . . . . 10 4.4. Use the SRTP MKI field . . . . . . . . . . . . . . . . . . 11
4.5. Use an Octet in the Padding . . . . . . . . . . . . . . . 11 4.5. Use an Octet in the Padding . . . . . . . . . . . . . . . 12
4.6. Redefine the SSRC field . . . . . . . . . . . . . . . . . 11 4.6. Redefine the SSRC field . . . . . . . . . . . . . . . . . 12
5. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Specification . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Support of Multiple RTP Sessions Over Single Transport . . 13
6.1. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Enable Same SSRC Value in Multiple RTP Sessions . . . . . 13
6.2. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.1. Avoid SSRC Translation in Gateways/Translation . . . . 13
6.3. SRTP Key Management . . . . . . . . . . . . . . . . . . . 17 5.2.2. Support Existing Extensions . . . . . . . . . . . . . 14
6.3.1. Security Description . . . . . . . . . . . . . . . . . 17 5.3. Ensure SRTP Functions . . . . . . . . . . . . . . . . . . 14
6.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 18 5.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 15
6.3.3. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . 18 5.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 16
6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 17
6.4.1. RTP Packet with Transport Header . . . . . . . . . . . 18 5.7. Usable over Multicast . . . . . . . . . . . . . . . . . . 18
6.4.2. SDP Offer/Answer example . . . . . . . . . . . . . . . 19 5.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 18
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.9. Summary and Conclusion . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Specification . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6.1. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 6.2. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.3. SRTP Key Management . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 6.3.1. Security Description . . . . . . . . . . . . . . . . . 25
11.2. Informational References . . . . . . . . . . . . . . . . . 23 6.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3.3. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4.1. RTP Packet with Transport Header . . . . . . . . . . . 26
6.4.2. SDP Offer/Answer example . . . . . . . . . . . . . . . 27
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
11.2. Informational References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
There has been renewed interest for having a solution that allows There has been renewed interest for having a solution that allows
multiple RTP sessions [RFC3550] to use a single lower layer multiple RTP sessions [RFC3550] to use a single lower layer
transport, such as a bi-directional UDP flow. The main reason is the transport, such as a bi-directional UDP flow. The main reason is the
cost of doing NAT/FW traversal for each individual flow. ICE and cost of doing NAT/FW traversal for each individual flow. ICE and
other NAT/FW traversal solutions are clearly capable of attempting to other NAT/FW traversal solutions are clearly capable of attempting to
open multiple flows. However, there is both increased risk for open multiple flows. However, there is both increased risk for
failure and an increased cost in the creation of multiple flows. The failure and an increased cost in the creation of multiple flows. The
skipping to change at page 4, line 19 skipping to change at page 5, line 19
solution. solution.
3.1. Support Use of Multiple RTP Sessions 3.1. Support Use of Multiple RTP Sessions
This may at first glance appear to be an obvious requirement. This may at first glance appear to be an obvious requirement.
Although the authors are convinced it is a mandatory requirement for Although the authors are convinced it is a mandatory requirement for
a solution, it warrants some discussion around the implications of a solution, it warrants some discussion around the implications of
not having multiple RTP sessions and instead use a single RTP not having multiple RTP sessions and instead use a single RTP
session. session.
The main purpose of RTP sessions is to allow separation of streams The usage of multiple RTP sessions allow separation of media streams
that have different purposes, for example different media types. A that have different usages or purposes in an RTP based application,
big reason for establishing this is the knowledge that any SSRC for example to separate the video of a presenter or most important
within the session is supposed to be processed in a similar way. current talker from those of the listeners that not all end-points
receiver. Also separation for different processing based on media
types such as audio and video in end-points and central nodes. Thus
providing the node with the knowledge that any SSRC within the
session is supposed to be processed in a similar or same way.
For simpler cases, where the streams within each media type need the For simpler cases, where the streams within each media type need the
same processing, it is clearly possible to find other multiplex same processing, it is clearly possible to find other multiplex
solutions, for example based on the Payload Type and the differences solutions, for example based on the Payload Type and the differences
in encoding that the payload type allows to describe. This may in encoding that the payload type allows to describe. This may
anyhow be insufficient when you get into more advanced usages where anyhow be insufficient when you get into more advanced usages where
you have multiple sources of the same media type, but for different you have multiple sources of the same media type, but for different
purposes or as alternatives. For example when you have one set of usages or as alternatives. For example when you have one set of
video sources that shows session participants and another set of video sources that shows session participants and another set of
video sources that shares an application or slides, you likely want video sources that shares an application or slides, you likely want
to separate those streams for various reasons such as control, to separate those streams for various reasons such as control,
prioritization, QoS, methods for robustification, etc. In those prioritization, QoS, methods for robustification, etc. In those
cases, using the RTP session for separation of properties is a cases, using the RTP session for separation of properties is a
powerful tool. A tool with properties that need to be preserved when powerful tool. A tool with properties that need to be preserved when
providing a solution for how to use only a single lower-layer providing a solution for how to use only a single lower-layer
transport. transport.
For more discussion of the usage of RTP sessions verses other For more discussion of the usage of RTP sessions verses other
skipping to change at page 5, line 8 skipping to change at page 6, line 12
transport need to be able to use the same SSRC value. This is a transport need to be able to use the same SSRC value. This is a
strong requirement, for two reasons: strong requirement, for two reasons:
1. To avoid mandating SSRC assignment rules that are coordinated 1. To avoid mandating SSRC assignment rules that are coordinated
between the sessions. If the RTP sessions multiplexed together between the sessions. If the RTP sessions multiplexed together
must have unique SSRC values, then additional code that works must have unique SSRC values, then additional code that works
between RTP Sessions is needed in the implementations. Thus between RTP Sessions is needed in the implementations. Thus
raising the bar for implementing this solution. In addition, if raising the bar for implementing this solution. In addition, if
one gateways between parts of a system using this multiplexing one gateways between parts of a system using this multiplexing
and parts that aren't multiplexing, the part that isn't and parts that aren't multiplexing, the part that isn't
multiplexing must also fulfil the requirements on how SSRC is multiplexing must also fulfill the requirements on how SSRC is
assigned or force the gateway to translate SSRCs. Translating assigned or force the gateway to translate SSRCs. Translating
SSRC is actually hard as it requires one to understand the SSRC is actually hard as it requires one to understand the
semantics of all current and future RTP and RTCP extensions. semantics of all current and future RTP and RTCP extensions.
Otherwise a barrier for deploying new extensions is created. Otherwise a barrier for deploying new extensions is created.
2. There are some few RTP extensions that currently rely on being 2. There are some few RTP extensions that currently rely on being
able to use the same SSRC in different RTP sessions: able to use the same SSRC in different RTP sessions:
* XOR FEC (RFC5109) * XOR FEC (RFC5109)
skipping to change at page 5, line 31 skipping to change at page 6, line 35
* Certain Layered Coding * Certain Layered Coding
3.3. SRTP 3.3. SRTP
SRTP [RFC3711] is one of the most commonly used security solutions SRTP [RFC3711] is one of the most commonly used security solutions
for RTP. In addition, it is the only one recommended by IETF that is for RTP. In addition, it is the only one recommended by IETF that is
integrated into RTP. This integration has several aspects that needs integrated into RTP. This integration has several aspects that needs
to be considered when designing a solution for multiplexing RTP to be considered when designing a solution for multiplexing RTP
sessions on the same lower layer transport. sessions on the same lower layer transport.
Determing Crypto Context: SRTP first of all needs to know which Determining Crypto Context: SRTP first of all needs to know which
session context a received or to-be-sent packet relates to. It session context a received or to-be-sent packet relates to. It
also normally relies on the lower layer transport to identify the also normally relies on the lower layer transport to identify the
session. It uses the MKI, if present, to determine which key set session. It uses the MKI, if present, to determine which key set
is to be used. Then the SSRC and sequence number are used by most is to be used. Then the SSRC and sequence number are used by most
crypto suites, including the most common use of AES Counter Mode, crypto suites, including the most common use of AES Counter Mode,
to actually generate the correct cipher 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 unencrypted,
to allow for both header compression and monitoring to work also to allow for both header compression and monitoring to work also
skipping to change at page 6, line 26 skipping to change at page 7, line 29
3.5. Firewall Friendly 3.5. Firewall Friendly
It is desirable that current firewalls will accept the solutions as It is desirable that current firewalls will accept the solutions as
normal RTP packets. However, in the authors' opinion we can't let normal RTP packets. However, in the authors' opinion we can't let
the firewall stifle invention and evolution of the protocol. It is the firewall stifle invention and evolution of the protocol. It is
also necessary to be aware that a change that will make most deep also necessary to be aware that a change that will make most deep
inspecting firewall consider the packet as not valid RTP/RTCP will inspecting firewall consider the packet as not valid RTP/RTCP will
have more difficult deployment story. have more difficult deployment story.
3.6. Monitioring and Reporting 3.6. Monitoring and Reporting
It is desirable that a third party monitor can still operate on the It is desirable that a third party monitor can still operate on the
multiplexed RTP Sessions. It is however likely that they will multiplexed RTP Sessions. It is however likely that they will
require an update to correctly monitor and report on multiplexed RTP require an update to correctly monitor and report on multiplexed RTP
Sessions. Sessions.
Another type of function to consider is packet sniffers and their Another type of function to consider is packet sniffers and their
selector filters. These may be impacted by a change of the fields. selector filters. These may be impacted by a change of the fields.
An observation is that many such systems are usually quite rapidly An observation is that many such systems are usually quite rapidly
updated to consider new types of standardized or simply common packet updated to consider new types of standardized or simply common packet
skipping to change at page 9, line 34 skipping to change at page 10, line 34
streams in a single RTP session. Doing this avoids the need to de- streams in a single RTP session. Doing this avoids the need to de-
multiplex several sessions on a single transport, but at the cost of multiplex several sessions on a single transport, but at the cost of
losing the RTP session as a separator for different type of streams. losing the RTP session as a separator for different type of streams.
Lacking different RTP sessions to demultiplex incoming packets, a Lacking different RTP sessions to demultiplex incoming packets, a
receiver will have to dig deeper into the packet before determining receiver will have to dig deeper into the packet before determining
what to do with it. Care must be taken in that inspection. For what to do with it. Care must be taken in that inspection. For
example, you must be careful to ensure that each real media source example, you must be careful to ensure that each real media source
uses its own SSRC in the session and that this SSRC doesn't change uses its own SSRC in the session and that this SSRC doesn't change
media type. media type.
The loss of the RTP session as a purpose separator is likely not a The loss of the RTP session as a separator for different usages or
big issue if the only difference between RTP Sessions is the media purpose would be an minor issue if the only difference between the
type. In this case, you can use the Payload Type field to identify RTP sessions is the media type. In this case, the application could
the media type. The loss of the RTP Session functionality is more use the Payload Type field to identify the media type. The loss of
severe, however, if you actually use the RTP Session for separating the RTP Session functionality is however severe, if the application
different treatments, contexts etc. Then you would need additional uses the RTP Session for separating different treatments, contexts
signalling to bind the different sources to groups which can help etc. Then you would need additional signalling to bind the different
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
issue with this approach. The RTP Multiplexing Architecture
[I-D.westerlund-avtcore-multiplex-architecture] discusses a number of
issues in Section 6.7. These include RTCP bandwidth differences,
limitations in the number of payload types, media aware RTP mixers
and interactions with Legacy end-points.
Additional attention should be place on this important aspect. In
multi-party situations using central nodes there exist some
difficulties in having a legacy implementation using multiple RTP
sessions interworking with an end-point having only a single RTP
session across the central node. The main reason is the fact that
the one using single session with multiple media types has only one
SSRC space, while the other end-points have multiple spaces. Thus
translation may have to occur because there is several RTP sessions
using the same SSRC value. This has both limitations, processing
overhead and the possibility of becoming an deployment obstacle for
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.holmberg-mmusic-sdp-bundle-negotiation]. These drafts describe [I-D.ietf-mmusic-sdp-bundle-negotiation]. These drafts describe how
how to signal multiple media streams multiplexed into a single RTP to signal multiple media streams multiplexed into a single RTP
session, and address some of the issues raised here and in Section session, and address some of the issues raised here and in Section
7.2.9 of the RTP Multiplexing Architecture 6.7 of the RTP Multiplexing Architecture
[I-D.westerlund-avtcore-multiplex-architecture] draft. However, they [I-D.westerlund-avtcore-multiplex-architecture] draft.
fail to discuss maybe the largest issue with this solution: how to do
incremental deployment and transition.
Many transition scenarios use an RTP translator as a gateway between
a single RTP session containing multiple media types multiplexed
together, and several separate RTP sessions each using a single media
type. In this scenario, it is possible that a legacy device that
uses one RTP session for each media type will use the same SSRC in
each session. When translating these into a single RTP session, it
will be necessary to rewrite one of the SSRCs, so that each stream
has a unique SSRC. This SSRC translation process is straight-forward
for RTP packets, but is very complex for RTCP packets. It also
hinders innovation, since such a gateway will not be able to
translate new RTCP extensions that it is unaware of, even if they are
supported by devices on both sides of the gateway.
This method has several limitations that makes it unsuitable as This method has several limitations that limits its usage as solution
general mechanism to provide multiple RTP sessions on the same lower in providing multiple RTP sessions on the same lower layer transport.
layer transport. However, we acknowledge that there are some uses However, we acknowledge that there are some uses for which this
for which this method may be sufficient and which can accept the method may be sufficient and which can accept the methods limitations
method limitations and other downsides. The RTCWEB WG has a working and downsides. The RTCWEB WG has a working assumption to support
assumption to support this method. For more details of this method, this method. For more details of this method, see the relevant
see the relevant drafts under development. drafts under development. We do include this method in the
comparison to provide a more complete picture of the pro and cons of
this method.
This solution has no per packet overhead. The signalling overhead This solution has no per packet overhead. The signalling overhead
will be a different question. will be a different question.
4.4. Use the SRTP MKI field 4.4. Use the SRTP MKI field
This proposal is to overload the MKI SRTP/SRTCP identifier to not This proposal is to overload the MKI SRTP/SRTCP identifier to not
only identify a particular crypto context, but also identify the only identify a particular crypto context, but also identify the
actual RTP Session. This clearly is a miss use of the MKI field, actual RTP Session. This clearly is a miss use of the MKI field,
however it appears to be with little negative implications. SRTP however it appears to be with little negative implications. SRTP
skipping to change at page 11, line 32 skipping to change at page 12, line 35
There is one downside of this proposal and that has to do with SRTP. There is one downside of this proposal and that has to do with SRTP.
To be able to determine the crypto context, it is necessary to access To be able to determine the crypto context, it is necessary to access
to the encrypted payload of the packet. Thus, the only mechanism to the encrypted payload of the packet. Thus, the only mechanism
available for a receiver to solve this issue is to try the existing available for a receiver to solve this issue is to try the existing
crypto contexts for any session on the same lower layer transport and crypto contexts for any session on the same lower layer transport and
then use the one where the packet decrypts and verifies correctly. then use the one where the packet decrypts and verifies correctly.
Thus for transport flows with many crypto contexts, an attacker could Thus for transport flows with many crypto contexts, an attacker could
simply generate packets that don't validate to force the receiver to simply generate packets that don't validate to force the receiver to
try all crypto contexts they have rather than immediately discard it try all crypto contexts they have rather than immediately discard it
as not matching a context. A receiver can mitigate this somewhat by as not matching a context. A receiver can mitigate this somewhat by
using hueristics based on the RTP header fields to determine which using heuristics based on the RTP header fields to determine which
context applies for a received packet, but this is not a complete context applies for a received packet, but this is not a complete
solution. solution.
This solution has a 16-bit per packet overhead. This solution has a 16-bit per packet overhead.
4.6. Redefine the SSRC field 4.6. Redefine the SSRC field
The Rosenberg et. al. Internet draft "Multiplexing of Real-Time The Rosenberg et. al. Internet draft "Multiplexing of Real-Time
Transport Protocol (RTP) Traffic for Browser based Real-Time Transport Protocol (RTP) Traffic for Browser based Real-Time
Communications (RTC)" [I-D.rosenberg-rtcweb-rtpmux] proposed to Communications (RTC)" [I-D.rosenberg-rtcweb-rtpmux] proposed to
redefine the SSRC field. This has the advantage of no packet redefine the SSRC field. This has the advantage of no packet
expansion. It also looks like regular RTP. However, it has a number expansion. It also looks like regular RTP. However, it has a number
of implications. First of all it prevents any RTP functionality that of implications. First of all it prevents any RTP functionality that
require the same SSRC in multiple RTP sessions. require the same SSRC in multiple RTP sessions.
Secondly its interoperability with normal RTP is problematic. Such Secondly its interoperability with end-point using multiple RTP
interoperability requires an SSRC translator function in the gateway sessions are problematic. Such interoperability will requires an
to ensure that the SSRCs fulfill the requirements of the different SSRC translator function in the gatewaying node to ensure that the
domains. That translator is actually far from easy as it needs to SSRCs fulfill the semantic rules of the different domains. That
understand the semantics of all RTP and RTCP extensions that include translator is actually far from easy as it needs to understand the
SSRC/CSRC. This as it is necessary to know when a particular semantics of all RTP and RTCP extensions that include SSRC/CSRC.
matching 32-bit pattern is an SSRC field and when the field is just a This as it is necessary to know when a particular matching 32-bit
combination of other fields that create the same matching 32-bit pattern is an SSRC field and when the field is just a combination of
pattern. Thus any future RTCP extension might not work through the other fields that create the same matching 32-bit pattern. Thus
translator, causing a barrier for deployment of future extensions. there is a possibility that such a translator becomes a obstacle in
deploying future RTP/RTCP extensions. In addition the translator
actually have significant overhead when SRTP are in use. This as a
verification that the packet is authentic, decryption, SSRC
translation, encryption and finally generation of authentication tags
are required. In addition the translator must be part of the
security context.
This solution has no per packet overhead. This solution has no per packet overhead.
5. Recommendation 5. Comparison
This section compares the above potential solutions with the
requirements. Motivations are provided in addition to a high level
metric of successfully, partially and failing to meet requirement.
In the end a summary table (Figure 1) of the high level value are
provided.
5.1. Support of Multiple RTP Sessions Over Single Transport
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
rest fully support this requirement. The main question around this
requirement is how important it is to have as discussed in
Section 3.1.
5.2. Enable Same SSRC Value in Multiple RTP Sessions
Based on the discussion in Section 3.2 two sub-requirements have been
derived.
5.2.1. Avoid SSRC Translation in Gateways/Translation
This sub-requirement is derived based on the desire to avoid having
gateways or translators perform full SSRC translation to minimize
complexity, avoid the requirement to have gateways in security
context, and as a hinder to long-term evolution. Two of the
proposals have issues with this, due to their lack of support for
multiple 32-bit SSRC spaces and lacking possibility to have the same
SSRC value in multiple RTP sessions. The proposals that have these
properties and thus are marked as failing are the Single Session and
Redefine the SSRC field. The other proposals are all succcesful in
meeting this requirement.
5.2.2. Support Existing Extensions
The second sub-requirement is how well the proposals support using
the existing RTP mechanisms. Here both Single Session and Redefine
the SSRC field will have clear issues as they cannot support the same
full 32-bit SSRC value in two different RTP sessions. This is
clearly an issue for the XOR based FEC. RTP retransmission and
scalable encoding are minor issues as there exist alternatives to
those mechanisms that works with the structure of these two
proposals. Thus we give them a fail. The Header Extension gets a
partial due to unclear interaction between putting in an header
extension and these mechanisms.
5.3. Ensure SRTP Functions
This requirement is about ensuring both secure and efficient usage of
SRTP. The Octet in Padding field proposal gets a fail as the
receiving end-point cannot determine the intended RTP session prior
to de-encryption of the padding field. Thus a catch-22 arises which
can only be resolved by trying all session contexts and see what
decrypts. This causes a security vulnerability as an attacker can
inject a packet which does not meet any of the session contexts. The
receiver will then attempt decryption and authentication of it using
all its session contexts, increasing the amount of wasted resources
by a factor equal to the number of multiplexed sessions. Thus this
proposal gets a fail.
The proposal of Overloading the SRTP MKI field as session identifier
gets a partial due to the fact that it cannot use SRTP's key-
management mechanism out of the box. It forces the key-management
mechanism and the SRTP implementations to maintain the MKI-to-RTP
session bindings to maintain secure and correct function.
The Redefine the SSRC field gets a partial due to its need to modify
the key-management mechanisms to correctly identify the partial SSRC
space the parameters applies to. Similarly, the SRTP implementation
also needs to be updated to correctly support this security context
differentiation.
The header extension based solution gets a less severe partial than
Redefine the SSRC and the MKI. It will however have an issue when
being gatewayed to a domain that does not multiplex multiple RTP
sessions over the same transport. Then the gateway will require to
be in the security context to be able to add or remove the header
extension as it is in the part of the packet that is integrity
protected by SRTP.
The remaining two proposals do not affect SRTP mechanisms and thus
successfully meet this requirement.
5.4. Don't Redefine Used Bits
This requirement is all about RTP and RTCP header fields having a
given definition should not be changed as it can cause
interoperability problems between modified and non-modified
implementations. This becomes especially problematic in RTP sessions
used for multi-party sessions.
Redefine the SSRC field gets a big fail on this as it redefines the
SSRC field, a core field in RTP. It has been identified that such a
change will have issues since if it gets connected to a non-modified
end-point that randomly assigns the SSRC, as supposed by RFC 3550,
those SSRCs will be distributed over different RTP sessions at the
modified end-point. Also other functions using the SSRC field, not
understanding the additional semantics of the SSRC field, is likely
to have issues.
Using the SRTP MKI field to identify a session is overloading that
field with double semantics. This likely has minimal negative impact
in RTP since it should be possible to have the SRTP stack use the MKI
field to both look up the security context and which output RTP
session the processed packet belongs to. However, this redefinition
clearly creates issues with the key-management scheme. That will
have to be modified to handle both this change and deal with the
interoperability issues when negotiating its usage. This gets a full
fail due to that it makes the problem someone else's, namely the RTP
implementors.
Defining an Octet in the Padding field redefines a field, whose
definition is to have zero value and is expected to be ignored by the
receiver according to the original semantics. Thus this is one of
the more benign modifications one can do, however this can still
cause issues in implementations that unnecessarily check the field
values, or in firewalls. This is judged to be partially meeting the
requirement.
The Header Extension proposal does in fact not redefine any currently
used bits in RTP. The header extension would be a correctly
identified extension with its own definition. However, it does
redefine a rule on what header extensions are for. The RTCP solution
however would have more severe impact as it would need to redefine
the standard meaning of an RTCP packet header in addition to the
default compound packet rules. Due to these issues the proposal
fails to meet this requirement.
The multiplexing shim and the single session both successfully meet
this requirement.
5.5. Firewall Friendly
This requirement is clearly difficult to judge as firewall
implementations are highly different in both implementation, scope of
what it investigates in packets, and set policies. A reasonable goal
is to minimize the likeliness that rules and policies intended to let
RTP media streams pass, will also let these streams through when
multiplexing RTP sessions over a single transport. The below
analysis shows that no solution is truly firewall friendly and all
are judged as being partially meeting this goal. However, the reason
why it is believed that a firewall might react to the streams are
quite different.
The Single Session and Redefine the SSRC field are likely the least
suspect solutions from a firewall perspective. However, as their
transport flows contain multiple SSRCs with payloads that indicate
likely multiple different media types they are still likely to make a
picky firewall block the transport. This is especially true for
firewalls that take signalling messages into account where it will
expect a particular media type in a given context. A non upgraded
firewall might in fact produce two different contexts with
overlapping transport parameters where both rules will receive media
streams of the other media type that are outside of the allowed rule.
However, to be clear if these proposals doesn't get through, none of
the other will either as they all will have this behavior.
The header extension proposal is potentially problematic for two
reasons. The first reason, which also other proposals has, is
related to that the same SSRC value can exist in two RTP sessions
over the same underlying flow. Anyone tracking the sequence number
and timestamp will react badly as the second media stream with the
same SSRC causes constant jumps back and forth in these fields
compared to the first stream, if packets are transmitted
simultaneously for both SSRCs. This issue can likely only be solved
by having the firewalls that like to track flows to also use the
session identifier to create context. This is possible as the header
extension will be in the clear and in the front. The second issue is
that the header extension itself may get the firewall to react.
Especially very picky ones that expect packets with certain media
types to have certain packet lengths. They are not compatible with a
header extension.
The Multiplexing Shim shares the issue with multiple flows for the
same SSRC. Firewalls and deep packet inspection cause the shim
placement to be in question. If it is a pre-fixed shim, it prevents
the packet from looking like regular IP/UDP/RTP packets and be
correctly classified in firewalls and DPI engines. However, if one
puts it last, it is unlikely that any firewall or DPI ever will be
able to take the session context into account as it is at the end of
the packet. This as many line rate processing devices only take a
certain amount of the the headers into account.
The SRTP MKI field is likely the solution that has least firewall and
DPI issues, after the single RTP session. There is no additional
suspect field. The only difference from a single RTP session in the
transport flow is the fact that multiple MKI are guaranteed to be
used. However, that may occur also in a single RTP session usage.
Thus the only issues are the one shared with single session and the
one that several RTP media streams may use the same SSRC.
The octet in the padding field has, in addition to the issues the
SRTP MKI field has, the single issue that it redefines something that
is supposed to be zero into a value. Thus potentially causing a
deeply inspecting firewall to clamp the flow in fear of covert
channel or non-compliance.
5.6. Monitoring and Reporting
The monitoring and reporting requirement considers several aspects.
How useful monitoring can one get from an existing legacy monitor,
and secondary any issues in upgrading them to handle the selected
solution. Thirdly, packet selector filters and packet sniffers
concerns are considered.
In general one can expect the proposals that have only a single SSRC
space to work better with legacy. Thus both Single Session and
Redefine SSRC space can gather and report data on media flows most
likely. The only potential issue is that due to the different media
types and clock rates, some failure may occur. In particular a third
party monitor may be targeted to a specific media type, like
monitoring VoIP. That monitor will have problems processing any
video packets correctly and generate the VoIP specific metrics for
any video sending SSRC. In general, no legacy solution for
monitoring will be able to correctly create the sub-contexts that
each RTP session has in the solutions, without update to handle the
new semantics. Also when it comes to the packet filtering and
selector filters, fine grained control can only be accomplished
implementing the new semantics. Therefore only the Single Session
meets this requirement fully.
Redefine the SSRC field is close to fully meeting the requirement,
however due to that there exist a session structure that is hidden to
anyone that is not upgraded to understand the semantics, this only
gets a partial.
The other proposals all can have multiple RTP sessions using the same
SSRC. This will create significant issues for any legacy third party
monitor. Only an updated monitor, or for that matter packet
selector, can pick out the individual media streams and their
associated RTCP traffic. Thus all these proposals gets a failure to
meet the requirement.
5.7. Usable over Multicast
As discussed earlier the goal with having the option usable also over
multicast is to remove the need to produce different media streams
for transport over unicast and multicast. All of the proposals
successfully meet the requirement.
5.8. Incremental Deployment
The possibility to deploy the usage of the multiplexing of multiple
RTP sessions over a single transport, especially in the context of
multi-party sessions, is a great benefit for any of the proposals.
Thus not all end-point implementations needs to be upgraded before
one start enabling it in the central node and any signalling.
Considering a centralized multi-party application where some
participants are using multiple transport flows and you want to
enable one particular participant to use the single transport to the
central node, one criteria stands out. The possibility to have one
RTP session per transport in one leg, and in the next multiplex them
together with minimal complexity and packet changes. Here there are
significant differences.
The Multiplexing Shim has the least overhead for this. As the
central node or gateway between deployments only needs to either add
or remove the shim identifier and then forward the packet over the
corresponding transport, either a joint one on the single transport
side, or over the individual one on the multiple transport side.
The SRTP MKI field proposal is almost as good, as the only main
difference is the need to coordinate the used MKIs on the non-
multiplexed legs so that there is no overlap between the RTP
sessions. And if there is, the MKI can be translated in gateway as
SRTP has no integrity protection over the MKI. Thus both
multiplexing shim and SRTP MKI field does successfully meet this
requirement.
The Header Extension supports multiple full 32-bit SSRC spaces and
can thus handle all the RTP sessions without need for any SSRC
translation, however this proposal does run into the problem that the
gateway needs to be in the security context to be able to add or
remove the header extension when SRTP is used. In addition to the
security implications of that, there is a complexity overhead due to
the need to redo the authentication tags on all RTP/RTCP packets.
Thus it gets a partial.
The Octet in the Padding field share issues with the header extension
but have even higher complexities for this. The reason is that the
padding field is also encrypted. Thus to add or remove it (although
removing it may be unncessary) forces the end-point to encrypt at
least that byte also, and for ciphers that are not stream-ciphers,
the whole packet needs to be re-encrypted. Thus this proposal gets a
very weak partially meeting the requirement.
The Single Session and Redefine the SSRC field do not allow several
vanilla RTP sessions to be connected to these proposals. The reason
is the single 32-bit SSRC space they have. Single Session only has
one session and the Redefine the SSRC fields uses some of the bits as
session identifier. This forces the gateway to translate the SSRC
whenever it does not fulfill the rules or semantics of the
multiplexed side. For Redefine SSRC field this becomes almost
constant as the session identifier part of the SSRC must be the same
over all SSRCs from the same session. For Single Session it may only
be needed when there otherwise would be an SSRC collision between the
sessions. This further assumes that the non-multiplexed side would
never use any of the RTP mechanisms that require the same SSRC in
multiple RTP sessions, as they cannot be gatewayed at all. When
translating an SSRC there is first of all an overhead, with SRTP that
includes a complete authenticate, decrypte, encrypt and create a new
authentication tag cycle. In addition, the SSRC translation could
potentially be a deployment obstacle for new RTP/RTCP extensions
required to be understood by the translator to be correctly
translated. Therefore these two proposals gets a fail to meet the
requirements.
5.9. Summary and Conclusion
This section contains a summary table of the high level outcome
against the different requirements.
A table mapping the requirements against the ID numbers used in the
table is the following:
1: Support multiple RTP sessions over one transport flow
2: Enable same SSRC value in multiple RTP sessions
2.1: Avoid SSRC translation in gateways/translators
2.2: Support existing extensions
3: Ensure SRTP functions
4: Don't Redefine used bits
5: Firewall Friendly
6: Monitoring and Reporting should still function
7: Usable over Multicast
8: Incremental deployment
OH: Overhead in Bytes. + means variable
---------------+---+---+---+---+---+---+---+---+---+----
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+
Multiplex Shim | S | S | S | S | S | P | F | S | S | 1
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
Padding Field | S | S | S | F | P | P | F | S | P | 2
Redefine SSRC | S | F | F | P | F | P | P | S | S | 0
---------------+---+---+---+---+---+---+---+---+---+----
Figure 1: Summary Table of Evaluation (Successfully (S), Partially
(P) or Fails (F) to meet requirement)
Considering these options, the authors would recommend that AVTCORE Considering these options, the authors would recommend that AVTCORE
standardize a solution based on a postfixed multiplexing field, i.e. standardize a solution based on a postfixed multiplexing field, i.e.
a shim approach combined with the appropriate signalling as described a shim approach combined with the appropriate signalling as described
in Section 4.2. in Section 4.2.
6. Specification 6. Specification
This section contains the specification of the solution based on a This section contains the specification of the solution based on a
SHIM, with the explicit session identifier at the end of the SHIM, with the explicit session identifier at the end of the
skipping to change at page 12, line 44 skipping to change at page 21, line 24
+---------------------+ +---------------------+
| Session ID Layer | | Session ID Layer |
+---------------------+ +---------------------+
| Transport layer | | Transport layer |
+---------------------+ +---------------------+
Stack View with Session ID SHIM Stack View with Session ID 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 is sent over the same Transport layer and where the Session ID
layer will combine and encapsulate them with the session ID on 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 |
+-------------------+ +-------------------+
Figure 1: Multiple RTP Session On Top of Session ID Layer Figure 2: Multiple RTP Session On Top of Session ID Layer
The Session ID layer encapsulates one RTP or RTCP packet from a given The Session ID layer encapsulates one RTP or RTCP packet from a given
RTP session and postfixes a one byte Session ID (SID) field to the RTP session and postfixes a one byte Session ID (SID) field to the
packet. Each RTP session being multiplexed on top of a given packet. Each RTP session being multiplexed on top of a given
transport layer is assigned either a single or a pair of unique SID transport layer is assigned either a single or a pair of unique SID
in the range 0-255. The reason for assigning a pair of SIDs to a in the range 0-255. The reason for assigning a pair of SIDs to a
given RTP session are for RTP Sessions that doesn't support given RTP session are for RTP Sessions that doesn't support
"Multiplexing RTP Data and Control Packets on a Single Port" "Multiplexing RTP Data and Control Packets on a Single Port"
[RFC5761] to still be able to use a single 5-tuple. The reasons for [RFC5761] to still be able to use a single 5-tuple. The reasons for
supporting this extra functionality is that RTP and RTCP multiplexing supporting this extra functionality is that RTP and RTCP multiplexing
based on the payload type/packet type fields enforces certain based on the payload type/packet type fields enforces certain
restrictions on the RTP sessions. These restrictions may not be restrictions on the RTP sessions. These restrictions may not be
acceptable. As this solution does not have these restrictions, acceptable. As this solution does not have these restrictions,
performing RTP and RTCP multiplexing in this way has benefits. performing RTP and RTCP 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, DCCP, TCP, and SCTP protocol. Common transport protocols like UDP, DCCP, TCP, and SCTP
can all be scoped by one or more 5-tuple (Transport protocol, source can all be scoped by one or more 5-tuple (Transport protocol, source
address and port, destination address and port). The case of address and port, destination address and port). The case of
multiple 5-tuples occur in the case of multi-unicast topologies, also multiple 5-tuples occur in the case of multi-unicast topologies, also
called meshed multiparty RTP sessions. called meshed multiparty RTP sessions or in case any application
would need more than 128 RTP sessions.
0 1 2 3 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|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 | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
skipping to change at page 14, line 31 skipping to change at page 22, line 39
| | | RTP padding | RTP pad count | | | | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ | | ~ SRTP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : | | : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Session ID | | | | Session ID | |
| +---------------+ | | +---------------+ |
+- Encrypted Portion* Authenticated Portion ---+ +- Encrypted Portion* Authenticated Portion ---+
SRTP Packet encapsulated by Session ID Layer Figure 3: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|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 ~ |
skipping to change at page 15, line 37 skipping to change at page 23, line 37
| |E| SRTCP index | | | |E| SRTCP index | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTCP MKI (OPTIONAL) ~ | | ~ SRTCP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag : | | : authentication tag : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Session ID | | | | Session ID | |
| +---------------+ | | +---------------+ |
+-- Encrypted Portion Authenticated Portion -----+ +-- Encrypted Portion Authenticated Portion -----+
SRTCP packet encapuslated by Session ID layer Figure 4: 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
skipping to change at page 16, line 24 skipping to change at page 24, line 24
all RTP Sessions being sent over the same 5-tuple. The same Session all RTP Sessions being sent over the same 5-tuple. The same Session
ID shall be used for an RTP session independently of the traffic ID shall be used for an RTP session independently of the traffic
direction. Note that nothing prevents a multi-media application from direction. Note that nothing prevents a multi-media application from
using multiple 5-tuples if desired for some reason, in which case using multiple 5-tuples if desired for some reason, in which case
each 5-tuple has its own session ID value space. each 5-tuple has its own session ID value space.
This section defines how to negotiate the use of the Session ID This section defines how to negotiate the use of the Session ID
layer, using the Session Description Protocol (SDP) Offer/Answer layer, using the Session Description Protocol (SDP) Offer/Answer
mechanism [RFC3264]. A new media-level SDP attribute, mechanism [RFC3264]. A new media-level SDP attribute,
'session-mux-id', is defined, in order to be used with the media 'session-mux-id', is defined, in order to be used with the media
BUNDLE mechanism defined in BUNDLE mechanism defined in [I-D.ietf-mmusic-sdp-bundle-negotiation].
[I-D.holmberg-mmusic-sdp-bundle-negotiation]. The attribute allows The attribute allows each media description ("m=" line) associated
each media description ("m=" line) associated with a 'BUNDLE' group with a 'BUNDLE' group to form separate RTP sessions.
to form a separate RTP session.
The 'session-mux-id' attribute is included for a media description, The 'session-mux-id' attribute is included for a media description,
in order to indicate the Session ID for that particular media in order to indicate the Session ID for that particular media
description. Every media description that shares a common attribute description. Every media description that shares a common attribute
value is assumed to be part of a single RTP session. An SDP Offerer value is assumed to be part of a single RTP session. An SDP Offerer
MUST include the 'session-mux-id' attribute for every media MUST include the 'session-mux-id' attribute for every media
description associated with a 'BUNDLE' group. If the SDP Answer does description associated with a 'BUNDLE' group. If the SDP Answer does
not contain 'session-mux-id' attributes, the SDP Offerer MUST NOT not contain 'session-mux-id' attributes, the SDP Offerer MUST NOT
assume that separate RTP sessions will be used. If the SDP Answer assume that separate RTP sessions will be used. If the SDP Answer
still describes a 'BUNDLE' group, the procedures in still describes a 'BUNDLE' group, the procedures in
[I-D.holmberg-mmusic-sdp-bundle-negotiation] apply. [I-D.ietf-mmusic-sdp-bundle-negotiation] apply.
An SDP Answerer MUST NOT include the 'session-mux-id' attribute in an An SDP Answerer MUST NOT include the 'session-mux-id' attribute in an
SDP Answer, unless included in the SDP Offer. SDP Answer, unless included in the SDP Offer.
The attribute has the following ABNF [RFC5234] definition. The attribute has the following ABNF [RFC5234] definition.
Session-mux-id-attr = "a=session-mux-id:" SID *SID-prop Session-mux-id-attr = "a=session-mux-id:" SID *SID-prop
SID = SID-value / SID-pairs SID = SID-value / SID-pairs
SID-value = 1*3DIGIT / "NoN" SID-value = 1*3DIGIT / "NoN"
SID-pairs = SID-value "/" SID-value ; RTP/RTCP SIDs SID-pairs = SID-value "/" SID-value ; RTP/RTCP SIDs
skipping to change at page 20, line 14 skipping to change at page 28, line 14
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:BUNDLE foo bar a=group:BUNDLE foo bar
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-mxu-id:0 policy=suggest 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 10000 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=session-mxu-id:1 policy=suggest 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
The SDP answer from an end-point that supports this BUNDLEing: The SDP answer from an end-point that supports this BUNDLEing:
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:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=session-mux-id:0 policy=suggest a=session-mux-id:0 policy=tentative
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=session-mux-id:1 policy=suggest a=session-mux-id:1 policy=tentative
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
The SDP answer from an end-point that does not support this BUNDLEing The SDP answer from an end-point that does not support this BUNDLEing
or the general signalling of or the general signalling of
[I-D.holmberg-mmusic-sdp-bundle-negotiation]. [I-D.ietf-mmusic-sdp-bundle-negotiation].
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32 m=video 30000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
The SDP answer of a client supporting The SDP answer of a client supporting
[I-D.holmberg-mmusic-sdp-bundle-negotiation] but not this BUNDLEing [I-D.ietf-mmusic-sdp-bundle-negotiation] but not this BUNDLEing would
would look like this: look like this:
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:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
skipping to change at page 21, line 42 skipping to change at page 29, line 42
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
In this last case, the result is a sing RTP session with both media In this last case, the result is a sing RTP session with both media
types being established. If that isn't supported or desired, the types being established. If that isn't supported or desired, the
offerer will have to either re-invite without the BUNDLE grouping to offerer will have to either re-invite without the BUNDLE grouping to
force different 5-tuples, or simply terminate the session. force different 5-tuples, or simply terminate the session.
7. Open Issues 7. Open Issues
This is the first version of this draft. It will obviously have a This work is still in the early phase of specification. This section
number of open issues. This section contains a list of open issues contains a list of open issues where the author desires some input.
where the author desires some input.
1. Should RTP and RTCP multiplexing without RFC 5761 support be 1. Should RTP and RTCP multiplexing without RFC 5761 support be
included? included?
2. In Section 6.2 there is a discussion of which parameters that
must be configured. The scope of these rules and if they do make
sense needs additional discussion.
3. Can we provide better control so that applications that doesn't
desire fallback to single RTP session when Multiplexing shim
fails to be supported but Bundle is supported ends up with a
better alternative?
8. IANA Considerations 8. IANA Considerations
This document request the registration of one SDP attribute. Details This document request the registration of one SDP attribute. Details
of the registration to be filled in. of the registration to be filled in.
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
skipping to change at page 22, line 33 skipping to change at page 30, line 38
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 document is based on the input from various people, especially
in the context of the RTCWEB discussion of how to use only a single in the context of the RTCWEB discussion of how to use only a single
lower layer transport. The RTP and RTCP packet figures are borrowed 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.holmberg-mmusic-sdp-bundle-negotiation]. The authors would like [I-D.ietf-mmusic-sdp-bundle-negotiation]. The authors would like to
to thank Christer Holmberg for assistance in utilizing the BUNDLE thank Christer Holmberg for assistance in utilizing the BUNDLE
grouping mechanism. grouping mechanism.
The proposal in Section 4.5 is original suggested by Colin Perkins. The proposal in Section 4.5 is original suggested by Colin Perkins.
The idea in Section 4.6 is from an Internet Draft The idea in Section 4.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 Section 4.3 is a result of discussion by a group of The proposal in Section 4.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.holmberg-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation
Using Session Description Protocol (SDP) Port Numbers", Using Session Description Protocol (SDP) Port Numbers",
draft-holmberg-mmusic-sdp-bundle-negotiation-00 (work in draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in
progress), October 2011. progress), February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
11.2. Informational References 11.2. Informational References
[I-D.lennox-rtcweb-rtp-media-type-mux] [I-D.lennox-rtcweb-rtp-media-type-mux]
Lennox, J. and J. Rosenberg, "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)", Real-Time Communications (RTC)",
draft-rosenberg-rtcweb-rtpmux-00 (work in progress), draft-rosenberg-rtcweb-rtpmux-00 (work in progress),
July 2011. July 2011.
[I-D.westerlund-avtcore-multiplex-architecture] [I-D.westerlund-avtcore-multiplex-architecture]
Westerlund, M., Burman, B., and C. Perkins, "RTP Westerlund, M., Burman, B., and C. Perkins, "RTP
Multiplexing Architecture", Multiplexing Architecture",
draft-westerlund-avtcore-multiplex-architecture-00 (work draft-westerlund-avtcore-multiplex-architecture-01 (work
in progress), October 2011. in progress), March 2012.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. 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.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
 End of changes. 37 change blocks. 
127 lines changed or deleted 513 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/