Network Working Group M. Westerlund Internet-Draft Ericsson Intended status: Standards Track C. Perkins Expires: August 29, 2013 University of Glasgow February 25, 2013 Multiple RTP Sessions on a Single Lower-Layer Transport draft-westerlund-avtcore-transport-multiplexing-05 Abstract This memo defines a mechanism to allow multiple RTP sessions to be multiplexed onto a single lower-layer transport flow (e.g., onto a single UDP 5-tuple). Requirements for multiplexing RTP sessions are discussed, along with the trade-off between the different options. A shim-based multiplexing layer is proposed, along with associated signalling. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 29, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Westerlund & Perkins Expires August 29, 2013 [Page 1] Internet-Draft Multiple RTP Session on Single Transport February 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 5 3.2. No Transport Level QoS . . . . . . . . . . . . . . . . . . 5 3.3. Multiple RTP sessions . . . . . . . . . . . . . . . . . . 5 3.4. Usage of RTP Extensions . . . . . . . . . . . . . . . . . 6 3.5. Incremental Deployment . . . . . . . . . . . . . . . . . . 7 3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Support Use of Multiple RTP Sessions . . . . . . . . . . . 7 4.2. Same SSRC Value in Multiple RTP Sessions . . . . . . . . . 8 4.3. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 9 4.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 9 4.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 9 4.7. Usable Also Over Multicast . . . . . . . . . . . . . . . . 10 4.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 10 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 10 5.1. Location of SHIM . . . . . . . . . . . . . . . . . . . . . 10 5.2. ICE and DTLS-SRTP Integration . . . . . . . . . . . . . . 12 5.3. Signalling Fall Back . . . . . . . . . . . . . . . . . . . 12 6. Specification . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. SRTP Key Management . . . . . . . . . . . . . . . . . . . 18 6.3.1. Security Description . . . . . . . . . . . . . . . . . 19 6.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 19 6.3.3. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . 19 6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.4.1. RTP Packet with Transport Header . . . . . . . . . . . 20 6.4.2. SDP Offer/Answer example . . . . . . . . . . . . . . . 21 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.2. Informational References . . . . . . . . . . . . . . . . . 27 Appendix A. Possible Solutions . . . . . . . . . . . . . . . . . 29 A.1. Header Extension . . . . . . . . . . . . . . . . . . . . . 29 A.2. Multiplexing Shim . . . . . . . . . . . . . . . . . . . . 30 Westerlund & Perkins Expires August 29, 2013 [Page 2] Internet-Draft Multiple RTP Session on Single Transport February 2013 A.3. Single Session . . . . . . . . . . . . . . . . . . . . . . 31 A.4. Use the SRTP MKI field . . . . . . . . . . . . . . . . . . 32 A.5. Use an Octet in the Padding . . . . . . . . . . . . . . . 33 A.6. Redefine the SSRC field . . . . . . . . . . . . . . . . . 33 Appendix B. Comparison . . . . . . . . . . . . . . . . . . . . . 34 B.1. Support of Multiple RTP Sessions Over Single Transport . . 34 B.2. Enable Same SSRC Value in Multiple RTP Sessions . . . . . 34 B.2.1. Avoid SSRC Translation in Gateways/Translation . . . . 34 B.2.2. Support Existing Extensions . . . . . . . . . . . . . 35 B.3. Ensure SRTP Functions . . . . . . . . . . . . . . . . . . 35 B.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 36 B.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 37 B.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 38 B.7. Usable over Multicast . . . . . . . . . . . . . . . . . . 39 B.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 39 B.9. Summary and Conclusion . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Westerlund & Perkins Expires August 29, 2013 [Page 3] Internet-Draft Multiple RTP Session on Single Transport February 2013 1. Introduction With the ongoing development of the WebRTC conferencing and CLUE telepresence standards, there is renewed interest in defining a mechanism that allows multiple RTP sessions [RFC3550] to share a single lower layer transport, such as a bi-directional UDP flow. The main problem driving this is the cost of doing NAT/firewall traversal for each individual RTP flow. ICE and other NAT/firewall traversal solutions are clearly capable of attempting to open multiple flows. However, there is both increased risk for failure, and an increased cost in the creation of multiple flows. The increased cost comes as slightly higher delay in establishing the traversal, and the amount of consumed NAT/firewall resources. The latter might be an increasing problem in the IPv4 to IPv6 transition period. There is ongoing work on specifying how and when one RTP session can contain multiple media types [I-D.ietf-avtcore-multi-media-rtp-session]. That addresses certain use cases, while this proposal addresses a different set of use cases and motivations (discussed further in Section 3). The classical method of having each RTP session run over a specific transport flow is still motivated for a number of use cases, especially when flow based QoS is to be used for some media streams. This document draws up some requirements for consideration on how to transport multiple RTP sessions over a single lower-layer transport. These requirements have to be weighted carefully, as no known solution exists that can fulfil the combined set of requirements completely. A number of possible solutions where considered and discussed with respect to their properties. Based on that, this memo defines a multiplexing shim, along with SDP signalling, and examples. The other considered proposals and the comparison is available as appendices. 2. Conventions The following terminology is used in this document. Multiplexing: Unless specifically noted, all mentioning of multiplexing in this document refer to the multiplexing of multiple RTP Sessions on the same lower layer transport. It is important to make this distinction as RTP does contain a number of multiplexing points for various purposes, such as media formats (Payload Type), media sources (SSRC), and RTP sessions. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Westerlund & Perkins Expires August 29, 2013 [Page 4] Internet-Draft Multiple RTP Session on Single Transport February 2013 document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Motivations This section looks at the motivations why an additional solution is needed, assuming that you can do both the classical method of having one RTP session per transport flow [RFC3550], and when you have multiple media types within one RTP session [I-D.ietf-avtcore-multi-media-rtp-session]. 3.1. NAT and Firewalls The existence of NATs and Firewalls on almost all Internet access has implications for protocols, like RTP, that were designed to use multiple transport-layer flows. The NAT/firewall traversal solution has to to ensure that all these transport flows are established. This has three different impacts: 1. Increased delay to perform the transport flow establishment 2. The more transport flows, the more state and the more resource consumption in the NAT and Firewalls. When the resource consumption in NAT/firewalls reaches their limits, unexpected behaviours usually occur. Commonly resulting in service disruptions. 3. More transport flows means a higher risk that some transport flow fails to be established, thus preventing the application to communicate. Using fewer transport-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, Westerlund & Perkins Expires August 29, 2013 [Page 5] Internet-Draft Multiple RTP Session on Single Transport February 2013 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 A developed solution needs to minimize the number of RTP/RTCP extension and mechanisms that can't be used. Westerlund & Perkins Expires August 29, 2013 [Page 6] Internet-Draft Multiple RTP Session on Single Transport February 2013 3.5. Incremental Deployment In various multi-party communication scenarios deployment can become an issue if all session participants need to have the functionality before enabling its usage. This is especially difficult in communication scenarios where not all possible participants and their capabilities are know ahead of establishing the communication session with some sub-set of the participants. At least for centralized communication sessions it is desirable to have a solution that enables allows the solution to be used on a single leg without affecting any other leg, nor require advanced translation functionality in any central node. 3.6. Summary The centre of the motivation is to ensure that the RTP session is a available and usable tool also for applications that has no need for network level separation of its media streams and wants to reduce its exposure to any NAT or Firewall inconsistencies and minimize the resource consumption. As a benefit a well designed solution will enable incremental deployment and minimal limitations in what existing RTP mechanisms or extensions that can be used by the RTP using application. 4. Requirements This section lists and discusses a number of potential requirements. However, it is not difficult to realize that it is in fact possible to put requirements that makes the set of feasible solutions an empty set. It is thus necessary to consider which requirements that are essential to fulfil and which can be compromised on to arrive at a solution. 4.1. Support Use of Multiple RTP Sessions Section 3.3 discusses a number of reasons why an application might like to have multiple RTP sessions. Considering the motivations for this work this is an absolute requirement. We also are of the opinion that the session provided by the solution needs to fulfil the definition in the RTP [RFC3550] specification: "The distinguishing feature of an RTP session is that each maintains a full, separate space of SSRC identifiers (defined next). The set of participants included in one RTP session consists of those that can receive an SSRC identifier transmitted by any one of the participants either in RTP as the SSRC or a CSRC (also defined below) or in RTCP." Westerlund & Perkins Expires August 29, 2013 [Page 7] Internet-Draft Multiple RTP Session on Single Transport February 2013 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 between the sessions. If the RTP sessions multiplexed together need to have unique SSRC values, then additional code that works between RTP Sessions is needed in the implementations. Thus raising the bar for implementing this solution. In addition, if one gateways between parts of a system using this multiplexing and parts that aren't multiplexing, the 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. 2. There are some few RTP extensions that currently rely on being able to use the same SSRC in different RTP sessions: * XOR FEC (RFC5109) * RTP Retransmission in session mode (RFC4588) * 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 session context a received or to-be-sent packet relates to. It also normally relies on the lower layer transport to identify the session. It uses the Master Key Indicator (MKI), if present, to determine which key set 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, to actually generate the correct cipher stream. Westerlund & Perkins Expires August 29, 2013 [Page 8] Internet-Draft Multiple RTP Session on Single Transport February 2013 Unencrypted Headers: SRTP has chosen to leave the RTP headers and the first two 32-bit words of the first RTCP header unencrypted, to allow for both header compression and monitoring to work also in the presence of encryption. As these fields are in clear text they are used in most crypto suites for SRTP to determine how to 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 deployment story and numerous implementations, changing any of the field definitions is highly problematic. First of all, the implementations need to change to support this new semantics. Secondly, you get a large transition issue 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. 4.5. Firewall Friendly It is desirable that current Firewalls will accept the solutions as normal RTP packets. However, in the authors' opinion we can't let the firewall stifle invention and evolution of the protocol. It is also necessary to be aware that a change that will make most deep inspecting firewall consider the packet as not valid RTP/RTCP 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 multiplexed RTP Sessions. It is however likely that they will require an update to correctly monitor and report on multiplexed RTP Sessions. Another type of function to consider is packet sniffers and their selector filters. These can be impacted by a change of the fields. An observation is that many such systems are usually quite rapidly updated to consider new types of standardized or simply common packet formats. Westerlund & Perkins Expires August 29, 2013 [Page 9] Internet-Draft Multiple RTP Session on Single Transport February 2013 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 A good solution has the property that in topologies that contains RTP mixers or Translators, a single session participant can enable multiplexing without having any impact on any other session participants. Thus a node ought to be able to take a multiplexed packet and then easily send it out with minimal or no modification on another leg of the session, where each RTP session is transported over its own lower-layer transport. It also needs to be as easy to do the reverse forwarding operation. 5. Design Considerations When defining a SHIM solution for identifying RTP sessions over a single transport layer there has been some special considerations that is discussed in this section. 5.1. Location of SHIM A major question affecting the SHIM is the location of the SHIM header providing the Identifier of the session the packet relate to. This section will discuss in detail about the impact of making the different choices. Identified aspects to consider are: Possibility to Process: A prefixed shim header, i.e. between the transport protocol and the RTP/RTCP packet header has the advantage that any node on the network that likes to include the header in any per-packet processing can reach it. Reasons for per-packet processing are: A. Quality of Service classification B. SHIM ingress or egress Westerlund & Perkins Expires August 29, 2013 [Page 10] Internet-Draft Multiple RTP Session on Single Transport February 2013 C. Monitoring Many routers or similar devices can only read and process the first N bytes of the whole packet, where N is commonly on the order of 64-128 bytes. Any other type of processing means putting the packet on the slow path. Thus a prefixed solution enables this processing while a postfixed solution will most likely forever prevent this type of devices to process it. Legacy Processing: Packets or at least flows of the type IP/UDP/RTP can in many cases be identified in Deep Packet Inspection, Firewalls or other network entities that concern themselves with trying determine what traffic that flows in a particular packet. These nodes can clearly be updated but until they can create a barrier to deployment. Thus a post fix gives likely the least resistance for initial deployment. However, also for postfix location the deployment can be hindered in cases multiple RTP sessions using the same SSRC values due to irregular behaviour of the fields for what the third party believes is one media stream rather than multiple ones. The prefixed will however maintain the long-term capabilities of such devices assuming they can be updated to include the SHIM header as part of the classification. Header Compression: The different header compression techniques that has been developed compresses IP/UDP/RTP as complete combination. If one instead have a IP/UDP/SHIM/RTP then the compression for the full set might not work or poorly. Instead only IP/UDP header compression is likely to be applied. Thus a prefix will loose some compression efficiency until compression profiles for IP/UDP/ SHIM/RTP has been developed, implemented and deployed. Postfix don't have that issue, but nor can it ever gain anything from header compression which an prefixed solution could once an updated profile is deployed. Postfix also will have reduced efficiency compressing sessions when the same SSRC is used in two different RTP sessions as the RTP header fields like sequence number, etc., will not behave as expected and need frequent explicit updates. The question of a prefixed or a postfixed header comes down to a trade-off between long term usability and deployment issues: Prefixed: Long term good possibility to adapt any network function that needs to take the SHIM header into account. At the same time any function that tries to analyse packets and because of that might block the packets will be a hinder to deployment. Westerlund & Perkins Expires August 29, 2013 [Page 11] Internet-Draft Multiple RTP Session on Single Transport February 2013 Postfixed: This solution will likely short term have the best possibilities to deploy successfully. However, long term this choice will likely prevent many network nodes that like to be capable of separating the RTP sessions being multiplexed together from successfully doing that. After discussion in the working group it has been determined that prefixed is the preferred solution. 5.2. ICE and DTLS-SRTP Integration When using ICE [RFC5245] or DTLS-SRTP [RFC5764] or both with RTP there exist the issue that RTP, STUN [RFC5389] and DTLS-SRTP are simultaneously in use over the same lower layer transport flow, like 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 DTLS-SRTP [RFC5764]. The replacement of a single RTP session with the multiple RTP sessions identified by a SHIM ought not be misidentified to be either STUN or DTLS-SRTP or any other protocol intending to take the 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 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 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 There exist an important aspect in how the SDP signalling functions, especially Offer/Answer [RFC3264]. The initial idea for the signalling was to build on top of bundle [I-D.ietf-mmusic-sdp-bundle-negotiation] which in its default function negotiate multiple media types over one RTP session [I-D.ietf-avtcore-multi-media-rtp-session]. If the signalling for the solution that main purpose is to enable multiple RTP sessions results in those cases the peer doesn't support this specification the communicating peer can end up in single RTP session if the peer supports that. We consider it important that in the signalling design that the application developer can decide what type of 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 Westerlund & Perkins Expires August 29, 2013 [Page 12] Internet-Draft Multiple RTP Session on Single Transport February 2013 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 grouping in addition to the SHIM when the fall back from SHIM is to BUNDLE. Note: Signalling solution is awaiting resolution of design path for bundle and will then consider that solution and issues raised. 6. Specification This section contains the specification of the RTP session multiplexing SHIM, using an explicit session identifier of the encapsulated payload. Westerlund & Perkins Expires August 29, 2013 [Page 13] Internet-Draft Multiple RTP Session on Single Transport February 2013 6.1. Shim Layer This solution is based on a shim layer that is inserted in the stack between the regular RTP and RTCP packets and the transport layer being used by the RTP sessions. Thus the layering looks like the following: +---------------------+ | RTP / RTCP Packet | +---------------------+ | Session ID Layer | +---------------------+ | Transport layer | +---------------------+ Stack View with Session ID SHIM The above stack is in fact a layered one as it does allow multiple RTP Sessions to be multiplexed on top of the Session ID shim layer. This enables the example presented in Figure 1 where four sessions, S1-S4 is sent over the same Transport layer and where the Session ID layer will combine and encapsulate them with the session ID on transmission and separate and decapsulate them on reception. +-------------------+ | S1 | S2 | S3 | S4 | +-------------------+ | Session ID Layer | +-------------------+ | Transport layer | +-------------------+ Figure 1: Multiple RTP Session On Top of Session ID Layer The Session ID layer encapsulates one RTP or RTCP packet from a given RTP session and prefixes the 2-byte Session ID layer to the packet. The Session ID layer is depicted below (Figure 2) and consists of first 2 fixed bit values (10b) followed by a 14 bits unsigned integer field with the Session ID (SID) value. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0| Session ID (SID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Session ID layer Each RTP session being multiplexed on top of a given transport layer Westerlund & Perkins Expires August 29, 2013 [Page 14] Internet-Draft Multiple RTP Session on Single Transport February 2013 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 session are for RTP Sessions that doesn't support "Multiplexing RTP Data and Control Packets on a Single Port" [RFC5761] to still be able to use a single 5-tuple. The reasons for supporting this extra functionality is that RTP and RTCP multiplexing based on the payload type/packet type fields enforces certain restrictions on the RTP sessions. These restrictions might not be acceptable. As this solution does not have these restrictions, performing RTP and RTCP multiplexing in this way has benefits. Each Session ID value space is scoped by the underlying transport protocol. Common transport protocols like UDP [RFC0768], DCCP [RFC4340], TCP [RFC0793], and SCTP [RFC4960] can all be scoped by one or more 5-tuple (Transport protocol, source address and port, destination address and port). The case of multiple 5-tuples occur in the case of multi-unicast topologies, also called meshed multiparty RTP sessions or in case any application would need more than 8192 RTP sessions. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+ |1 0| Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |V=2|P|X| CC |M| PT | sequence number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | timestamp | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | synchronization source (SSRC) identifier | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | contributing source (CSRC) identifiers | | | .... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | RTP extension (OPTIONAL) | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | payload ... | | | | +-------------------------------+ | | | | RTP padding | RTP pad count | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | ~ SRTP MKI (OPTIONAL) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : authentication tag (RECOMMENDED) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +- Encrypted Portion* Authenticated Portion ---+ Figure 3: SRTP Packet encapsulated by Session ID Layer Westerlund & Perkins Expires August 29, 2013 [Page 15] Internet-Draft Multiple RTP Session on Single Transport February 2013 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 +-------------------------------+ |1 0| Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |V=2|P| RC | PT=SR or RR | length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | SSRC of sender | | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | ~ sender info ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ report block 1 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ report block 2 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |V=2|P| SC | PT=SDES=202 | length | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | SSRC/CSRC_1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ SDES items ~ | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | ~ ... ~ | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | |E| SRTCP index | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | ~ SRTCP MKI (OPTIONAL) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : authentication tag : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-- Encrypted Portion Authenticated Portion -----+ Figure 4: SRTCP packet encapsulated by Session ID layer The processing in a receiver when the Session ID layer is present will be to 1. Pick up the packet from the lower layer transport 2. Inspect the SID field value 3. Strip the SID field from the packet 4. Forward it to the (S)RTP Session context identified by the SID value Westerlund & Perkins Expires August 29, 2013 [Page 16] Internet-Draft Multiple RTP Session on Single Transport February 2013 6.2. Signalling Note: This section might need updating as the direction of the solution for Bundle has settled and the impact of the raised issues has been analysed. The use of the Session ID layer needs to be explicitly agreed on between the communicating parties. Each RTP Session the application uses needs, in addition to the regular configuration such as payload types, RTCP extension, etc., have both the underlying 5-tuple (source address and port, destination address and port, and transport protocol) and the Session ID used for the particular RTP session. The signalling requirement is to assign unique Session ID values to all RTP Sessions being sent over the same 5-tuple. The same Session ID SHALL be used for an RTP session independently of the traffic direction. Note that nothing prevents a multi-media application from using multiple 5-tuples if desired for some reason, in which case each 5-tuple has its own session ID value space. This section defines how to negotiate the use of the Session ID layer, using the Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264]. A new SDP grouping semantics is defined "SHIM" and a new media-level SDP attribute, 'session-mux-id. The attribute allows each media description ("m=" line) associated with a 'SHIM' group to be identified in which RTP session it belongs. The 'session-mux-id' attribute is included for a media description, in order to indicate the Session ID for that particular media description. Every media description that shares a common attribute value is assumed to be part of a single RTP session. An SDP Offerer MUST include the 'session-mux-id' attribute for every media description associated with a 'SHIM' group. If the SDP Answer does not contain the SHIM group, the SDP Offerer MUST NOT use SHIM based layering. However, if that is separate RTP sessions or BUNDLE is determined on what was present in the offer and answer. This will depend on what the offering party likes to happen. If they want a failure to negotiate a SHIM, instead can be one or more bundle groups then also the BUNDLE grouping is included in the offer. If the SDP Answer still describes a 'BUNDLE' group, the procedures in [I-D.ietf-mmusic-sdp-bundle-negotiation] apply. If not independent transports and sessions are used. An SDP Answerer MUST NOT include the 'SHIM' group and 'session-mux-id' attribute in an SDP Answer, unless they where included in the SDP Offer. The attribute has the following ABNF [RFC5234] definition. Westerlund & Perkins Expires August 29, 2013 [Page 17] Internet-Draft Multiple RTP Session on Single Transport February 2013 Session-mux-id-attr = "a=session-mux-id:" SID *SID-prop SID = SID-value / SID-pairs SID-value = 1*3DIGIT / "NoN" SID-pairs = SID-value "/" SID-value ; RTP/RTCP SIDs SID-prop = SP assignment-policy / prop-ext prop-ext = token "=" value assignment-policy = "policy=" ("tentative" / "fixed") The SHIM group SHALL contain all media descriptions that are intended to be sent over the same transport flow, independent of Session ID. For all media descriptions part of the same SHIM group the transport parameters, i.e. ports, ICE-candidates, etc., MUST be the same and handled as described by BUNDLE. Note, the parameters related to the RTP session does not need to be same. For media descriptions that have the same value of the Session ID SHALL be treated the same way as if they where part of a BUNDLE group, independently if that is indicated or not in the SDP. The SID property "policy" is used in negotiation by an end-point to indicate if the session ID values are merely a tentative suggestion or if they need to have these values. This is used when negotiating SID for multi-party RTP sessions to support shared transports such as multicast or RTP translators that are unable to produce renumbered SIDs on a per end-point basis. The normal behaviour is that the offer suggest a tentative set of values, indicated by "policy=tentative". These SHOULD be accepted by the peer unless that peer negotiate session IDs on behalf of a centralized policy, in which case it MAY change the value(s) in the answer. If the offer represents a policy that does not allow changing the session ID values, it can indicate that to the answerer by setting the policy to "fixed". This enables the answering peer to either accept the value or indicate that there is a conflict in who is performing the assignment by setting the SID value to NoN (Not a Number). Offerer and answerer SHOULD always include the policy they are operating under. Thus, in case of no centralized behaviours, both offerer and answerer will indicate the tentative policy. 6.3. SRTP Key Management Key management for SRTP do needs discussion as we do cause multiple SRTP sessions to exist on the same underlying transport flow. Thus we need to ensure that the key management mechanism still are properly associated with the SRTP session context it intends to key. To ensure that we do look at the three SRTP key management mechanism that IETF has specified, one after another. Westerlund & Perkins Expires August 29, 2013 [Page 18] Internet-Draft Multiple RTP Session on Single Transport February 2013 6.3.1. Security Description Session Description Protocol (SDP) Security Descriptions for Media Streams [RFC4568] as being based on SDP has no issue with the RTP session multiplexing on lower layer specified here. The reason is that the actual keying is done using a media level SDP attribute. Thus the attribute is already associated with a particular media description. A media description that also will have an instance of the "a=session-mux-id" attribute carrying the SID value/pair used with this particular crypto parameters. 6.3.2. DTLS-SRTP Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) [RFC5764] is a keying mechanism that works on the media plane on the same lower layer transport that SRTP/SRTCP will be transported over. The most direct solution would be to use the SHIM and the SID context identifier to be applied also on DTLS packets. Thus using the same SID that is used with RTP and/or RTCP also for the DTLS message intended to key that particular SRTP and/or SRTCP flow(s). This of course requires independent usage of DTLS-SRTP for each RTP session. In addition it requires changing the layering for DTLS-SRTP as well as RTP. Thus this behaviour doesn't gain you anything in regards to key-management when using SHIM and have some costs. Instead we propose that an DTLS-SRTP key-derivation change is introduced. By including the Session ID value in the derivation of the keying material a single DTLS-SRTP key-management operation could apply keys and parameters for all the RTP sessions in the same transport flow. Thus the keying cost is significantly reduced, especially in regards to network communication and delay impact and vulnerability to packet loss. Details to be written up. 6.3.3. MIKEY MIKEY: Multimedia Internet KEYing [RFC3830] is a key management protocol that has several transports. In some cases it is used directly on a transport protocol such as UDP, but there is also a specification for how MIKEY is used with SDP "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)" [RFC4567]. Lets start with the later, i.e. the SDP transport, which shares the properties with Security Description in that is can be associated Westerlund & Perkins Expires August 29, 2013 [Page 19] Internet-Draft Multiple RTP Session on Single Transport February 2013 with a particular media description in a SDP. As long as one avoids using the session level attribute one can be certain to correctly associate the key exchange with a given SRTP/SRTCP context. It does appear that MIKEY directly over a lower layer transport protocol will have similar issues as DTLS. 6.4. Examples 6.4.1. RTP Packet with Transport Header The below figure contains an RTP packet with SID field encapsulated by a UDP packet (added UDP header). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0| Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |V=2|P|X| CC |M| PT | sequence number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | timestamp | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | synchronization source (SSRC) identifier | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | contributing source (CSRC) identifiers | | | .... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | RTP extension (OPTIONAL) | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | payload ... | | | | +-------------------------------+ | | | | RTP padding | RTP pad count | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | ~ SRTP MKI (OPTIONAL) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : authentication tag (RECOMMENDED) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +- Encrypted Portion* Authenticated Portion ---+ SRTP Packet Encapsulated by Session ID Layer Westerlund & Perkins Expires August 29, 2013 [Page 20] Internet-Draft Multiple RTP Session on Single Transport February 2013 6.4.2. SDP Offer/Answer example 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. The audio is using SID 0, and the video is using SID 1 to indicate that they are different RTP sessions despite being offered over the same 5-tuple. v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 a=group:SHIM foo bar m=audio 10000 RTP/AVP 0 8 97 b=AS:200 a=mid:foo a=session-mux-id:0 policy=tentative a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 10000 RTP/AVP 31 32 b=AS:1000 a=mid:bar a=session-mux-id:1 policy=tentative a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 The SDP answer from an end-point that supports this BUNDLEing: Westerlund & Perkins Expires August 29, 2013 [Page 21] Internet-Draft Multiple RTP Session on Single Transport February 2013 v=0 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 a=group:SHIM foo bar m=audio 20000 RTP/AVP 0 b=AS:200 a=mid:foo a=session-mux-id:0 policy=tentative a=rtpmap:0 PCMU/8000 m=video 20000 RTP/AVP 32 b=AS:1000 a=mid:bar a=session-mux-id:1 policy=tentative a=rtpmap:32 MPV/90000 The SDP answer from an end-point that does not support this SHIM. v=0 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 m=audio 20000 RTP/AVP 0 b=AS:200 a=rtpmap:0 PCMU/8000 m=video 30000 RTP/AVP 32 b=AS:1000 a=rtpmap:32 MPV/90000 6.4.2.2. Advanced Example In this example we have two BUNDLED sessions, one with audio and video and one with XOR based FEC [RFC5109] for the audio and the video. These two RTP session are then SHIMed into a single transport flow. Westerlund & Perkins Expires August 29, 2013 [Page 22] Internet-Draft Multiple RTP Session on Single Transport February 2013 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: Westerlund & Perkins Expires August 29, 2013 [Page 23] Internet-Draft Multiple RTP Session on Single Transport February 2013 v=0 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 a=group:BUNDLE 1 2 a=group:BUNDLE foo bar a=group:FEC foo 1 a=group:FEC bar 2 m=audio 20000 RTP/AVP 0 8 97 b=AS:200 a=mid:foo a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 20000 RTP/AVP 31 32 b=AS:1000 a=mid:bar a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m=audio 20002 RTP/AVP 100 b=AS:100 a=rtpmap:100 ulpfec/8000 a=mid:1 m=video 20002 RTP/AVP 101 b=AS:500 a=mid:2 a=rtpmap:101 ulpfec/90000 In the above case two different RTP sessions, both being of a BUNDLE type with multiple media types in each. The two established flows will be Alice:10000<->Bob:20000, and Alice:10000<->Bob:20002. If the peer did support neither of the SHIM or BUNDLE extension the answer would look like this: Westerlund & Perkins Expires August 29, 2013 [Page 24] Internet-Draft Multiple RTP Session on Single Transport February 2013 v=0 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 a=group:FEC foo 1 a=group:FEC bar 2 m=audio 20000 RTP/AVP 0 8 97 b=AS:200 a=mid:foo a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 20002 RTP/AVP 31 32 b=AS:1000 a=mid:bar a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 m=audio 20004 RTP/AVP 100 b=AS:100 a=rtpmap:100 ulpfec/8000 a=mid:1 m=video 20006 RTP/AVP 101 b=AS:500 a=mid:2 a=rtpmap:101 ulpfec/90000 In this case four different transport flows would be established for RTP, each with a different RTP session over them. The answer also knows the binding between the sessions with FEC and their source data thanks to the FEC specification. 7. Open Issues This work is still at a relatively early phase. This section contains a list of open issues where the author desires some input. 1. In Section 6.2 there is a discussion of which parameters that need to be configured. The scope of these rules and if they do make sense needs additional discussion. 2. Can we provide better control so that applications that doesn't desire fall back to single RTP session when Multiplexing shim fails to be supported but Bundle is supported ends up with a better alternative? Westerlund & Perkins Expires August 29, 2013 [Page 25] Internet-Draft Multiple RTP Session on Single Transport February 2013 3. The details for how to do key-derivation, preferably in such a way that it can be reused by multiple key-management solutions like MIKEY and DTLS-SRTP 4. The signalling solution will be revisited when the BUNDLE solution discussion has yield some result. 8. IANA Considerations (tbd: complete the details of the IANA registration for the SDP attribute) 9. Security Considerations The security properties of the Session ID layer is depending on what mechanism is used to protect the RTP and RTCP packets of a given RTP session. If IPsec or transport layer security solutions such as DTLS or TLS are being used then both the encapsulated RTP/RTCP packets and the session ID layer will be protected by that security mechanism. Thus potentially providing both confidentiality, integrity and source authentication. If SRTP is used, the session ID layer will not be directly protected by SRTP. However, it will be implicitly integrity protected (assuming the RTP/RTCP packet is integrity protected) as the only function of the field is to identify the session context. Thus any modification of the SID field will attempt to retrieve the wrong SRTP crypto context. If that retrieval fails, the packet will be anyway be discarded. If it is successful, the context will not lead to successful verification of the packet. 10. Acknowledgements This document is based on the input from various people, especially in the context of the RTCWEB discussion of how to use only a single lower layer transport. The RTP and RTCP packet figures are borrowed from RFC3711. The SDP example is extended from the one present in [I-D.ietf-mmusic-sdp-bundle-negotiation]. Eric Rescorla contributed the basic idea of optimizing the DTLS-SRTP key-management by modifying the key derivation process. The proposal in Appendix A.5 is original suggested by Colin Perkins. The idea in Appendix A.6 is from an Internet Draft [I-D.rosenberg-rtcweb-rtpmux] written by Jonathan Rosenberg et. al. The proposal in Appendix A.3 is a result of discussion by a group of people at IETF meeting #81 in Quebec. Westerlund & Perkins Expires August 29, 2013 [Page 26] Internet-Draft Multiple RTP Session on Single Transport February 2013 11. References 11.1. Normative References [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-bundle-negotiation-03 (work in progress), February 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 11.2. Informational References [I-D.ietf-avtcore-multi-media-rtp-session] Westerlund, M., Perkins, C., and J. Lennox, "Multiple Media Types in an RTP Session", draft-ietf-avtcore-multi-media-rtp-session-01 (work in progress), October 2012. [I-D.lennox-rtcweb-rtp-media-type-mux] Rosenberg, J. and J. Lennox, "Multiplexing Multiple Media Types In a Single Real-Time Transport Protocol (RTP) Session", draft-lennox-rtcweb-rtp-media-type-mux-00 (work in progress), October 2011. [I-D.rosenberg-rtcweb-rtpmux] Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M., Rescorla, E., and T. Terriberry, "Multiplexing of Real- Time Transport Protocol (RTP) Traffic for Browser based Real-Time Communications (RTC)", draft-rosenberg-rtcweb-rtpmux-00 (work in progress), July 2011. [I-D.westerlund-avtcore-multiplex-architecture] Westerlund & Perkins Expires August 29, 2013 [Page 27] Internet-Draft Multiple RTP Session on Single Transport February 2013 Westerlund, M., Burman, B., Perkins, C., and H. Alvestrand, "Guidelines for using the Multiplexing Features of RTP", draft-westerlund-avtcore-multiplex-architecture-02 (work in progress), July 2012. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 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. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006. [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, Westerlund & Perkins Expires August 29, 2013 [Page 28] Internet-Draft Multiple RTP Session on Single Transport February 2013 October 2008. [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009. [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010. [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Appendix A. Possible Solutions This section documents the solutions explored when selecting a SHIM based one and discusses their feasibility. A.1. Header Extension One proposal is to define an RTP header extension [RFC5285] that explicitly enumerates the session identifier in each packet. This proposal has some merits regarding RTP, since it uses an existing extension mechanism; it explicitly enumerates the session allowing for third parties to associate the packet to a given RTP session; and it works with SRTP as currently defined since a header extension is by default not encrypted, and is thus readable by the receiving stack without needing to guess which session it belongs to and attempt to decrypt it. This approach does, however, conflict with the requirement from [RFC5285] that "header extensions using this specification MUST only be used for data that can be safely ignored by the recipient", since correct processing of the received packet depends on using the header extension to demultiplex it to the correct RTP session. Using a header extension also result in the session ID is in the integrity protected part of the packet. Thus a translator between multiplexed and non-multiplexed has the options: 1. to be part of the security context to verify the field 2. to be part of the security context to verify the field and remove it before forwarding the packet 3. to be outside of the security context and leave the header extension in the packet. However, that requires successful negotiation of the header extension, but not of the Westerlund & Perkins Expires August 29, 2013 [Page 29] Internet-Draft Multiple RTP Session on Single Transport February 2013 functionality, with the receiving end-points. The biggest existing hurdle for this solution is that there exist no header extension field in the RTCP packets. This requires defining a solution for RTCP that allows carrying the explicit indicator, preferably in a position that isn't encrypted by SRTCP. However, the current SRTCP definition does not offer such a position in the packet. Modifying the RR or SR packets is possible using profile specific extensions. However, that has issues when it comes to deployment and in addition any information placed there would end up in the encrypted part. Another alternative could be to define another RTCP packet type that only contains the common header, using the 5 bits in the first byte of the common header to carry a session id. That would allow SRTCP to work correctly as long it accepts this new packet type being the first in the packet. Allowing a non-SR/RR packet as the first packet in a compound RTCP packet is also needed if an implementation is to support Reduced Size RTCP packets [RFC5506]. The remaining downside with this is that all stack implementations supporting multiplexing would need to modify its RTCP compound packet rules to include this packet type first. Thus a translator box between supporting nodes and non-supporting nodes needs to be in the crypto context. This solution's per packet overhead is expected to be 64-bits for RTCP. For RTP it is 64-bits if no header extension was otherwise used, and an additional 16 bits (short header), or 24 bits plus (if needed) padding to next 32-bits boundary if other header extensions are used. A.2. Multiplexing Shim This proposal is to prefix or postfix all RTP and RTCP packets with a session ID field. This field would be outside of the normal RTP and RTCP packets, thus having no impact on the RTP and RTCP packets and their processing. An additional step of demultiplexing processing would be added prior to RTP stack processing to determine in which RTP session context the packet is to be included. This has also no impact on SRTP/SRTCP as the shim layer would be outside of its protection context. The shim layer's session ID is however implicitly integrity protected as any error in the field will result in the packet being placed in the wrong or non-existing context, thus resulting in a integrity failure if processed by SRTP/SRTCP. This proposal is quite simple to implement in any gateway or translating device that goes from a multiplexed to a non-multiplexed Westerlund & Perkins Expires August 29, 2013 [Page 30] Internet-Draft Multiple RTP Session on Single Transport February 2013 domain or vice versa, as only an additional field needs to be added to or removed from the packet. The main downside of this proposal is that it is very likely to trigger a firewall response from any deep packet inspection device. If the field is prefixed, the RTP fields are not matching the heuristics field (unless the shim is designed to look like an RTP header, in which case the payload length is unlikely to match the expected value) and thus are likely preventing classification of the packet as an RTP packet. If it is postfixed, it is likely classified as an RTP packet but might not correctly validate if the content validation is such that the payload length is expected to match certain values. It is expected that a postfixed shim will be less problematic than a prefixed shim in this regard, but we are lacking hard data on this. This solution's per packet overhead is 1 byte. A.3. Single Session Given the difficulty of multiplexing several RTP sessions onto a single lower-layer transport, it's tempting to send multiple media 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 losing the RTP session as a separator for different type of streams. Lacking different RTP sessions to demultiplex incoming packets, a receiver will have to dig deeper into the packet before determining what to do with it. Care has to be taken in that inspection. For example, it is important to be careful to ensure that each real media source uses its own SSRC in the session and that this SSRC doesn't change media type. The loss of the RTP session as a separator for different usages or purpose would be an minor issue if the only difference between the 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 the RTP Session functionality is however severe, if the application uses the RTP Session for separating different treatments, contexts etc. Then you would need additional signalling to bind the different 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. Westerlund & Perkins Expires August 29, 2013 [Page 31] Internet-Draft Multiple RTP Session on Single Transport February 2013 Additional attention needs to be placed 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 might 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 [I-D.lennox-rtcweb-rtp-media-type-mux] and [I-D.ietf-mmusic-sdp-bundle-negotiation]. These drafts describe how to signal multiple media streams multiplexed into a single RTP session, and address some of the issues raised here and in Section 6.7 of the RTP Multiplexing Architecture [I-D.westerlund-avtcore-multiplex-architecture] draft. This method has several limitations that limits its usage as solution in providing multiple RTP sessions on the same lower layer transport. However, we acknowledge that there are some uses for which this method can be sufficient and which can accept the methods limitations and downsides. The RTCWEB WG has a working assumption to support this method. For more details of this method, see the relevant 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 will be a different question. A.4. Use the SRTP MKI field This proposal is to overload the MKI SRTP/SRTCP identifier to not only identify a particular crypto context, but also identify the actual RTP Session. This clearly is a miss use of the MKI field, however it appears to be with little negative implications. SRTP already supports handling of multiple crypto contexts. The two major downsides with this proposal is first the fact that it requires using SRTP/SRTCP to multiplex multiple sessions on a single lower layer transport. The second issue is that the session ID parameter needs to be put into the various key-management schemes and to make them understand that the reason to establish multiple crypto contexts is because they are connected to various RTP Sessions. Considering that SRTP have at least 3 used keying mechanisms, DTLS- Westerlund & Perkins Expires August 29, 2013 [Page 32] Internet-Draft Multiple RTP Session on Single Transport February 2013 SRTP [RFC5764], Security Descriptions [RFC4568], and MIKEY [RFC3830], this is not an insignificant amount of work. This solution has 32-bit per packet overhead, but only if the MKI was not already used. A.5. Use an Octet in the Padding The basics of this proposal is to have the RTP packet and the last (mandated by RFC3550) RTCP packet in a compound to include padding, at least 2 bytes. One byte for the padding count (last byte) and one byte just before the padding count containing the session ID. This proposal uses bytes to carry the session ID that have no defined value and is intended to be ignored by the receiver. From that perspective it only causes packet expansion that is supported and handled by all existing equipment. If an implementation fails to understand that it is needs to interpret this padding byte to learn the session ID, it will see a mostly coherent RTP session except where SSRCs overlap or where the payload types overlap. However, reporting on the individual sources or forwarding the RTCP RR are not completely without merit. 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 the encrypted payload of the packet. Thus, the only mechanism 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 then use the one where the packet decrypts and verifies correctly. Thus for transport flows with many crypto contexts, an attacker could simply generate packets that don't validate to force the receiver to try all crypto contexts they have rather than immediately discard it as not matching a context. A receiver can mitigate this somewhat by using heuristics based on the RTP header fields to determine which context applies for a received packet, but this is not a complete solution. This solution has a 16-bit per packet overhead. A.6. Redefine the SSRC field The Rosenberg et. al. Internet draft "Multiplexing of Real-Time Transport Protocol (RTP) Traffic for Browser based Real-Time Communications (RTC)" [I-D.rosenberg-rtcweb-rtpmux] proposed to redefine the SSRC field. This has the advantage of no packet expansion. It also looks like regular RTP. However, it has a number of implications. First of all it prevents any RTP functionality that require the same SSRC in multiple RTP sessions. Westerlund & Perkins Expires August 29, 2013 [Page 33] Internet-Draft Multiple RTP Session on Single Transport February 2013 Secondly its interoperability with end-point using multiple RTP sessions are problematic. Such interoperability will requires an SSRC translator function in the gateway node to ensure that the SSRCs fulfil the semantic rules of the different domains. That translator is actually far from easy as it needs to understand the semantics of all RTP and RTCP extensions that include SSRC/CSRC. This as it is necessary to know when a particular matching 32-bit pattern is an SSRC field and when the field is just a combination of other fields that create the same matching 32-bit pattern. Thus 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 needed. In addition the translator has to be part of the security context. This solution has no per packet overhead. Appendix B. 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 5) of the high level value are provided. B.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 4.1. B.2. Enable Same SSRC Value in Multiple RTP Sessions Based on the discussion in Section 4.2 two sub-requirements have been derived. B.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 Westerlund & Perkins Expires August 29, 2013 [Page 34] Internet-Draft Multiple RTP Session on Single Transport February 2013 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 successful in meeting this requirement. B.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. B.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 using a gateway to a domain that does not multiplex multiple RTP sessions over the same transport. Then the gateway will require to Westerlund & Perkins Expires August 29, 2013 [Page 35] Internet-Draft Multiple RTP Session on Single Transport February 2013 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. B.4. Don't Redefine Used Bits This requirement is all about RTP and RTCP header fields having a given definition ought 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 ought to 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 implementers. 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 Westerlund & Perkins Expires August 29, 2013 [Page 36] Internet-Draft Multiple RTP Session on Single Transport February 2013 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. B.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 behaviour. 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 can 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. Westerlund & Perkins Expires August 29, 2013 [Page 37] Internet-Draft Multiple RTP Session on Single Transport February 2013 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 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 can 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 can 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. B.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 can occur. In particular a third party monitor can 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. Westerlund & Perkins Expires August 29, 2013 [Page 38] Internet-Draft Multiple RTP Session on Single Transport February 2013 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. B.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. B.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. Westerlund & Perkins Expires August 29, 2013 [Page 39] Internet-Draft Multiple RTP Session on Single Transport February 2013 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 might be unnecessary) 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 fulfil the rules or semantics of the multiplexed side. For Redefine SSRC field this becomes almost constant as the session identifier part of the SSRC has to be the same over all SSRCs from the same session. For Single Session it might 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, decrypt, encrypt and create a new authentication tag cycle. In addition, the SSRC translation could potentially be a deployment obstacle for new RTP/RTCP extensions that has to be understood by the translator to be correctly translated. Therefore these two proposals gets a fail to meet the requirements. B.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: Westerlund & Perkins Expires August 29, 2013 [Page 40] Internet-Draft Multiple RTP Session on Single Transport February 2013 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 still needs to 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 5: Summary Table of Evaluation (Successfully (S), Partially (P) or Fails (F) to meet requirement) Considering these options, the authors would recommend that AVTCORE standardize a solution based on a post or prefixed multiplexing field, i.e. a shim approach combined with the appropriate signalling as described in Appendix A.2. Westerlund & Perkins Expires August 29, 2013 [Page 41] Internet-Draft Multiple RTP Session on Single Transport February 2013 Authors' Addresses Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org Westerlund & Perkins Expires August 29, 2013 [Page 42]