draft-ietf-avt-rtp-and-rtcp-mux-00.txt   draft-ietf-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: April 2, 2007 Ericsson Intended status: Standards Track Ericsson
September 29, 2006 Expires: April 23, 2007 October 20, 2006
Multiplexing RTP Data and Control Packets on a Single Port Multiplexing RTP Data and Control Packets on a Single Port
draft-ietf-avt-rtp-and-rtcp-mux-00.txt draft-ietf-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 April 2, 2007. This Internet-Draft will expire on April 23, 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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
(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 . . . . . . . . . . . . . . . . . . . . . 6 5.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . . . 6
5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 7 5.1.1. SDP Signalling . . . . . . . . . . . . . . . . . . . . 6
5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 7 5.1.2. Interactions with SIP forking . . . . . . . . . . . . 7
6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 8 5.1.3. Interactions with ICE . . . . . . . . . . . . . . . . 7
5.1.4. Interactions with Header Compression . . . . . . . . . 7
5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 8
5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 8
6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13
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 the RTP and RTCP flows for a single media type can memo discusses how the RTP and RTCP flows for a single media type can
be run on a single port, to ease NAT traversal, and considers when be run on a single port, to ease NAT traversal, and considers when
skipping to change at page 6, line 10 skipping to change at page 6, line 10
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
port to ease NAT traversal for unicast sessions, provided the RTP port to ease NAT traversal for unicast sessions, provided the RTP
payload types used in the session are chosen according to the rules payload types used in the session are chosen according to the rules
in Section 4. in Section 4. The following sections describe how such multiplexed
sessions can be signalled using the Session Initiation Protocol (SIP)
with the offer/answer model.
5.1.1. SDP Signalling
When the Session Description Protocol (SDP) [8] is used to negotiate When the Session Description Protocol (SDP) [8] is used to negotiate
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 same
same port as included in the "m=" line. For example: 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 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
port it MUST include an "a=rtcp:" attribute in the answer. The port port it MUST include an "a=rtcp:" attribute in the answer, and the
specified in that attribute MUST be the same as that used for RTP in port specified in that attribute MUST be the same as that used for
the "m=" line of the answer. The RTP payload types used MUST conform RTP in the "m=" line of the answer. The RTP payload types used in
to the rules in Section 4, and the answer MUST be rejected if there the answer MUST conform to the rules in Section 4.
is a conflict between the chosen RTP payload types and the expected
RTCP packet types.
If the answer does not contain an "a=rtcp:" attribute, the offerer If the answer does not contain an "a=rtcp:" attribute, the offerer
MUST NOT multiplex RTP and RTCP packets on a single port. Instead, MUST NOT multiplex RTP and RTCP packets on a single port. Instead,
it must send and receive RTCP on a port allocated according to the it must send and receive RTCP on a port allocated according to the
usual port pair rules. This will occur when talking to a peer that usual port pair rules. This will occur when talking to a peer that
does not understand the "a=rtcp:" attribute or this specification. does not understand the "a=rtcp:" attribute or this specification.
If the answer contains an "a=rtcp:" attribute, but that attribute
specifies a different port for RTCP than for RTP, then the answer
MUST be rejected, and the session re-negotiated using separate RTP
and RTCP ports.
Answerers which support the "a=rtcp:" attribute but do not understand Answerers which support the "a=rtcp:" attribute but do not understand
this memo should reject sessions where the RTP and RTCP ports are the this memo should return an answer which does not contain an "a=rtcp:"
same (Section 11 of [1] prohibits such sessions unless the mechanisms attribute (since Section 11 of [1] prohibits such sessions unless the
described in this memo are used). It is likely that this is a poorly mechanisms described in this memo are used). It is likely that this
tested feature of older implementations, however, and implementations is a poorly tested feature of older implementations, however, and
should be robust to unexpected behaviour. If the offerer suspects a implementations should be robust to unexpected behaviour.
session was rejected due to the presence of multiplexed RTP and RTCP,
it MAY retry the offer using separate ports for RTP and RTCP.
When using SIP with a forking proxy, it is possible that multiple 200 5.1.2. Interactions with SIP forking
(OK) answers will be received, some supporting multiplexed RTP and
RTCP, some not. This is not an issue if a separate RTP session is
established with each answerer, since multiplexing occurs on a per
session basis, but does prevent a single RTP session being opened
between the offerer and all answerers.
TODO: expand this discussion. Does SIP define if this should be a When using SIP with a forking proxy, it is possible that an INVITE
single RTP session or multiple sessions? request may result in multiple 200 (OK) responses. If RTP and RTCP
multiplexing is offered in that INVITE, it is important to be aware
that some answerers may support multiplexed RTP and RTCP, some not.
This will require the offerer listen for RTCP on both the RTP port
and the usual RTCP port, and to send RTCP on both ports, unless
branches of the call that support multiplexing are re-negotiated to
use separate RTP and RTCP ports.
TODO: discuss interactions between multiplexed RTP and RTCP, and 5.1.3. Interactions with ICE
Interactive Connectivity Establishment (ICE) [15].
It is common to use the Interactive Connectivity Establishment (ICE)
[15] methodology to establish RTP sessions in the presence of Network
Address Translation (NAT) devices or other middleboxes. An RTP media
stream usually comprises two components in ICE (one for RTP and one
for RTCP), and connectivity checks are performed for each component.
The RTCP port must always be explicitly signalled using the "a=rtcp:"
attribute when using ICE.
When RTP and RTCP are to be multiplexed on a single UDP port, there
is no need to perform ICE checks for the RTCP traffic. Accordingly,
each RTP stream MUST be treated as comprising only a single component
when multiplexing is in use (this can be detected by the port on the
"a=rtcp:" line matching that on the "m=" line). Multiplexing RTP and
RTCP therefore cuts the number of ICE checks that must be performed
in half.
5.1.4. Interactions with Header Compression
Multiplexing RTP and RTCP packets onto a single port may negatively
impact header compression schemes, for example Compressed RTP (CRTP)
[16] and RObust Header Compression (ROHC) [17]. Header compression
exploits patterns of change in the RTP headers of consecutive packets
to send an indication that the packet changed in the expected way,
rather than sending the complete header each time. This can lead to
significant bandwidth savings if flows have uniform behaviour. The
presence of RTCP packets multiplexed with RTP data packets disrupts
these patterns, however, and can significantly reduce the gains
available due to header compression.
This effect may be especially significant in those environments, such
as some wireless telephony systems, which rely on the efficiency of
header compression to match the media to a limited capacity channel.
The implications of multiplexing RTP and RTCP should be carefully
considered before use in such environments.
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 38 skipping to change at page 9, line 21
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, Bandwidth, 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 combined 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 The bandwidth required for a multiplexed stream comprises the session
bandwidth of the RTP stream, plus the bandwidth used by RTCP. In the 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:" 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 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. reservation SHOULD therefore be made for 105% of the "b=AS:" value.
If a non-standard RTCP bandwidth fraction is used, signalled by the If a non-standard RTCP bandwidth fraction is used, signalled by the
skipping to change at page 9, line 31 skipping to change at page 10, line 14
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, Christer Holmberg, Gunnar We wish to thank Steve Casner, Joerg Ott, Christer Holmberg, Gunnar
Hellstrom, Randell Jesup, Hadriel Kaplan and Harikishan Desineni for Hellstrom, Randell Jesup, Hadriel Kaplan, Harikishan Desineni, and
their comments on this memo. This work is supported in part by the Stephan Wenger for their comments on this memo. This work is
UK Engineering and Physical Sciences Research Council. supported in part by the 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.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
skipping to change at page 11, line 5 skipping to change at page 11, line 34
[14] 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.
[15] 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.
[16] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", RFC 2508, February 1999.
[17] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001.
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
Glasgow G12 8QQ Glasgow G12 8QQ
UK UK
Email: csp@csperkins.org Email: csp@csperkins.org
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Torshamgatan 23 Torshamgatan 23
Stockholm SE-164 80 Stockholm SE-164 80
Sweden Sweden
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 12, line 29 skipping to change at page 13, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 21 change blocks. 
66 lines changed or deleted 112 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/