draft-perkins-avt-rtp-and-rtcp-mux-00.txt   draft-perkins-avt-rtp-and-rtcp-mux-01.txt 
Network Working Group C. Perkins Network Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Updates: 3550 (if approved) M. Westerlund Updates: 3550 (if approved) M. Westerlund
Expires: March 11, 2007 Ericsson Expires: March 24, 2007 Ericsson
September 7, 2006 September 20, 2006
Multiplexing RTP Data and Control Packets on a Single Port Multiplexing RTP Data and Control Packets on a Single Port
draft-perkins-avt-rtp-and-rtcp-mux-00.txt draft-perkins-avt-rtp-and-rtcp-mux-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 11, 2007. This Internet-Draft will expire on March 24, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This memo discusses issues that arise when multiplexing RTP data This memo discusses issues that arise when multiplexing RTP data
packets and RTP control protocol (RTCP) packets on a single UDP port. packets and RTP control protocol (RTCP) packets on a single UDP port.
It updates RFC 3550 to describe when such multiplexing is, and is It updates RFC 3550 to describe when such multiplexing is, and is
not, appropriate, and explains how the Session Description Protocol not, appropriate, and explains how the Session Description Protocol
(SDP) can be used to signal multiplexed sessions. (SDP) can be used to signal multiplexed sessions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Distinguishable RTP and RTCP Packets . . . . . . . . . . . . . 4 4. Distinguishable RTP and RTCP Packets . . . . . . . . . . . . . 4
5. Multiplexing RTP and RTCP on a Single Port . . . . . . . . . . 5 5. Multiplexing RTP and RTCP on a Single Port . . . . . . . . . . 5
5.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . . . 5 5.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . . . 6
5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 7 5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 7
5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 7 5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 7
6. Multiplexing and Quality of Service . . . . . . . . . . . . . 8 6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Introduction 1. Introduction
The Real-time Transport Protocol (RTP) [1] comprises two components: The Real-time Transport Protocol (RTP) [1] comprises two components:
a data transfer protocol, and an associated control protocol (RTCP). a data transfer protocol, and an associated control protocol (RTCP).
Historically, RTP and RTCP have been run on separate UDP ports. With Historically, RTP and RTCP have been run on separate UDP ports. With
increased use of Network Address Translation (NAT) this has become increased use of Network Address Translation (NAT) this has become
problematic, since opening multiple NAT pinholes can be costly. This problematic, since opening multiple NAT pinholes can be costly. This
memo discusses how RTP and RTCP can be run on a single port, to ease memo discusses how the RTP and RTCP flows for a single media type can
NAT traversal, and considers when such multiplexing is appropriate. be run on a single port, to ease NAT traversal, and considers when
such multiplexing is appropriate. The multiplexing of several types
of media (e.g. audio and video) onto a single port is not considered
here (but see Section 5.2 of [1]).
This memo is structured as follows: in Section 2 we discuss the This memo is structured as follows: in Section 2 we discuss the
design choices which led to the use of separate ports, and comment on design choices which led to the use of separate ports, and comment on
the applicability of those choices to current network environments. the applicability of those choices to current network environments.
We discuss terminology in Section 3, how to distinguish multiplexed We discuss terminology in Section 3, how to distinguish multiplexed
packets in Section 4, and then specify when and how RTP and RTCP packets in Section 4, and then specify when and how RTP and RTCP
should be multiplexed in Section 5. Quality of service issues are should be multiplexed in Section 5. Quality of service and bandwidth
discussion in Section 6. We conclude with security considerations in issues are discussion in Section 6. We conclude with security
Section 7. considerations in Section 7.
This memo updates Section 11 of [1]. This memo updates Section 11 of [1].
2. Background 2. Background
An RTP session comprises data packets and periodic control (RTCP) An RTP session comprises data packets and periodic control (RTCP)
packets. RTCP packets are assumed to use "the same distribution packets. RTCP packets are assumed to use "the same distribution
mechanism as the data packets" and the "underlying protocol MUST mechanism as the data packets" and the "underlying protocol MUST
provide multiplexing of the data and control packets, for example provide multiplexing of the data and control packets, for example
using separate port numbers with UDP" [1]. Multiplexing was deferred using separate port numbers with UDP" [1]. Multiplexing was deferred
to the underlying transport protocol, rather than being provided to the underlying transport protocol, rather than being provided
within RTP, for the following reasons: within RTP, for the following reasons:
1. Simplicity: an RTP implementation is simplified by moving the RTP 1. Simplicity: an RTP implementation is simplified by moving the RTP
and RTCP demultiplexing to the transport layer, since it need not and RTCP demultiplexing to the transport layer, since it need not
concern itself with the separation of data and control packets. concern itself with the separation of data and control packets.
This allows the implementation to be structured in a very natural This allows the implementation to be structured in a very natural
fashion, with a clean separation of data and control planes. fashion, with a clean separation of data and control planes.
2. Efficiency: following the principle of integrated layer 2. Efficiency: following the principle of integrated layer
processing [12] an implementation will be more efficient when processing [13] an implementation will be more efficient when
demultiplexing happens in a single place (e.g. according to UDP demultiplexing happens in a single place (e.g. according to UDP
port) than when split across multiple layers of the stack (e.g. port) than when split across multiple layers of the stack (e.g.
according to UDP port then according to packet type). according to UDP port then according to packet type).
3. To enable third party monitors: while unicast voice-over-IP has 3. To enable third party monitors: while unicast voice-over-IP has
always been considered, RTP was also designed to support loosely always been considered, RTP was also designed to support loosely
coupled multicast conferences [13] and very large-scale multicast coupled multicast conferences [14] and very large-scale multicast
streaming media applications (such as the so-called "triple-play" streaming media applications (such as the so-called "triple-play"
IPTV service). Accordingly, the design of RTP allows the RTCP IPTV service). Accordingly, the design of RTP allows the RTCP
packets to be multicast using a separate IP multicast group and packets to be multicast using a separate IP multicast group and
UDP port to the data packets. This not only allows participants UDP port to the data packets. This not only allows participants
in a session to get reception quality feedback, but also enables in a session to get reception quality feedback, but also enables
deployment of third party monitors which listen to reception deployment of third party monitors which listen to reception
quality without access to the data packets. This was intended to quality without access to the data packets. This was intended to
provide manageability of multicast sessions, without compromising provide manageability of multicast sessions, without compromising
privacy. privacy.
skipping to change at page 5, line 34 skipping to change at page 5, line 39
Given these constraints, it is RECOMMENDED to follow the guidelines Given these constraints, it is RECOMMENDED to follow the guidelines
in the RTP/AVP profile [7] for the choice of RTP payload type values, in the RTP/AVP profile [7] for the choice of RTP payload type values,
with the additional restriction that payload type values in the range with the additional restriction that payload type values in the range
64-95 MUST NOT be used. Specifically, dynamic RTP payload types 64-95 MUST NOT be used. Specifically, dynamic RTP payload types
SHOULD be chosen in the range 96-127 where possible. Values below 64 SHOULD be chosen in the range 96-127 where possible. Values below 64
MAY be used if that is insufficient, in which case it is RECOMMENDED MAY be used if that is insufficient, in which case it is RECOMMENDED
that payload type numbers that are not statically assigned by [7] be that payload type numbers that are not statically assigned by [7] be
used first. used first.
Note: since all RTCP packets MUST be sent as compound packets
beginning with an SR or an RR packet ([1] Section 6.1), one might
wonder why RTP payload types other than 72 and 73 are prohibited
when multiplexing RTP and RTCP. This is done to ensure robustness
against broken nodes which send non-compliant RTCP packets, which
might otherwise be confused with multiplexed RTP packets.
5. Multiplexing RTP and RTCP on a Single Port 5. Multiplexing RTP and RTCP on a Single Port
The procedures for multiplexing RTP and RTCP on a single port depend The procedures for multiplexing RTP and RTCP on a single port depend
on whether the session is a unicast session or a multicast session. on whether the session is a unicast session or a multicast session.
For a multicast sessions, also depends whether ASM or SSM multicast For a multicast sessions, also depends whether ASM or SSM multicast
is to be used. is to be used.
5.1. Unicast Sessions 5.1. Unicast Sessions
It is acceptable to multiplex RTP and RTCP packets on a single UDP It is acceptable to multiplex RTP and RTCP packets on a single UDP
skipping to change at page 6, line 11 skipping to change at page 6, line 23
RTP sessions according to the offer/answer model [9], the "a=rtcp:" RTP sessions according to the offer/answer model [9], the "a=rtcp:"
attribute [10] is used to indicate the port chosen for RTCP traffic, attribute [10] is used to indicate the port chosen for RTCP traffic,
if the default of using an odd/even port pair is not desirable. If if the default of using an odd/even port pair is not desirable. If
RTP and RTCP are to be multiplexed on a single port, this attribute RTP and RTCP are to be multiplexed on a single port, this attribute
MUST be included in the initial SDP offer, and MUST indicate the the MUST be included in the initial SDP offer, and MUST indicate the the
same port as included in the "m=" line. For example: same port as included in the "m=" line. For example:
v=0 v=0
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
s=- s=-
c=IN IP6 IP6 2001:DB8::211:24ff:fea3:7a2e c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
t=1153134164 1153137764 t=1153134164 1153137764
m=audio 49170 RTP/AVP 97 m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=rtcp:49170 a=rtcp:49170
This offer denotes a unicast voice-over-IP session using the RTP/AVP This offer denotes a unicast voice-over-IP session using the RTP/AVP
profile with iLBC coding. The answerer is requested to send both RTP profile with iLBC coding. The answerer is requested to send both RTP
and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e. and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e.
If the answerer supports multiplexing of RTP and RTCP onto a single If the answerer supports multiplexing of RTP and RTCP onto a single
skipping to change at page 7, line 12 skipping to change at page 7, line 23
(OK) answers will be received, some supporting multiplexed RTP and (OK) answers will be received, some supporting multiplexed RTP and
RTCP, some not. This is not an issue if a separate RTP session is RTCP, some not. This is not an issue if a separate RTP session is
established with each answerer, since multiplexing occurs on a per established with each answerer, since multiplexing occurs on a per
session basis, but does prevent a single RTP session being opened session basis, but does prevent a single RTP session being opened
between the offerer and all answerers. between the offerer and all answerers.
TODO: expand this discussion. Does SIP define if this should be a TODO: expand this discussion. Does SIP define if this should be a
single RTP session or multiple sessions? single RTP session or multiple sessions?
TODO: discuss interactions between multiplexed RTP and RTCP, and TODO: discuss interactions between multiplexed RTP and RTCP, and
Interactive Connectivity Establishment (ICE) [14]. Interactive Connectivity Establishment (ICE) [15].
5.2. Any Source Multicast Sessions 5.2. Any Source Multicast Sessions
The problem of NAT traversal is less severe for any source multicast The problem of NAT traversal is less severe for any source multicast
(ASM) RTP sessions than for unicast RTP sessions, and the benefit of (ASM) RTP sessions than for unicast RTP sessions, and the benefit of
using separate ports for RTP and RTCP is greater, due to the ability using separate ports for RTP and RTCP is greater, due to the ability
to support third party RTCP only monitors. Accordingly, RTP and RTCP to support third party RTCP only monitors. Accordingly, RTP and RTCP
packets SHOULD NOT be multiplexed onto a single port when using ASM packets SHOULD NOT be multiplexed onto a single port when using ASM
multicast RTP sessions, and SHOULD instead use separate ports and multicast RTP sessions, and SHOULD instead use separate ports and
multicast groups. multicast groups.
skipping to change at page 8, line 19 skipping to change at page 8, line 30
only path, so multiplexing is not a concern. only path, so multiplexing is not a concern.
Multiplexing RTP and RTCP onto a single port is more acceptable for Multiplexing RTP and RTCP onto a single port is more acceptable for
an SSM session than for an ASM session, since SSM sessions cannot an SSM session than for an ASM session, since SSM sessions cannot
readily make use of third party reception quality monitoring devices readily make use of third party reception quality monitoring devices
that listen to the multicast RTCP traffic but not the data traffic that listen to the multicast RTCP traffic but not the data traffic
(since the RTCP traffic is unicast to the distribution source, rather (since the RTCP traffic is unicast to the distribution source, rather
than multicast, and since one cannot subscribe to only the RTCP than multicast, and since one cannot subscribe to only the RTCP
packets on the SSM channel, even if sent on a separate port). packets on the SSM channel, even if sent on a separate port).
6. Multiplexing and Quality of Service 6. Multiplexing, Bandwidth, and Quality of Service
Multiplexing RTP and RTCP has implications on the use of Quality of Multiplexing RTP and RTCP has implications on the use of Quality of
Service (QoS) mechanism that handles flow that are determined by a Service (QoS) mechanism that handles flow that are determined by a
three or five tuple (protocol, port and address for source and/or three or five tuple (protocol, port and address for source and/or
destination). In these cases the RTCP flow will be merged with the destination). In these cases the RTCP flow will be merged with the
RTP flow when multiplexing them together. Thus the RTCP bandwidth RTP flow when multiplexing them together. Thus the RTCP bandwidth
requirement needs to be considered when doing QoS reservations for requirement needs to be considered when doing QoS reservations for
the combinded RTP and RTCP flow. However from an RTCP perspective it the combinded RTP and RTCP flow. However from an RTCP perspective it
is beneficial to receive the same treatment of RTCP packets as for is beneficial to receive the same treatment of RTCP packets as for
RTP as it provides more accurate statistics for the measurements RTP as it provides more accurate statistics for the measurements
performed by RTCP. performed by RTCP.
The bandwidth required for a multiplexed stream comprises the session
bandwidth of the RTP stream, plus the bandwidth used by RTCP. In the
usual case, the RTP session bandwidth is signalled in the SDP "b=AS:"
line, and the RTCP traffic is limited to 5% of this value. Any QoS
reservation SHOULD therefore be made for 105% of the "b=AS:" value.
If a non-standard RTCP bandwidth fraction is used, signalled by the
SDP "b=RR:" and/or "b=RS:" lines [11], then any QoS reservation
SHOULD be made for bandwidth equal to (AS + RS + RR), taking the RS
and RR values from the SDP answer.
7. Security Considerations 7. Security Considerations
The security considerations in the RTP specification [1] and any The security considerations in the RTP specification [1] and any
applicable RTP profile (e.g. [7]) and payload format(s) apply. applicable RTP profile (e.g. [7]) and payload format(s) apply.
If the Secure Real-time Transport Protocol (SRTP) [11] is to be used If the Secure Real-time Transport Protocol (SRTP) [12] is to be used
in conjunction with multiplexed RTP and RTCP, then multiplexing MUST in conjunction with multiplexed RTP and RTCP, then multiplexing MUST
be done below the SRTP layer. The sender generates SRTP and SRTCP be done below the SRTP layer. The sender generates SRTP and SRTCP
packets in the usual manner, based on their separate cryptographic packets in the usual manner, based on their separate cryptographic
contexts, and multiplexes them onto a single port immediately before contexts, and multiplexes them onto a single port immediately before
transmission. At the receiver, the cryptographic context is derived transmission. At the receiver, the cryptographic context is derived
from the SSRC, destination network address and destination transport from the SSRC, destination network address and destination transport
port number in the usual manner, augmented using the RTP payload type port number in the usual manner, augmented using the RTP payload type
and RTCP packet type to demultiplex SRTP and SRTCP according to the and RTCP packet type to demultiplex SRTP and SRTCP according to the
rules in Section 4 of this memo. After the SRTP and SRTCP packets rules in Section 4 of this memo. After the SRTP and SRTCP packets
have been demultiplexed, cryptographic processing happens in the have been demultiplexed, cryptographic processing happens in the
usual manner. usual manner.
8. IANA Considerations 8. IANA Considerations
No IANA actions are required. No IANA actions are required.
9. Acknowledgements 9. Acknowledgements
We wish to thank Steve Casner, Joerg Ott and Christer Holmberg for We wish to thank Steve Casner, Joerg Ott, Christer Holmberg, Gunnar
Hellstrom, Randell Jesup, Hadriel Kaplan and Harikishan Desineni for
their comments on this memo. This work is supported in part by the their comments on this memo. This work is supported in part by the
UK Engineering and Physical Sciences Research Council. UK Engineering and Physical Sciences Research Council.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
skipping to change at page 10, line 5 skipping to change at page 10, line 28
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[10] Huitema, C., "Real Time Control Protocol (RTCP) attribute in [10] Huitema, C., "Real Time Control Protocol (RTCP) attribute in
Session Description Protocol (SDP)", RFC 3605, October 2003. Session Description Protocol (SDP)", RFC 3605, October 2003.
[11] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [11] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.
[12] 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.
10.2. Informative References 10.2. Informative References
[12] Clark, D. and D. Tennenhouse, "Architectural Considerations for [13] Clark, D. and D. Tennenhouse, "Architectural Considerations for
a New Generation of Protocols", Proceedings of ACM a New Generation of Protocols", Proceedings of ACM
SIGCOMM 1990, September 1990. SIGCOMM 1990, September 1990.
[13] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM [14] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM
SIGCOMM Computer Communication Review, Volume 22, Number 3, SIGCOMM Computer Communication Review, Volume 22, Number 3,
July 1992. July 1992.
[14] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-10 (work in Offer/Answer Protocols", draft-ietf-mmusic-ice-10 (work in
progress), August 2006. progress), August 2006.
Authors' Addresses Authors' Addresses
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
Department of Computing Science Department of Computing Science
17 Lilybank Gardens 17 Lilybank Gardens
 End of changes. 20 change blocks. 
23 lines changed or deleted 48 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/