draft-ietf-avt-rtp-and-rtcp-mux-05.txt		draft-ietf-avt-rtp-and-rtcp-mux-06.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: November 22, 2007 May 21, 2007		Expires: January 24, 2008 July 23, 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-05.txt		draft-ietf-avt-rtp-and-rtcp-mux-06.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 November 22, 2007.		This Internet-Draft will expire on January 24, 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
	not, appropriate, and explains how the Session Description Protocol		not, appropriate, and explains how the Session Description Protocol
	(SDP) can be used to signal multiplexed sessions.		(SDP) can be used to signal multiplexed sessions.
	Table of Contents		Table of Contents
	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 . . . . . . . . . . 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 . . . . . . . . . . . . . . 8
	5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 9		5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 9
	6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 9		6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 11		10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	10.2. Informative References . . . . . . . . . . . . . . . . . . 12		10.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	Intellectual Property and Copyright Statements . . . . . . . . . . 14		Intellectual Property and Copyright Statements . . . . . . . . . . 15
	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 Port Translation (NAPT) [14] this
	problematic, since opening multiple NAT pinholes can be costly. This		has become problematic, since maintaining multiple NAT bindings can
	memo discusses how the RTP and RTCP flows for a single media type can		be costly. It also complicates firewall administration, since
	be run on a single port, to ease NAT traversal, and considers when		multiple ports must be opened to allow RTP traffic. This memo
	such multiplexing is appropriate. The multiplexing of several types		discusses how the RTP and RTCP flows for a single media type can be
	of media (e.g. audio and video) onto a single port is not considered		run on a single port, to ease NAT traversal and simplify firewall
	here (but see Section 5.2 of [1]).		administration, and considers when such multiplexing is appropriate.
			The multiplexing of several types of media (e.g. audio and video)
			onto a single port is not considered 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, and how to signal multiplexed sessions, in		should be multiplexed, and how to signal multiplexed sessions, in
	Section 5. Quality of service and bandwidth issues are discussion in		Section 5. Quality of service and bandwidth issues are discussion in
	Section 6. We conclude with security considerations in Section 7.		Section 6. We conclude with security considerations in Section 7.
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 49 ¶
	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 [14] an implementation will be more efficient when		processing [15] 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 [15] and very large-scale multicast		coupled multicast conferences [16] 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 4, line 41 ¶		skipping to change at page 4, line 43 ¶
	the RTP implementation, in exchange for simplified NAT traversal.		the RTP implementation, in exchange for simplified NAT traversal.
	3. Terminology		3. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [2].		document are to be interpreted as described in RFC 2119 [2].
	4. Distinguishable RTP and RTCP Packets		4. Distinguishable RTP and RTCP Packets
	When RTP and RTCP packets are multiplexed onto a single port, they		When RTP and RTCP packets are multiplexed onto a single port, the
	can be distinguished provided: 1) the RTP payload type (PT) values		RTCP packet type field occupies the same position in the packet as
			the combination of the RTP marker (M) bit and the RTP payload type
			(PT). This field can be used to distinguish RTP and RTCP packets
			when two restrictions are observed: 1) the RTP payload type values
	used are distinct from the RTCP packet types used; and 2) for each		used are distinct from the RTCP packet types used; and 2) for each
	RTP payload type, PT+128 is distinct from the RTCP packet types used.		RTP payload type (PT), PT+128 is distinct from the RTCP packet types
	The first constraint precludes a direct conflict between RTP payload		used. The first constraint precludes a direct conflict between RTP
	type and RTCP packet type, the second constraint precludes a conflict		payload type and RTCP packet type, the second constraint precludes a
	between an RTP data packet with marker bit set and an RTCP packet.		conflict between an RTP data packet with the marker bit set and an
	This demultiplexing method works because the RTP payload type and		RTCP packet.
	RTCP packet type occupy the same position within the packet.
	The following conflicts between RTP and RTCP packet types are known:		The following conflicts between RTP and RTCP packet types are known:
	o RTP payload types 64-65 conflict with the (obsolete) RTCP FIR and		o RTP payload types 64-65 conflict with the (obsolete) RTCP FIR and
	NACK packets defined in the original RTP Payload Format for H.261		NACK packets defined in the original RTP Payload Format for H.261
	[3].		[3].
	o RTP payload types 72-76 conflict with the RTCP SR, RR, SDES, BYE		o RTP payload types 72-76 conflict with the RTCP SR, RR, SDES, BYE
	and APP packets defined in the RTP specification [1].		and APP packets defined in the RTP specification [1].
	skipping to change at page 5, line 29 ¶		skipping to change at page 5, line 32 ¶
	o RTP payload type 80 conflicts with Receiver Summary Information		o RTP payload type 80 conflicts with Receiver Summary Information
	(RSI) packets defined in the RTCP Extensions for Single-Source		(RSI) packets defined in the RTCP Extensions for Single-Source
	Multicast Sessions with Unicast Feedback [6].		Multicast Sessions with Unicast Feedback [6].
	New RTCP packet types may be registered in future, and will further		New RTCP packet types may be registered in future, and will further
	reduce the RTP payload types that are available when multiplexing RTP		reduce the RTP payload types that are available when multiplexing RTP
	and RTCP onto a single port. To allow this multiplexing, future RTCP		and RTCP onto a single port. To allow this multiplexing, future RTCP
	packet type assignments SHOULD be made after the current assignments		packet type assignments SHOULD be made after the current assignments
	in the range 209-223, then in the range 194-199, so that only the RTP		in the range 209-223, then in the range 194-199, so that only the RTP
	payload types in the range 64-95 are blocked.		payload types in the range 64-95 are blocked. RTCP packet types in
			the ranges 1-191 and 224-254 SHOULD only be used when other values
			have been exhausted.
	Given these constraints, it is RECOMMENDED to follow the guidelines		Given these constraints, it is RECOMMENDED to follow the guidelines
	in the RTP/AVP profile [7] for the choice of RTP payload type values,		in the RTP/AVP profile [7] for the choice of RTP payload type values,
	with the additional restriction that payload type values in the range		with the additional restriction that payload type values in the range
	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.
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 29 ¶
	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)
	[16] methodology to establish RTP sessions in the presence of Network		[17] 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 17 ¶		skipping to change at page 8, line 22 ¶
	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)
	[17] and RObust Header Compression (ROHC) [18]. Header compression		[18] and RObust Header Compression (ROHC) [19]. 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 11, line 16 ¶		skipping to change at page 11, line 24 ¶
	o Long-form attribute name: RTP and RTCP multiplexed on one port		o Long-form attribute name: RTP and RTCP multiplexed on one port
	o Type of attribute: media level		o Type of attribute: media level
	o Subject to charset: no		o Subject to charset: no
	This attribute is used to signal that RTP and RTCP traffic should be		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		multiplexed on a single port (see Section 5 of this memo). It is a
	property attribute, which does not take a value.		property attribute, which does not take a value.
			The rules for assignment of RTP RTCP Control Packet Types in the RTP
			Parameters registry are updated as follows. When assigning RTP RTCP
			Control Packet types, IANA is requested to assign unused values from
			the range 200-223 where possible. If that range is fully occupied,
			values from the range 194-199 may be used, and then values from the
			ranges 1-191 and 224-254. This improves header validity checking of
			RTCP packets compared to RTP packets or other unrelated packets. The
			values 0 and 255 are avoided for improved validity checking relative
			to random packets since all-zeros and all-ones are common values.
	Note to RFC Editor: please replace "RFC XXXX" above with the RFC		Note to RFC Editor: please replace "RFC XXXX" above with the RFC
	number of this memo, and remove this note.		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,		Hellstrom, Randell Jesup, Hadriel Kaplan, Harikishan Desineni,
	Stephan Wenger, Jonathan Rosenberg, Roni Even, Ingemar Johansson,		Stephan Wenger, Jonathan Rosenberg, Roni Even, Ingemar Johansson,
	Dave Singer, and Kevin Johns for their comments on this memo. This		Dave Singer, Kevin Johns, and David Black for their comments on this
	work was supported in part by the UK Engineering and Physical		memo. This work was supported in part by the UK Engineering and
	Sciences Research Council.		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
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[3] Turletti, T., "RTP Payload Format for H.261 Video Streams",		[3] Turletti, T., "RTP Payload Format for H.261 Video Streams",
	skipping to change at page 12, line 33 ¶		skipping to change at page 13, line 7 ¶
	[12] Casner, S., "Session Description Protocol (SDP) Bandwidth		[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.
	[13] 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
	[14] Clark, D. and D. Tennenhouse, "Architectural Considerations for		[14] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
			Translator (Traditional NAT)", RFC 3022, January 2001.
			[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.
	[15] 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.
	[16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A		[17] 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-15 (work in
	progress), March 2007.		progress), March 2007.
	[17] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for		[18] 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.,		[19] 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. 25 change blocks.
	39 lines changed or deleted		59 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/