draft-ietf-avt-app-rtp-keepalive-08.txt   draft-ietf-avt-app-rtp-keepalive-09.txt 
Network Working Group X. Marjou Network Working Group X. Marjou
Internet-Draft A. Sollaud Internet-Draft A. Sollaud
Intended status: Standards Track France Telecom Orange Intended status: Standards Track France Telecom Orange
Expires: December 20, 2010 June 18, 2010 Expires: March 28, 2011 September 24, 2010
Application Mechanism for keeping alive the Network Address Translator Application Mechanism for keeping alive the Network Address Translator
(NAT) mappings associated to RTP flows. (NAT) mappings associated to RTP flows.
draft-ietf-avt-app-rtp-keepalive-08 draft-ietf-avt-app-rtp-keepalive-09
Abstract Abstract
This document lists the different mechanisms that enable applications This document lists the different mechanisms that enable applications
using Real-time Transport Protocol (RTP) to maintain their RTP using Real-time Transport Protocol (RTP) to maintain their RTP
Network Address Translator (NAT) mappings alive. It also makes a Network Address Translator (NAT) mappings alive. It also makes a
recommendation for a preferred mechanism. This document is not recommendation for a preferred mechanism. This document is not
applicable to Interactive Connectivity Establishment (ICE) agents. applicable to Interactive Connectivity Establishment (ICE) agents.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 December 20, 2010. This Internet-Draft will expire on March 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 4, line 10 skipping to change at page 4, line 10
agents to use symmetric RTP [RFC4961] in addition to RTP keepalive. agents to use symmetric RTP [RFC4961] in addition to RTP keepalive.
This document first states the requirements that must be supported to This document first states the requirements that must be supported to
perform RTP keepalives (Section 3). In a second step, the document perform RTP keepalives (Section 3). In a second step, the document
reports the different mechanisms to overcome this problem reports the different mechanisms to overcome this problem
(Section 4). Section 5 finally states the recommended solution for (Section 4). Section 5 finally states the recommended solution for
RTP keepalive. RTP keepalive.
This document is not applicable to Interactive Connectivity This document is not applicable to Interactive Connectivity
Establishment (ICE) [RFC5245] agents. Indeed, the ICE protocol Establishment (ICE) [RFC5245] agents. Indeed, the ICE protocol
together with Simple Traversal of User Datagram Protocol (STUN) together with Session Traversal Utilities for NAT (STUN) [RFC5389]
[RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5761] and Traversal Using Relays around NAT (TURN) [RFC5766] solve the
solve the overall Network Address Translator (NAT) traversal overall Network Address Translator (NAT) traversal mechanism of media
mechanism of media streams. In the context of RTP media streams, streams. In the context of RTP media streams, some agents may not
some agents may not require all ICE functionalities and may only need require all ICE functionalities and may only need a keepalive
a keepalive mechanism. This document thus applies to such agents, mechanism. This document thus applies to such agents, and does not
and does not apply to agents implementing ICE. apply to agents implementing ICE.
The scope of the draft is also limited to RTP flows. In particular, The scope of the draft is also limited to RTP flows. In particular,
this document does not address keepalive activity related to: this document does not address keepalive activity related to:
o Session signaling flows, such as the Session Initiation Protocol o Session signaling flows, such as the Session Initiation Protocol
(SIP). (SIP).
o RTP Control Protocol (RTCP) flows. o RTP Control Protocol (RTCP) flows.
Recall that [RFC3550] recommends a minimum interval of 5 Recall that [RFC3550] recommends a minimum interval of 5
seconds and that "on hold" procedures of [RFC3264] do not seconds and that "on hold" procedures of [RFC3264] do not
skipping to change at page 6, line 13 skipping to change at page 6, line 13
chosen. chosen.
4.3. RTCP Packets Multiplexed with RTP Packets 4.3. RTCP Packets Multiplexed with RTP Packets
The application sends RTCP packets in the RTP media path itself (i.e. The application sends RTCP packets in the RTP media path itself (i.e.
same tuples for both RTP and RTCP packets) [RFC5761]. RTCP packets same tuples for both RTP and RTCP packets) [RFC5761]. 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 Some RTCP monitoring tools expect that RTCP are not multiplexed. o Some RTCP monitoring tools expect that RTCP packets are not
multiplexed.
4.4. STUN Indication Packet 4.4. STUN Indication Packet
The application sends a STUN [RFC5389] Binding Indication packet as The application sends a STUN [RFC5389] Binding Indication packet as
specified in ICE [RFC5245]. specified in ICE [RFC5245].
Thanks to the RTP validity check, STUN packets will be ignored by the Thanks to the RTP validity check, STUN packets will be ignored by the
RTP stack. RTP stack.
Cons: Cons:
skipping to change at page 7, line 5 skipping to change at page 7, line 6
payload type that has not been negotiated by the peers (e.g. not payload type that has not been negotiated by the peers (e.g. not
negotiated within the SDP offer/answer, and thus not mapped to any negotiated within the SDP offer/answer, and thus not mapped to any
media format). media format).
The sequence number is incremented by one for each packet, as it is The sequence number is incremented by one for each packet, as it is
sent within the same RTP session as the actual media. The timestamp sent within the same RTP session as the actual media. The timestamp
contains the same value a media packet would have at this time. The contains the same value a media packet would have at this time. The
marker bit is not significant for the keepalive packets and is thus marker bit is not significant for the keepalive packets and is thus
set to zero. set to zero.
The SSRC is the same than one one of the media for which keepalive is The SSRC is the same as for the media for which keepalive is sent.
sent.
Normally the peer will ignore this packet, as RTP [RFC3550] states Normally the peer will ignore this packet, as RTP [RFC3550] states
that "a receiver MUST ignore packets with payload types that it does that "a receiver MUST ignore packets with payload types that it does
not understand". not understand".
Cons: Cons:
o [RFC4566] and [RFC3264] mandate not to send media with inactive o [RFC4566] and [RFC3264] mandate not to send media with inactive
and recvonly attributes, however this is mitigated as no real and recvonly attributes, however this is mitigated as no real
media is sent with this mechanism. media is sent with this mechanism.
o [RFC3550] does not preclude examination of received packets by the o [RFC3550] does not preclude examination of received packets by the
skipping to change at page 7, line 49 skipping to change at page 8, line 5
An application supporting this specification MUST transmit either An application supporting this specification MUST transmit either
keepalive packets or media packets at least once every Tr seconds keepalive packets or media packets at least once every Tr seconds
during the whole duration of the media session. during the whole duration of the media session.
Tr has different value according to the transport protocol Tr has different value according to the transport protocol
For UDP, the minimum RECOMMENDED Tr value is 15 seconds, and Tr For UDP, the minimum RECOMMENDED Tr value is 15 seconds, and Tr
SHOULD be configurable to larger values. SHOULD be configurable to larger values.
For TCP, [TODO]. For TCP, the recommended Tr value is 7200 seconds.
For DCCP, [TODO].
When using the "RTCP packets multiplexed with RTP packets" solution When using the "RTCP packets multiplexed with RTP packets" solution
for keepalive, Tr MUST comply with the RTCP timing rules of for keepalive, Tr MUST comply with the RTCP timing rules of
[RFC3550]. [RFC3550].
Keepalive packets within a particular RTP session MUST use the tuple Keepalive packets within a particular RTP session MUST use the tuple
(source IP address, source TCP/UDP ports, target IP address, target (source IP address, source TCP/UDP ports, target IP address, target
TCP/UDP Port) of the regular RTP packets. TCP/UDP Port) of the regular RTP packets.
The agent SHOULD only send RTP keepalive when it does not send The agent SHOULD only send RTP keepalive when it does not send
skipping to change at page 10, line 5 skipping to change at page 9, line 52
April 2010. April 2010.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008. RFC 5382, October 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
Authors' Addresses Authors' Addresses
Xavier Marjou Xavier Marjou
France Telecom Orange France Telecom Orange
2, avenue Pierre Marzin 2, avenue Pierre Marzin
Lannion 22307 Lannion 22307
France France
Email: xavier.marjou@orange-ftgroup.com Email: xavier.marjou@orange-ftgroup.com
 End of changes. 8 change blocks. 
16 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/