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.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |