draft-ietf-avt-rtp-and-rtcp-mux-01.txt   draft-ietf-avt-rtp-and-rtcp-mux-02.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
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: April 23, 2007 October 20, 2006 Expires: May 20, 2007 November 16, 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-01.txt draft-ietf-avt-rtp-and-rtcp-mux-02.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 23, 2007. This Internet-Draft will expire on May 20, 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 16 skipping to change at page 2, line 16
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.1.1. SDP Signalling . . . . . . . . . . . . . . . . . . . . 6 5.1.1. SDP Signalling . . . . . . . . . . . . . . . . . . . . 6
5.1.2. Interactions with SIP forking . . . . . . . . . . . . 7 5.1.2. Interactions with SIP forking . . . . . . . . . . . . 7
5.1.3. Interactions with ICE . . . . . . . . . . . . . . . . 7 5.1.3. Interactions with ICE . . . . . . . . . . . . . . . . 7
5.1.4. Interactions with Header Compression . . . . . . . . . 7 5.1.4. Interactions with Header Compression . . . . . . . . . 8
5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 8 5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 8
5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 8 5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 9
6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 9 6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14
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
such multiplexing is appropriate. The multiplexing of several types such multiplexing is appropriate. The multiplexing of several types
of media (e.g. audio and video) onto a single port is not considered of media (e.g. audio and video) onto a single port is not considered
here (but see Section 5.2 of [1]). 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 and bandwidth should be multiplexed, and how to signal multiplexed sessions, in
issues are discussion in Section 6. We conclude with security Section 5. Quality of service and bandwidth issues are discussion in
considerations in Section 7. Section 6. We conclude with security 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 [13] an implementation will be more efficient when processing [14] 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 [14] and very large-scale multicast coupled multicast conferences [15] 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 6, line 17 skipping to change at page 6, line 17
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. The following sections describe how such multiplexed in Section 4. The following sections describe how such multiplexed
sessions can be signalled using the Session Initiation Protocol (SIP) sessions can be signalled using the Session Initiation Protocol (SIP)
with the offer/answer model. with the offer/answer model.
5.1.1. SDP Signalling 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 following the offer/answer model [9], the "a=rtcp-mux"
attribute [10] is used to indicate the port chosen for RTCP traffic attribute (see Section 8) indicates the desire to multiplex RTP and
if the default of using an odd/even port pair is not desirable. If RTCP onto a single port. The initial SDP offer MUST include this
RTP and RTCP are to be multiplexed on a single port, this attribute attribute to request multiplexing of RTP and RTCP on a single port.
MUST be included in the initial SDP offer, and MUST indicate the same 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-mux
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 wishes to multiplex RTP and RTCP onto a single port
port it MUST include an "a=rtcp:" attribute in the answer, and the it MUST include an "a=rtcp-mux" attribute in the answer. The RTP
port specified in that attribute MUST be the same as that used for payload types used in the answer MUST conform to the rules in
RTP in the "m=" line of the answer. The RTP payload types used in Section 4.
the answer MUST conform to the rules in Section 4.
If the answer does not contain an "a=rtcp:" attribute, the offerer If the answer does not contain an "a=rtcp-mux" attribute, the offerer
MUST NOT multiplex RTP and RTCP packets on a single port. Instead, SHOULD 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 should 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 selection rules (either the port pair, or a signalled port
does not understand the "a=rtcp:" attribute or this specification. if the "a=rtcp:" attribute [10] is also included). This will occur
when talking to a peer that does not understand the "a=rtcp-mux"
attribute.
Answerers which support the "a=rtcp:" attribute but do not understand When SDP is used in a declarative manner, the presence of an "a=rtcp-
this memo should return an answer which does not contain an "a=rtcp:" mux" attribute signals that the sender will multiplex RTP and RTCP on
attribute (since Section 11 of [1] prohibits such sessions unless the the same port. The receiver MUST be prepared to receive RTCP packets
mechanisms described in this memo are used). It is likely that this on the RTP port, and any resource reservation needs to be made
is a poorly tested feature of older implementations, however, and including the RTCP bandwidth.
implementations should be robust to unexpected behaviour.
5.1.2. Interactions with SIP forking 5.1.2. Interactions with SIP forking
When using SIP with a forking proxy, it is possible that an INVITE When using SIP with a forking proxy, it is possible that an INVITE
request may result in multiple 200 (OK) responses. If RTP and RTCP request may result in multiple 200 (OK) responses. If RTP and RTCP
multiplexing is offered in that INVITE, it is important to be aware multiplexing is offered in that INVITE, it is important to be aware
that some answerers may support multiplexed RTP and RTCP, some not. that some answerers may support multiplexed RTP and RTCP, some not.
This will require the offerer listen for RTCP on both the RTP port 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 and the usual RTCP port, and to send RTCP on both ports, unless
branches of the call that support multiplexing are re-negotiated to branches of the call that support multiplexing are re-negotiated to
use separate RTP and RTCP ports. use separate RTP and RTCP ports.
5.1.3. Interactions with ICE 5.1.3. Interactions with ICE
It is common to use the Interactive Connectivity Establishment (ICE) It is common to use the Interactive Connectivity Establishment (ICE)
[15] methodology to establish RTP sessions in the presence of Network [16] methodology to establish RTP sessions in the presence of Network
Address Translation (NAT) devices or other middleboxes. An RTP media Address Translation (NAT) devices or other middleboxes. If RTP and
stream usually comprises two components in ICE (one for RTP and one RTCP are sent on separate ports, the RTP media stream comprises two
for RTCP), and connectivity checks are performed for each component. components in ICE (one for RTP and one for RTCP), with connectivity
The RTCP port must always be explicitly signalled using the "a=rtcp:" checks being performed for each component. If RTP and RTCP are to be
attribute when using ICE. multiplexed on the same port some of these connectivity checks can be
avoided, reducing the overhead of ICE.
When RTP and RTCP are to be multiplexed on a single UDP port, there If it is desired to use both ICE and multiplexed RTP and RTCP, the
is no need to perform ICE checks for the RTCP traffic. Accordingly, initial offer MUST contain an "a=rtcp-mux" attribute to indicate that
each RTP stream MUST be treated as comprising only a single component RTP and RTCP multiplexing is desired, and MUST contain "a=candidate:"
when multiplexing is in use (this can be detected by the port on the lines for both RTP and RTCP along with an "a=rtcp:" line indicating a
"a=rtcp:" line matching that on the "m=" line). Multiplexing RTP and fallback port for RTCP in the case that the answerer does not support
RTCP therefore cuts the number of ICE checks that must be performed RTP and RTCP multiplexing. This MUST be done for each media where
in half. RTP and RTCP multiplexing is desired.
If the answerer wishes to multiplex RTP and RTCP on a single port, it
MUST generate an answer containing an "a=rtcp-mux" attribute, and a
single "a=candidate:" line corresponding to the RTP port (i.e. there
is no candidate for RTCP), for each media where it is desired to use
RTP and RTCP multiplexing. The answerer then performs connectivity
checks for that media as if the offer had contained only a single
candidate for RTP. If the answerer does not want to multiplex RTP
and RTCP on a single port, it MUST NOT include the "a=rtcp-mux"
attribute in its answer, and MUST perform connectivity checks for all
offered candidates in the usual manner.
On receipt of the answer, the offerer looks for the presence of the
"a=rtcp-mux" line for each media where multiplexing was offered. If
this is present, then connectivity checks proceed as if only a single
candidate (for RTP) were offered, and multiplexing is used once the
session is established. If the "a=rtcp-mux" line is not present, the
session proceeds with connectivity checks using both RTP and RTCP
candidates, eventually leading to a session being established with
RTP and RTCP on separate ports (as signalled by the "a=rtcp:"
attribute).
5.1.4. Interactions with Header Compression 5.1.4. Interactions with Header Compression
Multiplexing RTP and RTCP packets onto a single port may negatively Multiplexing RTP and RTCP packets onto a single port may negatively
impact header compression schemes, for example Compressed RTP (CRTP) impact header compression schemes, for example Compressed RTP (CRTP)
[16] and RObust Header Compression (ROHC) [17]. Header compression [17] and RObust Header Compression (ROHC) [18]. Header compression
exploits patterns of change in the RTP headers of consecutive packets exploits patterns of change in the RTP headers of consecutive packets
to send an indication that the packet changed in the expected way, to send an indication that the packet changed in the expected way,
rather than sending the complete header each time. This can lead to rather than sending the complete header each time. This can lead to
significant bandwidth savings if flows have uniform behaviour. The significant bandwidth savings if flows have uniform behaviour.
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 The presence of RTCP packets multiplexed with RTP data packets can
as some wireless telephony systems, which rely on the efficiency of disrupt the patterns of change between headers, and has the potential
header compression to match the media to a limited capacity channel. to significantly reduce header compression efficiency. The extent of
this disruption depends on the header compression algorithm used, and
on the way flows are classified. A well designed classifier should
be able to separate RTP and RTCP multiplexed on the same port into
different compression contexts, using the payload type field, such
that the effect on the compression ratio is small. A classifier that
assigns compression contexts based only on the IP addresses and UDP
ports will not perform well. It is expected that implementations of
header compression will need to be updated to efficiently support RTP
and RTCP multiplexed on the same port.
The implications of multiplexing RTP and RTCP should be carefully This effect of multiplexing RTP and RTCP on header compression may be
considered before use in such environments. 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 39 skipping to change at page 9, line 26
1. RTP and RTCP flows between media sender and distribution source. 1. RTP and RTCP flows between media sender and distribution source.
In many scenarios, the media sender and distribution source are In many scenarios, the media sender and distribution source are
collocated, so multiplexing is not a concern. If the media collocated, so multiplexing is not a concern. If the media
sender and distribution source are connected by a unicast sender and distribution source are connected by a unicast
connection, the rules in Section 5.1 of this memo apply to that connection, the rules in Section 5.1 of this memo apply to that
connection. If the media sender and distribution source are connection. If the media sender and distribution source are
connected by an Any Source Multicast connection, the rules in connected by an Any Source Multicast connection, the rules in
Section 5.2 apply to that connection. If the media sender and Section 5.2 apply to that connection. If the media sender and
distribution source are connected by a Source Specific Multicast distribution source are connected by a Source Specific Multicast
connection, the RTP and RTCP packets MAY be multiplexed on a connection, the RTP and RTCP packets MAY be multiplexed on a
single port, provided this is signalled (for example, using single port, provided this is signalled (using "a=rtcp-mux" if
"a=rtcp:" with the same port number as specified for RTP on the using SDP).
"m=" line, if using SDP).
2. RTP and RTCP sent from the distribution source to the receivers. 2. RTP and RTCP sent from the distribution source to the receivers.
The distribution source MAY multiplex RTP and RTCP onto a single The distribution source MAY multiplex RTP and RTCP onto a single
port to ease NAT traversal issues on the forward SSM path, since port to ease NAT traversal issues on the forward SSM path,
this does not hinder third party monitoring. When using SDP, the although doing so may hinder third party monitoring devices if
multiplexing MUST be signalled using the "a=rtcp:" attribute [10] the session uses the simple feedback model. When using SDP, the
with the same port number as specified for RTP on the "m=" line. multiplexing SHOULD be signalled using the "a=rtcp-mux"
attribute.
3. RTCP sent from receivers to distribution source. This is an RTCP 3. RTCP sent from receivers to distribution source. This is an RTCP
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 packets on a single port in an SSM session
an SSM session than for an ASM session, since SSM sessions cannot has the potential for interactions with header compression described
readily make use of third party reception quality monitoring devices in Section 5.1.4.
that listen to the multicast RTCP traffic but not the data traffic
(since the RTCP traffic is unicast to the distribution source, rather
than multicast, and since one cannot subscribe to only the RTCP
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 combined 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 (or "b=TIAS:" [11]) line, and the RTCP traffic is limited to 5% of
reservation SHOULD therefore be made for 105% of the "b=AS:" value. this value. Any QoS reservation SHOULD therefore be made for 105% of
If a non-standard RTCP bandwidth fraction is used, signalled by the the "b=AS:" value. If a non-standard RTCP bandwidth fraction is
SDP "b=RR:" and/or "b=RS:" lines [11], then any QoS reservation used, signalled by the SDP "b=RR:" and/or "b=RS:" lines [12], then
SHOULD be made for bandwidth equal to (AS + RS + RR), taking the RS any QoS reservation SHOULD be made for bandwidth equal to (AS + RS +
and RR values from the SDP answer. 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 usage of multiplexing RTP and RTCP is not believed to introduce
applicable RTP profile (e.g. [7]) and payload format(s) apply. any new security considerations. Known major issues are, integrity
and authentication of the signalling used to setup the multiplexing,
the integrity, authentication and confidentiality of the actual RTP
and RTCP traffic. The security considerations in the RTP
specification [1] and any applicable RTP profile (e.g. [7]) and
payload format(s) apply.
If the Secure Real-time Transport Protocol (SRTP) [12] is to be used If the Secure Real-time Transport Protocol (SRTP) [13] 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. The IANA is requested to register one new SDP attribute, following
the guidelines in [8]:
o Contact name/email: authors of RFC XXXX
o Attribute name: rtcp-mux
o Type of attribute: media level
o Subject to charset: no
This attribute is used to signal that RTP and RTCP traffic should be
multiplexed on a single port (see Section 5 of this memo). It is a
property attribute, which does not take a value.
Note to RFC Editor: please replace "RFC XXXX" above with the RFC
number of this memo, and remove this note.
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, Harikishan Desineni, and Hellstrom, Randell Jesup, Hadriel Kaplan, Harikishan Desineni,
Stephan Wenger for their comments on this memo. This work is Stephan Wenger, Jonathan Rosenberg, Roni Even, and Ingemar Johansson
supported in part by the UK Engineering and Physical Sciences for their comments on this memo. This work is supported in part by
Research Council. 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 11 skipping to change at page 12, line 17
[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] Casner, S., "Session Description Protocol (SDP) Bandwidth [11] Westerlund, M., "A Transport Independent Bandwidth Modifier for
the Session Description Protocol (SDP)", RFC 3890,
September 2004.
[12] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003. July 2003.
[12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [13] 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
[13] Clark, D. and D. Tennenhouse, "Architectural Considerations for [14] 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.
[14] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM [15] 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 [16] 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 [17] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", RFC 2508, February 1999. Low-Speed Serial Links", RFC 2508, February 1999.
[17] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [18] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed", Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001. RFC 3095, July 2001.
Authors' Addresses Authors' Addresses
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
 End of changes. 36 change blocks. 
98 lines changed or deleted 149 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/