One document matched: draft-ietf-avt-app-rtp-keepalive-07.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 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 RFC4103 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4103.xml'>
<!ENTITY RFC4961 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4961.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'>
]>
<?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 maintaining alive the
Network Address Translator (NAT) mappings associated to RTP flows.
</title>
<author initials='X.' surname='Marjou' fullname='Xavier Marjou'>
<organization>France Telecom</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</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='December' year='2009' />
<area>Real-time Applications and Infrastructure Area</area>
<keyword>NAT</keyword>
<keyword>RTP</keyword>
<keyword>SDP</keyword>
<keyword>binding</keyword>
<keyword>mapping</keyword>
<keyword>keepalive</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 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 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 SIP, agents can negotiate a unidirectional media stream by
using the SDP "recvonly" attribute on one agent and "sendonly" on the peer,
as defined in <xref target="RFC3264"/>.
RFC 3264 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 RFC 3264 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> In case of audio media, if silence suppression is in use, long periods of silence
may cause media transmission to cease sufficiently long for NAT bindings to time out.<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'/>) and makes recommendations about their use.
<xref target='recommend'/> finally states the recommended solution for RTP keepalive.
</t>
<t> The scope of the draft is limited to non-ICE agents.
Indeed, ICE agents need to follow the RTP keepalive mechanism specified
in the ICE specification <xref target="DRAFT-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> 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>More than one mechanism MAY exist.</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="DRAFT-RTP-RTCP"/>.
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>Multiplexing RTP and RTCP must be signalled in SDP offer/answer.</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="DRAFT-ICE"/>.</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>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>
</list>
</t>
</section>
</section>
<section anchor='recommend' title="Recommended Solution for Keepalive Mechanism">
<t> Some mechanisms do not meet the requirements as they are either specific to the transport (<xref target="transport"/>),
or specific to a media type (<xref target="comfort-noise"/>), or waste one RTP version number (<xref target="incorrect-version"/>).
These mechanisms are thus NOT RECOMMENDED. </t>
<t> Other mechanisms are dependent on the capabilities of the peer (<xref target="rtcp-mux"/>, <xref target="stun"/>).
Among these mechanisms, RTCP packets multiplexed with RTP packets (<xref target="rtcp-mux"/>) is desirable because it reduces
the number of ports used.</t>
<t>The RECOMMENDED solution is thus the "RTCP packets multiplexed with RTP packets" (<xref target="rtcp-mux"/>). However, when this mechanism cannot be negotiated, it
is RECOMMENDED to use the fallback "RTP Packet with Unknown Payload Type" mechanism (<xref target="unknown-pt"/>) as it will always work.</t>
<t>When using SDP, an agent supporting the fallback solution MUST indicate its support by adding an a=rtp-keepalive SDP attribute.
This attribute is declarative only and can not be negotiated.
It indicates that the fallback solution will be used if the recommended solution can not be used.</t>
<t>When using the SDP offer-answer <xref target="RFC3264"/>, the agent SHOULD offer both the "a=rtcp-mux" and "a=rtp-keepalive" attributes.
If "a=rtcp-mux" attribute is present in the answer, the agent uses RTCP packets being multiplexed on the RTP port as a keepalive. Otherwise, the agent uses RTP packets with an invalid payload type as a keepalive.</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>
<t>Real-time text payload format <xref target="RFC4103"/> is an example
of such a media format.</t>
<section title="Real-time Text Payload Format Keepalive Mechanism">
<t>Real-time text payload format <xref target="RFC4103"/> does not allow
different payloads within a same RTP session, so the fallback mechanism does not work.</t>
<t>For real-time text, the RECOMMENDED solution is the "RTCP packets multiplexed
with RTP packets". When this mechanism cannot be negotiated, it is
RECOMMENDED to use an empty T140block containing no data in the same
manner as for the idle procedure defined in <xref target="RFC4103"/>.</t>
</section>
</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. The minimum RECOMMENDED Tr
value is 15 seconds, and Tr SHOULD be configurable to larger values.</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"/>.
The fallback "RTP Packet with Unknown Payload Type" solution uses RTP,
and thus does not have these RTCP constraints.</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">
<section title="Registration of the SDP 'rtp-keepalive' Attribute">
<t>
This section instructs the IANA to register the following SDP att-
field under the Session Description Protocol (SDP) Parameters
registry:
</t>
<t>
Contact name: xavier.marjou@orange-ftgroup.com
</t>
<t>
Attribute name: rtp-keepalive
</t>
<t>
Long-form attribute name: RTP keepalive
</t>
<t>
Type of attribute Media level
</t>
<t>
Subject to charset: No
</t>
<t>
Purpose of attribute: The 'rtp-keepalive' attribute declares that the agent supports the fallback RTP keepalive mechanism (<xref target="unknown-pt"/>).</t>
<t>
Allowed attribute values: None
</t>
</section>
</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,
Randell Jesup, Remi Denis-Courmont, and Steve Casner for their useful inputs and comments.</t>
</section>
</middle>
<back>
<references title="Normative references">
&RFC2119;
&RFC3550;
&RFC5405;
&RFC4961;
<reference anchor='DRAFT-RTP-RTCP'>
<front>
<title>Multiplexing RTP Data and Control Packets on a Single Port</title>
<author initials='C.' surname='Perkins' fullname='Colin Perkins'><organization/></author>
<author initials='M.' surname='Magnus' fullname='Magnus Westerlund'><organization/></author>
<date month='August' year='2007' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-avt-rtp-and-rtcp-mux-07' />
</reference>
</references>
<references title="Informative references">
&RFC4787;
&RFC5382;
<reference anchor='DRAFT-ICE'>
<front>
<title>Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols</title>
<author initials='J.' surname='Rosenberg' fullname='Jonathan Rosenberg'><organization/></author>
<date month='October' year='2007' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-ice-19' />
</reference>
&RFC3264;
&RFC4103;
&RFC5389;
&RFC4566;
&RFC3389;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:56:27 |