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