RFC 5117
RTP Topologies
RTP Topologies 🎀
Okay bestie, here's the title block tea ☕ This is RFC 5117, from the Network Working Group, with Request for Comments: 5117. It was written by M. Westerlund (Ericsson) and S. Wenger (Nokia) in January 2008. It's in the Informational category, and the title block doesn't list anything it obsoletes or updates 🦋.
Status of This Memo ✨
Okay so this memo is just here to provide information for the Internet community 💅. It does not specify an Internet standard of any kind, and distribution of this memo is unlimited 🌈.
Abstract 🦋
This doc talks about multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments 🧚. Specifically, the centralized setups that the video conferencing industry loves get mapped to RTP terminology 💜.
Table of Contents 📜
1. Introduction ....................................................2
2. Definitions .....................................................3
2.1. Glossary ...................................................3
2.2. Indicating Requirement Levels ..............................3
3. Topologies ......................................................3
3.1. Point to Point .............................................4
3.2. Point to Multipoint Using Multicast ........................5
3.3. Point to Multipoint Using the RFC 3550 Translator ..........6
3.4. Point to Multipoint Using the RFC 3550 Mixer Model .........9
3.5. Point to Multipoint Using Video Switching MCUs ............11
3.6. Point to Multipoint Using RTCP-Terminating MCU ............12
3.7. Non-Symmetric Mixer/Translators ...........................13
3.8. Combining Topologies ......................................14
4. Comparing Topologies ...........................................15
4.1. Topology Properties .......................................15
4.1.1. All to All Media Transmission ......................15
4.1.2. Transport or Media Interoperability ................16
4.1.3. Per Domain Bit-Rate Adaptation .....................16
4.1.4. Aggregation of Media ...............................16
4.1.5. View of All Session Participants ...................16
4.1.6. Loop Detection .....................................17
4.2. Comparison of Topologies ..................................17
5. Security Considerations ........................................17
6. Acknowledgements ...............................................19
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................201. Introduction 🎀
So when the team was working on the Codec Control Messages [CCM], the community got super confused 😭 about terms like Multipoint Control Unit (MCU), Mixer, and Translator, and how they show up in different topologies 💀. This document tries to fix that by giving everyone a shared info base for future discussion and spec work ✨. It explains sections of the Real-time Transport Protocol (RTP) spec [RFC3550] in an informal way 🫶. It is not intended to update or change what is normatively specified in RFC 3550 🙅.
When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was developed, the main focus was efficient support for point to point and small multipoint scenarios without centralized multipoint control 🌸. But in practice, lots of small multipoint conferences run on devices called Multipoint Control Units (MCUs) 🍓. MCUs may implement Mixer or Translator (in RTP [RFC3550] terminology) functionality and signalling support. They may also contain additional application functionality 👑. This document focuses on the media transport aspects of the MCU that can be realized using RTP, as discussed below 🦋. It also considers the properties of Mixers and Translators, and how some types of deployed MCUs deviate from these properties 💅.
2. Definitions 💖
2.1. Glossary 📖
ASM - Any Source Multicast
AVPF - The Extended RTP Profile for RTCP-based Feedback
CSRC - Contributing Source
Link - The data transport to the next IP hop
MCU - Multipoint Control Unit
Path - The concatenation of multiple links, resulting in an
end-to-end data transfer.
PtM - Point to Multipoint
PtP - Point to Point
SSM - Source-Specific Multicast
SSRC - Synchronization Source2.2. Indicating Requirement Levels 📏
Here's where the requirement words live 🔥 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
The RFC 2119 language is used in this document to highlight the important requirements and/or resulting solutions that are necessary to address the issues raised in this document 💜.
3. Topologies 🗺️
This part defines several basic topologies that are relevant for codec control ✨. The first four relate to the RTP system model that uses multicast and/or unicast, as envisioned in RFC 3550. The last two, on the other hand, describe the deployed system models used in lots of H.323 [H323] video conferences, where both the media streams and the RTP Control Protocol (RTCP) control traffic terminate at the MCU 🧚. In those last two cases, the media sender does not receive the (unmodified or Translator-modified) Receiver Reports from all sources (which it needs to interpret based on Synchronization Source (SSRC) values). So it has no full info about all the endpoints' situations as reported in RTCP Receiver Reports (RRs) 😭. More topologies can be built by combining any of these models; see Section 3.8 🎀.
The topologies may be referenced in other documents by a shortcut name, indicated by the prefix "Topo-" 🏷️.
For each of the RTP-defined topologies, we talk about how RTP, RTCP, and the carried media are handled 🌈. For RTCP, we also introduce how RTCP feedback messages are handled, as defined in [RFC4585] and [CCM]. Any important differences between the two will be illuminated in the discussion 💡.
3.1. Point to Point 💞
Shortcut name: Topo-Point-to-Point
The Point to Point (PtP) topology (Figure 1) is two endpoints talking over unicast 🫶. Both RTP and RTCP traffic go endpoint-to-endpoint, using unicast traffic only (even if, in exotic cases, this unicast traffic happens to be carried over an IP-multicast address) 🤓.
+---+ +---+
| A |<------->| B |
+---+ +---+
Figure 1 - Point to PointThe main property of this topology is that A sends to B, and only B, while B sends to A, and only A 💅. This avoids all the complexities of handling multiple endpoints and combining their requirements ✨. Note that an endpoint can still use multiple RTP Synchronization Sources (SSRCs) in an RTP session 🦋.
RTCP feedback messages for the indicated SSRCs are communicated directly between the endpoints. Therefore, this topology poses minimal (if any) issues for any feedback messages 🙌.
3.2. Point to Multipoint Using Multicast 📡
Shortcut name: Topo-Multicast
+-----+
+---+ / \ +---+
| A |----/ \---| B |
+---+ / Multi- \ +---+
+ Cast +
+---+ \ Network / +---+
| C |----\ /---| D |
+---+ \ / +---+
+-----+
Figure 2 - Point to Multipoint Using MulticastPoint to Multipoint (PtM) is defined here as using a multicast topology as a transmission model 🍓. Traffic from any participant reaches all the other participants, except for cases such as:
- packet loss, or
- when a participant does not wish to receive the traffic for a specific multicast group and therefore has not subscribed to the IP-multicast group in question. This is for the cases where a multi-media session is distributed using two or more multicast groups.
In this context, "traffic" covers both RTP and RTCP traffic 🎀. The number of participants can vary from one to many, since RTP and RTCP scale to very large multicast groups (the theoretical limit on participants in a single RTP session is approximately two billion 🤯). The above can be realized using Any Source Multicast (ASM). Source-Specific Multicast (SSM) may also be used with RTP. However, then only the designated source may reach all receivers. Please review [RTCP-SSM] for how RTCP can be made to work in combination with SSM 📚.
This document is mainly interested in the subset of multicast sessions where the number of participants in the group is so low that they can use early or immediate feedback, as defined in AVPF [RFC4585] 💜. This document refers to those groups as "small multicast groups" 🌸.
RTCP feedback messages in multicast will, like media, reach everyone (subject to packet losses and multicast group subscription). Therefore, the feedback suppression mechanism discussed in [RFC4585] is required 🙈. Each individual node needs to process every feedback message it receives to determine if it is affected or if the feedback message applies only to some other participant 🫶.
3.3. Point to Multipoint Using the RFC 3550 Translator
Shortcut name: Topo-Translator
Okay so, there are two main flavours of Translator bestie 🦋 Transport Translators (Topo-Trn-Translator) don't touch the actual media stream at all. They care about the transport parameters 💅 Those are the transport addresses (for bridging different domains) and the media packetization (so other transport protocols can plug into a session, in gateways). Of the transport Translators, this memo is mainly into the ones that use RTP on both sides, and that's the assumption from here on 🌸 If you're bridging between different protocol worlds, you have to think about how the SSRC/CSRC (Contributing Source) concept maps onto the non-RTP protocol. Designing a Translator for a non-RTP media transport is its own whole vibe, because handling different sources and their identities is a crucial factor. That problem space is NOT discussed henceforth, so we're skipping it 🙈
Then we have Media Translators (Topo-Media-Translator), which are the opposite energy 🔥 They DO modify the media stream itself. This is commonly known as transcoding. It can be as small as removing parts of the stream, or go all the way to a full transcoding (down to the sample level or equivalent) using a different media codec. Media Translators are commonly used to connect entities that don't have a common interoperability point, which is so relatable 🫶
Stand-alone Media Translators are rare, lowkey. Most commonly you'll see a combo of Transport and Media Translators, translating both the media stream and the transport aspects between two transport domains (or clouds) ☁️
Both Translator types share the common attributes that set them apart from Mixers 👑 For each media stream the Translator receives, it generates an individual stream in the other domain. A Translator always keeps the SSRC for a stream across the translation. A Mixer, on the other hand, can select a media stream or send them out mixed, always under its own SSRC, using the CSRC field to indicate the source(s) of the content. Different vibes entirely ✨
The RTCP translation process can be trivial, like when Transport Translators just need to adjust IP addresses. Or it can be quite complex, as in the case of media Translators. See Section 7.2 of [RFC3550] 💖
+-----+
+---+ / \ +------------+ +---+
| A |<---/ \ | |<---->| B |
+---+ / Multi- \ | | +---+
+ Cast +->| Translator |
+---+ \ Network / | | +---+
| C |<---\ / | |<---->| D |
+---+ \ / +------------+ +---+
+-----+Oops, let me fix that paste. Here is the figure as it appears in the original:
+-----+
+---+ / \ +------------+ +---+
| A |<---/ \ | |<---->| B |
+---+ / Multi- \ | | +---+
+ Cast +->| Translator |
+---+ \ Network / | | +---+
| C |<---\ / | |<---->| D |
+---+ \ / +------------+ +---+
+-----+
Figure 3 - Point to Multipoint Using a TranslatorFigure 3 shows a Transport Translator doing at least IP address translation 🌈 It lets the (non-multicast-capable) participants B and D join a multicast session by having the Translator forward their unicast traffic to the multicast addresses in use, and vice versa. It must also forward B's traffic to D, and vice versa, so that each of B and D gets a complete view of the session 💜
If B were behind a limited network path, the Translator MAY perform media transcoding so the traffic from the other participants can reach B without overloading the path 🍓
When the Translator in Figure 3 acts only as a Transport Translator, the RTCP traffic can just be forwarded, same as the media traffic. But once media translation happens, the Translator's job gets substantially more complex, even for RTCP traffic 😭 The Translator needs to rewrite B's RTCP Receiver Reports before forwarding them to D and the multicast network. That's because the stream B receives is NOT the same stream the other participants get. For example, the number of packets sent to B may be lower than what D receives, because of the different media format. So if the Receiver Reports were forwarded without changes, the extended highest sequence number would make it look like B was way behind in reception, when it most likely wasn't 🙈 That means the Translator MUST translate that number to a corresponding sequence number for the stream the Translator received. Similar arguments apply to most other fields in the RTCP Receiver Reports 🎀
As specified in Section 7.1 of [RFC3550], the SSRC space is common for all participants in the session, no matter which side of the Translator they're on. So it's the participants' responsibility to run SSRC collision detection, and the SSRC is a field the Translator SHOULD NOT change 🧚
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Translator |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+Figure 4 - RTP Translator (Relay) with Only Unicast Paths
Another Translator scenario is Figure 4 🦋 Here, the Translator connects multiple users of a conference through unicast. This can be done with a very simple transport Translator, which this document calls a relay. The relay forwards all traffic it receives, both RTP and RTCP, to all other participants. That way a multicast network gets emulated WITHOUT relying on a multicast-capable network infrastructure, which is honestly iconic ✨
A Translator normally does NOT use an SSRC of its own, and isn't visible as an active participant in the session 👀 One exception: a Translator acting as a quality monitor that sends RTCP reports, which means it REQUIRES an SSRC. Another example is when a Translator is set up to use RTCP feedback messages. That might happen when it suffers packet loss of important video packets and wants to trigger repair by the media sender, by sending feedback messages. To do this, it needs a unique SSRC 💅
A media Translator may sometimes act on behalf of the "real" source and respond to RTCP feedback messages. For example, when a receiver requests a bandwidth reduction and the media Translator hasn't detected any congestion or other reason for bandwidth reduction between the media source and itself. In that case, it's sensible for the media Translator to react to the codec control messages itself, for instance by transcoding to a lower media rate. If it didn't react, the media quality in the media sender's domain could suffer, because the media sender would adjust its media rate (and quality) to the needs of the slow past-Translator endpoint, at the expense of everyone else in the session 😭
In general, a Translator implementation SHOULD consider which RTCP feedback messages or codec-control messages it needs to understand in relation to its own functionality. This is totally in line with the requirement to also translate RTCP messages between the domains 💖
3.4. Point to Multipoint Using the RFC 3550 Mixer Model
Shortcut name: Topo-Mixer
A Mixer is a middlebox that aggregates multiple RTP streams that are part of a session, by mixing the media data and generating a new RTP stream 🎧 One common use case for a Mixer is letting a participant receive a session with fewer resources, which is such a mood 🌸
+-----+
+---+ / \ +-----------+ +---+
| A |<---/ \ | |<---->| B |
+---+ / Multi- \ | | +---+
+ Cast +->| Mixer |
+---+ \ Network / | | +---+
| C |<---\ / | |<---->| D |
+---+ \ / +-----------+ +---+
+-----+
Figure 5 - Point to Multipoint Using the RFC 3550 Mixer ModelThink of a Mixer as a device that terminates the media streams received from other session participants. Using the media data from those received streams, the Mixer generates a media stream that gets sent to the session participant 🦋
The content the Mixer provides is the mixed aggregate of what it receives over the PtP or PtM paths that are part of the same conference session 💜
The Mixer is the content source, since it mixes the content (often in the uncompressed domain) and then encodes it for transmission to a participant. The CSRC Count (CC) and CSRC fields in the RTP header are used to indicate the contributors to the newly generated stream. The SSRCs of the to-be-mixed streams on the Mixer input appear as the CSRCs at the Mixer output. That output stream uses a unique SSRC that identifies the Mixer's stream. The CSRCs are forwarded between the two domains to allow loop detection and identification of sources that are part of the global session. Note that Section 7.1 of RFC 3550 requires the SSRC space to be shared between domains for these reasons 🔥
The Mixer is responsible for generating RTCP packets in line with its role. It's a receiver, so it SHOULD send reception reports for the media streams it receives. In its role as a media sender, it SHOULD also generate Sender Reports for the media streams sent. As specified in Section 7.3 of RFC 3550, a Mixer MUST NOT forward RTCP unaltered between the two domains 🙅♀️
The Mixer in Figure 5 is involved in three domains that need to be separated: the multicast network, participant B, and participant D. The Mixer produces different mixed streams for B and D, since the one to B may contain content received from D, and vice versa. However, the Mixer only needs one SSRC in each domain that acts as the receiving entity and transmitter of mixed content 🧚
In the multicast domain, a Mixer still needs to provide a mixed view of the other domains. This makes the Mixer simpler to implement and avoids issues with advanced RTCP handling or loop detection, which would be problematic if the Mixer were providing non-symmetric behavior. Please see Section 3.7 for more discussion on this topic 🌈
A Mixer is responsible for receiving RTCP feedback messages and handling them appropriately. What counts as "appropriate" depends on the message itself and the context. In some cases, receiving a codec-control message may result in the Mixer generating and transmitting RTCP feedback messages to the participants in the other domain. In other cases, a message is handled by the Mixer itself and therefore NOT forwarded to any other domain 🎀
When the multicast network in Figure 5 (to the left of the Mixer) is replaced with individual unicast paths, as in Figure 6, the Mixer model is very similar to the one discussed in Section 3.6 below. Check out the discussion in Section 3.6 for the differences between these two models 💅
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Mixer |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+Figure 6 - RTP Mixer with Only Unicast Paths
3.5. Point to Multipoint Using Video Switching MCUs 🎬✨
Shortcut name: Topo-Video-switch-MCU 💖
+---+ +------------+ +---+
| A |------| Multipoint |------| B |
+---+ | Control | +---+
| Unit |
+---+ | (MCU) | +---+
| C |------| |------| D |
+---+ +------------+ +---+
Figure 7 - Point to Multipoint Using a Video Switching MCUokay so this PtM topology is still out there in the wild today 🌸 the RTCP-terminating MCUs (we get to them in the next section) are kinda more common tho 👑 both this one and the next one are giving "we don't have wide IP multicast yet" vibes 🫶 plus content switching is just way simpler than content mixing 💅 this is what people call "Video Switching MCUs" 🦋
a video switching MCU forwards ONE media stream to a participant, picked from all the available ones 🎀 the selection is usually based on voice activity in the audio-visual conference ✨ but other conference management stuff like presentation mode or explicit floor control also exists 💅
the video switching MCU can also do media translation to change the content's bit-rate, encoding, or resolution 🌈 but it can still show who the original sender was through the SSRC 🧚 and in that case, the CC and CSRC field values are kept 🍓
if it isn't terminating RTP, the RTCP Sender Reports get forwarded for whichever sender is currently selected 🦋 all the RTCP Receiver Reports are freely forwarded between participants 💜 and the MCU might also create its own RTCP control traffic to control the session and/or report on status from its point of view 🔥
so the video switching MCU has most of the attributes of a Translator 🌸 BUT its stream selection is actually a mixing behavior 😭 and that brings some RTP and RTCP issues with it 💀 suppressing all but one media stream means most participants only see a subset of the sent media streams at any time (often just one stream per conference) 🙈 so RTCP Receiver Reports only report on those streams 🥺 which means the media senders that aren't currently forwarded get a view of the session where their streams just... disappear somewhere along the way 👻 and honestly that makes using RTCP for congestion control, or any kind of quality reporting, super problematic 😩
to avoid all these issues, the MCU needs two features 👑 first, it needs to act as a Mixer (see Section 3.4) and forward the selected media stream under its own SSRC, with the appropriate CSRC values 🎀 second, the MCU needs to modify the RTCP RRs it forwards between domains 💅 so yeah, it is RECOMMENDED to build a centralized video switching conference using a Mixer according to RFC 3550, instead of this shortcut implementation 🫶✨
3.6. Point to Multipoint Using RTCP-Terminating MCU 💜
Shortcut name: Topo-RTCP-terminating-MCU 🧚
+---+ +------------+ +---+
| A |<---->| Multipoint |<---->| B |
+---+ | Control | +---+
| Unit |
+---+ | (MCU) | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Figure 8 - Point to Multipoint Using Content Modifying MCUsin this PtM scenario, every participant runs an RTP point-to-point session between itself and the MCU 🦋 this is a super commonly deployed topology in multipoint video conferencing 🔥 and the content the MCU gives each participant is either:
a) a selection of the content received from the other participants, or 💖
b) the mixed aggregate of what the MCU gets from the other PtP paths that are part of the same conference session 🌈
in case a), the MCU may modify the content's bit-rate, encoding, or resolution 🎀 there's no explicit RTP mechanism that links the original media sender to the version the MCU sends 😭 so the outgoing sessions typically use a different SSRC, and might well use a different payload type (PT), even if that different PT is mapped to the same media type 🙈 this happens because each participant gets an individually negotiated session 🧚
in case b), the MCU is the content source, since it mixes the content and then encodes it for transmission to a participant 💅 according to RTP [RFC3550], the SSRCs of the contributors are supposed to be signalled using the CSRC/CC mechanism 🫶 but honestly, today most deployed MCUs don't implement this 🥲 instead, which participants' content went into the Mixer's output isn't indicated through any explicit RTP mechanism 👻 most deployed MCUs just set the CSRC Count (CC) field in the RTP header to zero, meaning "no CSRC info here," even when they could identify the content sources like RTP suggests 💀
the big thing that sets this topology apart from what RFC 3550 describes is that the common RTP session gets broken across the centralized device, like the MCU 🌸 which means losing explicit RTP-level indication of all participants 😩 if you used RTP and RTCP mechanisms to signal this explicitly, the topology would follow the approach of an RTP Mixer 👑 without that explicit indication, there are at least these potential problems 🙈
- Loop detection cannot be performed on the RTP level. When carelessly connecting two misconfigured MCUs, a loop could be generated 🌀💀
- There is no information about active media senders available in the RTP packet. Since this info is missing, receivers can't use it 😭 it also deprives the client of information about currently active senders in a machine-usable way, so clients can't indicate active speakers in user interfaces, etc. 🥺
note that deployed MCUs (and endpoints) rely on signalling layer mechanisms to identify the contributing sources, for example a SIP conferencing package [RFC4575] 🦋 this kinda alleviates the issues above that come from ignoring RTP's CSRC mechanism, to some extent ✨
so because of these shortcomings, it is RECOMMENDED to instead implement the Mixer concept as specified by RFC 3550 🎀💅
3.7. Non-Symmetric Mixer/Translators 🌈
Shortcut name: Topo-Asymmetric 🧚
it is theoretically possible to build an MCU that's a Mixer in one direction and a Translator in another 🦋 the main reason to consider this would be to allow topologies similar to Figure 5, where the Mixer doesn't need to mix in the direction from B or D towards the multicast domains with A and C 💖 instead, the media streams from B and D get forwarded without changes 🌸 avoiding that mixing would save media processing resources that would otherwise do mixing when it isn't needed 💅 however, there would still be a need to mix B's stream towards D 😭 it would only be possible to work as a Translator in the direction B -> multicast domain or D -> multicast domain 🫶 in all other directions, it would function as a Mixer 👑
the Mixer/Translator would still need to process and change the RTCP before forwarding it in the directions of B or D to the multicast domain 🎀 one issue is that A and C don't know about the mixed-media stream the Mixer sends to either B or D 🙈 so any reports related to these streams MUST be removed 🥺 wait, sorry, I mean: any reports related to these streams must be removed 💀 also, receiver reports related to A and C's media stream would be missing 😩 so to stop A and C from thinking B and D aren't receiving them at all, the Mixer needs to insert its Receiver Reports for the streams from A and C into B and D's Sender Reports 🦋 in the opposite direction, the Receiver Reports from A and C about B's and D's streams also need to be aggregated into the Mixer's Receiver Reports sent to B and D ✨ since B and D only have the Mixer as their source for the stream, all RTCP from A and C must be suppressed by the Mixer 🔥
this topology is so problematic, and it's so easy to get the RTCP processing wrong, that it is NOT RECOMMENDED to implement it 🙅♀️💜
3.8. Combining Topologies 🧩
topologies can be combined and linked to each other using Mixers or Translators 🌸 but care must be taken with the SSRC/CSRC space 💅 a Mixer will not forward RTCP from sources in other domains 🫶 instead it generates its own RTCP packets for each domain it mixes into, including the necessary Source Description (SDES) information for both the CSRCs and the SSRCs 🎀 so in a mixed domain, the only SSRCs you'll see are the ones that are actually in that domain, while there can be CSRCs from all the domains connected together with a combo of Mixers and Translators 👑 the combined SSRC and CSRC space is common over any Translator or Mixer 🦋 this matters for loop detection 🔁 which is likely to be even more important in combined topologies because of the mixed behavior between domains 😩 any hybrid, like the Topo-Video-switch-MCU or Topo-Asymmetric, requires serious thought on how RTCP gets handled 💀✨
4. Comparing Topologies 📊
the topologies discussed in Section 3 have different properties 💖 this section first lists those properties and then maps each topology to them 🌈 please note that even if a certain property is supported within a particular topology concept, the necessary functionality may, in many cases, be optional to implement 🧚
4.1. Topology Properties 🎀
4.1.1. All to All Media Transmission 🌍
Multicast, at least Any Source Multicast (ASM), gives everyone the ability to send to, or receive from, everyone else in the session 🫶 MCUs, Mixers, and Translators can all provide that functionality too, at least on some basic level 🦋 but there are differences in what type of reachability each one gives 👀
the transport Translator function called "relay", in Section 3.3, is the one that emulates ASM closest to true IP-multicast-based, all to all transmission 👑 Media Translators, Mixers, and the MCU variants don't do fully meshed forwarding at the transport level 😭 instead, they only allow limited forwarding of content from the other session participants 🥺
the "all to all media transmission" requires that any media transmitting entity considers the path to the least capable receiver 🚨 otherwise, the media transmissions may overload that path 💀 so a media sender needs to monitor the path from itself to every participant, detect the currently least capable receiver, and adapt its sending rate accordingly 🫶 since multiple participants may send at the same time, the available resources may vary 🌊 RTCP's Receiver Reports help with this monitoring, at least on a medium time scale 📈✨
the transmission of RTCP automatically adapts to changes in the number of participants, thanks to the transmission algorithm defined in the RTP specification [RFC3550] and the extensions in AVPF [RFC4585] (when applicable) 🤖 that way, the resources used for RTCP stay within the bounds configured for the session 💅💖
4.1.2. Transport or Media Interoperability 🦋
okay so Translators, Mixers, and RTCP-terminating MCUs can all change the media encoding or the transport to other properties of the other domain 🫶 which means you still get interoperability when people don't share the same codecs and/or transport protocols. no cap, this is the feature that saves the day.
4.1.3. Per Domain Bit-Rate Adaptation 💖
bestie, participants are most likely to be connected over a totally mixed bag of paths 🌈 and that makes congestion control in a Point to Multipoint set kinda messy. for the ASM and "relay" scenario, every individual sender has to adapt to the receiver with the least capable path 😭. but once Media Translators, Mixers, or MCUs are involved, each participant only has to adapt to the slowest path within its own domain ✨. the Translator, Mixer, or MCU topologies all make their outgoing streams adjust the bit-rate, packet-rate, etc., to match the least capable path in each of the other domains 💅. that way nobody has to drag the quality down to the least-capable participant in all the domains, and the cost (complexity, delay, equipment) is the Mixer's or Translator's problem to carry 🧚 iconic.
4.1.4. Aggregation of Media 🎀
so in the all to all media property mentioned above, which ASM provides, every simultaneous media transmission shares the available bit-rate 🫠. for participants with limited reception capabilities, this can mean that even a minimal acceptable media quality just cannot happen 💀. it's the result of multiple media streams all needing to share the same resources. the fix is to have a Mixer or MCU aggregate the multiple streams into a single one 🌸. this aggregation can be done in different ways, and mixing or selection are the two common ones 👑.
4.1.5. View of All Session Participants 🫶
RTP has built-in functionality to identify the session participants using the SSRC and CSRC fields 🧚. it can also carry some extra identity info about these participants using the RTCP Source Descriptors (SDES) ✨. so to keep all of that working, RTCP has to be handled correctly in the domain bridging function 💜. this is specified for Translators and Mixers. the MCU described in Section 3.5 doesn't entirely fulfill this 🙈, and the one described in Section 3.6 doesn't support it at all 💀.
4.1.6. Loop Detection 🔁
in complex topologies with multiple interconnected domains, it's possible to form media loops 🌀. RTP and RTCP do support detecting these loops, as long as the SSRC and CSRC identities are set correctly in forwarded packets 🎀. loop detection will likely work for the MCU described in Section 3.5, at least as long as it forwards the RTCP between the participants 🦋. however, the MCU in Section 3.6 will definitely break the loop detection mechanism 😭.
4.2. Comparison of Topologies 📊
this table is the big summary of all the topologies in one glance 👀. the legend for the topology abbreviations goes like this: Topo-Point-to-Point (PtP), Topo-Multicast (Multic), Topo-Trns-Translator (TTrn), Topo-Media-Translator (including Transport Translator) (MTrn), Topo-Mixer (Mixer), Topo-Asymmetric (ASY), Topo-Video-switch-MCU (MCUs), and Topo-RTCP-terminating-MCU (MCUt) 🌸. in the table, Y means Yes or full support, N means No support, (Y) means partial support, and N/A means not applicable 💅.
Property PtP Multic TTrn MTrn Mixer ASY MCUs MCUt
------------------------------------------------------------------
All to All media N Y Y Y (Y) (Y) (Y) (Y)
Interoperability N/A N Y Y Y Y N Y
Per Domain Adaptation N/A N N Y Y Y N Y
Aggregation of media N N N N Y (Y) Y Y
Full Session View Y Y Y Y Y Y (Y) N
Loop Detection Y Y Y Y Y Y (Y) Nplease note that the Media Translator also includes the transport Translator functionality 🧚.
5. Security Considerations 🔐
okay this section is serious business, so listen up 👑. the use of Mixers and Translators has a real impact on security and on the security functions used 😳. the main issue is that both Mixers and Translators modify packets, which prevents the use of integrity and source authentication, unless they are trusted devices that take part in the security context 🚨. for example, the device can send Secure Realtime Transport Protocol (SRTP) and Secure Realtime Transport Control Protocol (SRTCP) [RFC3711] packets to session endpoints 🔒. if encryption is used, the media Translator and Mixer need to be able to decrypt the media to do their job 🙈. a transport Translator can work without access to the encrypted payload in cases where it translates parts that aren't included in the encryption and integrity protection, for example IP address and UDP port numbers in a media stream using SRTP [RFC3711] 🦋. but in general, the Translator or Mixer needs to be part of the signalling context and get the necessary security associations (e.g., SRTP crypto contexts) established with its RTP session participants 🫶.
including the Mixer and Translator in the security context lets that entity, if it's subverted or misbehaving, perform a bunch of very serious attacks, because it has full access 😱. it can do all the attacks possible (see RFC 3550 and any applicable profiles) as if the media session weren't protected at all, while giving the session participants the impression that they are protected 💀. this is the scary part, bestie, so keep your guard up ⚠️.
Transport Translators have no interactions with cryptography that works above the transport layer, such as SRTP, since that kind of Translator leaves the RTP header and payload unaltered 🧚. Media Translators, on the other hand, have strong interactions with cryptography, since they alter the RTP payload 🔥. a Media Translator in a session that uses cryptographic protection needs to do cryptographic processing on both inbound and outbound packets 🎀.
a Media Translator may need different cryptographic keys for the inbound and outbound processing 🗝️. for SRTP, different keys are required, because an RFC 3550 Media Translator leaves the SSRC unchanged during its packet processing, and SRTP key sharing is only allowed when distinct SSRCs can be used to protect distinct packet streams 💜.
when the Media Translator uses different keys to process inbound and outbound packets, each session participant needs to be given the right key, depending on whether they're listening to the Translator or to the original source 🌈. (note that there's an architectural difference between RTP media translation, where participants can rely on the RTP Payload Type field of a packet to figure out the right processing, and cryptographically protected media translation, where participants must use information that isn't carried in the packet 🤓.)
when you use security mechanisms with Translators and Mixers, the Translator or Mixer could create different security associations for the different domains it works in 🌸. doing so has some implications, so pay attention:
First, it might weaken security if the Mixer/Translator accepts a weaker algorithm or key in one domain than in another 😬. so care should be taken that appropriately strong security parameters are negotiated in all domains 💪. in many cases, "appropriate" translates to "similar" strength 💅. if a key management system does allow the negotiation of security parameters that result in a different strength of security, then this system SHOULD notify the participants in the other domains about this 🔔.
Second, the number of crypto contexts (keys and security related state) needed (for example, in SRTP [RFC3711]) may vary between Mixers and Translators 📚. a Mixer normally needs to represent only a single SSRC per domain, so it only needs to create one security association (SRTP crypto context) per domain ✨. a Translator, in contrast, needs one security association per participant it translates towards, in the opposite domain 😵. looking at Figure 3, the Translator needs two security associations towards the multicast domain, one for B and one for D 🧩. it may be forced to keep a set of totally independent security associations between itself and B and D respectively, so as to avoid two-time pad occurrences 🙅♀️. these contexts must also be able to handle all the sources present in the other domains 🌀. so using completely independent security associations (for certain keying mechanisms) may force a Translator to handle N*DM keys and related state, where N is the total number of SSRCs used over all domains and DM is the total number of domains 🫠.
there are a number of different mechanisms for providing keys to the different participants 🗝️. one example is the choice between group keys and unique keys per SSRC 🔑. the right keying model is impacted by the topologies you plan to use 🧠. the final security properties depend on both the topologies in use and the keying mechanisms' properties, and they need to be considered by the application 💖. exactly which mechanisms get used is outside the scope of this document 🙏.
6. Acknowledgements 🫶
the authors would like to thank Bo Burman, Umesh Chandra, Roni Even, Keith Lantz, Ladan Gharai, Geoff Hunt, and Mark Baugher for their help in reviewing this document 💕.
7. References 📚
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
7.2. Informative References
[CCM] Wenger, S., Chandra, U., Westerlund, M., Burman, B., "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", Work in Progress, July 2007.
[H323] ITU-T Recommendation H.323, "Packet-based multimedia communications systems", June 2006.
[RTCP-SSM] J. Ott, J. Chesterfield, E. Schooler, "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback," Work in Progress, March 2007.
Authors' Addresses ✍️
Magnus Westerlund
Ericsson Research
Ericsson AB
SE-164 80 Stockholm, SWEDEN
Phone: +46 8 7190000
EMail: magnus.westerlund@ericsson.com
Stephan Wenger
Nokia Corporation
P.O. Box 100
FIN-33721 Tampere
FINLAND
Phone: +358-50-486-0637
EMail: stewe@stewe.orgFull Copyright Statement 💖
Okay bestie, the legal bit 🎀 Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78. Except for what BCP 78 says, the authors keep all their rights 📜✨
The document and the info in it are provided "AS IS", and the contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust, and the Internet Engineering Task Force disclaim all warranties, ngl the most dramatic breakup energy 💀:
THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🦋
Okay so the IETF doesn't take a side on whether any patents or other rights covering this tech are valid or how wide they are, and it's not saying any licenses would be available either. It also hasn't gone out and hunted for rights holders, so it's not claiming it checked 🙈 If you want the rules on rights in RFC documents, check out BCP 78 and BCP 79. Periodt 💅
Copies of IPR disclosures sent to the IETF Secretariat, and any assurances of licenses that might be offered, are on the IETF's online IPR repository at http://www.ietf.org/ipr. This also covers the results of anyone trying to get a general license or permission to use proprietary rights, for implementers or users of this spec 🌸
The IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 🫶✨
📦 where this page comes from
- ietf: rfc5117 2008-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms