One document matched: draft-ietf-avt-app-rtp-keepalive-08.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC4787 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml'>
<!ENTITY RFC3550 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml'>
<!ENTITY RFC3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY RFC3264 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'>
<!ENTITY RFC4566 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml'>
<!ENTITY RFC3389 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3389.xml'>
<!ENTITY RFC4961 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4961.xml'>
<!ENTITY RFC4103 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4103.xml'>
<!ENTITY RFC5245 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml'>
<!ENTITY RFC5382 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5382.xml'>
<!ENTITY RFC5389 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5389.xml'>
<!ENTITY RFC5405 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5405.xml'>
<!ENTITY RFC5761 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5761.xml'>
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<rfc ipr='trust200811' category='std'>
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc sortrefs='yes'?>
<front>
<title abbrev='RTP keepalive'>
Application Mechanism for keeping alive the Network Address
Translator (NAT) mappings associated to RTP flows.
</title>
<author initials='X.' surname='Marjou' fullname='Xavier Marjou'>
<organization>France Telecom Orange</organization>
<address>
<postal>
<street>2, avenue Pierre Marzin</street>
<city>Lannion</city>
<code>22307</code>
<country>France</country>
</postal>
<email>xavier.marjou@orange-ftgroup.com</email>
</address>
</author>
<author initials='A.' surname='Sollaud' fullname='Aurelien Sollaud'>
<organization>France Telecom Orange</organization>
<address>
<postal>
<street>2, avenue Pierre Marzin</street>
<city>Lannion</city>
<code>22307</code>
<country>France</country>
</postal>
<email>aurelien.sollaud@orange-ftgroup.com</email>
</address>
</author>
<date month='June' year='2010' />
<area>Real-time Applications and Infrastructure Area</area>
<keyword>AVT</keyword>
<keyword>NAT</keyword>
<keyword>RTP</keyword>
<keyword>SDP</keyword>
<keyword>port</keyword>
<keyword>mapping</keyword>
<abstract>
<t>
This document lists the different mechanisms that enable applications
using Real-time Transport Protocol (RTP) to maintain their RTP
Network Address Translator (NAT) mappings alive. It also makes a
recommendation for a preferred mechanism. This document is not
applicable to Interactive Connectivity Establishment (ICE) agents.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> Documents <xref target="RFC4787"/> and <xref target="RFC5382"/> describe Network Address Translator (NAT) behaviors
and point out that two key aspects of NAT are mappings (a.k.a. bindings) and keeping them refreshed.
This introduces a derived requirement for applications engaged in a multimedia session
involving NAT traversal: they need to generate a minimum
of flow activity in order to create NAT mappings and maintain them.</t>
<t> When applied to applications using the real-time transport protocol (RTP) <xref target="RFC3550"/>,
the RTP media stream packets themselves normally fulfill this requirement.
However there exist some cases where RTP does not generate the minimum required flow activity.</t>
<t> The examples are:<vspace blankLines="1"/>
<list style="symbols">
<t> In some RTP usages, such as the Session Inititation Protocol (SIP) <xref target="RFC3550"/>, agents can negotiate a unidirectional media stream by
using the Session Description Protocol (SDP) <xref target="RFC4566"/> "recvonly" attribute on one agent and "sendonly" on the peer,
as defined in <xref target="RFC3264"/>.
<xref target="RFC3264"/> directs implementations not to transmit media on the receiving agent.
In case the agent receiving the media is located in the private side of a NAT,
it will never receive RTP packets
from the public peer if the NAT mapping has not been created.<vspace blankLines="1"/></t>
<t> Similarly, a bidirectional media stream can be "put on hold".
This is accomplished by using the SDP "sendonly" or "inactive" attributes.
Again <xref target="RFC3264"/> directs implementations to cease transmission of
media in these cases. However, doing so may cause NAT bindings to
timeout, and media won't be able to come off hold.<vspace blankLines="1"/></t>
<t> Some RTP payload formats, such as the payload format for
text conversation <xref target="RFC4103"/>, may send packets so infrequently that the
interval exceeds the NAT binding timeouts.</t>
</list>
</t>
<t> To solve these problems, an agent therefore needs to periodically send keepalive data
within the outgoing RTP session of an RTP media stream regardless of whether
the media stream is currently inactive, sendonly, recvonly or sendrecv,
and regardless of the presence or value of the bandwidth attribute.
</t>
<t> It is important to note that the above examples also require the agents to use symmetric RTP
<xref target="RFC4961"/> in addition to RTP keepalive.
</t>
<t> This document first states the requirements that must be supported
to perform RTP keepalives (<xref target='requirements'/>).
In a second step, the document reports the different mechanisms to overcome
this problem (<xref target='alternatives'/>).
<xref target='recommend'/> finally states the recommended solution for RTP keepalive.
</t>
<t> This document is not applicable to Interactive Connectivity Establishment (ICE) <xref target="RFC5245"/> agents.
Indeed, the ICE protocol together with Simple Traversal of User Datagram Protocol (STUN) <xref target="RFC5389"/>
and Traversal Using Relays around NAT (TURN) <xref target="RFC5761"/>
solve the overall Network Address Translator (NAT) traversal mechanism of media streams.
In the context of RTP media streams, some agents may not require all ICE functionalities and may only need a keepalive mechanism.
This document thus applies to such agents, and does not apply to agents implementing ICE.
</t>
<t> The scope of the draft is also limited to RTP flows.
In particular, this document does not address keepalive activity related to:<vspace blankLines="1"/>
<list style="symbols">
<t> Session signaling flows, such as the Session Initiation Protocol (SIP).<vspace blankLines="1"/></t>
<t> RTP Control Protocol (RTCP) flows.
<list style="empty">
<t>Recall that <xref target="RFC3550"/> recommends a minimum interval of 5 seconds
and that "on hold" procedures of <xref target="RFC3264"/> do not impact RTCP transmissions.
Therefore, when in use, there is always some RTCP flow activity.</t>
</list>
</t>
</list>
</t>
<t>Note that if a given media uses a codec that already integrates a keepalive mechanism, no additional keepalive mechanism is required at the RTP level.</t>
<t>As mentionned in Section 3.5 of <xref target="RFC5405"/> "It is important to note
that keep-alive messages are NOT RECOMMENDED for general use
-- they are unnecessary for many applications and can consume
significant amounts of system and network resources."</t>
</section>
<section title="Terminology">
<t> In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 <xref target="RFC2119" />.</t>
</section>
<section anchor='requirements' title="Requirements">
<t>This section outlines the key requirements that need to be
satisfied in order to provide RTP media keepalive.</t>
<t><list style="format REQ-%d">
<t>Some data is sent periodically within the outgoing RTP session for the whole duration of the RTP media stream.<vspace blankLines="1"/></t>
<t>Any type of transport (e.g. UDP, TCP) MUST be supported.<vspace blankLines="1"/></t>
<t>Any media type (e.g. audio, video, text) MUST be supported.<vspace blankLines="1"/></t>
<t>Any media format (e.g. G.711, H.263) MUST be supported.<vspace blankLines="1"/></t>
<t>Session signaling protocols SHOULD NOT be impacted.<vspace blankLines="1"/></t>
<t>Impacts on existing software SHOULD be minimized.<vspace blankLines="1"/></t>
<t>Remote peer SHOULD NOT be impacted.<vspace blankLines="1"/></t>
<t>The support for RTP keepalive SHOULD be described in the SDP.<vspace blankLines="1"/></t>
<t>The solution SHOULD cover the integration with RTCP.<vspace blankLines="1"/></t>
</list></t>
</section>
<section anchor='alternatives' title="List of Alternatives for Performing RTP Keepalive">
<t>This section lists, in no particular order, some alternatives that can be used to
perform a keepalive message within RTP media streams.</t>
<section anchor='transport' title="Transport Packet of 0-byte">
<t>The application sends an empty transport packet (e.g. UDP packet, DCCP packet).</t>
<t>Cons:
<list style="symbols">
<t> This alternative is specific to each transport protocol.</t>
</list>
</t>
</section>
<section anchor='comfort-noise' title="RTP Packet with Comfort Noise Payload">
<t>The application sends an RTP packet with a comfort-noise payload <xref target="RFC3389"/>.</t>
<t>Cons:
<list style="symbols">
<t>This alternative is limited to audio formats only. </t>
<t>Comfort Noise needs to be supported by the remote peer.</t>
<t>Comfort Noise needs to be signalled in SDP offer/answer.</t>
<t>The peer is likely to render comfort noise at the other side, so the content of the payload (the noise level) needs to be carefully chosen.</t>
</list>
</t>
</section>
<section anchor='rtcp-mux' title="RTCP Packets Multiplexed with RTP Packets">
<t>The application sends RTCP packets in the RTP media path itself
(i.e. same tuples for both RTP and RTCP packets) <xref target="RFC5761"/>.
RTCP packets therefore maintain the NAT mappings open.</t>
<t>Cons:
<list style="symbols">
<t>Multiplexing RTP and RTCP must be supported by the remote peer.</t>
<t>Some RTCP monitoring tools expect that RTCP are not multiplexed.</t>
</list>
</t>
</section>
<section anchor='stun' title="STUN Indication Packet">
<t>The application sends a STUN <xref target="RFC5389"/> Binding Indication packet as specified in ICE <xref target="RFC5245"/>.</t>
<t>Thanks to the RTP validity check, STUN packets will be ignored by the RTP stack.</t>
<t>Cons:
<list style="symbols">
<t>The sending agent needs to support STUN.</t>
</list>
</t>
</section>
<section anchor='incorrect-version' title="RTP Packet with Incorrect Version Number">
<t>The application sends an RTP packet with an incorrect version number, which value is zero.</t>
<t>Based on RTP specification <xref target="RFC3550"/>, the peer should perform a header validity check,
and therefore ignore these types of packet.</t>
<t>Cons:
<list style="symbols">
<t>Only four version numbers are possible. Using one of them for RTP keepalive would be wasteful.</t>
<t><xref target="RFC4566"/> and <xref target="RFC3264"/> mandate not to send
media with inactive and recvonly attributes, however this is mitigated as no real media is sent
with this mechanism.</t>
</list>
</t>
</section>
<section anchor='unknown-pt' title="RTP Packet with Unknown Payload Type">
<t>The application sends an RTP packet of 0 length with a dynamic 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 media format). </t>
<t> 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 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 set to zero.
</t>
<t>The SSRC is the same than one one of the media for which keepalive is sent.</t>
<t>Normally the peer will ignore this packet, as RTP <xref target="RFC3550"/> states that "a receiver
MUST ignore packets with payload types that it does not understand".</t>
<t>Cons:
<list style="symbols">
<t><xref target="RFC4566"/> and <xref target="RFC3264"/> mandate not to send
media with inactive and recvonly attributes, however this is mitigated as no real media is sent
with this mechanism.</t>
<t><xref target="RFC3550"/> does not preclude examination of received packets by the peer in an attempt to determine if it is under attack.</t>
<t>The statement "RTP Packet with Unknown Payload Type" of RFC3550 is not always observed in real life.</t>
</list>
</t>
</section>
</section>
<section anchor='recommend' title="Recommended Solution for Keepalive Mechanism">
<t>The RECOMMENDED mechanism is the "RTCP packets multiplexed with RTP packets" (<xref target="rtcp-mux"/>).
This mechanism is desirable because it reduces the number of ports when RTP and RTCP are used.
It also has the advantage of taking into account RTCP aspects, which is not the case of other mechanisms.</t>
<t> Other mechanisms (<xref target="transport"/>, <xref target="comfort-noise"/>,
<xref target="stun"/>, <xref target="incorrect-version"/>, <xref target="unknown-pt"/>) are NOT RECOMMENDED. </t>
</section>
<section anchor='exceptions' title="Media Format Exceptions">
<t>When a given media format does not allow the keepalive solution
recommended in <xref target="recommend"/>, an alternative mechanism SHOULD be defined
in the payload format specification for this media format.</t>
</section>
<section anchor='additional' title="Timing and Transport Considerations">
<t>An application supporting this specification MUST transmit either
keepalive packets or media packets at least once every Tr seconds
during the whole duration of the media session. </t>
<t>Tr has different value according to the transport protocol</t>
<t>For UDP, the minimum RECOMMENDED Tr value is 15 seconds, and Tr SHOULD be configurable to larger values.</t>
<t>For TCP, [TODO].</t>
<t>For DCCP, [TODO].</t>
<t>When using the "RTCP packets multiplexed with RTP packets" solution for
keepalive, Tr MUST comply with the RTCP timing rules of <xref target="RFC3550"/>.
</t>
<t>Keepalive packets within a particular RTP session MUST use the tuple (source IP
address, source TCP/UDP ports, target IP address, target TCP/UDP
Port) of the regular RTP packets.</t>
<t>The agent SHOULD only send RTP keepalive when it does not send regular RTP packets.</t>
</section>
<section title="Security Considerations">
<t>
The RTP keepalive packets are sent on the same path as regular RTP
media packets and may be perceived as an attack by a peer. However,
<xref target="RFC3550"/> mandates a peer to "ignore packets with payload types that
it does not understand". A peer that does not understand the
keepalive message will thus appropriately drop the received packets.
</t>
</section>
<section title="IANA Considerations">
<t>None.</t>
</section>
<section title="Acknowledgements">
<t>Jonathan Rosenberg provided the major inputs for this draft via the ICE specification.
In addition, thanks to Alfred E. Heggestad, Colin Perkins, Dan Wing, Gunnar Hellstrom, Hadriel Kaplan,
Magnus Westerlund, Randell Jesup, Remi Denis-Courmont, Robert Sparks, and Steve Casner for their useful inputs and comments.</t>
</section>
</middle>
<back>
<references title="Normative references">
&RFC2119;
&RFC3550;
&RFC5405;
&RFC4961;
&RFC5761;
</references>
<references title="Informative references">
&RFC4787;
&RFC5382;
&RFC5245;
&RFC3264;
&RFC3261;
&RFC5389;
&RFC4566;
&RFC4103;
&RFC3389;
&RFC5766;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:13:04 |