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 48 skipping to change at page 10, line 23
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")
skipping to change at page 27, line 12 skipping to change at page 26, line 35
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
 End of changes. 27 change blocks. 
86 lines changed or deleted 84 lines changed or added

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