One document matched: draft-ietf-avt-app-rtp-keepalive-03.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'>
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<rfc ipr='full3978' category='bcp'>
<?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='April' year='2008' />
<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="DRAFT-NAT-TCP-REQS"/> describe NAT behaviors
and point out that two key aspects of NAT are mappings (a.k.a. bindings) and their refreshment.
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 alive.</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 do not generate a minimum 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 RFC 3264 <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 also 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>
</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>Session description 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>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='udp' title="UDP Packet of 0-byte">
<t>The application sends an empty UDP packet.</t>
<t>Cons:
<list style="symbols">
<t> This alternative is specific to UDP.</t>
</list>
</t>
<t>Recommendation:
<list style="symbols">
<t>This method should not be used for RTP keepalive.</t>
</list>
</t>
</section>
<section anchor='dccp' title="DCCP Packet of 0-byte">
<t>The application sends an empty DCCP packet.</t>
<t>Cons:
<list style="symbols">
<t> This alternative is specific to DCCP.</t>
</list>
</t>
<t>Recommendation:
<list style="symbols">
<t>This method should not be used for RTP keepalive.</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>
<t>Recommendation:
<list style="symbols">
<t>This method may be used when the media allows for it.</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>
<t>Recommendation:
<list style="symbols">
<t>This method must only be used for RTP keepalive when negotiated between agents.</t>
</list>
</t>
</section>
<section anchor='stun' title="STUN Indication Packet">
<t>The application sends a STUN <xref target="DRAFT-STUN"/> 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 support STUN.</t>
</list>
</t>
<t>Recommendation:
<list style="symbols">
<t>This method must only be used for sessions between ICE agents, as specified in <xref target="DRAFT-ICE"/>.</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>RFC4566 <xref target="RFC4566"/> and RFC3264 <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>
<t>Recommendation:
<list style="symbols">
<t>This method should not be used for RTP keepalive.</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>RFC4566 <xref target="RFC4566"/> and RFC3264 <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>
<t>Recommendation:
<list style="symbols">
<t>This method should be used for RTP keepalive.</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="udp"/>, <xref target="dccp"/>),
or specific to a media type (<xref target="comfort-noise"/>). 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>
</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
to use 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 keepalive packets
every Tr seconds during the whole duration of the media session.
Tr SHOULD be configurable, and otherwise MUST default to 15 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"/>.
The fallback "RTP Packet with Unknown Payload Type" solution uses RTP,
and thus does no have these RTCP constraints.</t>
<t>Keepalives 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 keepalive packets are sent on the same path as regular RTP media packets.
In addition, they do not convey any valuable information.
So the mechanism described here does not imply new security issues.</t>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</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,
and Randell Jesup for their useful inputs and comments.</t>
</section>
</middle>
<back>
<references title="Normative references">
&RFC2119;
&RFC3550;
&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;
<reference anchor='DRAFT-NAT-TCP-REQS'>
<front>
<title>NAT Behavioral Requirements for TCP</title>
<author initials='S.' surname='Guha' fullname='Saikat Guha'><organization/></author>
<author initials='K.' surname='Biswas' fullname='Kaushik Biswas'><organization/></author>
<author initials='B.' surname='Ford' fullname='Bryan Ford'><organization/></author>
<author initials='P.' surname='Francis' fullname='Paul Francis'><organization/></author>
<author initials='S.' surname='Sivarkumar' fullname='Senthil Sivakumar'><organization/></author>
<author initials='P.' surname='Srisuresh' fullname='Pyda Srisuresh'><organization/></author>
<date month='April' year='2007' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-behave-tcp-07' />
</reference>
<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;
<reference anchor='DRAFT-STUN'>
<front>
<title>Simple Traversal Underneath Network Address Translators (NAT) (STUN)</title>
<author initials='J.' surname='Rosenberg' fullname='Jonathan Rosenberg'><organization/></author>
<author initials='P.' surname='Matthews' fullname='Philip Matthews'><organization/></author>
<author initials='R.' surname='Mahy' fullname='Rohan Mahy'><organization/></author>
<author initials='D.' surname='Wing' fullname='Dan Wing'><organization/></author>
<date month='February' year='2008' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-behave-rfc3489bis-15' />
</reference>
&RFC4566;
&RFC3389;
&RFC4103;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:31:29 |