< draft-marjou-behave-app-rtp-keepalive-00.txt		draft-marjou-behave-app-rtp-keepalive-01.txt >
	BEHAVE Working Group X. Marjou, Ed.		BEHAVE Working Group X. Marjou, Ed.
	Internet-Draft France Telecom		Internet-Draft France Telecom
	Intended status: Informational August 3, 2006		Intended status: Informational February 2, 2007
	Expires: February 4, 2007		Expires: August 6, 2007
	Application Requirements for maintaining alive the Network Address		Application Mechanism for maintaining alive the Network Address
	Translator (NAT) mappings associated to RTP flows.		Translator (NAT) mappings associated to RTP flows.
	draft-marjou-behave-app-rtp-keepalive-00		draft-marjou-behave-app-rtp-keepalive-01
	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 February 4, 2007.		This Internet-Draft will expire on August 6, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document defines a mechanism that enables applications using		This document defines a mechanism that enables applications using
	Real Time Protocol (RTP) to maintain their RTP Network Address		Real Time Protocol (RTP) to maintain their RTP Network Address
	Translator (NAT) mappings alive.		Translator (NAT) mappings alive.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. List of alternatives for performing RTP keepalive . . . . . . . 4		4. List of Alternatives for Performing RTP Keepalive . . . . . . . 4
	4.1. UDP packet of 0-byte . . . . . . . . . . . . . . . . . . . 5		4.1. UDP Packet of 0-byte . . . . . . . . . . . . . . . . . . . 5
	4.2. RTCP packets multiplexed with RTP packets . . . . . . . . . 5		4.2. RTCP Packets Multiplexed with RTP Packets . . . . . . . . . 5
	4.3. STUN packet . . . . . . . . . . . . . . . . . . . . . . . . 5		4.3. STUN Packet . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.4. RTP packet with Comfort Noise payload . . . . . . . . . . . 5		4.4. RTP Packet with Comfort Noise Payload . . . . . . . . . . . 5
	4.5. RTP packet with No-Op payload . . . . . . . . . . . . . . . 6		4.5. RTP Packet with No-Op Payload . . . . . . . . . . . . . . . 6
	4.6. RTP packet with incorrect version number . . . . . . . . . 6		4.6. RTP Packet with Incorrect Version Number . . . . . . . . . 6
	4.7. RTP packet with unknown payload type . . . . . . . . . . . 6		4.7. RTP Packet with Unknown Payload Type . . . . . . . . . . . 6
	5. Recommended solution . . . . . . . . . . . . . . . . . . . . . 6		5. Recommended Solution . . . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
	Intellectual Property and Copyright Statements . . . . . . . . . . 9		Intellectual Property and Copyright Statements . . . . . . . . . . 9
	1. Introduction		1. Introduction
	[Note: The content of this draft is basically a copy and paste of the		[Note: The content of this draft is basically a copy and paste of the
	current 7.12 section of ICE [5] concerning binding keepalives		current 7.12 section of ICE [5] concerning binding keepalives
	skipping to change at page 4, line 47 ¶		skipping to change at page 4, line 47 ¶
	REQ 6: Session signaling protocols SHOULD not be impacted.		REQ 6: Session signaling protocols SHOULD not be impacted.
	REQ 7: Session description protocols SHOULD not be impacted.		REQ 7: Session description protocols SHOULD not be impacted.
	REQ 8: Impacts on existing software SHOULD be minimized.		REQ 8: Impacts on existing software SHOULD be minimized.
	REQ 9: Remote peer SHOULD not be impacted.		REQ 9: Remote peer SHOULD not be impacted.
	REQ 10: One single mechanism MUST be recommended.		REQ 10: One single mechanism MUST be recommended.
	4. List of alternatives for performing RTP keepalive		4. List of Alternatives for Performing RTP Keepalive
	This section lists some alternatives that could be used in order to		This section lists some alternatives that could be used in order to
	perform a keepalive message within RTP media streams.		perform a keepalive message within RTP media streams.
	A common drawback of most of these alternatives is that they require		A common drawback of most of these alternatives is that they require
	media packets be sent by the application during "on hold" procedures,		media packets be sent by the application during "on hold" procedures,
	which violates the behavior of the inactive and recvonly attributes		which violates the behavior of the inactive and recvonly attributes
	specified in SDP-NEW [10] and in RFC3264 [6]. Although there can		specified in SDP-NEW [10] and in RFC3264 [6]. Although there can
	exist some debate whether STUN is a media flow or not, STUN also		exist some debate whether STUN is a media flow or not, STUN also
	requires the application to send some packets within the media stream		requires the application to send some packets within the media stream
	during on-hold procedures.		during on-hold procedures.
	4.1. UDP packet of 0-byte		4.1. UDP Packet of 0-byte
	The application sends an empty UDP packet.		The application sends an empty UDP packet.
	Cons:		Cons:
	o This alternative is specific to UDP.		o This alternative is specific to UDP.
	o There may be some implementations that will not ignore these		o There may be some implementations that will not ignore these
	packets.		packets.
	4.2. RTCP packets multiplexed with RTP packets		4.2. RTCP Packets Multiplexed with RTP Packets
	The application sends RTCP packets in the RTP media stream itself		The application sends RTCP packets in the RTP media stream itself
	(i.e. same tuples for both RTP and RTCP packets) [8]. RTCP packets		(i.e. same tuples for both RTP and RTCP packets) [8]. RTCP packets
	therefore maintain the NAT mappings open.		therefore maintain the NAT mappings open.
	Cons:		Cons:
	o Multiplexing RTP and RTCP must be supported by the remote peer.		o Multiplexing RTP and RTCP must be supported by the remote peer.
	o Multiplexing RTP and RTCP must be signalled in SDP offer/answer.		o Multiplexing RTP and RTCP must be signalled in SDP offer/answer.
	o This alternative may significantly impact existing software and		o This alternative may significantly impact existing software and
	specifications.		specifications.
	4.3. STUN packet		4.3. STUN Packet
	The application sends a STUN Request packet [9]		The application sends a STUN Binding Request packet and receives a
			STUN Binding Response [9]
	Cons:		Cons:
	o This alternative requires that both endpoints support STUN.		o This alternative requires that the remote endpoint support STUN.
	o For media sessions negotiated with SDP, there is a need for the
	endpoint to use ICE.
	4.4. RTP packet with Comfort Noise payload		4.4. RTP Packet with Comfort Noise Payload
	The application sends a RTP packet with a comfort-noise payload [11].		The application sends a RTP packet with a comfort-noise payload [11].
	Cons:		Cons:
	o This alternative is limited to voice payload formats only.		o This alternative is limited to voice payload formats only.
	o For each payload type, the content of the payload needs to be		o For each payload type, the content of the payload needs to be
	specified.		specified.
	4.5. RTP packet with No-Op payload		4.5. RTP Packet with No-Op Payload
	The application sends a RTP No-OP payload [12] .		The application sends a RTP No-OP payload [12] .
	Cons:		Cons:
	o This payload type needs to be supported by the remote peer.		o This payload type needs to be supported by the remote peer.
	o This payload type needs to be signalled in SDP offer/answer.		o This payload type needs to be signalled in SDP offer/answer.
	4.6. RTP packet with incorrect version number		4.6. RTP Packet with Incorrect Version Number
	The application sends a RTP with an incorrect version number.		The application sends a RTP with an incorrect version number.
	Based on RTP specification [4], the peer should perform a header		Based on RTP specification [4], the peer should perform a header
	validity check, and therefore ignore these types of packet.		validity check, and therefore ignore these types of packet.
	Cons:		Cons:
	o Only four version numbers are possible. Using one of them for RTP		o Only four version numbers are possible. Using one of them for RTP
	keepalive would be wasteful.		keepalive would be wasteful.
	4.7. RTP packet with unknown payload type		4.7. RTP Packet with Unknown Payload Type
	The application sends a RTP packet with an unknow payload type.		The application sends a RTP packet with an unknown payload type.
	Normally the peer will ignore it, as RTP [4] states that "a receiver		Normally the peer will ignore it, as RTP [4] states that "a receiver
	MUST ignore packets with payload types that it does not understand".		MUST ignore packets with payload types that it does not understand".
	For example, the keepalive RTP packets contain a dynamic payload type		For example, the keepalive RTP packets contain a dynamic payload type
	that has not been negotiated for the session.		that has not been negotiated for the session.
	[Note: more details on the selection of the payload type are needed		[Note: more details on the selection of the payload type are needed
	here.]		here.]
	Cons:		Cons:
	o None		o None
	5. Recommended solution		5. Recommended Solution
	An application supporting this specification MUST send keepalive		An application supporting this specification MUST send keepalive
	packets under the form of ... [Note: The recommended solution needs		packets under the form of ... [Note: The recommended solution needs
	to be discussed. However recommending a single method among the		to be discussed. However recommending a single method among the
	alternatives of the previous section is the best in term of		alternatives of the previous section is the best in term of
	interoperability. Proposal is the alternative of Section 4.7]		interoperability. Proposal is the alternative of Section 4.7]
	Keepalives packets MUST be sent for each RTP stream regardless of		Keepalives packets MUST be sent for each RTP stream regardless of
	whether the media stream is currently inactive, sendonly, recvonly or		whether the media stream is currently inactive, sendonly, recvonly or
	sendrecv.		sendrecv.
	skipping to change at page 7, line 35 ¶		skipping to change at page 7, line 33 ¶
	Jonathan Rosenberg, via the ICE specification, provided the major		Jonathan Rosenberg, via the ICE specification, provided the major
	inputs for this draft. In addition, thanks to the following folks		inputs for this draft. In addition, thanks to the following folks
	for useful inputs and comments: Dan Wing, and Aurelien Sollaud.		for useful inputs and comments: Dan Wing, and Aurelien Sollaud.
	8. References		8. References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, March 1997.		Levels", RFC 2119, March 1997.
	[2] Audet, F. and C. Jennings, "NAT Behavioral Requirements for		[2] Audet, F. and C. Jennings, "Network Address Translation (NAT)
	Unicast UDP", draft-ietf-behave-nat-udp-07 (work in progress),		Behavioral Requirements for Unicast UDP", RFC 4787,
	June 2006.		January 2007.
	[3] Guha, S., Biswas, K., Ford, B., Francis, P., Sivarkumar, S.,		[3] Guha, S., Biswas, K., Ford, B., Francis, P., Sivarkumar, S.,
	and P. Srisuresh, "NAT Behavioral Requirements for TCP",		and P. Srisuresh, "NAT Behavioral Requirements for TCP",
	draft-ietf-behave-tcp-01 (work in progress), June 2006.		draft-ietf-behave-tcp-04 (work in progress), January 2007.
	[4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,		[4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
	"RTP: A Transport Protocol for Real-Time Applications",		"RTP: A Transport Protocol for Real-Time Applications",
	RFC 3550, July 2003.		RFC 3550, July 2003.
	[5] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A		[5] 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-09 (work in		Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in
	progress), June 2006.		progress), January 2007.
	[6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with		[6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
	the Session Description Protocol (SDP)", RFC 3264, June 2002.		the Session Description Protocol (SDP)", RFC 3264, June 2002.
	[7] Hellstrom, G. and P. Jones, "RTP Payload for Text		[7] Hellstrom, G. and P. Jones, "RTP Payload for Text
	Conversation", RFC 4103, June 2005.		Conversation", RFC 4103, June 2005.
	[8] Perkins, C. and M. Magnus, "Multiplexing RTP and RTCP on a		[8] Perkins, C. and M. Magnus, "Multiplexing RTP Data and Control
	Single Port", draft-perkins-avt-rtp-and-rtcp-mux-00 (work in		Packets on a Single Port", draft-ietf-avt-rtp-and-rtcp-mux-03
	progress), August 2006.		(work in progress), December 2006.
	[9] Rosenberg, J., Huitema, C., Mahy, R., and D. Wing, "Simple		[9] Rosenberg, J., Huitema, C., Mahy, R., and D. Wing, "Simple
	Traversal Underneath Network Address Translators (NAT) (STUN)",		Traversal Underneath Network Address Translators (NAT) (STUN)",
	draft-ietf-behave-rfc3489bis-04 (work in progress), June 2006.		draft-ietf-behave-rfc3489bis-05 (work in progress),
			October 2006.
	[10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session		[10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, July 2006.		Description Protocol", RFC 4566, July 2006.
	[11] Robert, R., "Real-time Transport Protocol (RTP) Payload for		[11] Robert, R., "Real-time Transport Protocol (RTP) Payload for
	Comfort Noise (CN)", RFC 3389, September 2002.		Comfort Noise (CN)", RFC 3389, September 2002.
	[12] Andreason, F., Oran, D., and D. Wing, "A No-Op Payload Format		[12] Andreason, F., Oran, D., and D. Wing, "A No-Op Payload Format
	for RTP", draft-ietf-avt-rtp-no-op-00 (work in progress),		for RTP", draft-ietf-avt-rtp-no-op-00 (work in progress),
	May 2005.		May 2005.
	Author's Address		Author's Address
	Xavier Marjou (editor)		Xavier Marjou (editor)
	France Telecom		France Telecom
	2, hent Pierre Marzin		2, hent Pierre Marzin
	Lannion, Brittany 22307		Lannion, Brittany 22307
	France		France
	Email: xavier.marjou@orange-ft.com		Email: xavier.marjou@orange-ftgroup.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 27 change blocks.
	46 lines changed or deleted		45 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/