RFC 7656
A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources
3. Concepts of Inter-Relations
This section uses the concepts from previous sections and looks at different types of relationships among them. These relationships occur at different abstraction levels and for different purposes, but the reason for the needed relationship at a certain step in the media handling chain may exist at another step. For example, the use of simulcast (Section 3.6) implies a need to determine relations at the
RTP stream level, but the underlying reason is that multiple media encoders use the same media source, i.e., to be able to identify a common media source.3.1. Synchronization Context
A synchronization context defines a requirement for a strong timing relationship between the media sources, typically requiring alignment of clock sources. Such a relationship can be identified in multiple ways as listed below. A single media source can only belong to a single synchronization context, since it is assumed that a single media source can only have a single media clock and requiring alignment to several synchronization contexts (and thus reference clocks) will effectively merge those into a single synchronization context.3.1.1. RTCP CNAME
[RFC3550] describes inter-media synchronization between RTP sessions based on RTCP CNAME, RTP, and timestamps of a reference clock formatted using the Network Time Protocol (NTP) [RFC5905]. As indicated in [RFC7273], despite using NTP format timestamps, it is not required that the clock be synchronized to an NTP source.3.1.2. Clock Source Signaling
[RFC7273] provides a mechanism to signal the clock source in the Session Description Protocol (SDP) [RFC4566] both for the reference clock as well as the media clock, thus allowing a synchronization context to be defined beyond the one defined by the usage of CNAME source descriptions.3.1.3. Implicitly via RtcMediaStream
WebRTC defines RtcMediaStream with one or more RtcMediaStreamTracks. All tracks in a RtcMediaStream are intended to be synchronized when rendered, implying that they must be generated such that synchronization is possible.3.1.4. Explicitly via SDP Mechanisms
The SDP Grouping Framework [RFC5888] defines an "m=" line (Section 4.2) grouping mechanism called Lip Synchronization (with LS identification-tag) for establishing the synchronization requirement across "m=" lines when they map to individual sources.
Source-Specific Media Attributes in SDP [RFC5576] extends the above mechanism when multiple media sources are described by a single "m=" line.3.2. Endpoint
Some applications require knowledge of what media sources originate from a particular endpoint (Section 2.2.1). This can include such decisions as packet routing between parts of the topology, knowing the endpoint origin of the RTP streams. In RTP, this identification has been overloaded with the synchronization context (Section 3.1) through the usage of the RTCP source description CNAME (Section 3.1.1). This works for some usages, but in others it breaks down. For example, if an endpoint has two sets of media sources that have different synchronization contexts, like the audio and video of the human participant as well as a set of media sources of audio and video for a shared movie, CNAME would not be an appropriate identification for that endpoint. Therefore, an endpoint may have multiple CNAMEs. The CNAMEs or the media sources themselves can be related to the endpoint.3.3. Participant
In communication scenarios, information about which media sources originate from which participant (Section 2.2.3) is commonly needed. One reason is, for example, to enable the application to correctly display participant identity information associated with the media sources. This association is handled through signaling to point at a specific multimedia session where the media sources may be explicitly or implicitly tied to a particular endpoint. Participant information becomes more problematic when there are media sources that are generated through mixing or other conceptual processing of raw streams or source streams that originate from different participants. These types of media sources can thus have a dynamically varying set of origins and participants. RTP contains the concept of CSRC that carries information about the previous step origin of the included media content on the RTP level.3.4. RtcMediaStream
An RtcMediaStream in WebRTC is an explicit grouping of a set of media sources (RtcMediaStreamTracks) that share a common identifier and a single synchronization context (Section 3.1).
3.5. Multi-Channel Audio
There exist a number of RTP payload formats that can carry multi- channel audio, despite the codec being a single-channel (mono) encoder. Multi-channel audio can be viewed as multiple media sources sharing a common synchronization context. These are independently encoded by a media encoder and the different encoded streams are packetized together in a time-synchronized way into a single source RTP stream, using the used codec's RTP payload format. Examples of codecs that support multi-channel audio are PCMA and PCMU [RFC3551], Adaptive Multi Rate (AMR) [RFC4867], and G.719 [RFC5404].3.6. Simulcast
A media source represented as multiple independent encoded streams constitutes a simulcast [SDP-SIMULCAST] or Modification Detection Code (MDC) of that media source. Figure 8 shows an example of a media source that is encoded into three separate simulcast streams, that are in turn sent on the same media transport flow. When using simulcast, the RTP streams may be sharing an RTP session and media transport, or be separated on different RTP sessions and media transports, or be any combination of these two. One major reason to use separate media transports is to make use of different quality of service (QoS) for the different source RTP streams. Some considerations on separating related RTP streams are discussed 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 Simulcast The simulcast relation between the RTP streams is the common media source. In addition, to be able to identify the common media source, a receiver of the RTP stream may need to know which configuration or encoding goals lay behind the produced encoded stream and its properties. This enables selection of the stream that is most useful in the application at that moment.
3.7. Layered Multi-Stream
Layered Multi-Stream (LMS) is a mechanism by which different portions of a layered or scalable encoding of a source stream are sent using separate RTP streams (sometimes in separate RTP sessions). LMSs are useful for receiver control of layered media. A media source represented as an encoded stream and multiple dependent streams constitutes a media source that has layered dependencies. Figure 9 represents an example of a media source that is encoded into three dependent layers, where two layers are sent on the same media transport using different RTP streams, i.e., SSRCs, and the third layer is sent 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 Dependency It is sometimes useful to make a distinction between using a single media transport or multiple separate media transports when (in both cases) using multiple RTP streams to carry encoded streams and dependent streams for a media source. Therefore, the following new terminology is defined here:
SRST: Single RTP stream on a Single media Transport MRST: Multiple RTP streams on a Single media Transport MRMT: Multiple RTP streams on Multiple media Transports MRST and MRMT relations need to identify the common media encoder origin for the encoded and dependent streams. When using different RTP sessions (MRMT), a single RTP stream per media encoder, and a single media source in each RTP session, common SSRCs and CNAMEs can be used to identify the common media source. When multiple RTP streams are sent from one media encoder in the same RTP session (MRST), then CNAME is the only currently specified RTP identifier that can be used. In cases where multiple media encoders use multiple media sources sharing synchronization context, and thus have a common CNAME, additional heuristics or identification need to be applied to create the MRST or MRMT relationships between the RTP streams.
3.8. RTP Stream Duplication
RTP Stream Duplication [RFC7198], using the same or different media transports, and optionally also delaying the duplicate [RFC7197], offers a simple way to protect media flows from packet loss in some cases (see Figure 10). This is a specific type of redundancy. All but one source RTP stream (Section 2.1.10) are effectively redundancy RTP streams (Section 2.1.12), but since both source and redundant RTP streams are the same, it does not matter which one is which. This can also be seen as a specific type of simulcast (Section 3.6) that transmits the same encoded stream (Section 2.1.7) multiple times. +----------------+ | 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 Duplication
3.9. Redundancy Format
"RTP Payload for Redundant Audio Data" [RFC2198] defines a transport for redundant audio data together with primary data in the same RTP payload. The redundant data can be a time-delayed version of the primary or another time-delayed encoded stream using a different media encoder to encode the same media source as the primary, as depicted in Figure 11. +--------------------+ | 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 Encoders The redundancy format is thus providing the necessary meta information to correctly relate different parts of the same encoded stream. The case depicted above (Figure 11) relates the received source stream fragments coming out of different media decoders, to be able to combine them together into a less erroneous source stream.3.10. RTP Retransmission
Figure 12 shows 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 Flows The RTP retransmission example (Figure 12) illustrates that this mechanism works purely on the source RTP stream. The RTP retransmission transforms buffers from the sent source RTP stream and, upon request, emits a retransmitted packet with an extra payload header as a redundancy RTP stream. The RTP retransmission mechanism [RFC4588] is specified such that there is a one-to-one relation between the source RTP stream and the redundancy RTP stream. Therefore, a redundancy RTP stream needs to be associated with its source RTP stream. This is done based on CNAME selectors and heuristics to match requested packets for a given source RTP stream with the original sequence number in the payload of any new redundancy RTP stream using the RTX payload format. In cases where the redundancy RTP stream is sent in a different RTP session than the source RTP stream, the RTP session relation is signaled by using the SDP media grouping's [RFC5888] Flow Identification (FID identification-tag) semantics.
3.11. Forward Error Correction
Figure 13 shows an example where two media sources' source RTP streams are protected by FEC. Source RTP stream A has an RTP-based redundancy transformation in FEC encoder 1. This produces a redundancy RTP stream 1, that is only related to source RTP stream A. The FEC encoder 2, however, takes two source RTP streams (A and B) and produces a redundancy RTP stream 2 that protects them jointly, i.e., redundancy RTP stream 2 relates to two source RTP streams (a FEC group). FEC decoding, when needed due to packet loss or packet corruption at the receiver, requires knowledge about which source RTP streams that the FEC encoding was based on. In Figure 13, all RTP streams are sent on the same media transport. This is, however, not the only possible choice. Numerous combinations exist for spreading these RTP streams over different media transports to achieve 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 Streams
As FEC encoding exists in various forms, the methods for relating FEC redundancy RTP streams with its source information in source RTP streams are many. The XOR-based RTP FEC payload format [RFC5109] is defined in such a way 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. This requires the use of either a separate RTP session or the redundancy RTP payload format [RFC2198]. The underlying relation requirement for this FEC format and a particular redundancy RTP stream is to know 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 based on their SSRC only, it is termed an "SSRC-only-based separation". Such streams can be related via RTCP CNAME to identify that the streams belong to the same endpoint. SSRC-based approaches [RFC5576], when used, can explicitly relate various such RTP streams. On the other hand, when RTP streams that are related are sent in the context of different RTP sessions to achieve separation, it is known as "RTP session-based separation". This is commonly used when the different RTP streams are intended for different media transports. Several mechanisms that use RTP session-based separation rely on it as a grouping mechanism expressing the relationship. The solutions have been based on using the same SSRC value in the different RTP sessions to implicitly indicate their relation. That way, no explicit RTP level mechanism has been needed; only signaling level relations have been established using semantics from the media-line grouping framework [RFC5888]. Examples of this 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 explained in the previous section. Such a relationship can be used to perform inter-media synchronization. RTP streams that are related and need to be associated can be part of different multimedia sessions, rather than just different RTP sessions within the same multimedia session context. This puts further demand on the scope of the mechanism(s) and its handling of identifiers used for expressing the relationships.
3.13. Multiple RTP Sessions over one Media Transport
[TRANSPORT-MULTIPLEX] describes a mechanism that allows several RTP sessions to be carried over a single underlying media transport. The main reasons for doing this are related to the impact of using one or more media transports (using a common network path or potentially having different ones). The fewer media transports used, the less need for NAT/firewall traversal resources and smaller number of flow- based QoS. However, multiple RTP sessions over one media transport imply that a single media transport 5-tuple is not sufficient to express in which RTP session context a particular RTP stream exists. Complexities in the relationship between media transports and RTP sessions already exist as one RTP session contains multiple media transports, e.g., even a Peer-to-Peer RTP Session with RTP/RTCP Multiplexing requires two media transports, one in each direction. The relationship between media transports and RTP sessions as well as additional levels of identifiers needs 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 previous sections.4.1. Telepresence Terms
The terms in this subsection are used in the context of CLUE [CLUE-FRAME]. Note that some terms listed in this subsection use the same names as terms defined elsewhere in this document. Unless explicitly stated (as "RTP Taxonomy") and in this subsection, they are to be read as references to the CLUE-specific term within this subsection.4.1.1. Audio Capture
Defined in CLUE as a Media Capture (Section 4.1.7) for audio. 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. Identifies a physical entity performing an RTP Taxonomy media capture (Section 2.1.2) transformation.
4.1.3. Capture Encoding
Defined in CLUE as a specific Encoding (Section 4.1.6) of a Media Capture (Section 4.1.7). Describes an encoded stream (Section 2.1.7) related to CLUE-specific semantic information.4.1.4. Capture Scene
Defined in CLUE as a structure representing a spatial region captured by one or more Capture Devices (Section 4.1.2), each capturing media representing a portion of the region. Describes a set of spatially related media sources (Section 2.1.4).4.1.5. Endpoint
Defined in CLUE as a CLUE-capable device that is the logical point of final termination through receiving, decoding, and rendering and/or initiation through capturing, encoding, and sending of media Streams (Section 4.1.10). CLUE further defines it to consist of one or more physical devices with source and sink media streams, and exactly one participant [RFC4353]. Describes exactly one participant (Section 2.2.3) and one or more RTP Taxonomy endpoints (Section 2.2.1).4.1.6. Individual Encoding
Defined in CLUE as a set of parameters representing a way to encode a Media Capture (Section 4.1.7) to become a Capture Encoding (Section 4.1.3). Describes the configuration information needed to perform a media encoder (Section 2.1.6) transformation.4.1.7. Media Capture
Defined in CLUE as a source of media, such as from one or more Capture Devices (Section 4.1.2) or constructed from other media Streams (Section 4.1.10). Describes either an RTP Taxonomy media capture (Section 2.1.2) or a media source (Section 2.1.4), depending on in which context the term is used.4.1.8. Media Consumer
Defined in CLUE as a CLUE-capable device that intends to receive Capture Encodings (Section 4.1.3). Describes the media receiving part of an RTP Taxonomy endpoint (Section 2.2.1).
4.1.9. Media Provider
Defined in CLUE as a CLUE-capable device that intends to send Capture Encodings (Section 4.1.3). Describes the media sending part of an RTP Taxonomy endpoint (Section 2.2.1).4.1.10. Stream
Defined in CLUE 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. Describes an RTP stream (Section 2.1.10).4.1.11. Video Capture
Defined in CLUE as a Media Capture (Section 4.1.7) for video. Describes a video media source (Section 2.1.4).4.2. Media Description
A single Session Description Protocol (SDP) [RFC4566] Media Description (or media block; an "m=" line and all subsequent lines until the next "m=" line or the end of the SDP) describes part of the necessary configuration and identification information needed for a media encoder transformation, as well as the necessary configuration and identification information for the media decoder to be able to correctly interpret a received RTP stream. A media description typically relates to a single media source. This is, for example, an explicit restriction in WebRTC. However, nothing prevents that the same media description (and same RTP session) is reused for multiple media sources [RTP-MULTI-STREAM]. It can thus describe properties of one or more RTP streams, and can also describe properties valid for an entire RTP session (via [RFC5576] mechanisms, for example).4.3. Media Stream
RTP [RFC3550] uses media stream, audio stream, video stream, and a stream of (RTP) packets interchangeably, which are all RTP streams.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 are using to communicate.
4.5. Multimedia Session
SDP [RFC4566] defines a multimedia session as a set of multimedia senders and receivers and the data streams flowing from senders to receivers, which 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 that are 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. This would correspond 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 be part of a communication among the participants.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).4.7. Multi-Session Transmission (MST)
One of two transmission modes defined in H.264-based SVC [RFC6190], the other mode being a Single-Session Transmission (SST) (Section 4.14). In Multi-Session Transmission (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, especially since the name indicates the use of multiple "sessions", while MST-type packetization is in fact required whenever two or more RTP streams are used for the encoded and dependent streams, regardless if those are sent in one or more RTP sessions. Corresponds either to MRST or MRMT (Section 3.7) stream relations defined in this document. The SVC RTP payload RFC [RFC6190] is not 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.
4.8. Recording Device
WebRTC specifications use this term to refer to locally available entities performing a media capture (Section 2.1.2) transformation.4.9. RtcMediaStream
A WebRTC RtcMediaStream is a set of media sources (Section 2.1.4) sharing the same synchronization context (Section 3.1).4.10. RtcMediaStreamTrack
A WebRTC RtcMediaStreamTrack is a media source (Section 2.1.4).4.11. RTP Receiver
RTP [RFC3550] uses this term, which can be seen as the RTP protocol part of a media depacketizer (Section 2.1.27).4.12. RTP Sender
RTP [RFC3550] uses this term, which can be seen as the RTP protocol part of a media packetizer (Section 2.1.9).4.13. RTP Session
Within the context of SDP, a singe "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 such as BUNDLE [SDP-BUNDLE], for example, which allows mapping of multiple "m=" lines to a single RTP session.4.14. Single-Session Transmission (SST)
One of two transmission modes defined in H.264-based SVC [RFC6190], the other mode 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, in that it sometimes refers to the use of a single RTP stream, like in sections relating to packetization, and sometimes appears to refer to use of a single RTP session, like in the context of discussing SDP. Closely corresponds to SRST (Section 3.7) defined in this document.
4.15. SSRC
RTP [RFC3550] defines this as "the source of a stream of RTP packets", which indicates that an SSRC is not only a unique identifier for the encoded stream (Section 2.1.7) carried in those packets but is also effectively used as a term to denote a media packetizer (Section 2.1.9). In [RFC3550], it is stated that "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 effectively also changes what media encoder (Section 2.1.6) is used for the encoded stream. No ambiguity is 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].5. Security Considerations
The purpose of this document is to make clarifications and reduce the confusion prevalent in RTP taxonomy because of inconsistent usage by multiple technologies and protocols making use of the RTP protocol. It does not introduce any new security considerations beyond those already well documented in the RTP protocol [RFC3550] and each of the many respective specifications of the various protocols making use of it. Having a well-defined common terminology and understanding of the complexities of the RTP architecture will help lead us to better standards, avoiding security problems.6. Informative References
[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>.
[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>. [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
This document has many concepts borrowed from several documents such as WebRTC [WEBRTC-OVERVIEW], CLUE [CLUE-FRAME], and Multiplexing Architecture [TRANSPORT-MULTIPLEX]. The authors would like to thank all the authors of each of those documents. The authors would also like to acknowledge the insights, guidance, and contributions of Magnus Westerlund, Roni Even, Paul Kyzivat, Colin Perkins, Keith Drage, Harald Alvestrand, Alex Eleftheriadis, Mo Zanaty, Stephan Wenger, and Bernard Aboba.Contributors
Magnus Westerlund has contributed the concept model for the media chain using transformations and streams model, including rewriting pre-existing concepts into this model and adding missing concepts. The first proposal for updating the relationships and the topologies based on this concept was also performed by Magnus.
Authors' Addresses
Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 United States Email: jonathan@vidyo.com Kevin Gross AVA Networks, LLC Boulder, CO United States Email: kevin.gross@avanw.com Suhas Nandakumar Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States Email: snandaku@cisco.com Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States Email: gsalguei@cisco.com Bo Burman (editor) Ericsson Kistavagen 25 SE-16480 Stockholm Sweden Email: bo.burman@ericsson.com