draft-ietf-avt-rtp-and-rtcp-mux-04.txt		draft-ietf-avt-rtp-and-rtcp-mux-05.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: September 4, 2007 March 3, 2007		Expires: November 22, 2007 May 21, 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-04.txt		draft-ietf-avt-rtp-and-rtcp-mux-05.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 September 4, 2007.		This Internet-Draft will expire on November 22, 2007.
	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 4, line 18 ¶		skipping to change at page 4, line 18 ¶
	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.
	While these design choices are appropriate for many use of RTP, they		While these design choices are appropriate for many uses of RTP, they
	are problematic in some cases. There are many RTP deployments which		are problematic in some cases. There are many RTP deployments which
	don't use IP multicast, and with the increased use of Network Address		don't use IP multicast, and with the increased use of Network Address
	Translation (NAT) the simplicity of multiplexing at the transport		Translation (NAT) the simplicity of multiplexing at the transport
	layer has become a liability, since it requires complex signalling to		layer has become a liability, since it requires complex signalling to
	open multiple NAT pinholes. In environments such as these, it is		open multiple NAT pinholes. In environments such as these, it is
	desirable to provide an alternative to demultiplexing RTP and RTCP		desirable to provide an alternative to demultiplexing RTP and RTCP
	using separate UDP ports, instead using only a single UDP port and		using separate UDP ports, instead using only a single UDP port and
	demultiplexing within the application.		demultiplexing within the application.
	This memo provides such an alternative by multiplexing RTP and RTCP		This memo provides such an alternative by multiplexing RTP and RTCP
	skipping to change at page 5, line 51 ¶		skipping to change at page 5, line 51 ¶
	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 broken nodes which send non-compliant RTCP packets, which
	might otherwise be confused with multiplexed RTP packets.		might otherwise be confused with multiplexed RTP packets.
	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 ASM or		For multicast sessions, the procedures also depend on whether Any
	SSM multicast is to be used.		Source Multicast (ASM) or Source Specific Multicast (SSM) multicast
			is to be used.
	5.1. Unicast Sessions		5.1. Unicast Sessions
	It is acceptable to multiplex RTP and RTCP packets on a single UDP		It is acceptable to multiplex RTP and RTCP packets on a single UDP
	port to ease NAT traversal for unicast sessions, provided the RTP		port to ease NAT traversal for unicast sessions, provided the RTP
	payload types used in the session are chosen according to the rules		payload types used in the session are chosen according to the rules
	in Section 4, and provided that multiplexing is signalled in advance.		in Section 4, and provided that multiplexing is signalled in advance.
	The following sections describe how such multiplexed sessions can be		The following sections describe how such multiplexed sessions can be
	signalled using the Session Initiation Protocol (SIP) with the offer/		signalled using the Session Initiation Protocol (SIP) with the offer/
	answer model.		answer model.
	skipping to change at page 7, line 15 ¶		skipping to change at page 7, line 17 ¶
	the same port. The receiver MUST be prepared to receive RTCP packets		the same port. The receiver MUST be prepared to receive RTCP packets
	on the RTP port, and any resource reservation needs to be made		on the RTP port, and any resource reservation needs to be made
	including the RTCP bandwidth.		including the RTCP bandwidth.
	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 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)
	[16] 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. 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
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	[4] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,		[4] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
	"Extended RTP Profile for Real-time Transport Control Protocol		"Extended RTP Profile for Real-time Transport Control Protocol
	(RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.		(RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
	[5] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol		[5] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
	Extended Reports (RTCP XR)", RFC 3611, November 2003.		Extended Reports (RTCP XR)", RFC 3611, November 2003.
	[6] Chesterfield, J., Ott, J., and E. Schooler, "RTCP Extensions		[6] Chesterfield, J., Ott, J., and E. Schooler, "RTCP Extensions
	for Single-Source Multicast Sessions with Unicast Feedback",		for Single-Source Multicast Sessions with Unicast Feedback",
	draft-ietf-avt-rtcpssm-12 (work in progress), October 2006.		draft-ietf-avt-rtcpssm-13 (work in progress), March 2007.
	[7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video		[7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
	Conferences with Minimal Control", STD 65, RFC 3551, July 2003.		Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
	[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.
	skipping to change at page 12, line 43 ¶		skipping to change at page 12, line 43 ¶
	[14] 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.
	[15] 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.
	[16] 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-13 (work in		Offer/Answer Protocols", draft-ietf-mmusic-ice-15 (work in
	progress), January 2007.		progress), March 2007.
	[17] 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.
	[18] 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.
End of changes. 8 change blocks.
	10 lines changed or deleted		11 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/