draft-westerlund-avtcore-transport-multiplexing-05.txt   draft-westerlund-avtcore-transport-multiplexing-06.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. S. Perkins
Expires: August 29, 2013 University of Glasgow Expires: March 01, 2014 University of Glasgow
February 25, 2013 August 28, 2013
Multiple RTP Sessions on a Single Lower-Layer Transport Multiple RTP Sessions on a Single Lower-Layer Transport
draft-westerlund-avtcore-transport-multiplexing-05 draft-westerlund-avtcore-transport-multiplexing-06
Abstract Abstract
This memo defines a mechanism to allow multiple RTP sessions to be This memo defines a mechanism to allow multiple RTP sessions to be
multiplexed onto a single lower-layer transport flow (e.g., onto a multiplexed onto a single lower-layer transport flow (e.g., onto a
single UDP 5-tuple). Requirements for multiplexing RTP sessions are single UDP 5-tuple). Requirements for multiplexing RTP sessions are
discussed, along with the trade-off between the different options. A discussed, along with the trade-off between the different options. A
shim-based multiplexing layer is proposed, along with associated shim-based multiplexing layer is proposed, along with associated
signalling. signalling.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 29, 2013. This Internet-Draft will expire on March 01, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 5 3.1. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 4
3.2. No Transport Level QoS . . . . . . . . . . . . . . . . . . 5 3.2. No Transport Level QoS . . . . . . . . . . . . . . . . . 5
3.3. Multiple RTP sessions . . . . . . . . . . . . . . . . . . 5 3.3. Multiple RTP sessions . . . . . . . . . . . . . . . . . . 5
3.4. Usage of RTP Extensions . . . . . . . . . . . . . . . . . 6 3.4. Usage of RTP Extensions . . . . . . . . . . . . . . . . . 5
3.5. Incremental Deployment . . . . . . . . . . . . . . . . . . 7 3.5. Incremental Deployment . . . . . . . . . . . . . . . . . 6
3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Support Use of Multiple RTP Sessions . . . . . . . . . . . 7 4.1. Support Use of Multiple RTP Sessions . . . . . . . . . . 7
4.2. Same SSRC Value in Multiple RTP Sessions . . . . . . . . . 8 4.2. Same SSRC Value in Multiple RTP Sessions . . . . . . . . 7
4.3. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 9 4.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . 8
4.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 9 4.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 9
4.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 9 4.6. Monitoring and Reporting . . . . . . . . . . . . . . . . 9
4.7. Usable Also Over Multicast . . . . . . . . . . . . . . . . 10 4.7. Usable Also Over Multicast . . . . . . . . . . . . . . . 9
4.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 10 4.8. Incremental Deployment . . . . . . . . . . . . . . . . . 9
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 10 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 9
5.1. Location of SHIM . . . . . . . . . . . . . . . . . . . . . 10 5.1. Location of SHIM . . . . . . . . . . . . . . . . . . . . 10
5.2. ICE and DTLS-SRTP Integration . . . . . . . . . . . . . . 12 5.2. ICE and DTLS-SRTP Integration . . . . . . . . . . . . . . 11
5.3. Signalling Fall Back . . . . . . . . . . . . . . . . . . . 12 5.3. Signalling Fall Back . . . . . . . . . . . . . . . . . . 12
6. Specification . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Specification . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Shim Layer . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Signalling . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. SRTP Key Management . . . . . . . . . . . . . . . . . . . 18 6.3. SRTP Key Management . . . . . . . . . . . . . . . . . . . 18
6.3.1. Security Description . . . . . . . . . . . . . . . . . 19 6.3.1. Security Description . . . . . . . . . . . . . . . . 18
6.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 19 6.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 18
6.3.3. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3.3. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4.1. RTP Packet with Transport Header . . . . . . . . . . . 20 6.4.1. RTP Packet with Transport Header . . . . . . . . . . 19
6.4.2. SDP Offer/Answer example . . . . . . . . . . . . . . . 21 6.4.2. SDP Offer/Answer example . . . . . . . . . . . . . . 20
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informational References . . . . . . . . . . . . . . . . . 27 11.2. Informational References . . . . . . . . . . . . . . . . 27
Appendix A. Possible Solutions . . . . . . . . . . . . . . . . . 29 Appendix A. Possible Solutions . . . . . . . . . . . . . . . . . 28
A.1. Header Extension . . . . . . . . . . . . . . . . . . . . . 29 A.1. Header Extension . . . . . . . . . . . . . . . . . . . . 28
A.2. Multiplexing Shim . . . . . . . . . . . . . . . . . . . . 30 A.2. Multiplexing Shim . . . . . . . . . . . . . . . . . . . . 30
A.3. Single Session . . . . . . . . . . . . . . . . . . . . . . 31 A.3. Single Session . . . . . . . . . . . . . . . . . . . . . 30
A.4. Use the SRTP MKI field . . . . . . . . . . . . . . . . . . 32 A.4. Use the SRTP MKI field . . . . . . . . . . . . . . . . . 32
A.5. Use an Octet in the Padding . . . . . . . . . . . . . . . 33 A.5. Use an Octet in the Padding . . . . . . . . . . . . . . . 32
A.6. Redefine the SSRC field . . . . . . . . . . . . . . . . . 33 A.6. Redefine the SSRC field . . . . . . . . . . . . . . . . . 33
Appendix B. Comparison . . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Comparison . . . . . . . . . . . . . . . . . . . . . 33
B.1. Support of Multiple RTP Sessions Over Single Transport . . 34 B.1. Support of Multiple RTP Sessions Over Single Transport . 33
B.2. Enable Same SSRC Value in Multiple RTP Sessions . . . . . 34 B.2. Enable Same SSRC Value in Multiple RTP Sessions . . . . . 34
B.2.1. Avoid SSRC Translation in Gateways/Translation . . . . 34 B.2.1. Avoid SSRC Translation in Gateways/Translation . . . 34
B.2.2. Support Existing Extensions . . . . . . . . . . . . . 35 B.2.2. Support Existing Extensions . . . . . . . . . . . . . 34
B.3. Ensure SRTP Functions . . . . . . . . . . . . . . . . . . 35 B.3. Ensure SRTP Functions . . . . . . . . . . . . . . . . . . 34
B.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . . 36 B.4. Don't Redefine Used Bits . . . . . . . . . . . . . . . . 35
B.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 37 B.5. Firewall Friendly . . . . . . . . . . . . . . . . . . . . 36
B.6. Monitoring and Reporting . . . . . . . . . . . . . . . . . 38 B.6. Monitoring and Reporting . . . . . . . . . . . . . . . . 37
B.7. Usable over Multicast . . . . . . . . . . . . . . . . . . 39 B.7. Usable over Multicast . . . . . . . . . . . . . . . . . . 38
B.8. Incremental Deployment . . . . . . . . . . . . . . . . . . 39 B.8. Incremental Deployment . . . . . . . . . . . . . . . . . 38
B.9. Summary and Conclusion . . . . . . . . . . . . . . . . . . 40 B.9. Summary and Conclusion . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
With the ongoing development of the WebRTC conferencing and CLUE With the ongoing development of the WebRTC conferencing and CLUE
telepresence standards, there is renewed interest in defining a telepresence standards, there is renewed interest in defining a
mechanism that allows multiple RTP sessions [RFC3550] to share a mechanism that allows multiple RTP sessions [RFC3550] to share a
single lower layer transport, such as a bi-directional UDP flow. The single lower layer transport, such as a bi-directional UDP flow. The
main problem driving this is the cost of doing NAT/firewall traversal main problem driving this is the cost of doing NAT/firewall traversal
for each individual RTP flow. ICE and other NAT/firewall traversal for each individual RTP flow. ICE and other NAT/firewall traversal
solutions are clearly capable of attempting to open multiple flows. solutions are clearly capable of attempting to open multiple flows.
skipping to change at page 10, line 42 skipping to change at page 10, line 17
5.1. Location of SHIM 5.1. Location of SHIM
A major question affecting the SHIM is the location of the SHIM A major question affecting the SHIM is the location of the SHIM
header providing the Identifier of the session the packet relate to. header providing the Identifier of the session the packet relate to.
This section will discuss in detail about the impact of making the This section will discuss in detail about the impact of making the
different choices. different choices.
Identified aspects to consider are: Identified aspects to consider are:
Possibility to Process: A prefixed shim header, i.e. between the Possibility to Process: A prefixed shim header, i.e. between the
transport protocol and the RTP/RTCP packet header has the transport protocol and the RTP/RTCP packet header has the
advantage that any node on the network that likes to include the advantage that any node on the network that likes to include the
header in any per-packet processing can reach it. Reasons for header in any per-packet processing can reach it. Reasons for
per-packet processing are: per-packet processing are:
A. Quality of Service classification a. Quality of Service classification
B. SHIM ingress or egress b. SHIM ingress or egress
C. Monitoring
c. Monitoring
Many routers or similar devices can only read and process the Many routers or similar devices can only read and process the
first N bytes of the whole packet, where N is commonly on the first N bytes of the whole packet, where N is commonly on the
order of 64-128 bytes. Any other type of processing means putting order of 64-128 bytes. Any other type of processing means putting
the packet on the slow path. Thus a prefixed solution enables the packet on the slow path. Thus a prefixed solution enables
this processing while a postfixed solution will most likely this processing while a postfixed solution will most likely
forever prevent this type of devices to process it. forever prevent this type of devices to process it.
Legacy Processing: Packets or at least flows of the type IP/UDP/RTP Legacy Processing: Packets or at least flows of the type IP/UDP/RTP
can in many cases be identified in Deep Packet Inspection, can in many cases be identified in Deep Packet Inspection,
skipping to change at page 17, line 47 skipping to change at page 17, line 15
not contain the SHIM group, the SDP Offerer MUST NOT use SHIM based not contain the SHIM group, the SDP Offerer MUST NOT use SHIM based
layering. However, if that is separate RTP sessions or BUNDLE is layering. However, if that is separate RTP sessions or BUNDLE is
determined on what was present in the offer and answer. This will determined on what was present in the offer and answer. This will
depend on what the offering party likes to happen. If they want a depend on what the offering party likes to happen. If they want a
failure to negotiate a SHIM, instead can be one or more bundle groups failure to negotiate a SHIM, instead can be one or more bundle groups
then also the BUNDLE grouping is included in the offer. If the SDP then also the BUNDLE grouping is included in the offer. If the SDP
Answer still describes a 'BUNDLE' group, the procedures in Answer still describes a 'BUNDLE' group, the procedures in
[I-D.ietf-mmusic-sdp-bundle-negotiation] apply. If not independent [I-D.ietf-mmusic-sdp-bundle-negotiation] apply. If not independent
transports and sessions are used. transports and sessions are used.
An SDP Answerer MUST NOT include the 'SHIM' group and An SDP Answerer MUST NOT include the 'SHIM' group and 'session-mux-
'session-mux-id' attribute in an SDP Answer, unless they where id' attribute in an SDP Answer, unless they where included in the SDP
included in the SDP Offer. 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
SID-prop = SP assignment-policy / prop-ext SID-prop = SP assignment-policy / prop-ext
prop-ext = token "=" value prop-ext = token "=" value
assignment-policy = "policy=" ("tentative" / "fixed") assignment-policy = "policy=" ("tentative" / "fixed")
The SHIM group SHALL contain all media descriptions that are intended The SHIM group SHALL contain all media descriptions that are intended
to be sent over the same transport flow, independent of Session ID. to be sent over the same transport flow, independent of Session ID.
For all media descriptions part of the same SHIM group the transport For all media descriptions part of the same SHIM group the transport
parameters, i.e. ports, ICE-candidates, etc., MUST be the same and parameters, i.e. ports, ICE-candidates, etc., MUST be the same and
handled as described by BUNDLE. Note, the parameters related to the handled as described by BUNDLE. Note, the parameters related to the
RTP session does not need to be same. RTP session does not need to be same.
For media descriptions that have the same value of the Session ID For media descriptions that have the same value of the Session ID
SHALL be treated the same way as if they where part of a BUNDLE SHALL be treated the same way as if they where part of a BUNDLE
group, independently if that is indicated or not in the SDP. group, independently if that is indicated or not in the SDP.
The SID property "policy" is used in negotiation by an end-point to The SID property "policy" is used in negotiation by an end-point to
indicate if the session ID values are merely a tentative suggestion indicate if the session ID values are merely a tentative suggestion
or if they need to have these values. This is used when negotiating or if they need to have these values. This is used when negotiating
skipping to change at page 19, line 51 skipping to change at page 19, line 19
6.3.3. MIKEY 6.3.3. MIKEY
MIKEY: Multimedia Internet KEYing [RFC3830] is a key management MIKEY: Multimedia Internet KEYing [RFC3830] is a key management
protocol that has several transports. In some cases it is used protocol that has several transports. In some cases it is used
directly on a transport protocol such as UDP, but there is also a directly on a transport protocol such as UDP, but there is also a
specification for how MIKEY is used with SDP "Key Management specification for how MIKEY is used with SDP "Key Management
Extensions for Session Description Protocol (SDP) and Real Time Extensions for Session Description Protocol (SDP) and Real Time
Streaming Protocol (RTSP)" [RFC4567]. Streaming Protocol (RTSP)" [RFC4567].
Lets start with the later, i.e. the SDP transport, which shares the Lets start with the later, i.e. the SDP transport, which shares the
properties with Security Description in that is can be associated properties with Security Description in that is can be associated
with a particular media description in a SDP. As long as one avoids with a particular media description in a SDP. As long as one avoids
using the session level attribute one can be certain to correctly using the session level attribute one can be certain to correctly
associate the key exchange with a given SRTP/SRTCP context. associate the key exchange with a given SRTP/SRTCP context.
It does appear that MIKEY directly over a lower layer transport It does appear that MIKEY directly over a lower layer transport
protocol will have similar issues as DTLS. protocol will have similar issues as DTLS.
6.4. Examples 6.4. Examples
skipping to change at page 26, line 46 skipping to change at page 26, line 24
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.ietf-mmusic-sdp-bundle-negotiation]. Eric Rescorla contributed [I-D.ietf-mmusic-sdp-bundle-negotiation]. Eric Rescorla contributed
the basic idea of optimizing the DTLS-SRTP key-management by the basic idea of optimizing the DTLS-SRTP key-management by
modifying the key derivation process. modifying the key derivation process.
The proposal in Appendix A.5 is original suggested by Colin Perkins. The proposal in Appendix A.5 is original suggested by Colin Perkins.
The idea in Appendix A.6 is from an Internet Draft The idea in Appendix A.6 is from an Internet Draft
[I-D.rosenberg-rtcweb-rtpmux] written by Jonathan Rosenberg et. al. [I-D.rosenberg-rtcweb-rtpmux] written by Jonathan Rosenberg et. al.
The proposal in Appendix A.3 is a result of discussion by a group of The proposal in Appendix A.3 is a result of discussion by a group of
people at IETF meeting #81 in Quebec. people at IETF meeting #81 in Quebec.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Multiplexing Negotiation Using Session Description "Multiplexing Negotiation Using Session Description
Protocol (SDP) Port Numbers", Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-
draft-ietf-mmusic-sdp-bundle-negotiation-03 (work in bundle-negotiation-04 (work in progress), June 2013.
progress), February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
11.2. Informational References 11.2. Informational References
[I-D.ietf-avtcore-multi-media-rtp-session] [I-D.ietf-avtcore-multi-media-rtp-session]
Westerlund, M., Perkins, C., and J. Lennox, "Multiple Westerlund, M., Perkins, C., and J. Lennox, "Sending
Media Types in an RTP Session", Multiple Types of Media in a Single RTP Session", draft-
draft-ietf-avtcore-multi-media-rtp-session-01 (work in ietf-avtcore-multi-media-rtp-session-03 (work in
progress), October 2012. progress), July 2013.
[I-D.lennox-rtcweb-rtp-media-type-mux] [I-D.lennox-rtcweb-rtp-media-type-mux]
Rosenberg, J. and J. Lennox, "Multiplexing Multiple Media Rosenberg, J. and J. Lennox, "Multiplexing Multiple Media
Types In a Single Real-Time Transport Protocol (RTP) Types In a Single Real-Time Transport Protocol (RTP)
Session", draft-lennox-rtcweb-rtp-media-type-mux-00 (work Session", draft-lennox-rtcweb-rtp-media-type-mux-00 (work
in progress), October 2011. in progress), October 2011.
[I-D.rosenberg-rtcweb-rtpmux] [I-D.rosenberg-rtcweb-rtpmux]
Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M., Rosenberg, J., Jennings, C., Peterson, J., Kaufman, M.,
Rescorla, E., and T. Terriberry, "Multiplexing of Real- Rescorla, E., and T. Terriberry, "Multiplexing of Real-
Time Transport Protocol (RTP) Traffic for Browser based Time Transport Protocol (RTP) Traffic for Browser based
Real-Time Communications (RTC)", Real-Time Communications (RTC)", draft-rosenberg-rtcweb-
draft-rosenberg-rtcweb-rtpmux-00 (work in progress), 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., Perkins, C., and H. Westerlund, M., Perkins, C., and H. Alvestrand,
Alvestrand, "Guidelines for using the Multiplexing "Guidelines for using the Multiplexing Features of RTP",
Features of RTP", draft-westerlund-avtcore-multiplex-architecture-03 (work
draft-westerlund-avtcore-multiplex-architecture-02 (work in progress), February 2013.
in progress), July 2012.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
RFC 793, September 1981. 793, September 1981.
[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
June 2002. 2002.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
RFC 4960, September 2007. 4960, September 2007.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, December 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245, April
April 2010. 2010.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
skipping to change at page 32, line 21 skipping to change at page 31, line 39
SSRC space, while the other end-points have multiple spaces. Thus SSRC space, while the other end-points have multiple spaces. Thus
translation might have to occur because there is several RTP sessions translation might have to occur because there is several RTP sessions
using the same SSRC value. This has both limitations, processing using the same SSRC value. This has both limitations, processing
overhead and the possibility of becoming an deployment obstacle for overhead and the possibility of becoming an deployment obstacle for
new RTP/RTCP extensions. new RTP/RTCP extensions.
This approach has been proposed in the RTCWeb context in This approach has been proposed in the RTCWeb context in
[I-D.lennox-rtcweb-rtp-media-type-mux] and [I-D.lennox-rtcweb-rtp-media-type-mux] and
[I-D.ietf-mmusic-sdp-bundle-negotiation]. These drafts describe how [I-D.ietf-mmusic-sdp-bundle-negotiation]. These drafts describe how
to signal multiple media streams multiplexed into a single RTP to signal multiple media streams multiplexed into a single RTP
session, and address some of the issues raised here and in Section session, and address some of the issues raised here and in
6.7 of the RTP Multiplexing Architecture Section 6.7 of the RTP Multiplexing Architecture
[I-D.westerlund-avtcore-multiplex-architecture] draft. [I-D.westerlund-avtcore-multiplex-architecture] draft.
This method has several limitations that limits its usage as solution This method has several limitations that limits its usage as solution
in providing multiple RTP sessions on the same lower layer transport. in providing multiple RTP sessions on the same lower layer transport.
However, we acknowledge that there are some uses for which this However, we acknowledge that there are some uses for which this
method can be sufficient and which can accept the methods limitations method can be sufficient and which can accept the methods limitations
and downsides. The RTCWEB WG has a working assumption to support and downsides. The RTCWEB WG has a working assumption to support
this method. For more details of this method, see the relevant this method. For more details of this method, see the relevant
drafts under development. We do include this method in the drafts under development. We do include this method in the
comparison to provide a more complete picture of the pro and cons of comparison to provide a more complete picture of the pro and cons of
skipping to change at page 33, line 45 skipping to change at page 33, line 15
try all crypto contexts they have rather than immediately discard it try all crypto contexts they have rather than immediately discard it
as not matching a context. A receiver can mitigate this somewhat by as not matching a context. A receiver can mitigate this somewhat by
using heuristics based on the RTP header fields to determine which using heuristics based on the RTP header fields to determine which
context applies for a received packet, but this is not a complete context applies for a received packet, but this is not a complete
solution. solution.
This solution has a 16-bit per packet overhead. This solution has a 16-bit per packet overhead.
A.6. Redefine the SSRC field A.6. Redefine the SSRC field
The Rosenberg et. al. Internet draft "Multiplexing of Real-Time The Rosenberg et. al. Internet draft "Multiplexing of Real-Time
Transport Protocol (RTP) Traffic for Browser based Real-Time Transport Protocol (RTP) Traffic for Browser based Real-Time
Communications (RTC)" [I-D.rosenberg-rtcweb-rtpmux] proposed to Communications (RTC)" [I-D.rosenberg-rtcweb-rtpmux] proposed to
redefine the SSRC field. This has the advantage of no packet redefine the SSRC field. This has the advantage of no packet
expansion. It also looks like regular RTP. However, it has a number expansion. It also looks like regular RTP. However, it has a number
of implications. First of all it prevents any RTP functionality that of implications. First of all it prevents any RTP functionality that
require the same SSRC in multiple RTP sessions. require the same SSRC in multiple RTP sessions.
Secondly its interoperability with end-point using multiple RTP Secondly its interoperability with end-point using multiple RTP
sessions are problematic. Such interoperability will requires an sessions are problematic. Such interoperability will requires an
SSRC translator function in the gateway node to ensure that the SSRCs SSRC translator function in the gateway node to ensure that the SSRCs
skipping to change at page 41, line 25 skipping to change at page 40, line 43
4: Don't Redefine used bits 4: Don't Redefine used bits
5: Firewall Friendly 5: Firewall Friendly
6: Monitoring and Reporting still needs to function 6: Monitoring and Reporting still needs to function
7: Usable over Multicast 7: Usable over Multicast
8: Incremental deployment 8: Incremental deployment
OH: Overhead in Bytes. + means variable OH: Overhead in Bytes. + means variable
---------------+---+---+---+---+---+---+---+---+---+---- ---------------+---+---+---+---+---+---+---+---+---+----
Solution | 1 |2.1|2.2| 3 | 4 | 5 | 6 | 7 | 8 | OH Solution | 1 |2.1|2.2| 3 | 4 | 5 | 6 | 7 | 8 | OH
---------------+---+---+---+---+---+---+---+---+---+---- ---------------+---+---+---+---+---+---+---+---+---+----
Header Ext. | S | S | P | P | F | P | F | S | P | 8+ Header Ext. | S | S | P | P | F | P | F | S | P | 8+
Multiplex Shim | S | S | S | S | S | P | F | S | S | 1 Multiplex Shim | S | S | S | S | S | P | F | S | S | 1
Single Session | F | F | F | S | S | P | S | S | F | 0 Single Session | F | F | F | S | S | P | S | S | F | 0
SRTP MKI Field | S | S | S | P | F | P | F | S | S | 4 SRTP MKI Field | S | S | S | P | F | P | F | S | S | 4
Padding Field | S | S | S | F | P | P | F | S | P | 2 Padding Field | S | S | S | F | P | P | F | S | P | 2
Redefine SSRC | S | F | F | P | F | P | P | S | S | 0 Redefine SSRC | S | F | F | P | F | P | P | S | S | 0
---------------+---+---+---+---+---+---+---+---+---+---- ---------------+---+---+---+---+---+---+---+---+---+----
Figure 5: Summary Table of Evaluation (Successfully (S), Partially Figure 5: Summary Table of Evaluation (Successfully (S), Partially
(P) or Fails (F) to meet requirement) (P) or Fails (F) to meet requirement)
Considering these options, the authors would recommend that AVTCORE Considering these options, the authors would recommend that AVTCORE
standardize a solution based on a post or prefixed multiplexing standardize a solution based on a post or prefixed multiplexing
field, i.e. a shim approach combined with the appropriate signalling field, i.e. a shim approach combined with the appropriate signalling
as described in Appendix A.2. as described in Appendix A.2.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE-164 80 Kista SE-164 80 Kista
Sweden Sweden
 End of changes. 25 change blocks. 
113 lines changed or deleted 111 lines changed or added

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