RFC 7656
A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources
A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources 🦋
okay bestie, here's the deal 💅 this one is RFC 7656, and the title block has the important stuff:
- RFC number: 7656
- Authors: J. Lennox (Vidyo), K. Gross (AVA), S. Nandakumar (Cisco Systems), G. Salgueiro (Cisco Systems), and B. Burman, Ed. (Ericsson). The "Ed." means B. Burman was the editor 🎀
- Category: Informational
- ISSN: 2070-1721
- Date: November 2015
- Obsoletes / Updates: the header doesn't list any RFCs that this one obsoletes or updates ✨
Abstract ✨
the terms and connections among RTP sources (Real-time Transport Protocol (RTP)) can get seriously complicated and kinda opaque, ngl 💀 this doc describes a bunch of existing and proposed properties and relationships among RTP sources, and it defines shared terminology so everyone is talking about the same things 🫶
Status of This Memo 📝
this is not an Internet Standards Track spec. It's published for informational purposes 🌸
this document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🔥 not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 💖
for the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7656 🧚
Copyright Notice 🌈
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. ✨
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date it was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜 any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💅
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Media Chain . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Physical Stimulus . . . . . . . . . . . . . . . . . . 10
2.1.2. Media Capture . . . . . . . . . . . . . . . . . . . . 10
2.1.3. Raw Stream . . . . . . . . . . . . . . . . . . . . . 10
2.1.4. Media Source . . . . . . . . . . . . . . . . . . . . 11
2.1.5. Source Stream . . . . . . . . . . . . . . . . . . . . 11
2.1.6. Media Encoder . . . . . . . . . . . . . . . . . . . . 12
2.1.7. Encoded Stream . . . . . . . . . . . . . . . . . . . 13
2.1.8. Dependent Stream . . . . . . . . . . . . . . . . . . 13
2.1.9. Media Packetizer . . . . . . . . . . . . . . . . . . 13
2.1.10. RTP Stream . . . . . . . . . . . . . . . . . . . . . 14
2.1.11. RTP-Based Redundancy . . . . . . . . . . . . . . . . 14
2.1.12. Redundancy RTP Stream . . . . . . . . . . . . . . . . 15
2.1.13. RTP-Based Security . . . . . . . . . . . . . . . . . 15
2.1.14. Secured RTP Stream . . . . . . . . . . . . . . . . . 16
2.1.15. Media Transport . . . . . . . . . . . . . . . . . . . 16
2.1.16. Media Transport Sender . . . . . . . . . . . . . . . 17
2.1.17. Sent RTP Stream . . . . . . . . . . . . . . . . . . . 18
2.1.18. Network Transport . . . . . . . . . . . . . . . . . . 18
2.1.19. Transported RTP Stream . . . . . . . . . . . . . . . 18
2.1.20. Media Transport Receiver . . . . . . . . . . . . . . 18
2.1.21. Received Secured RTP Stream . . . . . . . . . . . . . 19
2.1.22. RTP-Based Validation . . . . . . . . . . . . . . . . 19
2.1.23. Received RTP Stream . . . . . . . . . . . . . . . . . 19
2.1.24. Received Redundancy RTP Stream . . . . . . . . . . . 19
2.1.25. RTP-Based Repair . . . . . . . . . . . . . . . . . . 19
2.1.26. Repaired RTP Stream . . . . . . . . . . . . . . . . . 19
2.1.27. Media Depacketizer . . . . . . . . . . . . . . . . . 20
2.1.28. Received Encoded Stream . . . . . . . . . . . . . . . 20
2.1.29. Media Decoder . . . . . . . . . . . . . . . . . . . . 20
2.1.30. Received Source Stream . . . . . . . . . . . . . . . 20
2.1.31. Media Sink . . . . . . . . . . . . . . . . . . . . . 21
2.1.32. Received Raw Stream . . . . . . . . . . . . . . . . . 21
2.1.33. Media Render . . . . . . . . . . . . . . . . . . . . 21
2.2. Communication Entities . . . . . . . . . . . . . . . . . 22
2.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 23
2.2.2. RTP Session . . . . . . . . . . . . . . . . . . . . . 23
2.2.3. Participant . . . . . . . . . . . . . . . . . . . . . 24
2.2.4. Multimedia Session . . . . . . . . . . . . . . . . . 24
2.2.5. Communication Session . . . . . . . . . . . . . . . . 25
3. Concepts of Inter-Relations . . . . . . . . . . . . . . . . . 25
3.1. Synchronization Context . . . . . . . . . . . . . . . . . 26
3.1.1. RTCP CNAME . . . . . . . . . . . . . . . . . . . . . 26
3.1.2. Clock Source Signaling . . . . . . . . . . . . . . . 26
3.1.3. Implicitly via RtcMediaStream . . . . . . . . . . . . 26
3.1.4. Explicitly via SDP Mechanisms . . . . . . . . . . . . 26
3.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3. Participant . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 27
3.5. Multi-Channel Audio . . . . . . . . . . . . . . . . . . . 28
3.6. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7. Layered Multi-Stream . . . . . . . . . . . . . . . . . . 30
3.8. RTP Stream Duplication . . . . . . . . . . . . . . . . . 32
3.9. Redundancy Format . . . . . . . . . . . . . . . . . . . . 33
3.10. RTP Retransmission . . . . . . . . . . . . . . . . . . . 33
3.11. Forward Error Correction . . . . . . . . . . . . . . . . 35
3.12. RTP Stream Separation . . . . . . . . . . . . . . . . . . 36
3.13. Multiple RTP Sessions over one Media Transport . . . . . 37
4. Mapping from Existing Terms . . . . . . . . . . . . . . . . . 37
4.1. Telepresence Terms . . . . . . . . . . . . . . . . . . . 37
4.1.1. Audio Capture . . . . . . . . . . . . . . . . . . . . 37
4.1.2. Capture Device . . . . . . . . . . . . . . . . . . . 37
4.1.3. Capture Encoding . . . . . . . . . . . . . . . . . . 38
4.1.4. Capture Scene . . . . . . . . . . . . . . . . . . . . 38
4.1.5. Endpoint . . . . . . . . . . . . . . . . . . . . . . 38
4.1.6. Individual Encoding . . . . . . . . . . . . . . . . . 38
4.1.7. Media Capture . . . . . . . . . . . . . . . . . . . . 38
4.1.8. Media Consumer . . . . . . . . . . . . . . . . . . . 38
4.1.9. Media Provider . . . . . . . . . . . . . . . . . . . 39
4.1.10. Stream . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.11. Video Capture . . . . . . . . . . . . . . . . . . . . 39
4.2. Media Description . . . . . . . . . . . . . . . . . . . . 39
4.3. Media Stream . . . . . . . . . . . . . . . . . . . . . . 39
4.4. Multimedia Conference . . . . . . . . . . . . . . . . . . 39
4.5. Multimedia Session . . . . . . . . . . . . . . . . . . . 40
4.6. Multipoint Control Unit (MCU) . . . . . . . . . . . . . . 40
4.7. Multi-Session Transmission (MST) . . . . . . . . . . . . 40
4.8. Recording Device . . . . . . . . . . . . . . . . . . . . 41
4.9. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 41
4.10. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . . 41
4.11. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . 41
4.12. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . 41
4.13. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 41
4.14. Single-Session Transmission (SST) . . . . . . . . . . . . 41
4.15. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6. Informative References . . . . . . . . . . . . . . . . . . . 42
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 461. Introduction 🌷
okay so the existing taxonomy of sources in the Real-time Transport Protocol (RTP) [RFC3550] has been seen as confusing and inconsistent, and that makes it a real challenge to figure out how the different terms relate to each other 😭 two classic examples: (1) different protocols that use RTP use the same terms to mean different things, and (2) complexities that get handled at one layer are often glossed over or ignored at another 🙈
this document makes things clearer by looking closely at what various aspects of sources in RTP actually mean 💖 as an organizing trick, it walks through the different ways RTP sources get transformed on their way from sender to receiver, and how they can be grouped and associated together 🧩
all non-specific references to ControLling mUltiple streams for tElepresence (CLUE) in this document map to [CLUE-FRAME], and every reference to Web Real-time Communications (WebRTC) maps to [WEBRTC-OVERVIEW] 🎀
2. Concepts 🧚
this section defines the concepts used to identify and name the various transformations and streams in a given RTP usage ✨ for each concept, it lists the alternate definitions and usages that coexist today, along with the characteristics that describe the concept further 💅 the concepts split into two categories: one is about the chain of streams and transformations that Media can be subject to, and the other is about the entities involved in the communication 🦋
2.1. Media Chain ✨
okay so bestie, media in this doc means a sequence of synthetic or Physical Stimuli (Section 2.1.1) (sound waves, photons, key strokes 🎹) that's been turned into digital form 💻. Synthesized media is usually made straight in the digital world, so no real-world sensor needed 🧚
This section lays out everything that can happen while media goes from the sender side to a receiver, who might turn it back into physical stimuli at the end 🦋 The chain has two main flavors: streams and transformations. Streams are time-based sequences of samples of the physical stimulus, in different representations. Transformations change how those streams are represented 💅
The examples here are the basic ones, and this model is giving room for way more complex setups 🌈 Some get more attention in later sections. Generally, the following applies:
- A transformation may have zero or more inputs and one or more outputs.
- A stream is of some type, such as audio, video, real-time text, etc.
- A stream has one source transformation and one or more sink transformations (with the exception of physical stimulus (Section 2.1.1) that may lack source or sink transformation).
- Streams can be forwarded from a transformation output to any number of inputs on other transformations that support that type.
- If the output of a transformation is sent to multiple transformations, those streams will be identical; it takes a transformation to make them different.
- There are no formal limitations on how streams are connected to transformations.
Also, this is a conceptual model, so real-world implementations may look different and have a different structure 🙈
To get the vibe of the chain, let's start with the sender side (Figure 1) 🎀 It covers everything from physical stimuli until media packets are emitted onto the network 🚀
Physical Stimulus
|
V
+----------------------+
| Media Capture |
+----------------------+
|
Raw Stream
V
+----------------------+
| Media Source |<- Synchronization Timing
+----------------------+
|
Source Stream
V
+----------------------+
| Media Encoder |
+----------------------+
|
Encoded Stream +------------+
V | V
+----------------------+ | +----------------------+
| Media Packetizer | | | RTP-Based Redundancy |
+----------------------+ | +----------------------+
| | |
+-------------+ Redundancy RTP Stream
Source RTP Stream |
V V
+----------------------+ +----------------------+
| RTP-Based Security | | RTP-Based Security |
+----------------------+ +----------------------+
| |
Secured RTP Stream Secured Redundancy RTP Stream
V V
+----------------------+ +----------------------+
| Media Transport | | Media Transport |
+----------------------+ +----------------------+
Figure 1: Sender Side Concepts in the Media ChainIn Figure 1, we added a branched chain to show the concepts for using redundancy to make transport more reliable 🛡️ The Media Transport concept is an aggregate, and Section 2.1.15 breaks it down 💜
Figure 2 flips things around. It's the receiver media chain matching the sender side, looking at the inverse transformations and how they try to recover streams identical to the sender chain 🔄 That's subject to what may be lossy compression and imperfect media transport 🫠 Heads up: the streams coming out of a reverse transformation, like the Source Stream out of the Media Decoder, are usually not the same as the matching ones on the sender side, so they get a "received" prefix to show they might be modified 🏷️ The reason is that some transformations are irreversible 😭 For example, lossy source coding in the Media Encoder means the source stream out of the media decoder can't match the one that went into the encoder. Other reasons include packet loss in the media transport transformation that even RTP-based Repair, if used, fails to repair 💀
+----------------------+ +----------------------+
| Media Transport | | Media Transport |
+----------------------+ +----------------------+
Received | Received | Secured
Secured RTP Stream Redundancy RTP Stream
V V
+----------------------+ +----------------------+
| RTP-Based Validation | | RTP-Based Validation |
+----------------------+ +----------------------+
| |
Received RTP Stream Received Redundancy RTP Stream
| |
| +--------------------+
V V
+----------------------+
| RTP-Based Repair |
+----------------------+
|
Repaired RTP Stream
V
+----------------------+
| Media Depacketizer |
+----------------------+
|
Received Encoded Stream
V
+----------------------+
| Media Decoder |
+----------------------+
|
Received Source Stream
V
+----------------------+
| Media Sink |--> Synchronization Information
+----------------------+
|
Received Raw Stream
V
+----------------------+
| Media Render |
+----------------------+
|
V
Physical Stimulus
Figure 2: Receiver Side Concepts of the Media Chain2.1.1. Physical Stimulus
The physical stimulus is a physical event in the analog domain that can be sampled and converted to digital form by an appropriate sensor or transducer ⚡ That includes sound waves making up audio, photons in a light field, or other excitations or interactions with sensors, like keystrokes on a keyboard ⌨️
2.1.2. Media Capture
Media Capture is the process of transforming the analog physical stimulus (Section 2.1.1) into digital media using an appropriate sensor or transducer 📸 It usually does a digital sampling of the physical stimulus, often periodically, and outputs that as a Raw Stream (Section 2.1.3) 🎙️ This data counts as "media" because it's periodically sampled or made up of a set of timed asynchronous events ⏱️ Media capture is normally set up in some kind of device, a media capture device 🎥 Examples include digital cameras, microphones connected to A/D converters, or keyboards 🍓
Characteristics:
- A media capture is identified either by hardware/manufacturer ID or via a session-scoped device identifier as mandated by the application usage.
- A media capture can generate an Encoded Stream (Section 2.1.7) if the capture device supports such a configuration.
- The nature of the media capture may impose constraints on the clock handling in some of the subsequent steps. For example, many audio or video capture devices are not completely free in selecting the sample rate.
2.1.3. Raw Stream
A raw stream is the time-progressing stream of digitally sampled information, usually periodically sampled and provided by a media capture (Section 2.1.2) 🌸 A raw stream can also hold synthesized media that doesn't need any explicit media capture, since it's already in a suitable digital form 🧁
2.1.4. Media Source
A Media Source is the logical source of a time-progressing digital media stream synchronized to a reference clock ⏰ That stream is called a source stream (Section 2.1.5) 💖 This transformation takes one or more raw streams (Section 2.1.3) and gives a source stream as output 🎁 The output is synchronized with a reference clock (Section 3.1), which can be as simple as a system local wall clock or as complex as an NTP synchronized clock 🕰️
The output can come in different types. One type is directly tied to a particular media capture's raw stream 📹 Others are more conceptual sources, like an audio mix of multiple source streams (Figure 3) 🎶 Mixing multiple streams usually requires that the input streams can be related in time, which means they have to be source streams (Section 2.1.5) rather than raw streams ⏳ In Figure 3, the generated source stream is a mix of the three input source streams 🧃
Source Source Source
Stream Stream Stream
| | |
V V V
+--------------------------+
| Media Source |<-- Reference Clock
| Mixer |
+--------------------------+
|
V
Source Stream
Figure 3: Conceptual Media Source in the form of an Audio MixerAnother conceptual media source is a video surveillance switch 📷 Its input is multiple source streams from different cameras, and its output is one of those source streams picked based on some selection criteria, like round robin or some video activity measure 👀
2.1.5. Source Stream
A source stream is a stream of digital samples that has been synchronized with a reference clock and comes from a particular media source (Section 2.1.4) 🫶
2.1.6. Media Encoder ✨
okay bestie, a media encoder is a transform that takes the media data from a source stream (Section 2.1.5) and encodes it into another representation, usually way more compact 🫶 that comes out as an encoded stream (Section 2.1.7) 💖
the media encoder step commonly includes pre-encoding transformations, like scaling, resampling, etc. 🎀 and omg, the encoder can have a whole buffet of configuration options that change the properties of the encoded stream 💅 like codec, bitrate, start points for decoding, resolution, bandwidth, or other fidelity affecting properties 🦋
scalable media encoders need special attention 👑 because they produce multiple outputs that can be totally different types 🌈 as shown in Figure 4, a scalable media encoder takes one input source stream and encodes it into multiple output streams of two different types: at least one encoded stream that is independently decodable, plus one or more Dependent Streams (Section 2.1.8) 🧚 decoding needs at least one encoded stream and zero or more dependent streams 💜 and a dependent stream's dependency is one of the grouping relations this document discusses further in Section 3.7 ✨
Source Stream
|
V
+--------------------------+
| Scalable Media Encoder |
+--------------------------+
| | ... |
V V V
Encoded Dependent Dependent
Stream Stream Stream
Figure 4: Scalable Media Encoder Input and Outputsthere are also other variants of encoders, like Multiple Description Coding (MDC) 🌸 these produce multiple independent, individually decodable encoded streams 🫶 however, (logically) combining several of these encoded streams into a single Received Source Stream during decoding leads to an improvement in perceptual reproduced quality compared to decoding a single encoded stream 😭🔥
creating multiple encoded streams from the same source stream, where the encoded streams are neither in a scalable nor in an MDC relationship, is commonly used in simulcast [SDP-SIMULCAST] environments 🍓
2.1.7. Encoded Stream ✨
a stream of time synchronized encoded media that can be independently decoded 💖
due to temporal dependencies, an encoded stream may have limitations on where decoding can be started 🙈 these entry points (for example, Intra frames from a video encoder) may need to be identified, and their generation may be event based or configured to occur periodically 🦋
2.1.8. Dependent Stream ✨
a stream of time synchronized encoded media fragments that depend on one or more encoded streams (Section 2.1.7) and zero or more dependent streams in order to be possible to decode 🧚
each dependent stream has a set of dependencies 💅 these dependencies must be understood by the parties in a Multimedia Session (Section 2.2.4) that intend to use a dependent stream 👑
2.1.9. Media Packetizer ✨
the transformation that takes one or more encoded (Section 2.1.7) or dependent streams (Section 2.1.8), puts their content into one or more sequences of packets (normally RTP Packets), and outputs Source RTP Streams (Section 2.1.10) 🎀 this step includes both generating RTP Payloads and RTP packets 📦 the Media Packetizer then selects which synchronization source(s) (SSRC) [RFC3550] and RTP Sessions (Section 2.2.2) to use 💜
the media packetizer can combine multiple encoded or dependent streams into one or more RTP Streams:
- The media packetizer can use multiple inputs when producing a single RTP stream. One such example is Single RTP stream on a Single media Transport (SRST) packetization when using Scalable Video Coding (SVC) (Section 3.7) 🌈
- The media packetizer can also produce multiple RTP streams, for example, when encoded and/or dependent streams are distributed over multiple RTP streams. One example of this is Multiple RTP streams on Multiple media Transports (MRMT) packetization when using SVC (Section 3.7) 🫶
2.1.10. RTP Stream ✨
an RTP stream is a stream of RTP packets containing media data, source or redundant 💖 the RTP stream is identified by an SSRC belonging to a particular RTP Session 🦋 the RTP session is identified as discussed in Section 2.2.2 ✨
a source RTP stream is an RTP stream directly related to an encoded stream (Section 2.1.7), targeted for transport over RTP without any additional RTP-based Redundancy (Section 2.1.11) applied 🧚
characteristics:
- Each RTP stream is identified by an SSRC [RFC3550] that is carried in every RTP and RTP Control Protocol (RTCP) packet header. The SSRC is unique in a specific RTP session context 👑
- At any given point in time, an RTP stream can have one and only one SSRC, but SSRCs for a given RTP stream can change over time. SSRC collision and clock rate change [RFC7160] are examples of valid reasons to change SSRC for an RTP stream. In those cases, the RTP stream itself is not changed in any significant way, only the identifying SSRC number 🔥
- Each SSRC defines a unique RTP sequence numbering and timing space 💅
- Several RTP streams, each with their own SSRC, may represent a single media source 🌸
- Several RTP streams, each with their own SSRC, can be carried in a single RTP session 🍓
2.1.11. RTP-Based Redundancy ✨
RTP-based redundancy is defined here as a transformation that generates redundant or repair packets, sent out as a Redundancy RTP Stream (Section 2.1.12), to mitigate Network Transport (Section 2.1.18) impairments like packet loss and delay 🛡️ note that this excludes the type of redundancy that most suitable media encoders (Section 2.1.6) may add to the media format of the encoded stream (Section 2.1.7) to help it cope better with RTP packet losses 🙌
the RTP-based redundancy exists in many flavors 🌈 they may generate independent repair streams that are used in addition to the source stream (like RTP Retransmission (Section 3.10) and some special types of Forward Error Correction (FEC) (Section 3.11), like RTP stream duplication (Section 3.8)) 🦋 they may generate a new source stream by combining redundancy information with source information (using XOR FEC as a redundancy payload (Section 3.9)) 💜 or they may completely replace the source information with only redundancy packets 👑
2.1.12. Redundancy RTP Stream ✨
a redundancy RTP stream is an RTP stream (Section 2.1.10) that contains no original source data, only redundant data 🫶 it may either be used standalone or be combined with one or more Received RTP Streams (Section 2.1.23) to produce Repaired RTP Streams (Section 2.1.26) 🧚
2.1.13. RTP-Based Security ✨
the optional RTP-based Security transformation applies security services such as authentication, integrity protection, and confidentiality to an input RTP stream, like what is specified in "The Secure Real-time Transport Protocol (SRTP)" [RFC3711] 🔐 producing a Secured RTP Stream (Section 2.1.14) ✨ either an RTP stream (Section 2.1.10) or a redundancy RTP stream (Section 2.1.12) can be used as input to this transformation 💖
in SRTP and the related Secure RTCP (SRTCP), all of the above-mentioned security services are optional, except for integrity protection of SRTCP, which is mandatory 😭 also, confidentiality (encryption) is effectively optional in SRTP, since it is possible to use a NULL encryption algorithm 💀 as described in [RFC7201], the strength of SRTP data origin authentication depends on the cryptographic transform and key management used 🌸 for example, in group communication, it is sometimes possible to authenticate group membership but not the actual RTP stream sender 🙈
RTP-based security and RTP-based redundancy can be combined in a few different ways 🦋 one way is depicted in Figure 1, where an RTP stream and its corresponding redundancy RTP stream are protected by separate RTP-based security transforms 🎀 in other cases, like when a Media Translator is adding FEC in Section 3.2.1.3 of [RTP-TOPOLOGIES], a middlebox can apply RTP-based redundancy to an already secured RTP stream instead of a source RTP stream 🧚 one example of that is depicted in Figure 5 below 👑
Source RTP Stream +------------+
V | V
+----------------------+ | +----------------------+
| RTP-Based Security | | | RTP-Based Redundancy |
+----------------------+ | +----------------------+
| | |
| | Redundancy RTP Stream
+-------------+ |
| V
| +----------------------+
Secured RTP Stream | RTP-Based Security |
| +----------------------+
| |
| Secured Redundancy RTP Stream
V V
+----------------------+ +----------------------+
| Media Transport | | Media Transport |
+----------------------+ +----------------------+
Figure 5: Adding Redundancy to a Secured RTP Streamin this case, the redundancy RTP stream may already have been secured for confidentiality (encrypted) by the first RTP-based security, so it may therefore not be necessary to apply additional confidentiality protection in the second RTP-based security 🔒 to avoid attacks and negative impact on RTP-based Repair (Section 2.1.25) and the resulting repaired RTP stream (Section 2.1.26), it is, however, still necessary to have this second RTP-based security apply both authentication and integrity protection to the redundancy RTP stream 😭💅
2.1.14. Secured RTP Stream ✨
a secured RTP stream is a source or redundancy RTP stream that is protected through RTP-based security (Section 2.1.13) by one or more of the confidentiality, integrity, or authentication security services 🫶🌈
2.1.15. Media Transport ✨
Okay bestie, a media transport is the whole journey the RTP streams (Section 2.1.10) take from one RTP Sender (Section 4.12) to one specific RTP Receiver (Section 4.11) 🦋. An RTP session (Section 2.2.2) can have multiple RTP receivers per sender, so the main character has a whole fanbase 💖. Each media transport is defined by a transport association that's normally identified by a 5-tuple (source address, source port, destination address, destination port, transport protocol) 🌸. There's also a proposal for sending multiple transport associations on a single 5-tuple [TRANSPORT-MULTIPLEX] 👀.
Characteristics:
- Media transport transmits RTP streams of RTP packets from a source transport address to a destination transport address.
- Each media transport contains only a single RTP session.
- A single RTP session can span multiple media transports.
Sometimes the media transport concept needs to be broken into smaller steps so we can talk about what a sender emits, gets transformed by the network, and then arrives at the receiver 🧚. So here's the decomposition (Figure 6) 💅:
RTP Stream
|
V
+--------------------------+
| Media Transport Sender |
+--------------------------+
|
Sent RTP Stream
V
+--------------------------+
| Network Transport |
+--------------------------+
|
Transported RTP Stream
V
+--------------------------+
| Media Transport Receiver |
+--------------------------+
|
V
Received RTP Stream
Figure 6: Decomposition of Media Transport2.1.16. Media Transport Sender
The first step inside the media transport (Section 2.1.15) is the Media Transport Sender 🚀. The sending Endpoint (Section 2.2.1) takes an RTP stream and emits the packets onto the network using the transport association set up for this media transport, which creates a Sent RTP Stream (Section 2.1.17) ✨. Along the way, it transforms the RTP stream in a few ways. First, it generates the protocol headers the transport association needs, like IP and UDP headers, so you end up with IP/UDP/RTP packets 🎀. It can also queue, intentionally pace, or otherwise affect how the packets go out onto the network. That can introduce delay and delay variations [RFC5481] that end up characterizing the sent RTP stream 🌊.
2.1.17. Sent RTP Stream
The sent RTP stream is the RTP stream as it enters the first hop of the network path to its destination 🛫. It's identified using network transport addresses, like the 5-tuple (source IP address, source port, destination IP address, destination port, and protocol (UDP)) for IP/UDP 🦋.
2.1.18. Network Transport
Network transport is the transformation that takes the sent RTP stream (Section 2.1.17) and moves it from the source to the destination through the network 🌐. This can be messy, ngl 💀. It can result in loss of some packets, delay, and delay variation on a per-packet basis, packet duplication, and packet header or data corruption 😭. The output of this transformation is a Transported RTP Stream (Section 2.1.19) at the exit of the network path 🍓.
2.1.19. Transported RTP Stream
The transported RTP stream is the RTP stream that comes out of the network path at the destination, after being put through the network transport's transformation (Section 2.1.18) 🧚♀️.
2.1.20. Media Transport Receiver
The Media Transport Receiver is the receiver endpoint's (Section 2.2.1) transformation of the transported RTP stream (Section 2.1.19) through its reception process 📥. That process results in the received RTP stream (Section 2.1.23) ✨. This transformation includes verifying transport checksums 🔍. Sensible system designs usually either discard packets with mismatching checksums, or pass them along while marking them in the resulting received RTP stream so later transformations know the data might be corrupt 🚩. It's worth knowing that corrupt packets can typically slip through undetected with a checksum that still looks correct 🙈. Other transformations can smooth out delay variations between a packet arriving on the network interface and being handed to the application, which is what a de-jitter buffer is for 🫧.
2.1.21. Received Secured RTP Stream
This is the secured RTP stream (Section 2.1.14) that results from the aggregate transformation of the media transport (Section 2.1.15) 🔐.
2.1.22. RTP-Based Validation
RTP-based validation is the reverse transformation of RTP-based security (Section 2.1.13) 🔄. If this transformation fails, the result either must be discarded or may be usable but can't be trusted. Yikes 😬. If it succeeds, the result can be a received RTP stream (Section 2.1.23) or a Received Redundancy RTP Stream (Section 2.1.24), depending on what was input to the corresponding RTP-based security transformation. It can also be a Received Secured RTP Stream (Section 2.1.21) if several RTP-based security transformations were applied 👑.
2.1.23. Received RTP Stream
The received RTP stream is the RTP stream (Section 2.1.10) that results from the media transport's aggregate transformation (Section 2.1.15). In other words, it's the stream after it has been through packet loss, packet corruption, packet duplication, delay, and delay variation from sender to receiver 🌧️.
2.1.24. Received Redundancy RTP Stream
The received redundancy RTP stream is the redundancy RTP stream (Section 2.1.12) that results from the media transport's aggregate transformation. So it's gone through packet loss, packet corruption, packet duplication, delay, and delay variation from sender to receiver too 🫠.
2.1.25. RTP-Based Repair
RTP-based repair is a transformation that takes zero or more received RTP streams (Section 2.1.23) and one or more received redundancy RTP streams (Section 2.1.24) as input 🛠️. It produces one or more repaired RTP streams (Section 2.1.26) that are as close as possible to the corresponding sent source RTP streams (Section 2.1.10). It does this using different RTP-based repair methods, like the ones mentioned in RTP-based redundancy (Section 2.1.11) 💜.
2.1.26. Repaired RTP Stream
A repaired RTP stream is a received RTP stream (Section 2.1.23) for which received redundancy RTP stream information (Section 2.1.24) has been used to try to recover the source RTP stream (Section 2.1.10) as it was before media transport (Section 2.1.15) 🩹✨.
2.1.27. Media Depacketizer
A Media Depacketizer takes one or more RTP streams (Section 2.1.10), depacketizes them, and tries to reconstitute the encoded streams (Section 2.1.7) or dependent streams (Section 2.1.8) that are present in those RTP streams 📦.
In practical implementations, the media depacketizer and the media decoder can be tightly coupled and share information to improve or optimize the overall decoding and error concealment process 🤝. But there's no expectation that defining a taxonomy for those detailed (and probably very implementation-dependent) steps would be worth it 🙃.
2.1.28. Received Encoded Stream
The Received Encoded Stream is the received version of an encoded stream (Section 2.1.7) 📬.
2.1.29. Media Decoder
A media decoder is a transformation that's responsible for decoding encoded streams (Section 2.1.7) and any dependent streams (Section 2.1.8) into a source stream (Section 2.1.5) 🎬.
In practical implementations, the media decoder and the media depacketizer can be tightly coupled and share information to improve or optimize the overall decoding process in various ways 💫. Again, there's no expectation that defining a taxonomy for those detailed (and probably very implementation-dependent) steps would be worth it 🙃.
A media decoder has to deal with any errors in the encoded streams that came from corruption or from failing to repair packet losses 😤. So it's commonly robust to errors and losses, and includes concealment methods 🛡️. That's giving resilient queen 👑.
2.1.30. Received Source Stream
The received source stream is the received version of a source stream (Section 2.1.5) 💌.
2.1.31. Media Sink
The Media Sink receives a source stream (Section 2.1.5) that contains sampled media data, usually periodically, along with associated synchronization information 🎶. Depending on the application, this source stream then needs to be transformed into a raw stream (Section 2.1.3). That raw stream gets conveyed to the Media Render (Section 2.1.33) and synchronized with the output from other media sinks 🔊. A media sink can also be connected with a media source (Section 2.1.4) and be used as part of a conceptual media source 🪞.
The media sink can further transform the source stream into a representation that's suitable for rendering on the media render, as defined by the application or system-wide configuration 🎨. This includes sample scaling, level adjustments, and so on ✨.
2.1.32. Received Raw Stream
The Received Raw Stream is the received version of a raw stream (Section 2.1.3) 🌈.
2.1.33. Media Render
A media render takes a raw stream (Section 2.1.3) and converts it into physical stimulus (Section 2.1.1) that a human user can perceive 👀. Examples of such devices are screens and D/A converters connected to amplifiers and loudspeakers 🔈.
An endpoint can potentially have multiple media renders for each media type 🥰.
2.2. Communication Entities 🎀
okay so this section is all about the entities that show up in a call, aka the people and boxes doing the talking 💬 and yes it comes with a cute diagram 🥰
+------------------------------------------------------------+
| Communication Session |
| |
| +----------------+ +----------------+ |
| | Participant A | +------------+ | Participant B | |
| | | | Multimedia | | | |
| | +------------+ |<==>| Session |<==>| +------------+ | |
| | | Endpoint A | | | | | | Endpoint B | | |
| | | | | +------------+ | | | | |
| | | +----------+-+----------------------+-+----------+ | | |
| | | | RTP | | | | | | | |
| | | | Session |-+---Media Transport----+>| | | | |
| | | | Audio |<+---Media Transport----+-| | | | |
| | | | | | ^ | | | | | |
| | | +----------+-+----------|-----------+-+----------+ | | |
| | | | | v | | | | |
| | | | | +-----------------+ | | | | |
| | | | | | Synchronization | | | | | |
| | | | | | Context | | | | | |
| | | | | +-----------------+ | | | | |
| | | | | ^ | | | | |
| | | +----------+-+----------|-----------+-+----------+ | | |
| | | | RTP | | v | | | | | |
| | | | Session |<+---Media Transport----+-| | | | |
| | | | Video |-+---Media Transport----+>| | | | |
| | | | | | | | | | | |
| | | +----------+-+----------------------+-+----------+ | | |
| | +------------+ | | +------------+ | |
| +----------------+ +----------------+ |
+------------------------------------------------------------+
Figure 7: Example Point-to-Point Communication Session with Two RTP
SessionsFigure 7 is a high-level look at a super basic point-to-point Communication Session between Participants A and B 🦋 There are two RTP sessions between A's and B's endpoints, one audio and one video, and each RTP session is a group communications channel that can potentially carry a bunch of RTP streams ✨ Each one uses its own separate media transport too. The multimedia session they share can, for example, be set up using SIP (so yes, there's a SIP dialog between A and B) 📞
The terms in Figure 7 get the full breakdown in the subsections below 🧚
2.2.1. Endpoint 💖
An endpoint is a single addressable entity that sends or receives RTP packets 📦 It can be split into a bunch of functional blocks, but as long as it acts like one single RTP stack entity, it still counts as one "endpoint" 🫶
Characteristics:
- Endpoints can be identified in a few different ways 👀 RTCP Canonical Names (CNAMEs) [RFC3550] give you a globally unique and stable identifier for the whole communication session (see Section 2.2.5), but they only mean something inside a Synchronization Context (Section 3.1). So one endpoint can handle multiple CNAMEs, and each CNAME can be shared by a set of endpoints that belong to the same participant (Section 2.2.3). That's why mechanisms outside RTP, like application-defined ones, must be used to handle endpoint identification once you're outside that synchronization context 💅
- An endpoint can be associated with at most one participant (Section 2.2.3) at any single point in time 🙈
- In some contexts, an endpoint would typically match a single "host", like a computer with one network interface being used by one human 💻 In other contexts, one "host" can serve multiple participants, in which case each participant's endpoint may share properties, like the IP address part of a transport address 🌈
2.2.2. RTP Session 🌸
An RTP session is an association among a group of participants communicating with RTP 👯♀️ It's a group communications channel that can potentially carry a number of RTP streams. Inside an RTP session, everyone can find metadata and control info (over RTCP) about all the RTP streams in that session 👀 The bandwidth of the RTCP control channel gets shared between all participants in the RTP session 🍓
Characteristics:
- An RTP session can carry one or more RTP streams 💜
- An RTP session shares a single SSRC space as defined in [RFC3550] 🔥 So the endpoints in an RTP session can see an SSRC identifier sent by any of the other endpoints. An endpoint can receive an SSRC either as an SSRC or as a contributing source (CSRC) in RTP and RTCP packets, depending on the endpoints' network interconnection topology ✨
- An RTP session uses at least two media transports (Section 2.1.15): one for sending and one for receiving 📡 Usually the receiving media transport is the reverse direction of the one used for sending. An RTP session may use many media transports, and those define the session's network interconnection topology 🗺️
- A single media transport always carries a single RTP session 🦋
- Multiple RTP sessions can be conceptually related 🫶 For example, they might come from or be aimed at the same participant (Section 2.2.3) or endpoint (Section 2.2.1), or they might contain RTP streams that are somehow related (Section 3).
2.2.3. Participant 🧚
A participant is an entity reachable by a single signaling address, so it's more about the signaling side of things than the media side 📞
Characteristics:
- It's a single signaling-addressable entity, using an application-specific signaling address space, like a SIP URI 💌
- A participant can take part in several multimedia sessions (Section 2.2.4) 🎀
- A participant can be made up of several associated endpoints (Section 2.2.1) 💖
2.2.4. Multimedia Session 🌈
A multimedia session is an association among a group of participants (Section 2.2.3) who are communicating through one or more RTP sessions (Section 2.2.2) 🎬 It defines the logical relationships among media sources (Section 2.1.4) that show up in multiple RTP sessions 🔗
Characteristics:
- A multimedia session can be built from several RTP sessions, with potentially multiple RTP streams in each RTP session 🧩
- Each participant in a multimedia session can have a whole bunch of media captures and media rendering devices 📸
- A single multimedia session can contain media from one or more synchronization contexts (Section 3.1) 🌟 Here's an example: one multimedia session might have one set of audio and video for communication that belongs to one synchronization context, plus another set of audio and video for presentation purposes (like playing a video file) in a separate synchronization context. That second one has no strong timing relationship and doesn't need to be strictly synchronized with the communication audio and video 🎥
2.2.5. Communication Session 💜
A communication session is an association among two or more participants (Section 2.2.3) who talk to each other through one or more multimedia sessions (Section 2.2.4) 🥰
Characteristics:
- Each participant in a communication session is identified through an application-specific signaling address 🪪
- A communication session is made up of participants who share at least one multimedia session, with one or more parallel RTP sessions and potentially multiple RTP streams in each one 🔥
For example, in a full mesh communication, the communication session is a set of separate multimedia sessions, one between each pair of participants 🕸️ Another example is a centralized conference, where the communication session is a set of multimedia sessions between each participant and the conference handler 🎪
3. Concepts of Inter-Relations 🦋
This section takes the concepts from the earlier sections and looks at the different kinds of relationships between them 🧠 These relationships show up at different abstraction levels and for different reasons, but the reason you need a relationship at one step of the media handling chain might pop up at another step too. For example, using simulcast (Section 3.6) means you need to figure out relations at the RTP stream level, but the underlying reason is that multiple media encoders use the same media source. So the goal is to be able to identify a common media source 🎯
3.1. Synchronization Context ⏰
A synchronization context is a requirement for a strong timing relationship between media sources, which usually means their clock sources have to line up 🕰️ There are multiple ways to identify that relationship, listed below. A single media source can only belong to a single synchronization context, because it's assumed that one media source only has one media clock. If you required alignment to several synchronization contexts (and therefore several reference clocks), you'd effectively merge them into a single synchronization context 🫠
3.1.1. RTCP CNAME 🏷️
[RFC3550] describes inter-media synchronization between RTP sessions based on the RTCP CNAME, RTP, and timestamps of a reference clock formatted using the Network Time Protocol (NTP) [RFC5905] 🌅 As [RFC7273] points out, even though it uses NTP format timestamps, the clock doesn't have to be synchronized to an NTP source 🤷♀️
3.1.2. Clock Source Signaling 📣
[RFC7273] has a mechanism to signal the clock source in the Session Description Protocol (SDP) [RFC4566], covering both the reference clock and the media clock 🎙️ That means a synchronization context can be defined beyond what the CNAME source descriptions give you 🚀
3.1.3. Implicitly via RtcMediaStream 🌊
WebRTC defines RtcMediaStream, which has one or more RtcMediaStreamTracks 🎞️ All the tracks in an RtcMediaStream are meant to be synchronized when they're rendered, which implies that they must be generated in a way that makes synchronization possible 💫
3.1.4. Explicitly via SDP Mechanisms 📝
The SDP Grouping Framework [RFC5888] defines a grouping mechanism for "m=" lines (Section 4.2) called Lip Synchronization, with the LS identification-tag 👄 It sets up the synchronization requirement across "m=" lines when they map to individual sources 💕
Source-Specific Media Attributes in SDP [RFC5576] extends that mechanism for when multiple media sources are described by a single "m=" line 🧁
3.2. Endpoint ✨
Okay so some apps really need to know which media sources came from a specific endpoint (Section 2.2.1) 👀 Like, routing packets between parts of the topology gets way easier when you know the endpoint each RTP stream came from 🛣️
In RTP, this job got mashed together with the synchronization context (Section 3.1) through the RTCP source description CNAME (Section 3.1.1) 🥴 And honestly, it works fine for some setups, but then other setups totally fall apart. Say an endpoint has two groups of media sources with different synchronization contexts: the audio and video of the human participant, plus a separate set of audio and video for a shared movie 🎬 CNAME would NOT be the right way to identify that endpoint, bestie 💀 So an endpoint can have multiple CNAMEs 💅 The CNAMEs or the media sources themselves can be linked back to the endpoint 🔗
3.3. Participant 🙋♀️
In communication scenarios, you almost always want to know which participant (Section 2.2.3) each media source came from 🫶 It's needed so the app can show the right participant's identity next to their media. That link gets handled in signaling, which points at a specific multimedia session where the media sources can be explicitly or implicitly tied to one endpoint 🧚
Participant info gets messy when media sources are made by mixing or other processing of raw or source streams that came from different participants 🌀 Those sources can have a constantly changing set of origins and participants, which is a whole mood 😭 RTP has the CSRC concept for this, which carries info about the origin of the included media content from the previous step at the RTP level ✨
3.4. RtcMediaStream 🎀
An RtcMediaStream in WebRTC is an explicit group of media sources (RtcMediaStreamTracks) that share a common identifier and one synchronization context (Section 3.1) 💖 It's like a little family of tracks that all vibe together 🌸
3.5. Multi-Channel Audio 🎧
Okay this is so cool 😍 There are a bunch of RTP payload formats that can carry multi-channel audio, even though the codec itself is a single-channel (mono) encoder 🤯 You can think of multi-channel audio as multiple media sources sharing one synchronization context. Each one gets encoded on its own by a media encoder, and then the encoded streams get packetized together in a time-synchronized way into a single source RTP stream, using the codec's RTP payload format 🎶 Codecs that support multi-channel audio include PCMA and PCMU [RFC3551], Adaptive Multi Rate (AMR) [RFC4867], and G.719 [RFC5404] 🦋
3.6. Simulcast 🌈
A media source that shows up as multiple independent encoded streams is a simulcast [SDP-SIMULCAST] (or a Modification Detection Code (MDC)) of that media source 🪞 Check out Figure 8 for a media source encoded into three separate simulcast streams, all sent on the same media transport flow 🍓 When you use simulcast, the RTP streams can share one RTP session and media transport, sit on different RTP sessions and media transports, or be any mix of those two 🔀 A big reason to split them onto different media transports is to get different quality of service (QoS) for each source RTP stream 💅 We talk more about separating related RTP streams in Section 3.12 👀
+----------------+
| Media Source |
+----------------+
Source Stream |
+----------------------+----------------------+
| | |
V V V
+------------------+ +------------------+ +------------------+
| Media Encoder | | Media Encoder | | Media Encoder |
+------------------+ +------------------+ +------------------+
| Encoded | Encoded | Encoded
| Stream | Stream | Stream
V V V
+------------------+ +------------------+ +------------------+
| Media Packetizer | | Media Packetizer | | Media Packetizer |
+------------------+ +------------------+ +------------------+
| Source | Source | Source
| RTP | RTP | RTP
| Stream | Stream | Stream
+-----------------+ | +-----------------+
| | |
V V V
+-------------------+
| Media Transport |
+-------------------+
Figure 8: Example of Media Source SimulcastThe simulcast relation between RTP streams is the common media source 🫂 To spot that common source, a receiver might need to know what configuration or encoding goals were behind each encoded stream and its properties 🕵️♀️ That lets the app pick whichever stream is most useful at that exact moment 🎯
3.7. Layered Multi-Stream 🍰
Layered Multi-Stream (LMS) is a mechanism where different parts of a layered or scalable encoding of a source stream get sent using separate RTP streams (sometimes on separate RTP sessions) 🧅 LMSs are super useful for receiver control of layered media 🙌
A media source shown as an encoded stream plus multiple dependent streams is a media source with layered dependencies 🪜 Figure 9 is an example of a media source encoded into three dependent layers. Two of those layers go out on the same media transport using different RTP streams (so different SSRCs), and the third layer goes out on a separate media transport 🚀
+----------------+
| Media Source |
+----------------+
|
|
V
+---------------------------------------------------------+
| Media Encoder |
+---------------------------------------------------------+
| | |
Encoded Stream Dependent Stream Dependent Stream
| | |
V V V
+----------------+ +----------------+ +----------------+
|Media Packetizer| |Media Packetizer| |Media Packetizer|
+----------------+ +----------------+ +----------------+
| | |
RTP Stream RTP Stream RTP Stream
| | |
+------+ +------+ |
| | |
V V V
+-----------------+ +-----------------+
| Media Transport | | Media Transport |
+-----------------+ +-----------------+
Figure 9: Example of Media Source Layered DependencySometimes it's helpful to tell apart using one media transport versus multiple separate media transports, when both cases use multiple RTP streams for encoded and dependent streams of a media source 🧠 So here's some new terminology we're defining:
- SRST: Single RTP stream on a Single media Transport 1️⃣
- MRST: Multiple RTP streams on a Single media Transport 🔢
- MRMT: Multiple RTP streams on Multiple media Transports 🧩
MRST and MRMT relations need to figure out the common media encoder origin for the encoded and dependent streams 🔍 When you use different RTP sessions (MRMT), with a single RTP stream per media encoder and a single media source in each RTP session, you can use common SSRCs and CNAMEs to identify the common media source 🪪 When multiple RTP streams come from one media encoder in the same RTP session (MRST), CNAME is the only RTP identifier that's currently specified for this 🙃 And if multiple media encoders use multiple media sources that share a synchronization context (so they have a common CNAME), you need extra heuristics or identification to build the MRST or MRMT relationships between the RTP streams 🧐
3.8. RTP Stream Duplication 👯
RTP Stream Duplication [RFC7198] is a simple way to protect media flows from packet loss in some cases 🛡️ It can use the same or different media transports, and you can optionally delay the duplicate too [RFC7197] ⏳ It's a specific kind of redundancy 💫 All but one source RTP stream (Section 2.1.10) are basically redundancy RTP streams (Section 2.1.12), but since the source and redundant RTP streams are identical, it doesn't matter which one is which 🤷♀️ You can also think of this as a specific kind of simulcast (Section 3.6) that sends the same encoded stream (Section 2.1.7) multiple times 🔁 Check out Figure 10 for an example 👇
+----------------+
| Media Source |
+----------------+
Source Stream |
V
+----------------+
| Media Encoder |
+----------------+
Encoded Stream |
+-----------+-----------+
| |
V V
+------------------+ +------------------+
| Media Packetizer | | Media Packetizer |
+------------------+ +------------------+
Source | RTP Stream Source | RTP Stream
| V
| +-------------+
| | Delay (opt) |
| +-------------+
| |
+-----------+-----------+
|
V
+-------------------+
| Media Transport |
+-------------------+
Figure 10: Example of RTP Stream Duplication3.9. Redundancy Format ✨
Okay so "RTP Payload for Redundant Audio Data" [RFC2198] is the spec that lets you pack redundant audio data right next to the primary data in the same RTP payload 🎀. The redundant part can be a time-delayed copy of the primary, or a different time-delayed stream made by a different media encoder from the same media source as the primary. Figure 11 shows it 🦋.
+--------------------+
| Media Source |
+--------------------+
|
Source Stream
|
+------------------------+
| |
V V
+--------------------+ +--------------------+
| Media Encoder | | Media Encoder |
+--------------------+ +--------------------+
| |
| +------------+
Encoded Stream | Time Delay |
| +------------+
| |
| +------------------+
V V
+--------------------+
| Media Packetizer |
+--------------------+
|
V
RTP Stream
Figure 11: Concept for Usage of Audio Redundancy with Different Media
EncodersSo the redundancy format is basically giving you the extra meta info needed to correctly relate different parts of the same encoded stream 💅. What Figure 11 is doing is taking the received source stream fragments coming out of different media decoders and stitching them together into a less erroneous source stream. It's giving main character energy ✨.
3.10. RTP Retransmission 🍓
Figure 12 is an example where a media source's source RTP stream is protected by a retransmission (RTX) flow [RFC4588]. In this example the source RTP stream and the redundancy RTP stream share the same media transport.
+--------------------+
| Media Source |
+--------------------+
|
V
+--------------------+
| Media Encoder |
+--------------------+
| Retransmission
Encoded Stream +--------+ +---- Request
V | V V
+--------------------+ | +--------------------+
| Media Packetizer | | | RTP Retransmission |
+--------------------+ | +--------------------+
| | |
+------------+ Redundancy RTP Stream
Source RTP Stream |
| |
+---------+ +---------+
| |
V V
+-----------------+
| Media Transport |
+-----------------+
Figure 12: Example of Media Source Retransmission FlowsThe RTP retransmission example (Figure 12) shows that this mechanism works purely on the source RTP stream 🧚. It transforms buffers from the sent source RTP stream and, when asked, emits a retransmitted packet with an extra payload header as a redundancy RTP stream. The RTP retransmission mechanism [RFC4588] is specified so there's a one-to-one relation between the source RTP stream and the redundancy RTP stream 👑. That means a redundancy RTP stream needs to be associated with its source RTP stream. This is done using CNAME selectors and heuristics, matching requested packets for a given source RTP stream with the original sequence number in the payload of any new redundancy RTP stream that uses the RTX payload format. If the redundancy RTP stream is sent in a different RTP session from the source RTP stream, the RTP session relation gets signaled with the Flow Identification (FID identification-tag) semantics from the SDP media grouping's [RFC5888] framework 🫶.
3.11. Forward Error Correction 🔥
Figure 13 is an example where two media sources' source RTP streams are protected by FEC. Source RTP stream A goes through an RTP-based redundancy transformation in FEC encoder 1, which produces redundancy RTP stream 1. That one is only related to source RTP stream A. FEC encoder 2 is the one taking two source RTP streams (A and B) and making redundancy RTP stream 2, which protects them jointly. So redundancy RTP stream 2 relates to two source RTP streams (a FEC group) 🌈. When the receiver needs FEC decoding because of packet loss or packet corruption, it has to know which source RTP streams the FEC encoding was based on 😭.
In Figure 13 all the RTP streams go over the same media transport. That's not the only option though, and there are loads of combinations for spreading these RTP streams across different media transports to hit the communication application's goal 💖.
+--------------------+ +--------------------+
| Media Source A | | Media Source B |
+--------------------+ +--------------------+
| |
V V
+--------------------+ +--------------------+
| Media Encoder A | | Media Encoder B |
+--------------------+ +--------------------+
| |
Encoded Stream Encoded Stream
V V
+--------------------+ +--------------------+
| Media Packetizer A | | Media Packetizer B |
+--------------------+ +--------------------+
| |
Source RTP Stream A Source RTP Stream B
| |
+-----+---------+-------------+ +---+---+
| V V V |
| +---------------+ +---------------+ |
| | FEC Encoder 1 | | FEC Encoder 2 | |
| +---------------+ +---------------+ |
| Redundancy | Redundancy | |
| RTP Stream 1 | RTP Stream 2 | |
V V V V
+----------------------------------------------------------+
| Media Transport |
+----------------------------------------------------------+
Figure 13: Example of FEC Redundancy RTP StreamsFEC comes in lots of forms, so there are many ways to relate FEC redundancy RTP streams to their source information in the source RTP streams 🧚♀️. The XOR-based RTP FEC payload format [RFC5109] is defined so that a redundancy RTP stream has a one-to-one relation with a source RTP stream. In fact, the RFC requires the redundancy RTP stream to use the same SSRC as the source RTP stream. That means you need either a separate RTP session or the redundancy RTP payload format [RFC2198] ✨. The thing this FEC format needs for a particular redundancy RTP stream is knowing the related source RTP stream, including its SSRC 🍓.
3.12. RTP Stream Separation 🦋
RTP streams can be separated exclusively based on their SSRCs, at the RTP session level, or at the multimedia session level 👑.
When the RTP streams that have a relationship are all sent in the same RTP session and are uniquely identified by their SSRC only, that's called an "SSRC-only-based separation" 💅. Those streams can be related via RTCP CNAME so you know they belong to the same endpoint. SSRC-based approaches [RFC5576], when used, can explicitly relate various such RTP streams 🫶.
On the flip side, when related RTP streams are sent in the context of different RTP sessions to get separated, it's called "RTP session-based separation" 🌸. This is commonly used when the different RTP streams are meant for different media transports.
Several mechanisms that use RTP session-based separation rely on it as the grouping mechanism that expresses the relationship. These solutions use the same SSRC value in the different RTP sessions to implicitly show their relation, so no explicit RTP level mechanism is needed. Only signaling level relations get established, using semantics from the media-line grouping framework [RFC5888] 🎀. Examples are RTP retransmission [RFC4588], SVC Multi-Session Transmission [RFC6190], and XOR-based FEC [RFC5109]. RTCP CNAME explicitly relates RTP streams across different RTP sessions, as we covered in the previous section, and that relationship can be used to do inter-media synchronization 💖.
Related RTP streams that need to be associated can also be part of different multimedia sessions, not just different RTP sessions inside the same multimedia session context. That puts extra demand on the scope of the mechanism(s) and on how they handle the identifiers used to express the relationships 😭.
3.13. Multiple RTP Sessions over one Media Transport 🌈
[TRANSPORT-MULTIPLEX] describes a mechanism that lets several RTP sessions be carried over a single underlying media transport. The main reasons for doing this come down to the impact of using one or more media transports (whether they share a common network path or might have different ones). The fewer media transports you use, the less NAT/firewall traversal resources you need and the smaller the number of flow-based QoS 🧚.
Still, multiple RTP sessions over one media transport mean a single media transport 5-tuple isn't enough to express which RTP session context a particular RTP stream lives in 🙈. Things are already complicated between media transports and RTP sessions, since one RTP session can contain multiple media transports. Even a Peer-to-Peer RTP Session with RTP/RTCP Multiplexing needs two media transports, one in each direction 💅. The relationship between media transports and RTP sessions, plus any extra levels of identifiers, has to be considered in both signaling design and when defining terminology ✨.
4. Mapping from Existing Terms 🎀
This section describes a selected set of terms from some relevant RFCs and Internet-Drafts (at the time of writing), using the concepts from the previous sections 💜.
4.1. Telepresence Terms 🦋
The terms in this subsection are used in the context of CLUE [CLUE-FRAME]. Some terms here use the same names as terms defined elsewhere in this document. Unless they're explicitly stated (as "RTP Taxonomy") and in this subsection, read them as references to the CLUE-specific term inside this subsection 🫶.
4.1.1. Audio Capture 🎧
Defined in CLUE as a Media Capture (Section 4.1.7) for audio. It describes an audio media source (Section 2.1.4) 💖.
4.1.2. Capture Device 🌸
Defined in CLUE as a device that converts physical input into an electrical signal. It identifies a physical entity performing an RTP Taxonomy media capture (Section 2.1.2) transformation 👑.
4.1.3. Capture Encoding 🎀
okay so CLUE defines this as a specific Encoding (Section 4.1.6) of a Media Capture (Section 4.1.7) 💅 It describes an encoded stream (Section 2.1.7) that's tied to CLUE-specific semantic info. Main character energy 👑
4.1.4. Capture Scene 🌸
in CLUE, a Capture Scene is a structure representing a spatial region captured by one or more Capture Devices (Section 4.1.2), with each device capturing media for a portion of that region ✨ it describes a set of spatially related media sources (Section 2.1.4). the spatial vibes are immaculate 🦋
4.1.5. Endpoint 🧚
CLUE defines an Endpoint as a CLUE-capable device that's the logical point of final termination (receiving, decoding, and rendering) and/or initiation (capturing, encoding, and sending) of media Streams (Section 4.1.10) 💖 it also says it consists of one or more physical devices with source and sink media streams, and exactly one participant [RFC4353]. so it describes exactly one participant (Section 2.2.3) and one or more RTP Taxonomy endpoints (Section 2.2.1). it's giving multi-device energy 📱💻
4.1.6. Individual Encoding 🍓
CLUE calls this a set of parameters that represents a way to encode a Media Capture (Section 4.1.7) so it becomes a Capture Encoding (Section 4.1.3) ✨ basically it's the configuration info needed to perform a media encoder (Section 2.1.6) transformation. the setup era 🫶
4.1.7. Media Capture 🦋
in CLUE, a Media Capture is a source of media, like from one or more Capture Devices (Section 4.1.2) or constructed from other media Streams (Section 4.1.10) 🌈 depending on the context, it describes either an RTP Taxonomy media capture (Section 2.1.2) or a media source (Section 2.1.4). the word really be doing double duty 😭
4.1.8. Media Consumer 💜
CLUE says a Media Consumer is a CLUE-capable device that intends to receive Capture Encodings (Section 4.1.3) 🎧 it describes the media receiving part of an RTP Taxonomy endpoint (Section 2.2.1). the receiver era, iconic 👑
4.1.9. Media Provider 🔥
a Media Provider, per CLUE, is a CLUE-capable device that intends to send Capture Encodings (Section 4.1.3) 📤 it describes the media sending part of an RTP Taxonomy endpoint (Section 2.2.1). sender supremacy 💅
4.1.10. Stream ⭐
CLUE defines a Stream as a Capture Encoding (Section 4.1.3) sent from a Media Provider (Section 4.1.9) to a Media Consumer (Section 4.1.8) via RTP 🚀 it describes an RTP stream (Section 2.1.10). that's the whole vibe, bestie 🫶
4.1.11. Video Capture 🎬
CLUE defines a Video Capture as a Media Capture (Section 4.1.7) for video 📹 it describes a video media source (Section 2.1.4). simple, clean, slay 💖
4.2. Media Description 🎀
okay so a single Session Description Protocol (SDP) [RFC4566] Media Description (also called a media block: an m= line and all the subsequent lines until the next m= line or the end of the SDP) describes part of the configuration and identification info needed for a media encoder transformation 🧩 it also covers the config and identification info the media decoder needs so it can correctly interpret a received RTP stream. two jobs, one block, very efficient 💅
a media description typically relates to a single media source 🎯 this is, for example, an explicit restriction in WebRTC. BUT nothing prevents the same media description (and same RTP session) from being reused for multiple media sources [RTP-MULTI-STREAM] 🌸 so it can describe properties of one or more RTP streams, and it can also describe properties valid for an entire RTP session (via [RFC5576] mechanisms, for example). plot twist, it's versatile 🦋
4.3. Media Stream 🧚
RTP [RFC3550] uses media stream, audio stream, video stream, and a stream of (RTP) packets interchangeably 💜 they are all RTP streams. same thing, different names, no cap 🙈
4.4. Multimedia Conference 🌈
a Multimedia Conference is a communication session (Section 2.2.5) between two or more participants (Section 2.2.3), along with the software they're using to communicate ✨ the whole squad plus their apps 🫶
4.5. Multimedia Session 💖
okay this one has two angles 👀 SDP [RFC4566] defines a multimedia session as a set of multimedia senders and receivers and the data streams flowing from senders to receivers. that would correspond to a set of endpoints and the RTP streams that flow between them. in this document, multimedia session (Section 2.2.4) also assumes those endpoints belong to a set of participants engaged in communication via a set of related RTP streams 🎀
RTP [RFC3550] defines a multimedia session as a set of concurrent RTP sessions among a common group of participants 📞 for example, a video conference may contain an audio RTP session and a video RTP session. that corresponds to a group of participants (each using one or more endpoints) sharing a set of concurrent RTP sessions. in this document, multimedia session also defines those RTP sessions to have some relation and to be part of a communication among the participants 🔥 two definitions, one aesthetic 💅
4.6. Multipoint Control Unit (MCU) 👑
this term is commonly used to describe the central node in any type of star topology [RTP-TOPOLOGIES] conference ⭐ it describes a device that includes one participant (Section 2.2.3), usually corresponding to a so-called conference focus, and one or more related endpoints (Section 2.2.1), sometimes one or more per conference participant. the hub of the group chat 🍓
4.7. Multi-Session Transmission (MST) 🌈
one of two transmission modes defined in H.264-based SVC [RFC6190], the other being Single-Session Transmission (SST) (Section 4.14) 🎬 in MST, the SVC media encoder sends encoded streams and dependent streams distributed across two or more RTP streams in one or more RTP sessions. the term "MST" is ambiguous in RFC 6190 🙈 because the name suggests multiple "sessions", but MST-type packetization is actually required whenever two or more RTP streams are used for the encoded and dependent streams, regardless of whether those are sent in one or more RTP sessions. it corresponds either to MRST or MRMT (Section 3.7) stream relations defined in this document. the SVC RTP payload RFC [RFC6190] isn't particularly explicit about how the common media encoder (Section 2.1.6) relation between encoded streams (Section 2.1.7) and dependent streams (Section 2.1.8) is to be implemented 💀 we'll take the vague-era L and move on
4.8. Recording Device 🎧
WebRTC specs use this term to refer to locally available entities performing a media capture (Section 2.1.2) transformation 📼 the local recorders, basically 🦋
4.9. RtcMediaStream ✨
a WebRTC RtcMediaStream is a set of media sources (Section 2.1.4) that share the same synchronization context (Section 3.1) 🫶 they're in sync, bestie 🎶
4.10. RtcMediaStreamTrack 💜
a WebRTC RtcMediaStreamTrack is a media source (Section 2.1.4) 🎵 one track, one source, clean and simple 💅
4.11. RTP Receiver 🌸
RTP [RFC3550] uses this term, and it can be seen as the RTP protocol part of a media depacketizer (Section 2.1.27) 📦 the unpacking side of things 🧚
4.12. RTP Sender 🎀
RTP [RFC3550] uses this term too, and it can be seen as the RTP protocol part of a media packetizer (Section 2.1.9) 📦 the packing side, so the two are a matching set 🫶
4.13. RTP Session 🌈
okay so within the context of SDP, a single m= line can map to a single RTP session (Section 2.2.2), or multiple m= lines can map to a single RTP session 🤯 the latter is enabled via multiplexing schemes like BUNDLE [SDP-BUNDLE], which allows mapping of multiple m= lines to a single RTP session. one session, many lines, big multitasking energy 🦋
4.14. Single-Session Transmission (SST) 💖
another one of the two H.264-based SVC [RFC6190] transmission modes, the other being MST (Section 4.7) 🎬 in SST, the SVC media encoder sends encoded streams (Section 2.1.7) and dependent streams (Section 2.1.8) combined into a single RTP stream (Section 2.1.10) in a single RTP session (Section 2.2.2), using the SVC RTP payload format. the term "SST" is ambiguous in RFC 6190 🙃 sometimes it refers to a single RTP stream (like in the packetization sections), and sometimes it seems to mean a single RTP session (like when discussing SDP). it closely corresponds to SRST (Section 3.7), which is defined in this document 🧩
4.15. SSRC 👑
RTP [RFC3550] defines this as "the source of a stream of RTP packets," so an SSRC isn't just a unique identifier for the encoded stream (Section 2.1.7) carried in those packets. it's also effectively used as a term for a media packetizer (Section 2.1.9) 🔥 [RFC3550] says "a synchronization source may change its data format, e.g., audio encoding, over time". the related encoded stream data format in an RTP stream (Section 2.1.10) is identified by the RTP payload type 🎀 changing the data format for an encoded stream also changes which media encoder (Section 2.1.6) is used for it. no ambiguity gets introduced to SSRC as an encoded stream identifier by allowing RTP payload type changes, as long as only a single RTP payload type is valid for any given RTP Timestamp ✨ this is aligned with, and further described by, Section 5.2 of [RFC3550]. the identifier era is over and we are thriving 💅
5. Security Considerations 🔐
the whole point of this document is to make clarifications and reduce the confusion that's everywhere in RTP taxonomy 😭 because multiple technologies and protocols that use RTP are using terms inconsistently. it does not introduce any new security considerations beyond those already well documented in the RTP protocol [RFC3550] and in each of the many respective specifications of the various protocols that make use of it 🛡️
having a well-defined common terminology and a real understanding of the complexities of the RTP architecture will help lead us to better standards, avoiding security problems 🚨 clean vocab is literally a safety feature, bestie 💖
6. Informative References ✨
okay so this is the reading list bit 📚 these are the docs the spec leans on but doesn't actually define, and every single one is listed with all its details so you can go find it 🫶
[CLUE-FRAME]Duckworth, M., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", Work in Progress, draft-ietf-clue-framework-22, April 2015. 🎬[RFC2198]Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997,<http://www.rfc-editor.org/info/rfc2198>. 🎧[RFC3550]Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003,<http://www.rfc-editor.org/info/rfc3550>. 👑 the RTP classic, obviously[RFC3551]Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003,<http://www.rfc-editor.org/info/rfc3551>. 🎙️[RFC3711]Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004,<http://www.rfc-editor.org/info/rfc3711>. 🔐 security bestie[RFC4353]Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006,<http://www.rfc-editor.org/info/rfc4353>. 📞[RFC4566]Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006,<http://www.rfc-editor.org/info/rfc4566>. 📝[RFC4588]Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006,<http://www.rfc-editor.org/info/rfc4588>. 🔁[RFC4867]Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, April 2007,<http://www.rfc-editor.org/info/rfc4867>. 🎵[RFC5109]Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007,<http://www.rfc-editor.org/info/rfc5109>. 🛡️[RFC5404]Westerlund, M. and I. Johansson, "RTP Payload Format for G.719", RFC 5404, DOI 10.17487/RFC5404, January 2009,<http://www.rfc-editor.org/info/rfc5404>. 🎶[RFC5481]Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009,<http://www.rfc-editor.org/info/rfc5481>. ⏱️[RFC5576]Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,<http://www.rfc-editor.org/info/rfc5576>. 🏷️[RFC5888]Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010,<http://www.rfc-editor.org/info/rfc5888>. 🧩[RFC5905]Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,<http://www.rfc-editor.org/info/rfc5905>. 🕰️[RFC6190]Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011,<http://www.rfc-editor.org/info/rfc6190>. 🎥[RFC7160]Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014,<http://www.rfc-editor.org/info/rfc7160>. ⏲️[RFC7197]Begen, A., Cai, Y., and H. Ou, "Duplication Delay Attribute in the Session Description Protocol", RFC 7197, DOI 10.17487/RFC7197, April 2014,<http://www.rfc-editor.org/info/rfc7197>. 🪞[RFC7198]Begen, A. and C. Perkins, "Duplicating RTP Streams", RFC 7198, DOI 10.17487/RFC7198, April 2014,<http://www.rfc-editor.org/info/rfc7198>. 👯[RFC7201]Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,<http://www.rfc-editor.org/info/rfc7201>. 🔒[RFC7273]Williams, A., Gross, K., van Brandenburg, R., and H. Stokking, "RTP Clock Source Signalling", RFC 7273, DOI 10.17487/RFC7273, June 2014,<http://www.rfc-editor.org/info/rfc7273>. ⌚[RTP-MULTI-STREAM]Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session", Work in Progress, draft-ietf-avtcore-rtp-multi-stream-08, July 2015. 🌊[RTP-TOPOLOGIES]Westerlund, M. and S. Wenger, "RTP Topologies", Work in Progress, draft-ietf-avtcore-rtp-topologies-update-10, July 2015. 🗺️[SDP-BUNDLE]Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Work in Progress, draft-ietf-mmusic-sdp-bundle-negotiation-23, July 2015. 📦[SDP-SIMULCAST]Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, "Using Simulcast in SDP and RTP Sessions", Work in Progress, draft-ietf-mmusic-sdp-simulcast-01, July 2015. 📺[TRANSPORT-MULTIPLEX]Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP Sessions onto a Single Lower-Layer Transport", Work in Progress, draft-westerlund-avtcore-transport-multiplexing-07, October 2013. 🧵[WEBRTC-OVERVIEW]Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, draft-ietf-rtcweb-overview-14, June 2015. 🌐
Acknowledgements 🌸
okay the credit section and I need to give it all the love 🫶 this doc borrows a LOT of ideas from WebRTC [WEBRTC-OVERVIEW], CLUE [CLUE-FRAME], and Multiplexing Architecture [TRANSPORT-MULTIPLEX], so the authors say a big thank you to everyone who wrote those.
the authors also shout out Magnus Westerlund, Roni Even, Paul Kyzivat, Colin Perkins, Keith Drage, Harald Alvestrand, Alex Eleftheriadis, Mo Zanaty, Stephan Wenger, and Bernard Aboba for their insights, guidance, and contributions. the whole group chat deserves a crown 👑
Contributors 💖
Magnus Westerlund is the one who came up with the concept model for the media chain, using the transformations and streams model. he also rewrote the older concepts to fit this model and added the ones that were missing, and he made the first proposal for updating the relationships and topologies based on it. he's literally the main character of this section 🧚
Authors' Addresses 🦋
these are the people who wrote it, with where to find them 💌
Jonathan Lennox:
Jonathan Lennox
Vidyo, Inc.
433 Hackensack Avenue
Seventh Floor
Hackensack, NJ 07601
United States
Email: jonathan@vidyo.comKevin Gross:
Kevin Gross
AVA Networks, LLC
Boulder, CO
United States
Email: kevin.gross@avanw.comSuhas Nandakumar:
Suhas Nandakumar
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
United States
Email: snandaku@cisco.comGonzalo Salgueiro:
Gonzalo Salgueiro
Cisco Systems
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
United States
Email: gsalguei@cisco.comBo Burman (editor):
Bo Burman (editor)
Ericsson
Kistavagen 25
SE-16480 Stockholm
Sweden
Email: bo.burman@ericsson.com📦 where this page comes from
- ietf: rfc7656 2015-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms