draft-ietf-avt-rtp-and-rtcp-mux-06.txt   draft-ietf-avt-rtp-and-rtcp-mux-07.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: January 24, 2008 July 23, 2007 Expires: February 2, 2008 August 1, 2007
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-06.txt draft-ietf-avt-rtp-and-rtcp-mux-07.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 January 24, 2008. This Internet-Draft will expire on February 2, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 17 skipping to change at page 2, line 17
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 . . . . . . . . . . 6 5. Multiplexing RTP and RTCP on a Single Port . . . . . . . . . . 6
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 . . . . . . . . . 8 5.1.4. Interactions with Header Compression . . . . . . . . . 8
5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 8 5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 9
5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 9 5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 9
6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 10 6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 15
skipping to change at page 5, line 49 skipping to change at page 5, line 49
64-95 MUST NOT be used. Specifically, dynamic RTP payload types 64-95 MUST NOT be used. Specifically, dynamic RTP payload types
SHOULD be chosen in the range 96-127 where possible. Values below 64 SHOULD be chosen in the range 96-127 where possible. Values below 64
MAY be used if that is insufficient, in which case it is RECOMMENDED MAY be used if that is insufficient, in which case it is RECOMMENDED
that payload type numbers that are not statically assigned by [7] be that payload type numbers that are not statically assigned by [7] be
used first. used first.
Note: since all RTCP packets MUST be sent as compound packets Note: since all RTCP packets MUST be sent as compound packets
beginning with an SR or an RR packet ([1] Section 6.1), one might beginning with an SR or an RR packet ([1] Section 6.1), one might
wonder why RTP payload types other than 72 and 73 are prohibited wonder why RTP payload types other than 72 and 73 are prohibited
when multiplexing RTP and RTCP. This is done to ensure robustness when multiplexing RTP and RTCP. This is done to ensure robustness
against broken nodes which send non-compliant RTCP packets, which against nodes which send non-compound RTCP packets, which might
might otherwise be confused with multiplexed RTP packets. otherwise be confused with multiplexed RTP packets. At the time
of this writing, there is a proposal to allow non-compound RTCP
packets in some circumstances [17], so this robustness may become
more important in future.
5. Multiplexing RTP and RTCP on a Single Port 5. Multiplexing RTP and RTCP on a Single Port
The procedures for multiplexing RTP and RTCP on a single port depend The procedures for multiplexing RTP and RTCP on a single port depend
on whether the session is a unicast session or a multicast session. on whether the session is a unicast session or a multicast session.
For multicast sessions, the procedures also depend on whether Any For multicast sessions, the procedures also depend on whether Any
Source Multicast (ASM) or Source Specific Multicast (SSM) multicast Source Multicast (ASM) or Source Specific Multicast (SSM) multicast
is to be used. is to be used.
5.1. Unicast Sessions 5.1. Unicast Sessions
skipping to change at page 7, line 29 skipping to change at page 7, line 33
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 to listen for RTCP on both the RTP port This will require the offerer to 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)
[17] methodology to establish RTP sessions in the presence of Network [18] methodology to establish RTP sessions in the presence of Network
Address Translation (NAT) devices or other middleboxes. If RTP and Address Translation (NAT) devices or other middleboxes. If RTP and
RTCP are sent on separate ports, the RTP media stream comprises two RTCP are sent on separate ports, the RTP media stream comprises two
components in ICE (one for RTP and one for RTCP), with connectivity components in ICE (one for RTP and one for RTCP), with connectivity
checks being performed for each component. If RTP and RTCP are to be checks being performed for each component. If RTP and RTCP are to be
multiplexed on the same port some of these connectivity checks can be multiplexed on the same port some of these connectivity checks can be
avoided, reducing the overhead of ICE. avoided, reducing the overhead of ICE.
If it is desired to use both ICE and multiplexed RTP and RTCP, the If it is desired to use both ICE and multiplexed RTP and RTCP, the
initial offer MUST contain an "a=rtcp-mux" attribute to indicate that initial offer MUST contain an "a=rtcp-mux" attribute to indicate that
RTP and RTCP multiplexing is desired, and MUST contain "a=candidate:" RTP and RTCP multiplexing is desired, and MUST contain "a=candidate:"
skipping to change at page 8, line 22 skipping to change at page 8, line 25
session is established. If the "a=rtcp-mux" line is not present, the session is established. If the "a=rtcp-mux" line is not present, the
session proceeds with connectivity checks using both RTP and RTCP session proceeds with connectivity checks using both RTP and RTCP
candidates, eventually leading to a session being established with candidates, eventually leading to a session being established with
RTP and RTCP on separate ports (as signalled by the "a=rtcp:" RTP and RTCP on separate ports (as signalled by the "a=rtcp:"
attribute). 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)
[18] and RObust Header Compression (ROHC) [19]. Header compression [19] and RObust Header Compression (ROHC) [20]. 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. significant bandwidth savings if flows have uniform behaviour.
The presence of RTCP packets multiplexed with RTP data packets can The presence of RTCP packets multiplexed with RTP data packets can
disrupt the patterns of change between headers, and has the potential disrupt the patterns of change between headers, and has the potential
to significantly reduce header compression efficiency. The extent of to significantly reduce header compression efficiency. The extent of
this disruption depends on the header compression algorithm used, and this disruption depends on the header compression algorithm used, and
on the way flows are classified. A well designed classifier should on the way flows are classified. A well designed classifier should
skipping to change at page 13, line 18 skipping to change at page 13, line 18
Translator (Traditional NAT)", RFC 3022, January 2001. Translator (Traditional NAT)", RFC 3022, January 2001.
[15] Clark, D. and D. Tennenhouse, "Architectural Considerations for [15] 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.
[16] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM [16] 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.
[17] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [17] Johansson, I. and M. Westerlund, "Support for non-compund RTCP
in RTCP AVPF profile, opportunities and consequences",
draft-johansson-avt-rtcp-avpf-non-compound-02 (work in
progress), July 2007.
[18] 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-15 (work in Offer/Answer Protocols", draft-ietf-mmusic-ice-17 (work in
progress), March 2007. progress), July 2007.
[18] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for [19] 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.
[19] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [20] 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. 11 change blocks. 
13 lines changed or deleted 21 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/