draft-ietf-mmusic-rtsp-nat-evaluation-03.txt		draft-ietf-mmusic-rtsp-nat-evaluation-04.txt
	Network Working Group M. Westerlund		Network Working Group M. Westerlund
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Informational T. Zeng		Intended status: Informational T. Zeng
	Expires: September 15, 2011 March 14, 2011		Expires: April 29, 2012 October 27, 2011
	The Evaluation of Different Network Addres Translator (NAT) Traversal		The Evaluation of Different Network Addres Translator (NAT) Traversal
	Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)		Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)
	draft-ietf-mmusic-rtsp-nat-evaluation-03		draft-ietf-mmusic-rtsp-nat-evaluation-04
	Abstract		Abstract
	This document describes several Network Address Translator (NAT)		This document describes several Network Address Translator (NAT)
	traversal techniques that was considered to be used by Real-time		traversal techniques that was considered to be used by Real-time
	Streaming Protocol (RTSP). Each technique includes a description on		Streaming Protocol (RTSP). Each technique includes a description on
	how it would be used, the security implications of using it and any		how it would be used, the security implications of using it and any
	other deployment considerations it has. There are also disussions on		other deployment considerations it has. There are also disussions on
	how NAT traversal techniques relates to firewalls and how each		how NAT traversal techniques relates to firewalls and how each
	technique can be applied in different use cases. These findings		technique can be applied in different use cases. These findings
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on September 15, 2011.		This Internet-Draft will expire on April 29, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 24, line 42		skipping to change at page 24, line 42
	could be increased. To achieve a longer random tag while still using		could be increased. To achieve a longer random tag while still using
	RTP and RTCP, it will be necessary to develop RTP and RTCP payload		RTP and RTCP, it will be necessary to develop RTP and RTCP payload
	formats for carrying the random tag.		formats for carrying the random tag.
	4.3.5. A Variation to Symmetric RTP		4.3.5. A Variation to Symmetric RTP
	Symmetric RTP requires a valid RTP format in the FW packet, which is		Symmetric RTP requires a valid RTP format in the FW packet, which is
	the first packet that the client sends to the server to set up		the first packet that the client sends to the server to set up
	virtual RTP connection. There is currently no appropriate RTP packet		virtual RTP connection. There is currently no appropriate RTP packet
	format for this purpose, although the No-Op format is a proposal to		format for this purpose, although the No-Op format is a proposal to
	fix the problem [I-D.ietf-avt-rtp-no-op]. There exist a document		fix the problem [I-D.ietf-avt-rtp-no-op]. There exists a RFC that
	that discusses the implication of different type of packets as keep-		discusses the implication of different type of packets as keep-alives
	alives for RTP [I-D.ietf-avt-app-rtp-keepalive] and its findings are		for RTP [RFC6263] and its findings are very relevant to the FW
	very relevant to the FW packet.		packet.
	Meanwhile, there has been FW traversal techniques deployed in the		Meanwhile, there has been FW traversal techniques deployed in the
	wireless streaming market place that use non-RTP messages as FW		wireless streaming market place that use non-RTP messages as FW
	packets. This section attempts to summarize a subset of those		packets. This section attempts to summarize a subset of those
	solutions that happens to use a variation to the standard symmetric		solutions that happens to use a variation to the standard symmetric
	RTP solution.		RTP solution.
	In this variation of symmetric RTP, the FW packet is a small UDP		In this variation of symmetric RTP, the FW packet is a small UDP
	packet that does not contain RTP header. Hence the solution can no		packet that does not contain RTP header. Hence the solution can no
	longer be called symmetric RTP, yet it employs the same technique for		longer be called symmetric RTP, yet it employs the same technique for
	skipping to change at page 35, line 41		skipping to change at page 35, line 41
	are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon,		are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon,
	Amir Wolf, Anders Klemets, and Colin Perkins. Thomas Zeng would also		Amir Wolf, Anders Klemets, and Colin Perkins. Thomas Zeng would also
	like to give special thanks to Greg Sherwood of PacketVideo for his		like to give special thanks to Greg Sherwood of PacketVideo for his
	input into this memo.		input into this memo.
	Section Section 1.1 contains text originally written for RFC 4787 by		Section Section 1.1 contains text originally written for RFC 4787 by
	Francois Audet and Cullen Jennings.		Francois Audet and Cullen Jennings.
	10. Informative References		10. Informative References
	[I-D.ietf-avt-app-rtp-keepalive]
	Marjou, X. and A. Sollaud, "Application Mechanism for
	keeping alive the Network Address Translator (NAT)
	mappings associated to RTP/RTCP flows.",
	draft-ietf-avt-app-rtp-keepalive-10 (work in progress),
	March 2011.
	[I-D.ietf-avt-rtp-no-op]		[I-D.ietf-avt-rtp-no-op]
	Andreasen, F., "A No-Op Payload Format for RTP",		Andreasen, F., "A No-Op Payload Format for RTP",
	draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.		draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.
	[I-D.ietf-mmusic-rfc2326bis]		[I-D.ietf-mmusic-rfc2326bis]
	Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,		Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
	and M. Stiemerling, "Real Time Streaming Protocol 2.0		and M. Stiemerling, "Real Time Streaming Protocol 2.0
	(RTSP)", draft-ietf-mmusic-rfc2326bis-27 (work in		(RTSP)", draft-ietf-mmusic-rfc2326bis-27 (work in
	progress), March 2011.		progress), March 2011.
	skipping to change at page 37, line 26		skipping to change at page 37, line 20
	October 2008.		October 2008.
	[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using		[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
	Relays around NAT (TURN): Relay Extensions to Session		Relays around NAT (TURN): Relay Extensions to Session
	Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.		Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
	[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays		[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays
	around NAT (TURN) Extensions for TCP Allocations",		around NAT (TURN) Extensions for TCP Allocations",
	RFC 6062, November 2010.		RFC 6062, November 2010.
			[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
			Keeping Alive the NAT Mappings Associated with RTP / RTP
			Control Protocol (RTCP) Flows", RFC 6263, June 2011.
	[STUN-IMPL]		[STUN-IMPL]
	"Open Source STUN Server and Client, http://		"Open Source STUN Server and Client, http://
	www.vovida.org/applications/downloads/stun/index.html",		www.vovida.org/applications/downloads/stun/index.html",
	June 2007.		June 2007.
	Authors' Addresses		Authors' Addresses
	Magnus Westerlund		Magnus Westerlund
	Ericsson		Ericsson
	Farogatan 6		Farogatan 6
End of changes. 6 change blocks.
	14 lines changed or deleted		11 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/