draft-ietf-mmusic-sdp4nat-04.txt		draft-ietf-mmusic-sdp4nat-05.txt
	INTERNET DRAFT C. Huitema		INTERNET DRAFT C. Huitema
	<draft-ietf-mmusic-sdp4nat-04.txt> Microsoft		<draft-ietf-mmusic-sdp4nat-05.txt> Microsoft
	Expires November 12, 2003 May 12, 2003		Expires November 30, 2003 May 30, 2003
	RTCP attribute in SDP		RTCP attribute in SDP
	Status of this memo		Status of this memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	skipping to change at line 46		skipping to change at page 1, line 46
	of ports can be destroyed by the translation. To handle this, we		of ports can be destroyed by the translation. To handle this, we
	propose an extension attribute to SDP.		propose an extension attribute to SDP.
	1. Introduction		1. Introduction
	The session invitation protocol (SIP, [RFC3261]) is often used to		The session invitation protocol (SIP, [RFC3261]) is often used to
	establish multi-media sessions on the Internet. There are often		establish multi-media sessions on the Internet. There are often
	cases today in which one or both end of the connection are hidden		cases today in which one or both end of the connection are hidden
	behind a network address translation device [RFC2766]. In this case,		behind a network address translation device [RFC2766]. In this case,
	the SDP text must document the IP addresses and UDP ports as they		the SDP text must document the IP addresses and UDP ports as they
	appear on the 'public Internet' side of the NAT; in this memo, we		appear on the "public Internet" side of the NAT; in this memo, we
	will suppose that the host located behind a NAT has a way to obtain		will suppose that the host located behind a NAT has a way to obtain
	these numbers; a possible way to learn these numbers is briefly		these numbers; a possible way to learn these numbers is briefly
	outlined in section 3. However, just learning the numbers is not		outlined in section 3. However, just learning the numbers is not
	enough.		enough.
	The SIP messages use the encoding defined in SDP [RFC2327] to		The SIP messages use the encoding defined in SDP [RFC2327] to
	describe the IP addresses and TCP or UDP ports used my the various		describe the IP addresses and TCP or UDP ports used by the various
	media. Audio and video are typically sent using RTP [RTP-NEW], which		media. Audio and video are typically sent using RTP [RTP-NEW], which
	requires two UDP ports, one for the media and one for the control		requires two UDP ports, one for the media and one for the control
	protocol (RTCP). SDP carries only one port number per media, and		protocol (RTCP). SDP carries only one port number per media, and
	states that 'other ports used by the media application (such as the		states that "other ports used by the media application (such as the
	RTCP port) should be derived algorithmically from the base media		RTCP port) should be derived algorithmically from the base media
	port.' RTCP port numbers were necessarily derived from the base		port." RTCP port numbers were necessarily derived from the base
	media port in older versions of RTP (such as [RFC1889]), but now		media port in older versions of RTP (such as [RFC1889]), but now
	that this restriction has been lifted, there is a need to specify		that this restriction has been lifted, there is a need to specify
	RTCP ports explicitly in SDP. Note, however, that implementations of		RTCP ports explicitly in SDP. Note, however, that implementations of
	RTP adhering to the earlier [RFC1889] specification may not be able		RTP adhering to the earlier [RFC1889] specification may not be able
	to make use of the SDP attributes specified in this document.		to make use of the SDP attributes specified in this document.
	When the NAT device performs port mapping, there is no guarantee		When the NAT device performs port mapping, there is no guarantee
	that the mappings of two separate ports reflects the sequencing and		that the mappings of two separate ports reflects the sequencing and
	the parity of the original port numbers; in fact, when the NAT		the parity of the original port numbers; in fact, when the NAT
	manages a pool of IP addresses, it is even possible that the RTP and		manages a pool of IP addresses, it is even possible that the RTP and
	the RTCP ports may be mapped to different addresses. In order to		the RTCP ports may be mapped to different addresses. In order to
	successfully establish connections despite the misordering of the		successfully establish connections despite the misordering of the
	port numbers and the possible parity switches caused by the NAT, we		port numbers and the possible parity switches caused by the NAT, we
	propose to use a specific SDP attribute to document the RTCP port		propose to use a specific SDP attribute to document the RTCP port
	and optionally the RTCP address, and we also propose to make the		and optionally the RTCP address.
	behavior of RTP implementations more conforming to the robustness
	principle.
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Description of the solution		2. Description of the solution
	The main part of our solution is the declaration of an SDP attribute		The main part of our solution is the declaration of an SDP attribute
	for documenting the port used by RTCP.		for documenting the port used by RTCP.
	2.1. The RTCP attribute		2.1. The RTCP attribute
	The RTCP attribute is used to document the RTCP port used for media		The RTCP attribute is used to document the RTCP port used for media
	stream, when that port is not the next higher (odd) port number		stream, when that port is not the next higher (odd) port number
	following the RTP port described in the media line. The RTCP		following the RTP port described in the media line. The RTCP
	attribute is a ôvalueö attribute, and follows the general syntax		attribute is a "value" attribute, and follows the general syntax
	specified page 18 of [RFC2327]: "a=<attribute>:<value>". For the		specified page 18 of [RFC2327]: "a=<attribute>:<value>". For the
	RTCP attribute:		RTCP attribute:
	* the name is the ascii string 'rtcp' (lower case),		* the name is the ascii string "rtcp" (lower case),
	* the value is the RTCP port number and optional address.		* the value is the RTCP port number and optional address.
	The formal description of the attribute is defined by the following		The formal description of the attribute is defined by the following
	ABNF syntax:		ABNF syntax:
	rtcp-attribute = ôa=rtcp:ö port [nettype space addrtype space		rtcp-attribute = "a=rtcp:" port [nettype space addrtype space
	connection-address] CRLF		connection-address] CRLF
	In this description, the 'port', 'nettype', 'addrtype' and		In this description, the "port", "nettype", "addrtype" and
	ôconnection-addressö tokens are defined as specified in 'Appendix A:		"connection-address" tokens are defined as specified in "Appendix A:
	SDP Grammar' of [RFC2327].		SDP Grammar" of [RFC2327].
	Example encodings could be:		Example encodings could be:
	m=audio 49170 RTP/AVP 0		m=audio 49170 RTP/AVP 0
	a=rtcp:53020		a=rtcp:53020
	m=audio 49170 RTP/AVP 0		m=audio 49170 RTP/AVP 0
	a=rtcp:53020 IN IP4 126.16.64.4		a=rtcp:53020 IN IP4 126.16.64.4
	m=audio 49170 RTP/AVP 0		m=audio 49170 RTP/AVP 0
	a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD		a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD
	The RTCP attribute MAY be used as a media level attribute; it MUST		The RTCP attribute MAY be used as a media level attribute; it MUST
	NOT be used as a session level attribute.		NOT be used as a session level attribute.
	3. Discussion of the solution		3. Discussion of the solution
	The implementation of the solution is fairly straightforward. The		The implementation of the solution is fairly straightforward. The
	three questions that have been most often asked regarding this		questions that have been most often asked regarding this solution
	solution are whether this is useful, i.e. whether a host can		are whether this is useful, i.e. whether a host can actually
	actually discover port numbers in an unmodified NAT, whether it is		discover port numbers in an unmodified NAT, whether it is
	sufficient, i.e. whether or not there is a need to document more		sufficient, i.e. whether or not there is a need to document more
	than one ancillary port per media type, and whether relaxing the RTP		than one ancillary port per media type, and whether why should not
	requirements is legitimate.		change the media definition instead of adding a new attribute.
	3.1. How do we discover port numbers?		3.1. How do we discover port numbers?
	The proposed solution is only useful if the host can discover the		The proposed solution is only useful if the host can discover the
	ôtranslated port numbersö, i.e. the value of the ports as they		"translated port numbers", i.e. the value of the ports as they
	appear on the 'external side' of the NAT. One possibility is to ask		appear on the "external side" of the NAT. One possibility is to ask
	the cooperation of a well connected third party that will act as a		the cooperation of a well connected third party that will act as a
	server according to STUN [RFC3489]. We thus obtain a four step		server according to STUN [RFC3489]. We thus obtain a four step
	process:		process:
	1- The host allocate two UDP ports numbers for an RTP/RTCP pair,		1- The host allocates two UDP ports numbers for an RTP/RTCP pair,
	2- The host sends a UDP message from each port to the STUN server,		2- The host sends a UDP message from each port to the STUN server,
	3- The STUN server reads the source address and port of the packet,		3- The STUN server reads the source address and port of the packet,
	and copies them in the text of a reply,		and copies them in the text of a reply,
	4- The host parses the reply according to the STUN protocol and		4- The host parses the reply according to the STUN protocol and
	learns the external address and port corresponding to each of the		learns the external address and port corresponding to each of the
	two UDP port.		two UDP port.
	This algorithm supposes that the NAT will use the same translation		This algorithm supposes that the NAT will use the same translation
	for packets sent to the third party and to the ôSDP peerö with which		for packets sent to the third party and to the "SDP peer" with which
	the host wants to establish a connection. There is no guarantee that		the host wants to establish a connection. There is no guarantee that
	all NAT boxes deployed on the Internet have this characteristic.		all NAT boxes deployed on the Internet have this characteristic.
	Implementers are referred to the STUN specification [RFC3489] for an		Implementers are referred to the STUN specification [RFC3489] for an
	extensive discussion of the various types of NAT.		extensive discussion of the various types of NAT.
	3.2. Do we need to support multiple ports?		3.2. Do we need to support multiple ports?
	Most media streams are transmitted using a single pair of RTP and		Most media streams are transmitted using a single pair of RTP and
	RTCP ports. It is possible, however, to transmit a single media over		RTCP ports. It is possible, however, to transmit a single media over
	several RTP flows, for example using hierarchical encoding. In this		several RTP flows, for example using hierarchical encoding. In this
	skipping to change at line 198		skipping to change at page 4, line 42
	The RTP ports are documented in the media description line, and it		The RTP ports are documented in the media description line, and it
	would seem convenient to document the RTCP port at the same place,		would seem convenient to document the RTCP port at the same place,
	rather than create an RTCP attribute. We considered this design		rather than create an RTCP attribute. We considered this design
	alternative and rejected it for two reasons: adding an extra port		alternative and rejected it for two reasons: adding an extra port
	number and an option address in the media description would be		number and an option address in the media description would be
	awkward, and more importantly it would create problems with existing		awkward, and more importantly it would create problems with existing
	applications, which would have to reject the entire media		applications, which would have to reject the entire media
	description if they did not understand the extension. On the		description if they did not understand the extension. On the
	contrary, adding an attribute has a well defined failure mode:		contrary, adding an attribute has a well defined failure mode:
	implementations that donÆt understand the 'a=rtcp' attribute will		implementations that don't understand the "a=rtcp" attribute will
	simply ignore it; they will fail to send RTCP packets to the		simply ignore it; they will fail to send RTCP packets to the
	specified address, but they will at least be able to receive the		specified address, but they will at least be able to receive the
	media in the RTP packets.		media in the RTP packets.
	4. UNSAF considerations		4. UNSAF considerations
	The RTCP attribute in SDP is used to enable establishment of		The RTCP attribute in SDP is used to enable establishment of
	RTP/RTCP flows through NAT. This mechanism can be used in		RTP/RTCP flows through NAT. This mechanism can be used in
	conjunction with an address discovery mechanism such as STUN		conjunction with an address discovery mechanism such as STUN
	[RFC3489]. STUN is a short term fix to the NAT traversal problem,		[RFC3489]. STUN is a short term fix to the NAT traversal problem,
	which requires thus consideration of the general issues linked to		which requires thus consideration of the general issues linked to
	'Unilateral self-address fixing' [RFC3424].		"Unilateral self-address fixing" [RFC3424].
	The RTCP attribute addresses a very specific problem, the		The RTCP attribute addresses a very specific problem, the
	documentation of port numbers as they appear after address		documentation of port numbers as they appear after address
	translation by a port-mapping NAT. The RTCP attribute SHOULD NOT be		translation by a port-mapping NAT. The RTCP attribute SHOULD NOT be
	used for other applications.		used for other applications.
	We expect that, with time, one of two exit strategies can be		We expect that, with time, one of two exit strategies can be
	developed. The IETF may develop an explicit 'middlebox control'		developed. The IETF may develop an explicit "middlebox control"
	protocol that will enable applications to obtain a pair of port		protocol that will enable applications to obtain a pair of port
	numbers appropriate for RTP and RTCP. Another possibility is the		numbers appropriate for RTP and RTCP. Another possibility is the
	deployment of IPv6, which will enable use of 'end to end' addressing		deployment of IPv6, which will enable use of "end to end" addressing
	and guarantee that the two hosts will be able to use appropriate		and guarantee that the two hosts will be able to use appropriate
	ports. In both cases, there will be no need for documenting a ônon		ports. In both cases, there will be no need for documenting a "non
	standardö RTCP port with the RTCP attribute.		standard" RTCP port with the RTCP attribute.
	5. Security Considerations		5. Security Considerations
	This SDP extension is not believed to introduce any significant		This SDP extension is not believed to introduce any significant
	security risk to multi-media applications. One could conceive that a		security risk to multi-media applications. One could conceive that a
	malevolent third party would use the extension to redirect the RTCP		malevolent third party would use the extension to redirect the RTCP
	fraction of an RTP exchange, but this require intercepting and		fraction of an RTP exchange, but this requires intercepting and
	rewriting the signaling packet carrying the SDP text; if an		rewriting the signaling packet carrying the SDP text; if an
	interceptor can do that, many more attacks are available, including		interceptor can do that, many more attacks are available, including
	a wholesale change of the addresses and port numbers at which the		a wholesale change of the addresses and port numbers at which the
	media will be sent.		media will be sent.
	In order to avoid attacks of this sort, when SDP is used in a		In order to avoid attacks of this sort, when SDP is used in a
	signaling packet where it is of the form application/sdp, end-to-end		signaling packet where it is of the form application/sdp, end-to-end
	integrity using S/MIME [RFC3369] is the technical method to be		integrity using S/MIME [RFC3369] is the technical method to be
	implemented and applied. This is compatible with SIP [RFC3261].		implemented and applied. This is compatible with SIP [RFC3261].
	6. IANA Considerations		6. IANA Considerations
	This document defines a new SDP parameter, the attribute field		This document defines a new SDP parameter, the attribute field
	'rtcp', which per [RFC2327] should be registered by IANA. This		"rtcp", which per [RFC2327] should be registered by IANA. This
	attribute field is designed for use at media level only.		attribute field is designed for use at media level only.
	7. Copyright		7. Copyright
	The following copyright notice is copied from RFC 2026 [Bradner,		The following copyright notice is copied from RFC 2026 [Bradner,
	1996], Section 10.4, and describes the applicable copyright for this		1996], Section 10.4, and describes the applicable copyright for this
	document.		document.
	Copyright (C) The Internet Society March 21, 2001. All Rights		Copyright (C) The Internet Society March 21, 2001. All Rights
	Reserved.		Reserved.
	skipping to change at line 309		skipping to change at page 6, line 49
	can be obtained from the IETF Secretariat.		can be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	9. Acknowledgements		9. Acknowledgements
	The original idea for using the 'rtcp' attribute was developed by		The original idea for using the "rtcp" attribute was developed by
	Ann Demirtjis. The draft was reviewed by the MMUSIC and AVT working		Ann Demirtjis. The draft was reviewed by the MMUSIC and AVT working
	groups of the IETF.		groups of the IETF.
	10. References		10. References
	Normative references		Normative references
			[RFC2327] Handley, M., and V. Jacobson, "SDP: Session Description
			Protocol", RFC 2327, April 1998.
	[RFC2327] M. Handley, V. Jacobson, 'SDP: Session Description		[RTP-NEW] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Protocol', RFC 2327, April 1998.		Jacobson. "RTP: A Transport Protocol for Real-Time Applications",
			Work in progress, March 2003.
	[RTP-NEW] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP:
	A Transport Protocol for Real-Time Applications", Work in progress,
	March 2003.
	[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP:		[RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V.
	A Transport Protocol for Real-Time Applications", RFC 1889, January		Jacobson. "RTP: A Transport Protocol for Real-Time Applications",
	1996.		RFC 1889, January 1996.
	[RFC2119] S. Bradner, 'Key words for use in RFCs to Indicate		[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels', RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax		[RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 2234, November 1997.		Specifications: ABNF", RFC 2234, November 1997.
			[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy.
			"STUN - Simple Traversal of User Datagram Protocol (UDP) Through
			Network Address Translators (NATs)". RFC 3489, March 2003
	Informative references		Informative references
	[RFC2766] G. Tsirtsis, P. Srisuresh. 'Network Address Translation -		[RFC2766] Tsirtsis, G., and P. Srisuresh. "Network Address
	Protocol Translation (NAT-PT)', RFC 2766, February 2000.		Translation - Protocol Translation (NAT-PT)", RFC 2766, February
			2000.
	[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	J. Peterson, R. Sparks, M. Handley, E. Schooler. SIP: Session		A., Peterson, J., Sparks, R., Handley, M., and E. Schooler. SIP:
	Initiation Protocol. RFC 3261, June 2002.		Session Initiation Protocol. RFC 3261, June 2002.
	[RFC3369] R. Housley. Cryptographic Message Syntax (CMS). RFC 3369,		[RFC3369] R. Housley. Cryptographic Message Syntax (CMS). RFC 3369,
	August 2002.		August 2002.
	[RFC3424] L. Daigle, "IAB considerations for UNilateral self-address		[RFC3424] L. Daigle, "IAB considerations for UNilateral Self-Address
	fixing (UNSAF) across network address translation," RFC 3424,		Fixing (UNSAF) across network address translation," RFC 3424,
	November 2002.		November 2002.
	[RFC3489] J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy. ôSTUN -
	Simple Traversal of User Datagram Protocol (UDP) Through Network
	Address Translators (NATs)ö. RFC 3489, March 2003
	11. Author's Address		11. Author's Address
	Christian Huitema		Christian Huitema
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052-6399		Redmond, WA 98052-6399
	Email: huitema@microsoft.com		Email: huitema@microsoft.com
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/