One document matched: draft-ietf-avt-app-rtp-keepalive-10.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 RFC4585 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.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'>
<!ENTITY RFC5766 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5766.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/RTCP 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='March' year='2011' />
<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) and RTP control protocol (RTCP) 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 NAT traversals constraints also usually require the
agents to use Symmetric RTP / RTP Control Protocol (RTCP)
<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.
<xref target='exceptions'/> discusses some media format exceptions.
<xref target='additional'/> adds details about timing and transport considerations.
<xref target='rtcp'/> documents how to maintain NAT bindings for RTCP.
</t>
<t> This document is not applicable to Interactive Connectivity Establishment (ICE) <xref target="RFC5245"/> agents.
Indeed, the ICE protocol together with Session Traversal Utilities for NAT (STUN) <xref target="RFC5389"/>
and Traversal Using Relays around NAT (TURN) <xref target="RFC5766"/>
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>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 mentioned in Section 3.5 of <xref target="RFC5405"/> "It is important to note
that keepalive 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
as long as the requirements on parameter selection are fulfilled as discussed in <xref target="rtcp"/>.</t>
<t>Note: "on hold" procedures of <xref target="RFC3264"/> do not impact RTCP transmissions.</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 packets are not multiplexed.</t>
<t>RTCP must be configured so that Tmin value <xref target="RFC3550"/> is lower or equal to the Tr interval.</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 as for 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>
<t>There is no RTCP reporting for the keepalive packets as RFC3550 mandates to ignore "RTP Packet with Unknown Payload Type".</t>
<t>Some RTP payload formats do not handle gaps in RTP sequence number well.</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, the recommended Tr value is 7200 seconds.</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 anchor='rtcp' title="RTCP Flow Keepalive">
<t>RTCP packets are sent periodically and can thus normally maintain the NAT mappings
open as long as they are sent frequently enough. There are two conditions for that.
First RTCP needs to be used bi-directionally and in a symmetric fashion, as described in <xref target="RFC4961"/>.
Secondly, RTCP needs to be sent frequently enough. However, there are certain
configurations that can break this latter assumption.</t>
<t>There are two factors that need to be considered to ensure that RTCP is
sent frequently enough. First the RTCP bandwidth needs to be sufficiently large
so that transmission will occur more frequently than the longest acceptable packet
transmission interval (Tr). The worst case RTCP interval (Twc) can be calculated
using this formula by inserting the max value of the following parameters:
<list style="symbols">
<t>Maximum RTCP packet size (avg_rtcp_size_max)</t>
<t>Maximum number of participants (members_max)</t>
<t>RTCP receiver bandwidth (rtcp_bw)</t>
</list>
</t>
<t>The RTCP bandwidth value to use here is for a worst case, which will be the
receiver proportion when all members are not senders except one.
This can be approximated to be all members. Thus for sessions where RR and RS
values are used, then rtcp_bw shall be set to RR. For sessions where the <xref target="RFC3550"/>
defines proportions of 1/4 for sender and 3/4 for receivers are used, then
rtcp_bw will be 5% of 3/4 of the AS value in bits per second.</t>
<t>Twc = 1.5 / 1.21828 * members_max * rtcp_bw / avg_rtcp_size_max * 8</t>
<t>The second factor is the minimum RTCP interval Tmin defined in <xref target="RFC3550"/>.
Its base value is 5 seconds, but it might also be scaled to 360 divided by the session
bandwidth in kbps. The Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF) <xref target="RFC4585"/> also allows for the setting of a trr-int
parameter which is a minimal RTCP interval for regular RTCP packets. It is also used
as the Tmin value in the regular Td calculation. An analysis of the algorithm gives
that the longest possible regular RTCP interval possible are:</t>
<t>RTCP_int_max = trr-int * 1.5 + Td * 1.5 / 1.21828</t>
<t>And as long as the there is sufficient bandwidth according to criteria 1,
then this can be simplified by setting Td = trr-int giving</t>
<t>RTCP_int_max = trr-int * (1.5 + 1.5 / 1.21828) = 2.73123 * trr-int</t>
<t>Thus the requirements on the RTCP parameters are the following for functioning keepalive:
<list style="numbers">
<t>Ensure that sufficient RTCP bandwidth is provided by calculating Twc and ensure that this is less than or equal to Tr.</t>
<t>If AVP or SAVP is used the Tmin value can't be greater that Tr divided by 1.5 / (e-3/2).</t>
<t>If AVPF or SAVPF is to be used trr-min must not be set to a greater value than Tr / 3.</t>
</list>
</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. Magnus Westerlund provided the text for the RTCP flow keepalive section.
In addition, thanks to Alfred E. Heggestad, Colin Perkins, Dan Wing, Gunnar Hellstrom, Hadriel Kaplan,
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;
&RFC4585;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:45:42 |