One document matched: draft-lennox-avtcore-rtp-topo-offer-answer-00.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM
'reference.RFC.2119.xml'>
<!ENTITY rtp SYSTEM
'reference.RFC.3550.xml'>
<!ENTITY rtptopo SYSTEM
'reference.RFC.5117.xml'>
<!ENTITY sip SYSTEM
'reference.RFC.3261.xml'>
<!ENTITY sdp SYSTEM
'reference.RFC.4566.xml'>
<!ENTITY rtprtx SYSTEM
'reference.RFC.4588.xml'>
<!ENTITY avpf SYSTEM
'reference.RFC.4585.xml'>
<!ENTITY offeranswer SYSTEM
'reference.RFC.3264.xml'>
<!ENTITY bundle SYSTEM
'reference.I-D.ietf-mmusic-sdp-bundle-negotiation.xml'>
<!ENTITY sourcedesc SYSTEM
'reference.RFC.5576.xml'>
<!ENTITY cluertp SYSTEM
'reference.I-D.lennox-clue-rtp-usage.xml'>
]>
<?rfc toc="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="yes" ?>
<rfc category='info' ipr='trust200902' docName='draft-lennox-avtcore-rtp-topo-offer-answer-00'>
<front>
<title abbrev='RTP Offer/Answer Topology Considerations'>
Real-Time Transport Protocol (RTP) Topology Considerations for Offer/Answer-Initiated Sessions.
</title>
<author initials='J.' surname='Lennox'
fullname='Jonathan Lennox'>
<organization abbrev='Vidyo'>
Vidyo, Inc.
</organization>
<address>
<postal>
<street>433 Hackensack Avenue</street>
<street>Seventh Floor</street>
<city>Hackensack</city> <region>NJ</region>
<code>07601</code>
<country>US</country>
</postal>
<email>jonathan@vidyo.com</email>
</address>
</author>
<date />
<area>RAI</area>
<workgroup>AVTCORE</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<!-- TODO: more keywords -->
<abstract>
<t>
This document discusses a number of considerations related
to the topologies of Real-Time Transport Protocol (RTP)
sessions initated using the Session Description (SDP) unicast Offer/Answer Model,
especially as applied to source-multiplexed sessions.
</t>
<t>The primary observation is that certain topologies cannot be created by unicast SDP
Offer/Answer. Notably, the it is not possible to negotiate the topology that RFC 5117 calls
Topo-Transport-Translator (or "relay").
</t>
<t>As a consequence of this limitation, certain topological assumptions can safely be made for
RTP sessions initiated using unicast SDP Offer/Answer; and
therefore, certain optimizations to RTP are possible in such
sessions. This document also describes the optimizations
that these assumptions make possible.
</t>
</abstract>
</front>
<middle>
<section title='Introduction' anchor='introduction'>
<t>For interactive conferencing, by the far most common method of
negotiating <xref target='RFC3550'>Real-Time Tranport Protocol
(RTP)</xref> sessions is to use the <xref target='RFC4566'>Session
Description Protocol</xref> <xref target='RFC3264'>Offer/Answer
Model</xref>. In particular, conferences are typically negotated
using offer/answer unicast streams.</t>
<t>As discussed in <xref target='RFC5117' />, however, RTP sessions can be
arranged in a fairly large number of topologies, more complexly than
the simple dichotomy of "unicast" or "multicast" used by the
Offer/Answer model. Most of the unicast-based topologies in RFC
5117 can be negotiated as SDP Offer/Answer unicast streams.
However, for reasons that are explained in <xref target='topos' />,
one topology in particular cannot be negotiated using SDP
Offer/Answer: Topo-Transport-Translator.</t>
<t>While this might initially seem to be a limitation of SDP
Offer/Answer, it actually turns out that if an endpoint can assume
that its RTP topologies are limited to those that can be negotated
using offer/answer, a number of RTP optimizations become possible.
These are discussed in <xref target='optimizations' />, with
specific recommendations in <xref target='normative' />.</t>
</section>
<section title='Terminology'>
<t>The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY",
and "OPTIONAL" in this document
are to be interpreted as described in <xref
target='RFC2119'>RFC 2119</xref> and indicate requirement levels for
compliant implementations.</t>
</section>
<section title='RTP Topologies' anchor='topos'>
<t><xref target='RFC5117' /> discusses multi-endpoint topologies of
RTP sessions in detail. For the purposes of this document, a few
topologies in particular are of interest, and will be described in
detail.</t>
<figure anchor="point-to-point" title="Point to Point">
<artwork>
<![CDATA[
+---+ +---+
| A |<------->| B |
+---+ +---+
]]>
</artwork>
</figure>
<t>The simplest topology, shown in <xref target='point-to-point' />,
is Point to Point (Topo-Point-to-Point). A sends to B, and only B,
while B sends to A, and only A. An endpoint can still use multiple
synchronization sources (SSRCs) in a session.</t>
<t>This is topology is straightforwardly negotated by SDP
Offer-Answer unicast streams.</t>
<figure anchor="multicast" title="Point to Multipoint Using Multicast">
<artwork>
<![CDATA[
+-----+
+---+ / \ +---+
| A |----/ \---| B |
+---+ / Multi- \ +---+
+ Cast +
+---+ \ Network / +---+
| C |----\ /---| D |
+---+ \ / +---+
+-----+
]]>
</artwork>
</figure>
<t>Secondly, in the Topo-Multicast topology, shown in
<xref target='multicast' />, traffic from each endpoint in an RTP
session is received by all other session participants, transported by
the network level by sending to a special IP address. These
sessions can negotiated by the Offer/Answer model as multicast streams.</t>
<t>Multicast sessions are often supported within individual domains,
but are not typically supported accross the public Internet.</t>
<figure anchor="translator" title="RTP Translator (Relay) with Only Unicast Paths">
<artwork>
<![CDATA[
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Translator |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
]]>
</artwork>
</figure>
<t>Finally, for the purposes of this discussion, one other topology
described in <xref target='RFC5117' /> is specifically relevant; the
others can all be generalized.
The specific topology is the topology Topo-Transport-Translator,
illustrated in <xref target='translator' />, which simply forwards
unicast traffic (both media and Real-Time Transport Control Protocol
(RTCP) traffic) among all the unicast connections to a central
translator.</t>
<figure anchor="rtcp-modifier" title="RTCP-Modifying Central Box">
<artwork>
<![CDATA[
+---+ +------------+ +---+
| A |<---->| Media & |<---->| B |
+---+ | RTCP | +---+
| Modifier |
+---+ | or | +---+
| C |<---->| Terminator|<---->| D |
+---+ +------------+ +---+
]]>
</artwork>
</figure>
<t>By contrast, the topologies Topo-Media-Translator, Topo-Mixer,
Topo-Video-Switch-Mixer, and Topo-RTCP-Terminating-MCU can all be
summarized by the diagram shown in <xref target='rtcp-modifier' />. These
topologies all have the common property that they have a central box
(a media translator, mixer, or MCU) which terminates media and
RTCP traffic, and forwards it, modified to a greater or lesser
extent, to the topology's other endpoints.</t>
</section>
<section title='RTP Topologies and SDP Offer/Answer'>
<t><xref target='RFC3264'>The SDP Offer/Answer Model</xref> specifies
different behavior depending on whether the address of the transport connection being
negotiated is a unicast and multicast address. Effectively,
offer/answer assumes that the stream being negotated corresponds
either to Topo-Point-to-Point or Topo-Multicast.</t>
<t>Most of the RFC 5117 unicast topologies described in
<xref target='topos' /> can be negotiated by the
centralized point negotating with each endpoint using the
Offer/Answer unicast mode. However, the Topo-Transport-Translator
cannot be.</t>
<t>The difficulty is that SDP Offer/Answer unicast exchange is
designed to negotate each end of the excahnge's separate view of the
session, and each endpoint has a fair bit of control over what its
view of the session should look like. However, because the
translator at the center of the Topo-Transport-Translator topology
forwards media and RTCP unmodified, it is necessary that all
participants have a common view of all non-transport aspects of the
session.</t>
<t>Thus, the freedom that the Offer/Answer model gives each endpoint
to control its view of the session prevents the central box from
enforcing a single, uniform view of it. Among the session aspects
that can be different among the session participants are:</t>
<t><list style="hanging">
<t hangText='Media Types:'>Unicast Offer/Answer participants have the
freedom to remove media types from the session description (in an
answer or an updated offer). They also have the freedom to change
some fmtp media type parameters. Moreover, though RFC 3264 indicates
that it is NOT RECOMMENDED, they have the freedom to change the
mapping between media typees and RTP payload type numbers.</t>
<t hangText='Bandwidth:'>An answerer can specify a bandwidth attribute
(SDP b= value) for any media stream, indicating the bandwidth that
the answerer would like the offerer to use when sending media. This
does bear any relationship to bandwidth values in use in the other
direction. (This is somewhat problematic as SDP bandwidth
parameters are used to calculate RTCP bandwidth, and thus RTP
session membership timeout intervals.)</t>
<t hangText='Packetization Time:'>An SDP offer or answer can specify
the ptime attribute (packetization time interval) with which it
wants to receive media. This value is independent in offers and
answers.</t>
</list></t>
<t>In addition to these mismatches for the attributes specified by the
core SDP Offer/Answer specification, there are of course many
extensions to SDP which specify Offer/Answer behavior. These are
not discussed here, but many of them would have similar issues with
the Topo-Transport-Translator topology.</t>
<t>Any of the media and RTCP terminating topologies described in
<xref target='topos' /> as modifying media and RTCP will be able to
repair these mismatches, or else reject an endpoint that asks for a
configuration beyond its capacity to repair. The mismatch
difficulties arise only for the Topo-Transport-Translator.</t>
</section>
<section title='Advantages for Assuming RTCP rewriting' anchor='optimizations'>
<t>If we assume that we always have a central box that can rewrite, or
generates its own, media and RTCP, a number of optimizations and
protocol clarifications become possible.</t>
<section title='Independent RTCP bandwidth'>
<t>SDP Unicast Offer/answer allows RTP session bandwidth to be
specified independently in each direction of the offer/answer
exchange. The assumption is that bandwidth in each direction is
(over the relevant bottleneck links) non-rival, and that the
available bitrates can in some circumstances be dramatically
asymmetric.</t>
<t>It has always been somewhat unclear how offer/answer assymetric
bandwidths interact with the RTCP bandwidth fraction (5%, or the
SDP bandwidth modifiers).</t>
<t>If we assume that RTCP is never passively relayed, but rather will
always either be consumed locally or will actively be rewritten
before being forwarded, this problem largely goes away. Each
side of the unicast RTP session domain gets the appropriate fraction
of its (sending) RTP bandwidth to send RTCP. It can divide this
fraction among its sources as it wishes, subject ot the constraint
that a regular report is sent for each source with appropriate
frequency to prevent timeouts. Group size estimation is only
needed for timeout calculation. It can be done independently for
sending and receiving media.</t>
<t>Since RTCP bandwidth can be shared among all the sources, a sender
can then also send feedback from multiple of its sources in a single
compound RTCP packet, up to transport MTU issues, reducing transport
overhead.</t>
</section>
<section title='Optimization of receiver reports'>
<t>For the benefit of Topo-Multicast and Topo-Transport-Translator,
in an RTCP session, all session participants send RTCP reception reports (in SR or
RR RTCP packets) for every active RTP source from which they have
received packets in the previous reporting interval.</t>
<t>This means that the number of reception reports is quadratic in the
number of sources in a conference. (Specifically, the number equals the
number of conference participants, times the number of active senders
whos sent during a report interval. However, because the report
interval itself scales with the number of sources, this will in
a many-to-many conference converge to being quadratic in the number
of sources.)</t>
<t>In cases where there is an media-and-RTCP-modifying middlebox, this
quadratic behavior is useless. The relevant reception report
information is that between and endpoint and the middlebox, since
the middlebox can often perform reliability and repair mechanisms on
its own. These excess reception reports then increase the size of
RTCP packets, which by the formulas for calculating RTCP packet
transmission schedules reduces the RTCP timing interval. Thus,
these excess reception reports consume bandwidth which could instead
be used for timely RTCP feedback of relevant data.</t>
<t>These quadratic reception reports are particularly useless in
scenarios where a given session participant is sending multiple
sources of its own (rather than forwarding multiple remote sources)
in the same RTP session. Examples of such use cases are the
<xref target='I-D.lennox-clue-rtp-usage'>CLUE Telepresence
model</xref>, <xref target='I-D.ietf-mmusic-sdp-bundle-negotiation'>bundling of
multiple media types onto a single RTP session</xref>,
and <xref target='RFC4588'>single-session RTP retransmission</xref>;
in general, this will apply to most scenarios in
which <xref target='RFC5576'>SDP source descriptions</xref> are used.</t>
<t>The most useless data is reception reports by one local source
about another, since these will always (by definition) be "received"
perfectly (with zero loss and jitter) by their sender.</t>
<t>Nearly as useless redundant feedback from multiple co-located
sources about the same remote source. Since RTP traffic is in fact
received by an endpoint, not a source, this information will either
be identical (if an endpoint choses to synchronize its RTCP feedback
messages) or multiple, non-commensurate transmissions of the same
information (if it does not).</t>
<t>Also often useless is feedback by one remote source about
another one -- while there are some conceivable use cases where this
could be relevant information (for instance, a monitoring
application), in most conferencing models, this is uninteresting and
unimportant.</t>
</section>
</section>
<section title='Normative recommendations' anchor='normative'>
<t>Based on the analysis in <xref target='optimizations' />, this
section makes some normative recommendations for the behavior of RTP
endpoints in sessions negotiated using unicast SDP Offer/Answer.</t>
<t>(Open issue: it is possible that these recommendations might need to be a
normative update to <xref target='RFC3550' />; alternatively, they
may just be implementation guidance.)</t>
<t>When an <xref target='RFC3550'>RTP</xref> session is negotiated
using unicast <xref target='RFC3264'>SDP offer/answer</xref>,
RTCP bandwidth, and thus RTCP packet intervals and RTP group membership
timeout rules, MUST be calculated separately for the receiving and
sending direction, using the rules specified in
<xref target='RFC3550' /> as modified by any SDP attributes or the
RTP profile in use. An endpoint MAY send RTCP up to its available
bandwidth, independent of the bandwidth consumed in the reverse
direction, again subject to the SDP modifiers and profiles in use.</t>
<t>An endpoint MAY choose to send multiple sources' RTCP messages in a
single compound RTCP packet (though such compound packets SHOULD NOT
exceed the path MTU, if avoidable and if it is known). This will
reduce the average
compound RTCP packet size, and thus increase the frequency with which
RTCP messages can be sent. Regular (non-feedback) RTCP compound
packets MUST still begin with an SR or RR packet, but otherwise MAY
contain RTCP packets in any order. Receivers MUST be prepared to
receive such compound packets.</t>
<t>An endpoint SHOULD NOT send reception reports from one of
its own sources about another one ("cross-reports"). Endpoints
receiving reception reports MUST be
prepared that their peers might not be sending reception reports about
their own sources.</t>
<t>Similarly, an endpoint sending multiple sources SHOULD NOT send
reception reports about a remote source from more than one of its local
sources. Instead, it SHOULD create or pick one local source as the
"reporting" source for each remote source, which sends full report
blocks; all its other
sources SHOULD be treated as if they were disconnected, and never saw that
remote source. This reporting source MAY be one of the sending
sources in the session, or MAY be a receive-only source created
simply for the purpose of sending feedback. An endpoint MAY choose different local
sources as the reporting source for different remote sources (for
example, if it is
using <xref target='I-D.ietf-mmusic-sdp-bundle-negotiation'>bundle</xref>,
it could choose to send reports about remote audio sources
from its local audio source, and reports about remote video sources
from its local video source), or it MAY choose a single local source
for all its reports. If the reporting source leaves the
session (sends BYE), another reporting source MUST be chosen. If
the <xref target='RFC4585'>AVPF</xref> RTP profile, or one if its
secure equivalents, is in use, this
"reporting" source SHOULD also
be the source for any AVPF feedback messages about its
remote sources, as well. Endpoints interpreting reception reports
MUST be prepared to receive RTCP SR or RR messages where only one
remote source is reporting about its sources.</t>
</section>
<section title='Limitations of media and RTCP modifying middleboxes' anchor='limitations'>
<t>There are a few limitations of media and RTCP modifying
middleboxes, compared to what can be done by the
Topo-Transport-Translator topology.</t>
<t>A media and RTCP modifying middlebox will, necessarily, be more
complex (and thus be more expensive, or have lower capacity), than a
pure transport forwarder.</t>
<t>It is not possible to deploy new RTCP extensions across an
unmofidified RTCP-modifying central box, as that box will not know
how to re-write these extensions so they are correctly forwarded.</t>
<t>If SRTP is in use, these central middleboxes must be trusted with the
SRTP keying material. (Since SRTP keying material is usually
negotiated hop-by-hop, they may be doing a complete SRTP decryption
and re-encryption, with unrelated keys, and possibly even
translating between different ciphers or cipher strengths.)</t>
<t>It is possible, if the recommendations of
<xref target='normative'/> are in use, that a naive RTCP monitor
might think that an RTP flow should actually be interpreted as
Topo-Transport-Translator. In this case, it might think that there
is a network disconnection between the non-reporting sources and the
sources on which they are not reporting. However,
architecturally it is very unclear if such monitors actually exist,
for conferencing applications, or
would care about a disconnection of this sort.</t>
</section>
<section title='Security Considerations' anchor='security'>
<t>See the security considerations of <xref target='RFC5117' />.
Notably, as discussed in <xref target='limitations' />, a centralized
media and RTCP modifying box will need to terminate SRTP and SRTCP,
and so must be a trusted entity.</t>
</section>
<section title='IANA Considerations' anchor='iana'>
<t>This document makes no requests of IANA.</t>
<t>Note to the RFC Editor: please remove this section before publication.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rtp;
&sdp;
&offeranswer;
&avpf;
</references>
<references title='Informative References'>
&rtptopo;
&rtprtx;
&bundle;
&sourcedesc;
&cluertp;
</references>
<!--
<section title='Open issues'>
<t><list style='symbols'>
<t></t>
</list></t>
</section>
-->
<!--
<section title='Changes From Earlier Versions'>
<t>Note to the RFC-Editor: please remove this section prior to publication
as an RFC.</t>
<section title='Changes From Draft -00'>
<t><list style='symbols'>
<t></t>
</list></t>
</section>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:13:45 |