Network Working Group                                          J. Lennox
Internet-Draft                                                     Vidyo
Intended status: Informational                                  K. Gross
Expires: August 18, December 29, 2014                                           AVA
                                                           S. Nandakumar
                                                            G. Salgueiro
                                                           Cisco Systems
                                                               B. Burman
                                                                Ericsson
                                                       February 14,
                                                           June 27, 2014

A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport
                         Protocol (RTP) Sources
               draft-ietf-avtext-rtp-grouping-taxonomy-01
               draft-ietf-avtext-rtp-grouping-taxonomy-02

Abstract

   The terminology about, and associations among, Real-Time Transport
   Protocol (RTP) sources can be complex and somewhat opaque.  This
   document describes a number of existing and proposed relationships
   among RTP sources, and attempts to define common terminology for
   discussing protocol entities and their relationships.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 18, December 29, 2014.

Copyright Notice

   Copyright (c) 2014 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) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3   4
   2.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Media Chain . . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.1.  Physical Stimulus . . . . . . . . . . . . . . . . . .   8
       2.1.2.  Media Capture . . . . . . . . . . . . . . . . . . . .   8
       2.1.3.  Raw Stream  . . . . . . . . . . . . . . . . . . . . .   8
       2.1.4.  Media Source  . . . . . . . . . . . . . . . . . . . .   9   8
       2.1.5.  Source Stream . . . . . . . . . . . . . . . . . . . .  10   9
       2.1.6.  Media Encoder . . . . . . . . . . . . . . . . . . . .  10   9
       2.1.7.  Encoded Stream  . . . . . . . . . . . . . . . . . . .  11  10
       2.1.8.  Dependent Stream  . . . . . . . . . . . . . . . . . .  11
       2.1.9.  Media Packetizer  . . . . . . . . . . . . . . . . . .  12  11
       2.1.10. Packet RTP Stream  . . . . . . . . . . . . . . . . . . . .  12 .  11
       2.1.11. Media Redundancy  . . . . . . . . . . . . . . . . . .  13  12
       2.1.12. Redundancy Packet RTP Stream . . . . . . . . . . . . . .  14 . .  12
       2.1.13. Media Transport . . . . . . . . . . . . . . . . . . .  14  13
       2.1.14. Media Transport Sender  . . . . . . . . . . . . . . .  14
       2.1.15. Sent RTP Stream . . . . . . . . . . . . . . . . . . .  14
       2.1.16. Network Transport . . . . . . . . . . . . . . . . . .  14
       2.1.17. Transported RTP Stream  . . . . . . . . . . . . . . .  14
       2.1.18. Media Transport Receiver  . . . . . . . . . . . . . .  14
       2.1.19. Received Packet RTP Stream . . . . . . . . . . . . . . .  16
       2.1.15. . .  15
       2.1.20. Received Redundandy Packet Redundancy RTP Stream  . . . . . . . . . .  16
       2.1.16. .  15
       2.1.21. Media Repair  . . . . . . . . . . . . . . . . . . . .  16
       2.1.17.  15
       2.1.22. Repaired Packet RTP Stream . . . . . . . . . . . . . . .  17
       2.1.18. . .  15
       2.1.23. Media Depacketizer  . . . . . . . . . . . . . . . . .  17
       2.1.19.  15
       2.1.24. Received Encoded Stream . . . . . . . . . . . . . . .  17
       2.1.20.  16
       2.1.25. Media Decoder . . . . . . . . . . . . . . . . . . . .  17
       2.1.21.  16
       2.1.26. Received Source Stream  . . . . . . . . . . . . . . .  18
       2.1.22.  16
       2.1.27. Media Sink  . . . . . . . . . . . . . . . . . . . . .  18
       2.1.23.  16
       2.1.28. Received Raw Stream . . . . . . . . . . . . . . . . .  18
       2.1.24.  17
       2.1.29. Media Render  . . . . . . . . . . . . . . . . . . . .  18  17
     2.2.  Communication Entities  . . . . . . . . . . . . . . . . .  19  17
       2.2.1.  End Point . . . . . . . . . . . . . . . . . . . . . .  19  18
       2.2.2.  RTP Session . . . . . . . . . . . . . . . . . . . . .  19  18
       2.2.3.  Participant . . . . . . . . . . . . . . . . . . . . .  20  19
       2.2.4.  Multimedia Session  . . . . . . . . . . . . . . . . .  20
       2.2.5.  Communication Session . . . . . . . . . . . . . . . .  21  20

   3.  Relations at Different Levels . . . . . . . . . . . . . . . .  22  21
     3.1.  Media Source Relations  Synchronization Context . . . . . . . . . . . . . . . . .  22
       3.1.1.  Synchronization Context .  RTCP CNAME  . . . . . . . . . . . . . .  22
       3.1.2.  End Point . . . . . . .  22
       3.1.2.  Clock Source Signaling  . . . . . . . . . . . . . . .  23  22
       3.1.3.  Participant  Implicitly via RtcMediaStream . . . . . . . . . . . .  22
       3.1.4.  Explicitly via SDP Mechanisms . . . . . . . . .  24
       3.1.4.  WebRTC MediaStream . . .  22
     3.2.  End Point . . . . . . . . . . . . . .  24
     3.2.  Packetization Time Relations . . . . . . . . . .  22
     3.3.  Participant . . . .  24
       3.2.1.  Single and Multi-Session Transmission of SVC . . . .  24
       3.2.2.  Multi-Channel Audio . . . . . . . . . . . . . . .  23
     3.4.  RtcMediaStream  . .  25
       3.2.3.  Redundancy Format . . . . . . . . . . . . . . . . . .  25
     3.3.  Packet Stream Relations .  23
     3.5.  Single- and Multi-Session Transmission of SVC . . . . . .  23
     3.6.  Multi-Channel Audio . . . . . . . . . . . . . . . . . .  26
       3.3.1. .  24
     3.7.  Simulcast . . . . . . . . . . . . . . . . . . . . . .  27
       3.3.2. . .  24
     3.8.  Layered Multi-Stream  . . . . . . . . . . . . . . . . . .  25
     3.9.  RTP Stream Duplication  . . . . . . . . . . . . . . . . .  27
     3.10. Redundancy Format . . . . . . . . . . . . . . . . . . . .  27
     3.11. RTP Retransmission  . . . . . . . . . . . . . . . . . . .  28
       3.3.3.  Robustness and Repair
     3.12. Forward Error Correction  . . . . . . . . . . . . . . . .  29
       3.3.4.  Packet
     3.13. RTP Stream Separation . . . . . . . . . . . . . .  32
     3.4. . . . .  31
     3.14. Multiple RTP Sessions over one Media Transport  . . . . .  33  32
   4.  Topologies and Communication Entities  Mapping from Existing Terms . . . . . . . . . . . .  33 . . . . .  32
     4.1.  Point-to-Point Communication  Audio Capture . . . . . . . . . . . . . .  33 . . . . . . . .  32
     4.2.  Centralized Conferencing  Capture Device  . . . . . . . . . . . . . . . .  34 . . . . .  32
     4.3.  Full Mesh Conferencing  Capture Encoding  . . . . . . . . . . . . . . . . . .  37 . .  32
     4.4.  Source-Specific Multicast  Capture Scene . . . . . . . . . . . . . . . .  39
   5.  Security Considerations . . . . . .  33
     4.5.  Endpoint  . . . . . . . . . . . . .  41
   6.  Acknowledgement . . . . . . . . . . .  33
     4.6.  Individual Encoding . . . . . . . . . . . .  41
   7.  Contributors . . . . . . .  33
     4.7.  Multipoint Control Unit (MCU) . . . . . . . . . . . . . .  33
     4.8.  Media Capture . . .  41
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . .  33
     4.9.  Media Consumer  . .  41
   9.  References . . . . . . . . . . . . . . . . . . .  33
     4.10. Media Description . . . . . .  41
     9.1.  Normative References . . . . . . . . . . . . . .  33
     4.11. Media Provider  . . . .  42
     9.2.  Informative References . . . . . . . . . . . . . . . . .  42
   Appendix A.  Changes From Earlier Versions  34
     4.12. Media Stream  . . . . . . . . . . .  44
     A.1.  Modifications Between WG Version -00 and -03 . . . . . .  44
     A.2.  Modifications Between Version -02 and -03 . . . . .  34
     4.13. Multimedia Session  . . .  44
     A.3.  Modifications Between Version -01 and -02 . . . . . . . .  44
     A.4.  Modifications Between Version -00 and -01 . . . . . . . .  44
   Authors' Addresses  34
     4.14. Recording Device  . . . . . . . . . . . . . . . . . . . .  34
     4.15. RtcMediaStream  . . .  44

1.  Introduction

   The existing taxonomy of sources in RTP is often regarded as
   confusing and inconsistent.  Consequently, a deep understanding of
   how the different terms relate to each other becomes a real
   challenge.  Frequently cited examples of this confusion are (1) how
   different protocols that make use of RTP use the same terms to
   signify different things and (2) how the complexities addressed at
   one layer are often glossed over or ignored at another.

   This document attempts to provide some clarity by reviewing the
   semantics of various aspects of sources in RTP.  As an organizing
   mechanism, it approaches this by describing various ways that . . . . . . . . . . . . . . . . . .  34
     4.16. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . .  35
     4.17. RTP
   sources can be grouped and associated together.

   All non-specific references to ControLling mUltiple streams for
   tElepresence (CLUE) in this document map to [I-D.ietf-clue-framework]
   and all references to Web Real-Time Communications (WebRTC) map to
   [I-D.ietf-rtcweb-overview].

2.  Concepts

   This section defines concepts that serve to identify and name various
   transformations and streams in a given Sender  . . . . . . . . . . . . . . . . . . . . . . .  35
     4.18. RTP usage.  For each concept
   an attempt is made to list any alternate definitions and usages that
   co-exist today along with various characteristics that further
   describes the concept.  These concepts are divided into two
   categories, one related to the chain of streams and transformations
   that media can be subject to, the other for entities involved in the
   communication.

2.1.  Media Chain

   In the context of this memo, Media is a sequence of synthetic or
   Physical Stimulus (Section 2.1.1) (sound waves, photons, key-
   strokes), represented in digital form.  Synthesized Media is
   typically generated directly in the digital domain.

   This section contains the concepts that can be involved in taking
   Media at a sender side and transporting it to a receiver, which may
   recover a sequence of physical stimulus.  This chain of concepts is
   of two main types, streams and transformations.  Streams are time-
   based sequences of samples of the physical stimulus in various
   representations, while transformations changes the representation of
   the streams in some way.

   The below examples are basic ones and it is important to keep in mind
   that this conceptual model enables more complex usages.  Some will be
   further discussed in later sections of this document.  In general the
   following applies to this model:

   o  A transformation may have zero or more inputs and one or more
      outputs.

   o  A Stream is of some type.

   o  A Stream has one source transformation and one or more sink
      transformation (with the exception of Physical Stimulus
      (Section 2.1.1) that can have no source or sink transformation).

   o  Streams can be forwarded from a transformation output to any
      number of inputs on other transformations that support that type.

   o  If the output of a transformation is sent to multiple
      transformations, those streams will be identical; it takes a
      transformation to make them different.

   o  There are no formal limitations on how streams are connected to
      transformations, this may include loops if required by a
      particular transformation.

   It is also important to remember that this is a conceptual model.
   Thus real-world implementations may look different and have different
   structure.

   To provide a basic understanding of the relationships in the chain we
   below first introduce the concepts for the sender side (Figure 1).
   This covers physical stimulus 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  | | |  Media Redundancy  |
   +--------------------+ | +--------------------+
             |            |           |
             +------------+ Redundancy Packet Stream
      Source Packet Stream            |
             V                        V
   +--------------------+   +--------------------+
   |  Media Transport   |   |  Media Transport   |
   +--------------------+   +--------------------+

             Figure 1: Sender Side Concepts in the Media Chain

   In Figure 1 we have included a branched chain to cover the concepts
   for using redundancy to improve the reliability of the transport.
   The Media Transport concept is an aggregate that is decomposed below
   in Section 2.1.13.

   Below we review a receiver media chain (Figure 2) matching the sender
   side to look at the inverse transformations and their attempts to
   recover possibly identical streams as in the sender chain.  Note that
   the streams out of a reverse transformation, like the Source Stream
   out the Media Decoder are in many cases not the same as the
   corresponding ones on the sender side, thus they are prefixed with a
   "Received" to denote a potentially modified version.  The reason for
   not being the same lies in the transformations that can be of
   irreversible type.  For example, lossy source coding in the Media
   Encoder prevents the Source Stream out of the Media Decoder to be the
   same as the one fed into the Media Encoder.  Other reasons include
   packet loss or late loss in the Media Transport transformation that
   even Media Repair, if used, fails to repair.  It should be noted that
   some transformations are not always present, like Media Repair that
   cannot operate without Redundancy Packet Streams.

   +--------------------+   +--------------------+
   |  Media Transport   |   |  Media Transport   |
   +--------------------+   +--------------------+
             |                        |
   Received Packet Stream   Received Redundancy PS
             |                        |
             |    +-------------------+
             V    V
   +--------------------+
   |    Media Repair    |
   +--------------------+
             |
   Repaired Packet Stream
             V
   +--------------------+
   | Media Depacketizer |
   +--------------------+
             |
   Received Encoded Stream
             V
   +--------------------+
   |   Media Decoder    |
   +--------------------+
             |
   Received Source Stream
             V
   +--------------------+
   |     Media Sink     |--> Synchronization Information
   +--------------------+
             |
   Received Raw Stream
             V
   +--------------------+
   |   Media Renderer   |
   +--------------------+
             |
             V
     Physical Stimulus

            Figure 2: Receiver Side Concepts of the Media Chain

2.1.1.  Physical Stimulus

   The physical stimulus is a physical event that can be measured and
   converted to digital form by an appropriate sensor or transducer.
   This include sound waves making up audio, photons in a light field
   that is visible, 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 Physical Stimulus
   (Section 2.1.1) into digital Media using an appropriate sensor or
   transducer.  The Media Capture performs a digital sampling of the
   physical stimulus, usually periodically, and outputs this in some
   representation as a Raw Stream (Section 2.1.3).  This data is due to
   its periodical sampling, or at least being timed asynchronous events,
   some form of a stream of media data.  The Media Capture is normally
   instantiated in some type of device, i.e. media capture device.
   Examples of different types of media capturing devices are digital
   cameras, microphones connected to A/D converters, or keyboards.

   Alternate usages:

   o  The CLUE WG uses the term "Capture Device" to identify a physical
      capture device.

   o  WebRTC WG uses the term "Recording Device" to refer to the locally
      available capture devices in an end-system.

   Characteristics:

   o  A Media Capture is identified either by hardware/manufacturer ID
      or via a session-scoped device identifier as mandated by the
      application usage.

   o  A Media Capture can generate an Encoded Stream (Section 2.1.7) if
      the capture device support such a configuration.

2.1.3.  Raw Stream

   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 contain synthesized Media that may not require
   any explicit Media Capture, since it is already in an appropriate
   digital form.

2.1.4.  Media Source

   A Media Source is the logical source of a reference clock
   synchronized, time progressing, digital media stream, called a Source
   Stream (Section 2.1.5).  This transformation takes one or more Raw
   Streams (Section 2.1.3) and provides a Source Stream as output.  This
   output has been synchronized with some reference clock, even if just
   a system local wall clock.

   The output can be of different types.  One type is directly
   associated with a particular Media Capture's Raw Stream.  Others are
   more conceptual sources, like an audio mix of multiple Raw Streams
   (Figure 3), a mixed selection of the three loudest inputs regarding
   speech activity, a selection of a particular video based on the
   current speaker, i.e. typically based on other Media Sources.

      Raw       Raw       Raw
     Stream    Stream    Stream
       |         |         |
       V         V         V
   +--------------------------+
   |        Media Source      |<-- Reference Clock
   |           Mixer          |
   +--------------------------+
                 |
                 V
           Source Stream

         Figure 3: Conceptual Media Source in form of Audio Mixer

   The CLUE WG uses the term "Media Capture" for this purpose.  A CLUE
   Media Capture is identified via indexed notation.  The terms Audio
   Capture and Video Capture are used to identify Audio Sources and
   Video Sources respectively.  Concepts such as "Capture Scene",
   "Capture Scene Entry" and "Capture" provide a flexible framework to
   represent media captured spanning spatial regions.

   The WebRTC WG defines the term "RtcMediaStreamTrack" to refer to a
   Media Source.  An "RtcMediaStreamTrack" is identified by the ID
   attribute.

   Typically a Media Source is mapped to a single m=line via the Session
   Description Protocol (SDP) [RFC4566] unless mechanisms such as
   Source-Specific attributes are in place [RFC5576].  In the latter
   cases, an m=line can represent either multiple Media Sources,
   multiple Packet Streams (Section 2.1.10), or both.

   Characteristics:

   o  At any point, it can represent a physical captured source or
      conceptual source.

2.1.5.  Source Stream

   A time progressing stream of digital samples that has been
   synchronized with a reference clock and comes from particular Media
   Source (Section 2.1.4).

2.1.6.  Media Encoder

   A Media Encoder is a transform that is responsible for encoding the
   media data from a Source Stream (Section 2.1.5) into another
   representation, usually more compact, that is output as an Encoded
   Stream (Section 2.1.7).

   The Media Encoder step commonly includes pre-encoding
   transformations, such as scaling, resampling etc.  The Media Encoder
   can have a significant number of configuration options that affects
   the properties of the encoded stream.  This include properties such
   as bit-rate, start points for decoding, resolution, bandwidth or
   other fidelity affecting properties.  The actually used codec is also
   an important factor in many communication systems, not only its
   parameters.

   Scalable Media Encoders need special mentioning as they produce
   multiple outputs that are potentially of different types.  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 and one or more Dependent
   Streams (Section 2.1.8) that requires at least one Encoded Stream and
   zero or more Dependent Streams to be possible to decode.  A Dependent
   Stream's dependency is one of the grouping relations this document
   discusses further in Section 3.3.2.

          Source Stream
                |
                V
   +--------------------------+
   |  Scalable Media Encoder  |
   +--------------------------+
      |         |   ...    |
      V         V          V
   Encoded  Dependent  Dependent
   Stream    Stream     Stream

            Figure 4: Scalable Media Encoder Input and Outputs

   There are also other variants of encoders, like so-called Multiple
   Description Coding (MDC).  Such Media Encoder produce multiple
   independent and thus individually decodable Encoded Streams that are
   possible to combine into a Received Source Stream that is somehow a
   better representation of the original Source Stream than using only a
   single Encoded Stream.

   Alternate usages:

   o  Within the SDP usage, an SDP media description (m=line) describes
      part of the necessary configuration required for encoding
      purposes.

   o  CLUE's "Capture Encoding" provides specific encoding configuration
      for this purpose.

   Characteristics:

   o  A Media Source can be multiply encoded by different Media Encoders
      to provide various encoded representations.

2.1.7.  Encoded Stream

   A stream of time synchronized encoded media that can be independently
   decoded.

   Characteristics:

   o  Due to temporal dependencies, an Encoded Stream may have
      limitations in where decoding can be started.  These entry points,
      for example Intra frames from a video encoder, may require
      identification 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 are
   dependent on one or more Encoded Streams (Section 2.1.7) and zero or
   more Dependent Streams to be possible to decode.

   Characteristics:

   o  Each Dependent Stream has a set of dependencies.  These
      dependencies must be understood by the parties in a multi-media
      session that intend to use a Dependent Stream.

2.1.9.  Media Packetizer

   The transformation of taking one or more Encoded (Section 2.1.7) or
   Dependent Stream (Section 2.1.8) and put their content into one or
   more sequences of packets, normally RTP packets, and output Source
   Packet Streams (Section 2.1.10).  This step includes both generating
   RTP payloads as well as RTP packets.

   The Media Packetizer can use multiple inputs when producing a single
   Packet Stream.  One such example is SST packetization when using SVC
   (Section 3.2.1).

   The Media Packetizer can also produce multiple Packet Streams, for
   example when Encoded and/or Dependent Streams are distributed over
   multiple Packet Streams.  One example of this is MST packetization
   when using SVC (Section 3.2.1).

   Alternate usages:

   o  An RTP sender is part of the Media Packetizer.

   Characteristics:

   o  The Media Packetizer will select which Synchronization source(s)
      (SSRC) [RFC3550] in which RTP sessions that are used.

   o  Media Packetizer can combine multiple Encoded or Dependent Streams
      into one or more Packet Streams.

2.1.10.  Packet Stream

   A stream of RTP packets containing media data, source or redundant.
   The Packet 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 Packet Stream is a packet stream containing at least some
   content from an Encoded Stream.  Source material is any media
   material that is produced for transport over RTP without any
   additional redundancy applied to cope with network transport losses.
   Compare this with the Redundancy Packet Stream (Section 2.1.12).

   Alternate usages:

   o  The term "Stream" is used by the CLUE WG to define an encoded
      Media Source sent via RTP.  "Capture Encoding", "Encoding Groups"
      are defined to capture specific details of the encoding scheme.

   o  RFC3550 [RFC3550] uses the terms media stream, audio stream, video
      stream and streams of (RTP) packets interchangeably.  It defines
      the SSRC as the "The source of a stream of RTP packets, ...".

   o  The equivalent mapping of a Packet Stream in SDP [RFC4566] is
      defined per usage.  For example, each Media Description (m=line)
      and associated attributes can describe one Packet Stream OR
      properties for multiple Packet Streams OR for an RTP session (via
      [RFC5576] mechanisms for example).

   Characteristics:

   o  Each Packet Stream is identified by a unique Synchronization
      source (SSRC) [RFC3550] that is carried in every RTP and RTP
      Control Protocol (RTCP) packet header in a specific RTP session
      context.

   o  At any given point in time, a Packet Stream can have one and only
      one SSRC.  SSRC collision is a valid reason to change SSRC for a
      Packet Stream, since the Packet Stream itself is not changed in
      any way, only the identifying SSRC number.

   o  Each Packet Stream defines a unique RTP sequence numbering and
      timing space.

   o  Several Packet Streams may map to a single Media Source via the
      source transformations.

   o  Several Packet Streams can be carried over a single RTP Session.

2.1.11.  Media Redundancy

   Media redundancy is a transformation that generates redundant or
   repair packets sent out as a Redundancy Packet Stream to mitigate
   network transport impairments, like packet loss and delay.

   The Media Redundancy exists in many flavors; they may be generating
   independent Repair Streams that are used in addition to the Source
   Stream (RTP Retransmission [RFC4588] and some FEC [RFC5109]), they
   may generate a new Source Stream by combining redundancy information
   with source information (Using XOR FEC [RFC5109] as a redundancy
   payload [RFC2198]), or completely replace the source information with
   only redundancy packets.

2.1.12.  Redundancy Packet Stream

   A Packet Stream (Section 2.1.10) that contains no original source
   data, only redundant data that may be combined with one or more
   Received Packet Stream (Section 2.1.14) to produce Repaired Packet
   Streams (Section 2.1.17).

2.1.13.  Media Transport

   A Media Transport defines the transformation that the Packet Streams
   (Section 2.1.10) are subjected to by the end-to-end transport from
   one RTP sender to one specific RTP receiver (an RTP session may
   contain multiple RTP receivers per sender).  Each Media Transport is
   defined by a transport association that is identified by a 5-tuple
   (source address, source port, destination address, destination port,
   transport protocol).  Each transport association normally contains
   only a single RTP session, although a proposal exists for sending
   multiple RTP sessions over one transport association
   [I-D.westerlund-avtcore-transport-multiplexing].

   Characteristics:

   o  Media Transport transmits Packet Streams of RTP Packets from a
      source transport address to a destination transport address.

   The Media Transport concept sometimes needs to be decomposed into
   more steps to enable discussion of what a sender emits that gets
   transformed by the network before it is received by the receiver.
   Thus we provide also this Media Transport decomposition (Figure 5).

         Packet Stream
                |
                V
   +--------------------------+
   |  Media Transport Sender  |
   +--------------------------+
                |
         Sent Packet Stream
                V
   +--------------------------+
   |    Network Transport     |
   +--------------------------+
                |
    Transported Packet Stream
                V
   +--------------------------+
   | Media Transport Receiver |
   +--------------------------+
                |
                V
       Received Packet Stream

                Figure 5: Decomposition of Media Transport

2.1.13.1.  Media Transport Sender

   The first transformation within the Media Transport (Section 2.1.13)
   is the Media Transport Sender, where the sending End-Point
   (Section 2.2.1) takes a Packet Stream and emits the packets onto the
   network using the transport association established for this Media
   Transport thus creating a Sent Packet Stream (Section 2.1.13.2).  In
   this process it transforms the Packet Stream in several ways.  First,
   it gains the necessary protocol headers for the transport
   association, for example IP and UDP headers, thus forming IP/UDP/RTP
   packets.  In addition, the Media Transport Sender may queue, pace or
   otherwise affect how the packets are emitted onto the network.  Thus
   adding delay, jitter and inter packet spacings that characterize the
   Sent Packet Stream.

2.1.13.2.  Sent Packet Stream

   The Sent Packet Stream is the Packet Stream as entering the first hop
   of the network path to its destination.  The Sent Packet Session . . . . . . . . . . . . . . . . . . . . . . .  35
     4.19. SSRC  . . . . . . . . . . . . . . . . . . . . . . . . . .  35
     4.20. Stream is
   identified using network transport addresses, like for IP/UDP the
   5-tuple (source IP address, source port, destination IP address,
   destination port,  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     4.21. Video Capture . . . . . . . . . . . . . . . . . . . . . .  35
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  35
   6.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  36
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  36
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  36
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  36
   Appendix A.  Changes From Earlier Versions  . . . . . . . . . . .  38
     A.1.  Modifications Between WG Version -01 and -02  . . . . . .  38
     A.2.  Modifications Between WG Version -00 and protocol (UDP)).

2.1.13.3.  Network Transport

   Network Transport is the transformation that the Sent Packet Stream
   (Section 2.1.13.2) is subjected to by traveling from the source to
   the destination through the network.  These transformations include,
   loss of some packets, varying delay on a per packet basis, packet
   duplication, -01  . . . . . .  39
     A.3.  Modifications Between Version -02 and packet header or data corruption.  These
   transformations produces a Transported Packet Stream
   (Section 2.1.13.4) at the exit of the network path.

2.1.13.4.  Transported Packet Stream

   The Packet Stream that is emitted out of the network path at the
   destination, subjected to the Network Transport's transformation
   (Section 2.1.13.3).

2.1.13.5.  Media Transport Receiver

   The receiver End-Point's (Section 2.2.1) transformation of the
   Transported Packet Stream (Section 2.1.13.4) by its reception process
   that result in the Received Packet Stream (Section 2.1.14).  This
   transformation includes transport checksums being verified -03 . . . . . . . .  40
     A.4.  Modifications Between Version -01 and if
   non-matching, causing discarding of the corrupted packet.  Other
   transformations can include delay variations in receiving a packet on
   the network interface -02 . . . . . . . .  40
     A.5.  Modifications Between Version -00 and providing it to the application.

2.1.14.  Received Packet Stream

   The Packet Stream (Section 2.1.10) resulting from the Media
   Transport's transformation, i.e. subjected to packet loss, packet
   corruption, packet duplication -01 . . . . . . . .  40
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40

1.  Introduction

   The existing taxonomy of sources in RTP is often regarded as
   confusing and varying transmission delay from
   sender inconsistent.  Consequently, a deep understanding of
   how the different terms relate to receiver.

2.1.15.  Received Redundandy Packet Stream

   The Redundancy Packet Stream (Section 2.1.12) resulting from each other becomes a real
   challenge.  Frequently cited examples of this confusion are (1) how
   different protocols that make use of RTP use the
   Media Transport's transformation, i.e. subjected same terms to packet loss,
   packet corruption,
   signify different things and varying transmission delay from sender to
   receiver.

2.1.16.  Media Repair

   A Transformation that takes as input (2) how the complexities addressed at
   one layer are often glossed over or more Source Packet
   Streams (Section 2.1.10) as well as Redundancy Packet Streams
   (Section 2.1.12) and ignored at another.

   This document attempts to combine them to counter the
   transformations introduced provide some clarity by reviewing the Media Transport (Section 2.1.13) to
   minimize the difference between the Source Stream (Section 2.1.5)
   semantics of various aspects of sources in RTP.  As an organizing
   mechanism, it approaches this by describing various ways that RTP
   sources can be grouped and
   the Received Source Stream (Section 2.1.21) after Media Decoder
   (Section 2.1.20).  The output is a Repaired Packet Stream
   (Section 2.1.17).

2.1.17.  Repaired Packet Stream

   A Received Packet Stream (Section 2.1.14) associated together.

   All non-specific references to ControLling mUltiple streams for which Received
   Redundancy Packet Stream (Section 2.1.15) information has been used
   tElepresence (CLUE) in this document map to try [I-D.ietf-clue-framework]
   and all references to Web Real-Time Communications (WebRTC) map to
   [I-D.ietf-rtcweb-overview].

2.  Concepts

   This section defines concepts that serve to identify and name various
   transformations and streams in a given RTP usage.  For each concept
   an attempt is made to re-create list any alternate definitions and usages that
   co-exist today along with various characteristics that further
   describes the Packet Stream (Section 2.1.10) as it was
   before Media Transport (Section 2.1.13).

2.1.18.  Media Depacketizer

   A Media Depacketizer takes concept.  These concepts are divided into two
   categories, one or more Packet Streams
   (Section 2.1.10) and depacketizes them and attempts related to reconstitute the Encoded Streams (Section 2.1.7) or Dependent Streams
   (Section 2.1.8) present in those Packet Streams.

   It should be noted chain of streams and transformations
   that media can be subject to, the other for entities involved in practical implementations, the
   communication.

2.1.  Media
   Depacketizer and Chain

   In the context of this memo, Media Decoder may be tightly coupled and share
   information to improve is a sequence of synthetic or optimize the overall decoding process
   Physical Stimulus (Section 2.1.1) (sound waves, photons, key-
   strokes), represented in
   various ways.  It digital form.  Synthesized Media is however not expected
   typically generated directly in the digital domain.

   This section contains the concepts that there would can be any
   benefit involved in defining a taxonomy for those detailed (and likely very
   implementation-dependent) steps.

2.1.19.  Received Encoded Stream

   The received version of an Encoded Stream (Section 2.1.7).

2.1.20.  Media Decoder

   A taking
   Media Decoder is at a transformation that is responsible for decoding
   Encoded Streams (Section 2.1.7) sender side and any Dependent Streams
   (Section 2.1.8) into transporting it to a Source Stream (Section 2.1.5).

   It should be noted that receiver, which may
   recover a sequence of physical stimulus.  This chain of concepts is
   of two main types, streams and transformations.  Streams are time-
   based sequences of samples of the physical stimulus in practical implementations, various
   representations, while transformations changes the Media
   Decoder and representation of
   the Media Depacketizer may be tightly coupled streams in some way.

   The below examples are basic ones and share
   information it is important to improve or optimize the overall decoding process keep in
   various ways.  It is however not expected mind
   that there would this conceptual model enables more complex usages.  Some will be any
   benefit
   further discussed in defining a taxonomy for those detailed (and likely very
   implementation-dependent) steps.

   Alternate usages:

   o  Within the context later sections of SDP, an m=line describes this document.  In general the necessary
      configuration and identification (RTP Payload Types) required
   following applies to
      decode either this model:

   o  A transformation may have zero or more inputs and one or more incoming Media Streams.

   Characteristics:
      outputs.

   o  A Media Decoder stream is of some type.

   o  A stream has one source transformation and one or more sink
      transformations (with the entity exception of Physical Stimulus
      (Section 2.1.1) that will have may lack source or sink transformation).

   o  Streams can be forwarded from a transformation output to deal with any
      errors
      number of inputs on other transformations that support that type.

   o  If the output of a transformation is sent to multiple
      transformations, those streams will be identical; it takes a
      transformation to make them different.

   o  There are no formal limitations on how streams are connected to
      transformations, this may include loops if required by a
      particular transformation.

   It is also important to remember that this is a conceptual model.
   Thus real-world implementations may look different and have different
   structure.

   To provide a basic understanding of the relationships in the encoded streams that resulted from corruptions or
      failures to repair packet losses. chain we
   below first introduce the concepts for the sender side (Figure 1).
   This as a covers physical stimulus until media decoder
      generally is forced to produce some output periodically.  It thus
      commonly includes concealment methods.

2.1.21.  Received Source packets are emitted onto
   the network.

                 Physical Stimulus
                        |
                        V
              +--------------------+
              |    Media Capture   |
              +--------------------+
                        |
                   Raw Stream

   The received version of a
                        V
              +--------------------+
              |    Media Source    |<- Synchronization Timing
              +--------------------+
                        |
                  Source Stream (Section 2.1.5).

2.1.22.
                        V
              +--------------------+
              |   Media Sink

   The Encoder    |
              +--------------------+
                        |
                  Encoded Stream     +-----------+
                        V            |           V
              +--------------------+ | +--------------------+
              |  Media Sink receives a Source Packetizer  | | |  Media Redundancy  |
              +--------------------+ | +--------------------+
                        |            |           |
                        +------------+ Redundancy RTP Stream (Section 2.1.5) that
   contains, usually periodically, sampled media data together with
   associated synchronization information.  Depending on application,
   this
                 Source RTP Stream then needs to be transformed into a Raw Stream
   (Section 2.1.3) that is sent               |
                        V                        V
              +--------------------+   +--------------------+
              |  Media Transport   |   |  Media Transport   |
              +--------------------+   +--------------------+

             Figure 1: Sender Side Concepts in synchronization with the output from
   other Media Sinks to Chain

   In Figure 1 we have included a Media Render (Section 2.1.24). branched chain to cover the concepts
   for using redundancy to improve the reliability of the transport.
   The media sink
   may also be connected with a Media Source (Section 2.1.4) Transport concept is an aggregate that is decomposed below
   in Section 2.1.13.

   Below we review a receiver media chain (Figure 2) matching the sender
   side to look at the inverse transformations and be used their attempts to
   recover possibly identical streams as part of a conceptual Media Source.

   Characteristics:

   o  The Media Sink can further transform in the Source Stream into a
      representation sender chain.  Note that is suitable for rendering on the Media Render
      as defined by
   the application or system-wide configuration.  This
      include sample scaling, level adjustments etc.

2.1.23.  Received Raw Stream

   The received version streams out of a Raw reverse transformation, like the Source Stream (Section 2.1.3).

2.1.24.  Media Render

   A
   out the 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 Decoder are screens, D/A converters
   connected to amplifiers and loudspeakers.

   Characteristics:

   o  An End Point can potentially have multiple Media Renders for each
      media type.

2.2.  Communication Entities

   This section contains concept for entities involved in many cases not the
   communication.

2.2.1.  End Point

   A single addressable entity sending or receiving RTP packets.  It may
   be decomposed into several functional blocks, but as long as it
   behaves same as the
   corresponding ones on the sender side, thus they are prefixed with a single RTP stack entity it is classified as
   "Received" to denote a single
   "End Point".

   Alternate usages:

   o potentially modified version.  The CLUE Working Group (WG) uses reason for
   not being the terms "Media Provider" and
      "Media Consumer" to describes aspects of End Point pertaining to
      sending and receiving functionalities.

   Characteristics:

   o  End Points same lies in the transformations that can be identified of
   irreversible type.  For example, lossy source coding in several different ways.  While
      RTCP Canonical Names (CNAMEs) [RFC3550] provide a globally unique
      and stable identification mechanism for the duration Media
   Encoder prevents the Source Stream out of the
      Communication Session (see Section 2.2.5), their validity applies
      exclusively within a Synchronization Context (Section 3.1.1).
      Thus one End Point can have multiple CNAMEs.  Therefore,
      mechanisms outside Media Decoder to be the scope of RTP, such
   same as application defined
      mechanisms, must be used the one fed into the Media Encoder.  Other reasons include
   packet loss or late loss in the Media Transport transformation that
   even Media Repair, if used, fails to ensure End Point identification when
      outside this Synchronization Context.

2.2.2. repair.  It should be noted that
   some transformations are not always present, like Media Repair that
   cannot operate without Redundancy RTP Session

   An Streams.

           +--------------------+   +--------------------+
           |  Media Transport   |   |  Media Transport   |
           +--------------------+   +--------------------+
                     |                        |
            Received RTP session is an association among a group Stream  Received Redundancy RTP Stream
                     |                        |
                     |    +-------------------+
                     V    V
           +--------------------+
           |    Media 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 Renderer   |
           +--------------------+
                     |
                     V
             Physical Stimulus

            Figure 2: Receiver Side Concepts of participants
   communicating with RTP.  It the Media Chain

2.1.1.  Physical Stimulus

   The physical stimulus is a group communications channel which
   can potentially carry a number of Packet Streams.  Within an RTP
   session, every participant physical event that can find meta-data be measured and control information
   (over RTCP) about all the Packet Streams
   converted to digital form by an appropriate sensor or transducer.
   This include sound waves making up audio, photons in a light field
   that is visible, or other excitations or interactions with sensors,
   like keystrokes on a keyboard.

2.1.2.  Media Capture

   Media Capture is the RTP session.  The
   bandwidth process of transforming the RTCP control channel is shared between all
   participants within Physical Stimulus
   (Section 2.1.1) into digital Media using an RTP Session.

   Alternate usages:

   o  Within the context appropriate sensor or
   transducer.  The Media Capture performs a digital sampling of SDP, the
   physical stimulus, usually periodically, and outputs this in some
   representation as a singe m=line can map Raw Stream (Section 2.1.3).  This data is due to a single RTP
      Session
   its periodical sampling, or multiple m=lines can map to at least being timed asynchronous events,
   some form of a single RTP Session. stream of media data.  The
      latter Media Capture is enabled via multiplexing schemes such as BUNDLE
      [I-D.ietf-mmusic-sdp-bundle-negotiation], for example, which
      allows mapping normally
   instantiated in some type of multiple m=lines device, i.e. media capture device.
   Examples of different types of media capturing devices are digital
   cameras, microphones connected to a single RTP Session. A/D converters, or keyboards.

   Characteristics:

   o  Typically, an RTP Session can carry one ore more Packet Streams.

   o  An RTP Session shares  A Media Capture is identified either by hardware/manufacturer ID
      or via a single SSRC space as defined in RFC3550
      [RFC3550].  That is, the End Points participating in an RTP
      Session can see an SSRC session-scoped device identifier transmitted as mandated by any of the other
      End Points.  An End Point
      application usage.

   o  A Media Capture can receive generate an SSRC either as SSRC or as Encoded Stream (Section 2.1.7) if
      the capture device support such a Contributing source (CSRC) in RTP configuration.

2.1.3.  Raw Stream

   The time progressing stream of digitally sampled information, usually
   periodically sampled and RTCP packets, as defined provided by the endpoints' network interconnection topology.

   o  An RTP Session uses at least two a Media Transports Capture (Section 2.1.13), one for sending and one for receiving.
      Commonly, the receiving one 2.1.2).
   A Raw Stream can also contain synthesized Media that may not require
   any explicit Media Capture, since it is already in an appropriate
   digital form.

2.1.4.  Media Source

   A Media Source is the reverse direction logical source of the same a reference clock
   synchronized, time progressing, digital media stream, called a Source
   Stream (Section 2.1.5).  This transformation takes one as used for sending.  An RTP Session may use many Media
      Transports or more Raw
   Streams (Section 2.1.3) and these define the session's network interconnection
      topology.  A single Media Transport provides a Source Stream as output.  This
   output has been synchronized with some reference clock, even if just
   a system local wall clock.

   The output can normally not transport
      more than one RTP Session, unless be of different types.  One type is directly
   associated with a solution for multiplexing particular Media Capture's Raw Stream.  Others are
   more conceptual sources, like an audio mix of multiple RTP sessions over Raw Streams
   (Figure 3), a single mixed selection of the three loudest inputs regarding
   speech activity, a selection of a particular video based on the
   current speaker, i.e. typically based on other Media Sources.

                 Raw       Raw       Raw
                Stream    Stream    Stream
                  |         |         |
                  V         V         V
              +--------------------------+
              |        Media Source      |<-- Reference Clock
              |           Mixer          |
              +--------------------------+
                            |
                            V
                      Source Stream

         Figure 3: Conceptual Media Transport is used.  One
      example Source in form of such a scheme is Multiple RTP Sessions on a Single
      Lower-Layer Transport
      [I-D.westerlund-avtcore-transport-multiplexing]. Audio Mixer

   Characteristics:

   o  Multiple RTP Sessions  At any point, it can be related.

2.2.3.  Participant represent a physical captured source or
      conceptual source.

2.1.5.  Source Stream

   A participant is an entity reachable by time progressing stream of digital samples that has been
   synchronized with a single signaling address, reference clock and comes from particular Media
   Source (Section 2.1.4).

2.1.6.  Media Encoder

   A Media Encoder is thus related more to the signaling context than to a transform that is responsible for encoding the
   media
   context.

   Characteristics:

   o  A single signaling-addressable entity, using an application-
      specific signaling address space, for example data from a SIP URI.

   o  A participant can have several Multimedia Sessions Source Stream (Section 2.2.4).

   o  A participant can have several associated transport flows,
      including several separate local transport addresses for those
      transport flows.

2.2.4.  Multimedia Session

   A multimedia session 2.1.5) into another
   representation, usually more compact, that is output as an association among Encoded
   Stream (Section 2.1.7).

   The Media Encoder step commonly includes pre-encoding
   transformations, such as scaling, resampling etc.  The Media Encoder
   can have a group significant number of participants
   engaged in configuration options that affects
   the communication via one properties of the encoded stream.  This include properties such
   as bit-rate, start points for decoding, resolution, bandwidth or more RTP Sessions
   (Section 2.2.2).  It defines logical relationships among Media
   Sources (Section 2.1.4) that appear
   other fidelity affecting properties.  The actually used codec is also
   an important factor in multiple RTP Sessions.

   Alternate usages:

   o  RFC4566 [RFC4566] defines a multimedia session many communication systems, not only its
   parameters.

   Scalable Media Encoders need special mentioning as a set they produce
   multiple outputs that are potentially of
      multimedia senders and receivers different types.  A scalable
   Media Encoder takes one input Source Stream and the data streams flowing from
      senders to receivers.

   o  RFC3550 [RFC3550] defines encodes it as set of concurrent RTP sessions
      among a common group into
   multiple output streams of participants.  For example, a video
      conference (which two different types; at least one Encoded
   Stream that is a multimedia session) may contain an audio
      RTP session independently decodable and a video RTP session.

   Characteristics:

   o  A Multimedia Session can be composed of several parallel RTP
      Sessions with potentially multiple Packet one or more Dependent
   Streams per RTP Session.

   o  Each participant in a Multimedia Session can have a multitude of
      Media Captures (Section 2.1.8) that requires at least one Encoded Stream and Media Rendering devices.

2.2.5.  Communication Session
   zero or more Dependent Streams to be possible to decode.  A Communication Session Dependent
   Stream's dependency is an association among group one of participants
   communicating with each the grouping relations this document
   discusses further in Section 3.8.

                              Source Stream
                                    |
                                    V
                       +--------------------------+
                       |  Scalable Media Encoder  |
                       +--------------------------+
                          |         |   ...    |
                          V         V          V
                       Encoded  Dependent  Dependent
                       Stream    Stream     Stream

            Figure 4: Scalable Media Encoder Input and Outputs

   There are also other via a set variants of Multimedia Sessions.

   Alternate usages:

   o  The Session encoders, like so-called Multiple
   Description Protocol (SDP) [RFC4566] defines a
      multimedia session as a set of multimedia senders and receivers Coding (MDC).  Such Media Encoder produce multiple
   independent and the data streams flowing from senders thus individually decodable Encoded Streams that are
   possible to receivers.  In combine into a Received Source Stream that
      definition it is however not clear if somehow a multimedia session
      includes both the sender's and the receiver's view
   better representation of the same RTP
      Packet original Source Stream than using only a
   single Encoded Stream.

   Characteristics:

   o  Each participant in a Communication Session is identified via an
      application-specific signaling address.

   o  A Communication Session is composed of at least one Multimedia
      Session per participant, involving one or more parallel RTP
      Sessions with potentially multiple Packet Streams per RTP Session.

   For example, in a full mesh communication, the Communication Session
   consists of a set of separate Multimedia Sessions between each pair
   of Participants.  Another example is a centralized conference, where
   the Communication Session consists of a set of Multimedia Sessions
   between each Participant and the conference handler.

3.  Relations at Different Levels

   This section uses the concepts from previous section and look at Media Source can be multiply encoded by different types Media Encoders
      to provide various encoded representations.

2.1.7.  Encoded Stream

   A stream of relationships among them.  These relationships
   occur at different levels and for different purposes.  The section is
   organized such as time synchronized encoded media that can be independently
   decoded.

   Characteristics:

   o  Due to look at the level where a relation is required.
   The reason for the relationship temporal dependencies, an Encoded Stream may exist at another step in the
   media handling chain.  For example, using Simulcast (discussed have
      limitations in
   Section 3.3.1) needs where decoding can be started.  These entry points,
      for example Intra frames from a video encoder, may require
      identification and their generation may be event based or
      configured to determine relations at Packet occur periodically.

2.1.8.  Dependent Stream level,
   however the reason to relate Packet Streams is

   A stream of time synchronized encoded media fragments that multiple Media
   Encoders use the same Media Source, i.e. are
   dependent on one or more Encoded Streams (Section 2.1.7) and zero or
   more Dependent Streams to be able possible to identify decode.

   Characteristics:

   o  Each Dependent Stream has a
   common Media Source.

3.1.  Media Source Relations set of dependencies.  These
      dependencies must be understood by the parties in a multi-media
      session that intend to use a Dependent Stream.

2.1.9.  Media Sources Packetizer

   The transformation of taking one or more Encoded (Section 2.1.4) are commonly grouped and related to an
   End Point 2.1.7) or
   Dependent Stream (Section 2.2.1) 2.1.8) and put their content into one or a Participant
   more sequences of packets, normally RTP packets, and output Source
   RTP Streams (Section 2.2.3). 2.1.10).  This
   occurs for several reasons; step includes both application logic generating RTP
   payloads as well as media
   handling purposes.  These cases are further discussed below.

3.1.1.  Synchronization Context

   A Synchronization Context defines a requirement on a strong timing
   relationship between the RTP packets.

   The Media Sources, typically requiring alignment
   of clock sources.  Such relationship Packetizer can be identified in use multiple
   ways as listed below.  A inputs when producing a single
   RTP Stream.  One such example is SST packetization when using SVC
   (Section 3.5).

   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 MST packetization when
   using SVC (Section 3.5).

   Characteristics:

   o  The Media Source can only belong to a
   single Packetizer will select which Synchronization Context, since it is assumed source(s)
      (SSRC) [RFC3550] in which RTP sessions that a single are used.

   o  Media Source Packetizer can only have a single media clock and requiring
   alignment to several Synchronization Contexts (and thus reference
   clocks) will effectively merge those combine multiple Encoded or Dependent Streams
      into a single Synchronization
   Context.

   A single Multimedia Session can contain media from one or more
   Synchronization Contexts.  An example RTP Streams.

2.1.10.  RTP Stream

   A stream of that RTP packets containing media data, source or redundant.
   The RTP Stream is identified by an SSRC belonging to a Multimedia Session particular RTP
   session.  The RTP session is identified as discussed in
   Section 2.2.2.

   A Source RTP Stream is a RTP Stream containing one set of audio and video at least some content
   from an Encoded Stream.  Source material is any media material that
   is produced for communication purposes
   belonging transport over RTP without any additional redundancy
   applied to one Synchronization Context, and another set of audio
   and video for presentation purposes (like playing a video file) cope with network transport losses.  Compare this with the
   Redundancy RTP Stream (Section 2.1.12).

   Characteristics:

   o  Each RTP Stream is identified by a separate unique Synchronization Context source
      (SSRC) [RFC3550] that has no strong timing
   relationship and need not be strictly synchronized with the audio is carried in every RTP and
   video used for communication.

3.1.1.1.  RTCP CNAME

   RFC3550 [RFC3550] describes Inter-media synchronization between RTP
   Sessions based on RTCP CNAME, Control
      Protocol (RTCP) packet header in a specific RTP session context.

   o  At any given point in time, a RTP Stream can have one and Network Time Protocol (NTP)
   [RFC5905] formatted timestamps only one
      SSRC.  SSRC collision and clock rate change [RFC7160] are examples
      of valid reasons to change SSRC for a reference clock.  As indicated in
   [I-D.ietf-avtcore-clksrc], despite using NTP format timestamps, it RTP Stream, since the RTP
      Stream itself is not required that changed in any significant way, only the clock be synchronized to an NTP source.

3.1.1.2.  Clock Source Signaling

   [I-D.ietf-avtcore-clksrc] provides
      identifying SSRC number.

   o  Each RTP Stream defines a mechanism unique RTP sequence numbering and timing
      space.

   o  Several RTP Streams may map to signal a single Media Source via the clock
      source in SDP both for the reference clock as well transformations.

   o  Several RTP Streams can be carried over a single RTP Session.

2.1.11.  Media Redundancy

   Media redundancy is a transformation that generates redundant or
   repair packets sent out as the media
   clock, thus allowing a Synchronization Context Redundancy RTP Stream to mitigate
   network transport impairments, like packet loss and delay.

   The Media Redundancy exists in many flavors; they may be defined beyond generating
   independent Repair Streams that are used in addition to the one defined Source
   Stream (RTP Retransmission [RFC4588] and some FEC [RFC5109]), they
   may generate a new Source Stream by combining redundancy information
   with source information (Using XOR FEC [RFC5109] as a redundancy
   payload [RFC2198]), or completely replace the usage of CNAME source descriptions.

3.1.1.3.  CLUE Scenes

   In CLUE "Capture Scene", "Capture Scene Entry" and "Captures" define
   an implied Synchronization Context.

3.1.1.4.  Implicitly via RtcMediaStream

   The WebRTC WG defines "RtcMediaStream" information with
   only redundancy packets.

2.1.12.  Redundancy RTP Stream

   A RTP Stream (Section 2.1.10) that contains no original source data,
   only redundant data that may be combined with one or more
   "RtcMediaStreamTracks".  All tracks in a "RtcMediaStream" are
   intended to be possible Received
   RTP Stream (Section 2.1.19) to synchronize when rendered.

3.1.1.5.  Explicitly via SDP Mechanisms

   RFC5888 [RFC5888] produce Repaired RTP Streams
   (Section 2.1.22).

2.1.13.  Media Transport

   A Media Transport defines m=line grouping mechanism called "Lip
   Synchronization (LS)" for establishing the synchronization
   requirement across m=lines when they map transformation that the RTP Streams
   (Section 2.1.10) are subjected to individual sources.

   RFC5576 [RFC5576] extends by the above mechanism when end-to-end transport from
   one RTP sender to one specific RTP receiver (an RTP session may
   contain multiple media
   sources are described RTP receivers per sender).  Each Media Transport is
   defined by a transport association that is identified by a 5-tuple
   (source address, source port, destination address, destination port,
   transport protocol).  Each transport association normally contains
   only a single m=line.

3.1.2.  End Point

   Some applications requires knowledge RTP session, although a proposal exists for sending
   multiple RTP sessions over one transport association
   [I-D.westerlund-avtcore-transport-multiplexing].

   Characteristics:

   o  Media Transport transmits RTP Streams of RTP Packets from a source
      transport address to a destination transport address.

   The Media Transport concept sometimes needs to be decomposed into
   more steps to enable discussion of what a sender emits that gets
   transformed by the network before it is received by the receiver.
   Thus we provide also this Media Transport decomposition (Figure 5).

                             RTP Stream
                                    |
                                    V
                       +--------------------------+
                       |  Media Transport Sender  |
                       +--------------------------+
                                    |
                             Sent RTP Stream
                                    V
                       +--------------------------+
                       |    Network Transport     |
                       +--------------------------+
                                    |
                        Transported RTP Stream
                                    V
                       +--------------------------+
                       | Media Transport Receiver |
                       +--------------------------+
                                    |
                                    V
                           Received RTP Stream

                Figure 5: Decomposition of what Media Sources originate
   from a particular End Point Transport

2.1.14.  Media Transport Sender

   The first transformation within the Media Transport (Section 2.2.1).  This can include such
   decisions as packet routing between parts of 2.1.13)
   is the topology, knowing Media Transport Sender, where the End Point origin of sending End-Point
   (Section 2.2.1) takes a RTP Stream and emits the Packet Streams. packets onto the
   network using the transport association established for this Media
   Transport thus creating a Sent RTP Stream (Section 2.1.15).  In RTP, this identification has been overloaded with
   process it transforms the
   Synchronization Context through RTP Stream in several ways.  First, it
   gains the usage of necessary protocol headers for the source description
   CNAME item.  This works transport association,
   for some usages, but sometimes it breaks
   down.  For example, if an End Point has two sets of example IP and UDP headers, thus forming IP/UDP/RTP packets.  In
   addition, the Media Sources
   that have different Synchronization Contexts, like Transport Sender may queue, pace or otherwise
   affect how the audio packets are emitted onto the network.  Thus adding
   delay, jitter and
   video of inter packet spacings that characterize the human participant as well Sent
   RTP Stream.

2.1.15.  Sent RTP Stream

   The Sent RTP Stream is the RTP Stream as a set of Media Sources entering the first hop of
   audio and video for a shared movie.  Thus, an End Point may have
   multiple CNAMEs.
   the network path to its destination.  The CNAMEs or Sent RTP Stream is
   identified using network transport addresses, like for IP/UDP the
   5-tuple (source IP address, source port, destination IP address,
   destination port, and protocol (UDP)).

2.1.16.  Network Transport

   Network Transport is the Media Sources themselves can be
   related to transformation that the End Point.

3.1.3.  Participant

   In communication scenarios, it Sent RTP Stream
   (Section 2.1.15) is commonly needed subjected to know which Media
   Sources that originate by traveling from which Participant (Section 2.2.3).  Thus
   enabling the application source to for example display Participant Identity
   information correctly associated with the Media Sources.  This
   association is currently handled
   destination through the signaling solution to
   point at a specific Multimedia Session where the Media Sources may be
   explicitly or implicitly tied to a particular End Point.

   Participant information becomes more problematic due to Media Sources
   that are generated through mixing or other conceptual processing of
   Raw Streams or Source Streams that originate from different
   Participants.  This type network.  These transformations include, loss
   of Media Sources can thus have a dynamically some packets, varying set of origins delay on a per packet basis, packet
   duplication, and Participants. packet header or data corruption.  These
   transformations produces a Transported RTP contains the concept of
   Contributing Sources (CSRC) that carries such information about Stream (Section 2.1.17) at
   the
   previous step origin exit of the included media content on network path.

2.1.17.  Transported RTP level.

3.1.4.  WebRTC MediaStream

   An RtcMediaStream, in addition to requiring a single Synchronization
   Context as discussed above, Stream

   The RTP Stream that is also an explicit grouping of a set emitted out of
   Media Sources, as identified by RtcMediaStreamTracks, within the
   RtcMediaStream.

3.2.  Packetization Time Relations

   At RTP Packetization time, there exists a possibility for a number of
   different types of relationships between Encoded Streams network path at the
   destination, subjected to the Network Transport's transformation
   (Section 2.1.7), Dependent Streams 2.1.16).

2.1.18.  Media Transport Receiver

   The receiver End-Point's (Section 2.1.8) and Packet Streams 2.2.1) transformation of the
   Transported RTP Stream (Section 2.1.10).  These are caused 2.1.17) by grouping together or
   distributing these different types of streams into Packet Streams. its reception process that
   result in the Received RTP Stream (Section 2.1.19).  This section will look at such relationships.

3.2.1.  Single
   transformation includes transport checksums being verified and Multi-Session Transmission if
   non-matching, causing discarding of SVC

   Scalable Video Coding [RFC6190] has the corrupted packet.  Other
   transformations can include delay variations in receiving a mode of operation called Single
   Session Transmission (SST), where Encoded Streams packet on
   the network interface and Dependent
   Streams providing it to the application.

2.1.19.  Received RTP Stream

   The RTP Stream (Section 2.1.10) resulting from the SVC Media Encoder are sent in a single Transport's
   transformation, i.e. subjected to packet loss, packet corruption,
   packet duplication and varying transmission delay from sender to
   receiver.

2.1.20.  Received Redundancy RTP Session Stream

   The Redundancy RTP Stream (Section 2.2.2) using 2.1.12) resulting from the SVC RTP Payload format.  There is another
   mode of operation where Encoded Streams Media
   Transport transformation, i.e. subjected to packet loss, packet
   corruption, and Dependent Streams are
   distributed across multiple RTP Sessions, called Multi-Session
   Transmission (MST).  Regardless if used with SST or MST, varying transmission delay from sender to receiver.

2.1.21.  Media Repair

   A Transformation that takes as they are
   defined, each of those RTP Sessions may contain input one or more Packet
   Streams (SSRC) per Media Source.

   To elaborate, what could be called SST-SingleStream (SST-SS) uses a
   single Packet Stream in a single Source RTP Session to send all Encoded and
   Dependent Streams.  Similarly, SST-MultiStream (SST-MS) uses multiple
   Packet Streams in a single
   (Section 2.1.10) as well as Redundancy RTP Session Streams (Section 2.1.12)
   and attempts to send combine them to counter the Encoded and
   Dependent Streams.  MST-SS uses a single Packet transformations
   introduced by the Media Transport (Section 2.1.13) to minimize the
   difference between the Source Stream in each of
   multiple RTP Sessions (Section 2.1.5) and MST-MS uses multiple Packet Streams in each
   of the multiple Received
   Source Stream (Section 2.1.26) after Media Decoder (Section 2.1.25).
   The output is a Repaired RTP Sessions:

   +-----------------------+--------------------+----------------------+
   |                       | Single Stream (Section 2.1.22).

2.1.22.  Repaired RTP Session | Multiple Stream

   A Received RTP         |
   |                       |                    | Sessions             |
   +-----------------------+--------------------+----------------------+
   | Single Packet Stream  | SST-SS             | MST-SS               |
   | Multiple Packet       | SST-MS             | MST-MS               |
   | Streams               |                    |                      |
   +-----------------------+--------------------+----------------------+

3.2.2.  Multi-Channel Audio

   There exist a number of (Section 2.1.19) for which Received Redundancy
   RTP payload formats that can carry multi-
   channel audio, despite Stream (Section 2.1.20) information has been used to try to re-
   create the codec being a mono encoder.  Multi-channel
   audio can be viewed RTP Stream (Section 2.1.10) as multiple it was before Media Sources sharing a common
   Synchronization Context.  These are independently encoded by a
   Transport (Section 2.1.13).

2.1.23.  Media
   Encoder Depacketizer

   A Media Depacketizer takes one or more RTP Streams (Section 2.1.10)
   and depacketizes them and attempts to reconstitute the different Encoded
   Streams are then packetized
   together in a time synchronized way into a single Source Packet
   Stream using the used codec's RTP Payload format.  Example of such
   codecs are, PCMA and PCMU [RFC3551], AMR [RFC4867], and G.719
   [RFC5404].

3.2.3.  Redundancy Format

   The RTP Payload for Redundant Audio Data [RFC2198] defines how one
   can transport redundant audio data together with primary data (Section 2.1.7) or Dependent Streams (Section 2.1.8) present
   in the
   same those RTP payload.  The redundant data can Streams.

   It should be a time delayed version
   of noted that in practical implementations, the primary or another time delayed Encoded Stream using a
   different Media Encoder to encode
   Depacketizer and the same Media Source as Decoder may be tightly coupled and share
   information to improve or optimize the
   primary, as depicted below overall decoding process in Figure 6.

   +--------------------+
   |    Media Source    |
   +--------------------+
             |
        Source
   various ways.  It is however not expected that there would be any
   benefit in defining a taxonomy for those detailed (and likely very
   implementation-dependent) steps.

2.1.24.  Received Encoded Stream
             |
             +------------------------+
             |                        |
             V                        V
   +--------------------+   +--------------------+
   |   Media Encoder    |   |   Media Encoder    |
   +--------------------+   +--------------------+
             |                        |
             |                 +------------+

   The received version of an Encoded Stream          | Time Delay |
             |                 +------------+
             |                        |
             |     +------------------+
             V     V
   +--------------------+
   | (Section 2.1.7).

2.1.25.  Media Packetizer  |
   +--------------------+
             |
             V
      Packet Stream

   Figure 6: Concept for usage of Audio Redundancy with different Decoder

   A Media
                                 Encoders

   The Redundancy format Decoder is thus providing a transformation that is 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).

   It should be noted that in practical implementations, the necessary meta Media
   Decoder and the Media Depacketizer may be tightly coupled and share
   information to correctly relate different parts of the same Encoded
   Stream, improve or optimize the overall decoding process in
   various ways.  It is however not expected that there would be any
   benefit in defining a taxonomy for those detailed (and likely very
   implementation-dependent) steps.

   Characteristics:

   o  A Media Decoder is the case depicted above (Figure 6) relate entity that will have to deal with any
      errors in the encoded streams that resulted from corruptions or
      failures to repair packet losses.  This as a media decoder
      generally is forced to produce some output periodically.  It thus
      commonly includes concealment methods.

2.1.26.  Received Source Stream fragments coming out

   The received version of different Media Decoders to be
   able to combine them together into a less erroneous Source Stream.

3.3.  Packet Stream Relations

   This section discusses various cases of relationships among Packet
   Streams.  This is (Section 2.1.5).

2.1.27.  Media Sink

   The Media Sink receives a common relation to handle in RTP due to Source Stream (Section 2.1.5) that
   Packet Streams are separate and have their own SSRC, implying
   independent sequence numbers and timestamp spaces.  The underlying
   reasons for the Packet
   contains, usually periodically, sampled media data together with
   associated synchronization information.  Depending on application,
   this Source Stream relationships are different, as can then needs to be
   seen transformed into a Raw Stream
   (Section 2.1.3) that is sent in synchronization with the cases below. output from
   other Media Sinks to a Media Render (Section 2.1.29).  The different Packet Streams can media sink
   may also be handled
   within the same RTP Session or different RTP Sessions to accomplish
   different transport goals.  This separation of Packet Streams is
   further discussed in Section 3.3.4.

3.3.1.  Simulcast

   A connected with a Media Source represented (Section 2.1.4) and be used
   as multiple independent Encoded Streams
   constitutes a simulcast part of that a conceptual Media Source.  Figure 7 below
   represents an example of a

   Characteristics:

   o  The Media Sink can further transform the Source Stream into a
      representation that is encoded into three
   separate and different Simulcast streams, that are in turn sent is suitable for rendering on the same Media Transport flow.  When using Simulcast, Render
      as defined by the Packet
   Streams may be sharing RTP Session and Media Transport, or be
   separated on different RTP Sessions and Media Transports, application or be any
   combination system-wide configuration.  This
      include sample scaling, level adjustments etc.

2.1.28.  Received Raw Stream

   The received version of these two.  It is other considerations a Raw Stream (Section 2.1.3).

2.1.29.  Media Render

   A Media Render takes a Raw Stream (Section 2.1.3) and converts it
   into Physical Stimulus (Section 2.1.1) that affect
   which usage is desirable, as discussed a human user can
   perceive.  Examples of such devices are screens, D/A converters
   connected to amplifiers and loudspeakers.

   Characteristics:

   o  An End Point can potentially have multiple Media Renders for each
      media type.

2.2.  Communication Entities

   This section contains concept for entities involved in Section 3.3.4. the
   communication.

       +----------------------------------------------------------+
       | Communication Session                                    |
       |                                                          |
       | +----------------+                    +----------------+ |  Media Source
       |
                            +----------------+
                     Source Stream |
             +----------------------+----------------------+ Participant A  |   +------------+   | Participant B  | |
       | |                |   | Multimedia |   |                | |
       | | +-------------+|<=>| Session    |<=>|+-------------+ | |
       | | | End Point A ||   |            |   || End Point B | | |
       | | |             ||   +------------+   ||             | | |
       | | | +-----------++--------------------++-----------+ | | |
       | | | | RTP Session|                    |            | | | |
       | | | | Audio      |--Media Transport-->|            | | | |
       | | | |            |<--Media Transport--|            | | | |
       | | | +-----------++--------------------++-----------+ | | |
       | | |             ||                    ||             | | |
       | | | +-----------++--------------------++-----------+ | | |
       |
             v                      v                      v
    +------------------+   +------------------+   +------------------+ |  Media Encoder | |  Media Encoder RTP Session|                    |            |  Media Encoder |
    +------------------+   +------------------+   +------------------+ | Encoded | Encoded
       | Encoded | Stream | Stream | Stream
             v                      v                      v
    +------------------+   +------------------+   +------------------+ Video      |--Media Transport-->|            | Media Packetizer | | Media Packetizer |
       | Media Packetizer |
    +------------------+   +------------------+   +------------------+ | Source | Source            |<--Media Transport--|            | Source | Packet | Packet | Packet
       | Stream | Stream | Stream
             +-----------------+ +-----------++--------------------++-----------+ |    +-----------------+ | |
       |
                               V    V    V
                          +-------------------+ |  Media Transport +-------------+|                    |+-------------+ |
                          +-------------------+ |
       | +----------------+                    +----------------+ |
       +----------------------------------------------------------+

    Figure 7: 6: Example Point to Point Communication Session with two RTP
                                 Sessions

   The figure above shows a high-level example representation of a very
   basic point-to-point Communication Session between Participants A and
   B.  It uses two different audio and video RTP Sessions between A's
   and B's End Points, using separate Media Transports for those RTP
   Sessions.  The Multimedia Session shared by the participants can for
   example be established using SIP (i.e., there is a SIP Dialog between
   A and B).  The terms used in that figure are further elaborated in
   the sub-sections below.

2.2.1.  End Point

      Editor's note: Consider if a single word, "Endpoint", is
      preferable

   A single addressable entity sending or receiving RTP packets.  It may
   be decomposed into several functional blocks, but as long as it
   behaves as a single RTP stack entity it is classified as a single
   "End Point".

   Characteristics:

   o  End Points can be identified in several different ways.  While
      RTCP Canonical Names (CNAMEs) [RFC3550] provide a globally unique
      and stable identification mechanism for the duration of the
      Communication Session (see Section 2.2.5), their validity applies
      exclusively within a Synchronization Context (Section 3.1).  Thus
      one End Point can handle multiple CNAMEs, each of which can be
      shared among a set of Media Source Simulcast

   The simulcast relation between End Points belonging to the Packet Streams is same Participant
      (Section 2.2.3).  Therefore, mechanisms outside the common Media
   Source.  In addition, scope of RTP,
      such as application defined mechanisms, must be used to ensure End
      Point identification when outside this Synchronization Context.

   o  An End Point can be able associated with at most one Participant
      (Section 2.2.3) at any single point in time.

   o  In some contexts, an End Point would typically correspond to identify the common Media Source, a receiver of the Packet Stream may need to know which configuration
      single "host".

2.2.2.  RTP Session

      Editor's note: Re-consider if this is really a Communication
      Entity, or encoding goals that lay behind the produced Encoded Stream and its
   properties.  This to enable selection of the stream that if it is most
   useful in the application at rather an existing concept that moment.

3.3.2.  Layered Multi-Stream

   Layered Multi-Stream (LMS) should be
      described in Section 4.

   An RTP session is an association among a mechanism by which different portions group of participants
   communicating with RTP.  It is a layered encoding of group communications channel which
   can potentially carry a Source Stream are sent using separate
   Packet number of RTP Streams.  Within an RTP
   session, every participant can find meta-data and control information
   (over RTCP) about all the RTP Streams (sometimes in separate the RTP Sessions).  LMSs are useful
   for receiver control session.  The
   bandwidth of layered media.

   A Media Source represented the RTCP control channel is shared between all
   participants within an RTP Session.

   Characteristics:

   o  Typically, an RTP Session can carry one ore more RTP Streams.

   o  An RTP Session shares a single SSRC space as defined in RFC3550
      [RFC3550].  That is, the End Points participating in an Encoded Stream and multiple
   Dependent Streams constitutes a Media Source that has layered
   dependencies.  The figure below represents RTP
      Session can see an example SSRC identifier transmitted by any of a Media
   Source that is encoded into three dependent layers, where two layers
   are sent on the same Media Transport using different Packet Streams,
   i.e. SSRCs, other
      End Points.  An End Point can receive an SSRC either as SSRC or as
      a Contributing source (CSRC) in RTP and RTCP packets, as defined
      by the third layer is sent on a separate Media
   Transport, i.e. a different endpoints' network interconnection topology.

   o  An RTP Session.

                            +----------------+
                            |  Media Source  |
                            +----------------+
                                    |
                                    |
                                    V
       +---------------------------------------------------------+
       |                      Media Encoder                      |
       +---------------------------------------------------------+
               |                    |                     |
        Encoded Stream       Dependent Stream     Dependent Stream
               |                    |                     |
               V                    V                     V
       +----------------+   +----------------+   +----------------+
       |Media Packetizer|   |Media Packetizer|   |Media Packetizer|
       +----------------+   +----------------+   +----------------+
               |                    |                     |
         Packet Stream         Packet Stream        Packet Stream
               |                    |                     |
               +------+      +------+                     |
                      |      |                            |
                      V      V                            V
                +-----------------+              +-----------------+
                | Media Transport |              | Media Transport |
                +-----------------+              +-----------------+

           Figure 8: Example of Session uses at least two Media Source Layered Dependency

   As an example, the SVC MST Transports
      (Section 3.2.1) relation needs to identify
   the common Media Encoder origin 2.1.13), one for the Encoded and Dependent
   Streams.  The SVC RTP Payload RFC is not particularly explicit about
   how this relation is to be implemented.  When using different RTP
   Sessions, thus different Media Transports, sending and as long as there one for receiving.
      Commonly, the receiving one is
   only the reverse direction of the same
      one Packet Stream per Media Encoder and a single Media Source in
   each as used for sending.  An RTP Session (MST-SS (Section 3.2.1)), common SSRC may use many Media
      Transports and CNAMEs can
   be used to identify these define the common session's network interconnection
      topology.  A single Media Source.  When multiple Packet
   Streams are sent from Transport can normally not transport
      more than one Media Encoder in the same RTP Session (SST-
   MS), then CNAME Session, unless a solution for multiplexing
      multiple RTP sessions over a single Media Transport is the only currently specified used.  One
      example of such a scheme is Multiple RTP identifier that Sessions on a Single
      Lower-Layer Transport
      [I-D.westerlund-avtcore-transport-multiplexing].

   o  Multiple RTP Sessions can be used.  In cases where multiple Media Encoders use multiple
   Media Sources sharing Synchronization Context, related.

2.2.3.  Participant

   A Participant is an entity reachable by a single signaling address,
   and is thus having a
   common CNAME, additional heuristics need to be applied related more to create the
   MST relationship between signaling context than to the Packet Streams.

3.3.3.  Robustness and Repair

   Packet Streams may be protected by Redundancy Packet Streams during
   transport.  Several approaches listed below media
   context.

   Characteristics:

   o  A single signaling-addressable entity, using an application-
      specific signaling address space, for example a SIP URI.

   o  A Participant can achieve the same
   result; have several Multimedia Sessions
      (Section 2.2.4).

   o  Duplication  A Participant can have several associated End Points
      (Section 2.2.1).

2.2.4.  Multimedia Session

   A multimedia session is an association among a group of participants
   engaged in the original Packet Stream communication via one or more RTP Sessions
   (Section 2.2.2).  It defines logical relationships among Media
   Sources (Section 2.1.4) that appear in multiple RTP Sessions.

   Characteristics:

   o  Duplication  A Multimedia Session can be composed of the original Packet Stream several parallel RTP
      Sessions with a time offset, potentially multiple RTP Streams per RTP Session.

   o  Forward Error Correction (FEC) techniques,  Each participant in a Multimedia Session can have a multitude of
      Media Captures and Media Rendering devices.

   o  Retransmission of lost packets (either globally  A single Multimedia Session can contain media from one or selectively).

3.3.3.1.  RTP Retransmission

   The figure below (Figure 9) represents an more
      Synchronization Contexts (Section 3.1).  An example where a Media
   Source's Source Packet Stream of that is protected by a retransmission (RTX)
   flow [RFC4588].  In this example the Source Packet Stream
      Multimedia Session containing one set of audio and the
   Redundancy Packet Stream share the same Media Transport.

          +--------------------+
          |    Media Source    |
          +--------------------+
                    |
                    V
          +--------------------+
          |   Media Encoder    |
          +--------------------+
                    |                              Retransmission
              Encoded Stream     +--------+     +---- Request
                    V            |        V     V
          +--------------------+ | +--------------------+
          |  Media Packetizer  | | | RTP Retransmission |
          +--------------------+ | +--------------------+
                    |            |           |
                    +------------+  Redundancy Packet Stream
             Source Packet Stream            |
                    |                        |
                    +---------+    +---------+
                              |    |
                              V    V
                       +-----------------+
                       | Media Transport |
                       +-----------------+

          Figure 9: Example video for
      communication purposes belonging to one Synchronization Context,
      and another set of Media Source Retransmission Flows

   The RTP Retransmission example (Figure 9) helps illustrate that this
   mechanism works purely on the Source Packet Stream.  The RTP
   Retransmission transform buffers the sent Source Packet Stream audio and
   upon requests emits video for presentation purposes (like
      playing a retransmitted packet video file) with some extra payload
   header as a Redundancy Packet Stream.  The RTP Retransmission
   mechanism [RFC4588] is specified so separate Synchronization Context that there is a one to one
   relation between the Source Packet Stream
      has no strong timing relationship and the Redundancy Packet
   Stream.  Thus a Redundancy Packet Stream needs to need not be associated strictly
      synchronized with
   its Source Packet Stream upon being received.  This is done based on
   CNAME selectors the audio and heuristics to match requested packets video used for communication.

2.2.5.  Communication Session

   A Communication Session is an association among group of participants
   communicating with each other via a given
   Source Packet Stream set of Multimedia Sessions.

   Characteristics:

   o  Each participant in a Communication Session is identified via an
      application-specific signaling address.

   o  A Communication Session is composed of at least one Multimedia
      Session per participant, involving one or more parallel RTP
      Sessions with the original sequence number potentially multiple RTP Streams per RTP Session.

   For example, in a full mesh communication, the payload Communication Session
   consists of any new Redundancy Packet Stream using the RTX payload format.  In
   cases where the Redundancy Packet Stream is sent in a set of separate RTP Multimedia Sessions between each pair
   of Participants.  Another example is a centralized conference, where
   the Communication Session from consists of a set of Multimedia Sessions
   between each Participant and the Source Packet Stream, these sessions are related,
   e.g. using conference handler.

3.  Relations at Different Levels

   This section uses the SDP Media Grouping's [RFC5888] FID semantics.

3.3.3.2.  Forward Error Correction concepts from previous section and look at
   different types of relationships among them.  These relationships
   occur at different levels and for different purposes.  The figure below (Figure 10) represents an example section is
   organized such as to look at the level where two Media
   Sources' Source Packet Streams are protected by FEC.  Source Packet
   Stream A has a Media Redundancy transformation in FEC Encoder 1.

   This produces a Redundancy Packet Stream 1, that relation is only related required.
   The reason for the relationship may exist at another step in the
   media handling chain.  For example, using Simulcast (discussed in
   Section 3.7) needs to
   Source Packet determine relations at RTP Stream A. The FEC Encoder 2, level,
   however takes two Source
   Packet the reason to relate RTP Streams (A and B) and produces a Redundancy Packet Stream 2 is that protects them together, multiple Media
   Encoders use the same Media Source, i.e. Redundancy Packet Stream 2 relate to two Source Packet Streams (a FEC group).  FEC decoding, when
   needed be able to identify a
   common Media Source.

   Media Sources (Section 2.1.4) are commonly grouped and related to an
   End Point (Section 2.2.1) or a Participant (Section 2.2.3).  This
   occurs for several reasons; both due to packet loss application logic as well as
   for media handling purposes.

   At RTP Packetization time, there exists a possibility for a number of
   different types of relationships between Encoded Streams
   (Section 2.1.7), Dependent Streams (Section 2.1.8) and RTP Streams
   (Section 2.1.10).  These are caused by grouping together or packet corruption at the receiver,
   requires knowledge about which Source Packet
   distributing these different types of streams into RTP Streams.

   The resulting RTP Streams that the FEC
   encoding was based on.

   In Figure 10 all Packet will thus also have relations.  This is a
   common relation to handle in RTP due to that RTP Streams are sent on separate
   and have their own SSRC, implying independent sequence numbers and
   timestamp spaces.  The underlying reasons for the same Media Transport.
   This is however not RTP Stream
   relationships are different, as can be seen in the only possible choice.  Numerous combinations
   exist for spreading these Packet sub-sections
   below.

   RTP Streams over different Media
   Transports may be protected by Redundancy RTP Streams during
   transport.  Several approaches listed below can be used to achieve create
   Redundancy RTP Streams;

   o  Duplication of 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 Packet original RTP Stream A                Source Packet

   o  Duplication of the original RTP Stream B
                 |                                     |
           +-----+-------+-------------+       +-------+------+
           |             V             V       V              |
           |    +---------------+  +---------------+          |
           |    | FEC Encoder 1 |  | FEC Encoder 2 |          |
           |    +---------------+  +---------------+          |
           |             |                 |                  |
           |     Redundancy PS 1    Redundancy PS 2           |
           V             V                 V                  V
       +----------------------------------------------------------+
       |                    Media Transport                       |
       +----------------------------------------------------------+

                      Figure 10: Example with a time offset,

   o  Forward Error Correction (FEC) techniques, and

   o  Retransmission of FEC Flows

   As FEC Encoding exists lost packets (either globally or selectively).

   The different RTP Streams can be transported within the same RTP
   Session or in different RTP Sessions to accomplish different
   transport goals.  This explicit separation of RTP Streams is further
   discussed in various forms, Section 3.13.

3.1.  Synchronization Context

   A Synchronization Context defines a requirement on a strong timing
   relationship between the methods for relating FEC
   Redundancy Packet Streams with its source information Media Sources, typically requiring alignment
   of clock sources.  Such relationship can be identified in multiple
   ways as listed below.  A single Media Source
   Packet Streams are many.  The XOR 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 [RFC3550] describes Inter-media synchronization between RTP
   Sessions based on RTCP CNAME, RTP FEC Payload and Network Time Protocol (NTP)
   [RFC5905] formatted timestamps of a reference clock.  As indicated in
   [I-D.ietf-avtcore-clksrc], despite using NTP format

   [RFC5109] timestamps, it is defined in such a way
   not required that the clock be synchronized to an NTP source.

3.1.2.  Clock Source Signaling

   [I-D.ietf-avtcore-clksrc] provides a Redundancy Packet Stream
   has mechanism to signal the clock
   source in SDP both for the reference clock as well as the media
   clock, thus allowing a one Synchronization Context to be defined beyond
   the one relation defined by the usage of CNAME source descriptions.

3.1.3.  Implicitly via RtcMediaStream

   The WebRTC WG defines "RtcMediaStream" with one or more
   "RtcMediaStreamTracks".  All tracks in a Source Packet Stream.  In fact, the
   RFC requires "RtcMediaStream" are
   intended to be possible to synchronize when rendered.

3.1.4.  Explicitly via SDP Mechanisms

   RFC5888 [RFC5888] defines m=line grouping mechanism called "Lip
   Synchronization (LS)" for establishing the Redundancy Packet Stream synchronization
   requirement across m=lines when they map to use the same SSRC as individual sources.

   RFC5576 [RFC5576] extends the
   Source Packet Stream.  This requires to either use above mechanism when multiple media
   sources are described by a separate RTP
   session or to use the Redundancy RTP Payload format [RFC2198].  The
   underlying relation requirement for this FEC format and single m=line.

3.2.  End Point

   Some applications requires knowledge of what Media Sources originate
   from a particular
   Redundancy Packet Stream is to know the related Source Packet Stream,
   including its SSRC.

3.3.4.  Packet Stream Separation

   Packet Streams End Point (Section 2.2.1).  This can be separated exclusively based on their SSRCs or
   at include such
   decisions as packet routing between parts of the topology, knowing
   the End Point origin of the RTP Session level or at Streams.

   In RTP, this identification has been overloaded with the Multi-Media Session level as
   explained below.

   When
   Synchronization Context (Section 3.1) through the Packet Streams usage of the RTCP
   source description CNAME (Section 3.1.1) item.  This works for some
   usages, but sometimes it breaks down.  For example, if an End Point
   has two sets of Media Sources that have a relationship are all sent in different Synchronization
   Contexts, like the
   same RTP Session audio and are uniquely identified based on their SSRC
   only, it is termed video of the human participant as well
   as a set of Media Sources of audio and video for a shared movie.
   Thus, an SSRC-Only Based Separation.  Such streams can
   be related via RTCP CNAME to identify that End Point may have multiple CNAMEs.  The CNAMEs or the streams belong Media
   Sources themselves can be related to the
   same End Point.  [RFC5576]-based approaches, when used, can
   explicitly relate various such Packet Streams.

   On the other hand, when Packet Streams that are related but are sent
   in the context of different RTP Sessions to achieve separation,

3.3.  Participant

   In communication scenarios, it is
   known as RTP Session-based separation.  This is commonly used when
   the different Packet Streams are intended for different needed to know which Media
   Transports.

   Several mechanisms
   Sources that use RTP Session-based separation rely on it
   to enable an implicit grouping mechanism expressing originate from which Participant (Section 2.2.3).  Thus
   enabling the relationship.
   The solutions have been based on using application to for example display Participant Identity
   information correctly associated with the same SSRC value in Media Sources.  This
   association is currently handled through 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 Grouping
   of solution to
   point at a specific Multimedia Session where the Media lines framework [RFC5888].  Examples of this are RTP
   Retransmission [RFC4588], SVC Multi-Session Transmission [RFC6190]
   and XOR Based FEC [RFC5109].  RTCP CNAME Sources may be
   explicitly relates Packet
   Streams across different RTP Sessions, as explained in the previous
   section.  Such or implicitly tied to a relationship can be used particular End Point.

   Participant information becomes more problematic due to perform inter-media
   synchronization.

   Packet Streams Media Sources
   that are related and need to be associated generated through mixing or other conceptual processing of
   Raw Streams or Source Streams that originate from different
   Participants.  This type of Media Sources can be part thus have a dynamically
   varying set of different Multimedia Sessions, rather than just different origins and Participants.  RTP
   sessions within the same Multimedia Session context.  This puts
   further demand on contains the scope concept of
   Contributing Sources (CSRC) that carries such information about the mechanism(s) and its handling
   previous step origin of
   identifiers used for expressing the relationships.

3.4.  Multiple included media content on RTP Sessions over one Media Transport

   [I-D.westerlund-avtcore-transport-multiplexing] describes level.

3.4.  RtcMediaStream

   An RtcMediaStream in WebRTC is an explicit grouping of a mechanism set of Media
   Sources (RtcMediaStreamTracks) that allow several RTP Sessions to be carried over share a common identifier and a
   single
   underlying Synchronization Context (Section 3.1).

3.5.  Single- and Multi-Session Transmission of SVC

   Scalable Video Coding [RFC6190] has a mode of operation called Single
   Session Transmission (SST), where Encoded Streams and Dependent
   Streams from the SVC Media Transport.  The main reasons for doing this Encoder are
   related to sent in a single RTP Session
   (Section 2.2.2) using the impact SVC RTP Payload format.  There is another
   mode of using operation where Encoded Streams and Dependent Streams are
   distributed across multiple RTP Sessions, called Multi-Session
   Transmission (MST).  SST denotes one or more RTP Streams (SSRC) per
   Media Transports.  Thus
   using Source in a common network path or potentially have different ones.
   There is reduced need for NAT/FW traversal resources and no need for
   flow based QoS.

   However, Multiple single RTP Sessions over Session.  MST denotes one or more RTP
   Streams (SSRC) per Media Transport makes it Source in each of multiple RTP Sessions.
   This is not always clear from the SVC payload format text [RFC6190],
   but is what existing deployments of that RFC have implemented.

   To elaborate, what could be called SST-SingleStream (SST-SS) uses a
   single RTP Stream in a single Media Transport 5-tuple is not sufficient to
   express which RTP Session context to send all Encoded and
   Dependent Streams from a particular Packet single Media Source.  Similarly, SST-
   MultiStream (SST-MS) uses a single RTP Stream exists
   in.  Complexities per Media Source in a
   single RTP Session to send the relationship between Media Transports Encoded and Dependent Streams.  MST-SS
   uses a single RTP Session already exist as one Stream in each of multiple RTP Session contains Sessions, where each
   RTP Stream can originate from any one of possibly multiple Media
   Transports, e.g. even a Peer-to-Peer
   Sources.  Finally, MST-MS uses multiple RTP Session with RTP/RTCP
   Multiplexing requires two Media Transports, one Streams in each direction.
   The relationship between of the
   multiple RTP Sessions, where each RTP Stream can originate from any
   one of possibly multiple Media Transports and Sources.  This is summarized below:

   +--------------------------+------------------+---------------------+
   | RTP Streams per Media    | Single RTP       | Multiple RTP        |
   | Source                   | Session          | Sessions as well as
   additional levels            |
   +--------------------------+------------------+---------------------+
   | Single                   | SST-SS           | MST-SS              |
   | Multiple                 | SST-MS           | MST-MS              |
   +--------------------------+------------------+---------------------+

                        Table 1: SST / MST Summary

3.6.  Multi-Channel Audio

   There exist a number of identifiers need to be considered in both
   signaling design and when defining terminology.

4.  Topologies and Communication Entities

   This section reviews some communication topologies and looks at the
   relationship among the communication entities that are defined in
   Section 2.2.  It does not deal with discussions about the streams and
   their relation to the transport.  Instead, it covers the aspects RTP payload formats that
   enable the transport of those streams.  For example, can carry multi-
   channel audio, despite the codec being a mono encoder.  Multi-channel
   audio can be viewed as multiple Media Sources sharing a common
   Synchronization Context.  These are independently encoded by a Media
   Transports (Section 2.1.13) that exists between
   Encoder and the End Points
   (Section 2.2.1) that different Encoded Streams are part of an then packetized
   together in a time synchronized way into a single Source RTP session (Section 2.2.2) and
   their relationship to Stream
   using the Multi-Media Session (Section 2.2.4) between
   Participants (Section 2.2.3) used codec's RTP Payload format.  Example of such codecs
   are, PCMA and the established Communication
   session (Section 2.2.5) are explained.

   The text provided below is neither any exhaustive listing PCMU [RFC3551], AMR [RFC4867], and G.719 [RFC5404].

3.7.  Simulcast

   A Media Source represented as multiple independent Encoded Streams
   constitutes a simulcast of possible
   topologies, nor does it cover all topologies described in
   [I-D.ietf-avtcore-rtp-topologies-update].

4.1.  Point-to-Point Communication that Media Source.  Figure 11 shows 7 below
   represents an example of a very basic point-to-point communication session
   between A Media Source that is encoded into three
   separate and B. It uses two different audio and video RTP sessions
   between A's and B's end points.  Assume Simulcast streams, that are in turn sent on
   the Multi-media session
   shared by the participants is established using SIP (i.e., there is a
   SIP Dialog between A and B).  The high level representation of this
   communication scenario can be demonstrated using Figure 11.

   +---+         +---+
   | A |<------->| B |
   +---+         +---+

                  Figure 11: Point to Point Communication

   However, this picture gets slightly more complex when redrawn same Media Transport flow.  When using Simulcast, the communication entities concepts defined earlier in this document.

   +-----------------------------------------------------------+
   | Communication RTP Streams
   may be sharing RTP Session                                     |
   |                                                           |
   | +----------------+ and Media Transport, or be separated on
   different RTP Sessions and Media Transports, or be any combination of
   these two.  It is other considerations that affect which usage is
   desirable, as discussed in Section 3.13.

                            +----------------+
                            |  Media Source  |
                            +----------------+
                     Source Stream  | Participant A  |   +-------------+   | Participant B  |
             +----------------------+----------------------+
             |                      |                      |
             V                      V                      V
    +------------------+   +------------------+   +------------------+
    |  Media Encoder   | Multi-Media   |  Media Encoder   |   |  Media Encoder   |
    +------------------+   +------------------+   +------------------+
             | Encoded              | +-------------+|<=>| Session     |<=>|+-------------+ Encoded              | Encoded
             | Stream               | Stream               | Stream
             V                      V                      V
    +------------------+   +------------------+   +------------------+
    | End Point A ||   |(SIP Dialog) Media Packetizer |   || End Point B   | Media Packetizer |   | Media Packetizer |
    +------------------+   +------------------+   +------------------+
             | Source               |             ||   +-------------+   || Source               | Source
             | RTP                  | RTP                  | RTP
             | Stream               | +-----------++---------------------++-----------+ Stream               | Stream
             +-----------------+    |    +-----------------+
                               |    |    |
                               V    V    V
                          +-------------------+
                          |  Media Transport  |
                          +-------------------+

                Figure 7: 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 that lay behind the produced Encoded Stream and its
   properties.  This to enable selection of the stream that is most
   useful in the application at that moment.

3.8.  Layered Multi-Stream

   Layered Multi-Stream (LMS) is a mechanism by which different portions
   of a layered 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.  The figure below 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, i.e. a different RTP Session|                     |            | | | |
   | | | | Audio      |---Media Transport-->|            | | | |
   | | | |            |<--Media Transport---|            | | | |
   | | | +-----------++---------------------++-----------+ | | |
   | Session.

                            +----------------+
                            |  Media Source  |             ||                     ||
                            +----------------+
                                    |
                                    |
                                    V
       +---------------------------------------------------------+
       |                      Media Encoder                      |
       +---------------------------------------------------------+
               |                    | +-----------++---------------------++-----------+                     |
        Encoded Stream       Dependent Stream     Dependent Stream
               |                    |                     |
               V                    V                     V
       +----------------+   +----------------+   +----------------+
       |Media Packetizer|   |Media Packetizer|   |Media Packetizer|
       +----------------+   +----------------+   +----------------+
               |                    |                     |
          RTP Session|                     |            | | | |
   | | | | Video      |---Media Transport-->|            | | | |
   | | | |            |<--Media Transport---|            | | | |
   | Stream           RTP Stream            RTP Stream
               |                    | +-----------++---------------------++-----------+                     |
               +------+      +------+                     |
                      |      |                            | +-------------+|                     |+-------------+
                      V      V                            V
                +-----------------+              +-----------------+
                | Media Transport |              | +----------------+                     +----------------+ Media Transport |
   +-----------------------------------------------------------+

   Figure 12: Point to Point Communication Session with two RTP Sessions
                +-----------------+              +-----------------+

           Figure 12 shows the two RTP Sessions only exist between the two End
   Points A and B and over their respective 8: Example of Media Transports.  The
   Multi-Media Session establishes the association between Source Layered Dependency

   As an example, the two
   Participants and configures these RTP sessions and SVC MST (Section 3.5) relation needs to identify
   the common Media
   Transports that are used.

4.2.  Centralized Conferencing

   This section looks at Encoder origin for the centralized conferencing communication
   topology, where a number of participants, like A, B, C, Encoded and D in
   Figure 13, communicate using an Dependent
   Streams.  The SVC RTP mixer.

   +---+      +------------+      +---+
   | A |<---->|            |<---->| B |
   +---+      |            |      +---+
              |   Mixer    |
   +---+      |            |      +---+
   | C |<---->|            |<---->| D |
   +---+      +------------+      +---+

          Figure 13: Centralized Conferincing Payload RFC is not particularly explicit about
   how this relation is to be implemented.  When using an different RTP
   Sessions, thus different Media Transports, and as long as there is
   only one RTP Mixer

   In this case Stream per Media Encoder and a single Media Source in
   each of the Participants establish their Multi-media
   session with RTP Session (MST-SS (Section 3.5)), common SSRC and CNAMEs can
   be used to identify the Conference Bridge.  Thus, negotiation for common Media Source.  When multiple RTP
   Streams are sent from one Media Encoder in the
   establishment of same RTP Session (SST-
   MS), then CNAME is the used only currently specified RTP sessions identifier that
   can be used.  In cases where multiple Media Encoders use multiple
   Media Sources sharing Synchronization Context, and their configuration
   happens thus having a
   common CNAME, additional heuristics need to be applied to create the
   MST relationship between these entities.  The participants have their End
   Points (A, B, C, D) and the Conference Bridge has RTP Streams.

3.9.  RTP Stream Duplication

   RTP Stream Duplication [RFC7198], using the host running same or different Media
   Transports, and optionally also delaying the RTP mixer, referred duplicate [RFC7197],
   offers a simple way to as End Point M protect media flows from packet loss in Figure 14.  However,
   despite the individual establishment some
   cases.  It is a specific type of four Multi-Media Sessions redundancy and
   the corresponding Media Transports for each of the all but one Source
   RTP sessions
   between the respective End Points Stream (Section 2.1.10) are effectively Redundancy RTP Streams
   (Section 2.1.12), but since both Source and Redundant RTP Streams are
   the Conference Bridge, there same it does not matter which is
   actually only two RTP sessions.  One for audio and one for Video, which.  This can also be seen as
   these RTP sessions are, in this topology, shared between all
   a specific type of Simulcast (Section 3.7) that transmits the
   Participants.

   +-------------------------------------------------------------------+
   | Communication Session                                             |
   |                                                                   |
   | +----------------+                             +----------------+ |
   | | Participant A  |       +-------------+       | Conference     | |
   | |                |       | Multi-Media |       | Bridge same
   Encoded Stream (Section 2.1.7) multiple times.

                            +----------------+
                            |  Media Source  |
                            +----------------+
                     Source Stream  |
                                    V
                            +----------------+
                            | +-------------+|<=====>| Session A   |<=====>|+-------------+ Media Encoder  |
                            +----------------+
                    Encoded Stream  |
                        +-----------+-----------+
                        |                       |
                        V                       V
               +------------------+    +------------------+
               | End Point A ||       |(SIP Dialog) Media Packetizer |       || End Point M    | Media Packetizer |
               +------------------+    +------------------+
                 Source | RTP Stream     Source | RTP Stream
                        |                       V
                        |             ||                +-------------+       ||             | | |
                        |                | | +-----------++-----------------------------++-----------+ Delay (opt) |
                        |                +-------------+
                        |                       |
                        +-----------+-----------+
                                    |
                                    V
                          +-------------------+
                          |  Media Transport  |
                          +-------------------+

                Figure 9: Example of RTP Session|                             |            | | | |
   | | | | Stream Duplication

3.10.  Redundancy Format

   The RTP Payload for Redundant Audio      |-------Media Transport------>|            | | | |
   | | | |            |<------Media Transport-------|            | | | |
   | | | +-----------++-----------------------------++------+    | | Data [RFC2198] defines how one
   can transport 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 below in Figure 10.

              +--------------------+
              |    Media Source    |
              +--------------------+
                        |
                   Source Stream
                        |
                        +------------------------+
                        |             ||                             ||                        |
                        V                        V
              +--------------------+   +--------------------+
              |   Media Encoder    |   |   Media Encoder    |
              +--------------------+   +--------------------+
                        |                        |
                        | +-----------++-----------------------------++----+                 +------------+
                  Encoded Stream          | Time Delay |
                        |                 +------------+
                        |                        |
                        |     +------------------+
                        V     V
              +--------------------+
              |  Media Packetizer  |
              +--------------------+
                        |
                        V
                   RTP Stream

   Figure 10: 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, or in the case depicted above (Figure 10) relate 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.11.  RTP Retransmission

   The figure below (Figure 11) represents an example where a Media
   Source's Source RTP Session|                             |     | |    | | | |
   | | | | Video      |-------Media Transport------>|     | |    | | | |
   | | | |            |<------Media Transport-------|     | |    | | | |
   | | | +-----------++-----------------------------++    | |    | | | |
   | | +-------------+|                             ||    | |    | | | |
   | +----------------+                             ||    | |    | | | |
   |                                                ||    | |    | | | |
   | +----------------+                             ||    | |    | | 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
          +--------------------+
          | Participant B   Media Encoder    |       +-------------+       ||
          +--------------------+
                    |                              Retransmission
              Encoded Stream     +--------+     +---- Request
                    V            |        V     V
          +--------------------+ | +--------------------+
          |  Media Packetizer  | | | RTP Retransmission |
          +--------------------+ | +--------------------+
                    | Multi-Media            |       ||           |
                    +------------+  Redundancy RTP Stream
             Source RTP Stream               |
                    |                        |
                    +---------+    +---------+
                              |    |
                              V    V
                       +-----------------+
                       | Media Transport | +-------------+|<=====>|
                       +-----------------+

          Figure 11: Example of Media Source Retransmission Flows

   The RTP Retransmission example (Figure 11) helps illustrate that this
   mechanism works purely on the Source RTP Stream.  The RTP
   Retransmission transform buffers the sent Source RTP Stream and upon
   requests emits a retransmitted packet with some extra payload header
   as a Redundancy RTP Stream.  The RTP Retransmission mechanism
   [RFC4588] is specified so that there is a one to one relation between
   the Source RTP Stream and the Redundancy RTP Stream.  Thus a
   Redundancy RTP Stream needs to be associated with its Source RTP
   Stream upon being received.  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 separate RTP Session B   |<=====>||    | |    | | | |
   | | | End Point B ||       |(SIP Dialog) |       ||    | |    | | | |
   | | |             ||       +-------------+       ||    | |    | | | |
   | | | +-----------++-----------------------------++    | |    | | | |
   | | | | from the
   Source RTP Session|                             |     | |    | | | |
   | | | | Video      |-------Media Transport------>|     | |    | | | |
   | | | |            |<------Media Transport-------|     | |    | | | |
   | | | +-----------++-----------------------------++----+ |    | | | |
   | Stream, these sessions are related, e.g. using the SDP
   Media Grouping's [RFC5888] FID semantics.

3.12.  Forward Error Correction

   The figure below (Figure 12) represents an example where two Media
   Sources' Source RTP Streams are protected by FEC.  Source RTP Stream
   A has a Media 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 together, i.e.  Redundancy RTP Stream 2 relate 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 12 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 Session|                             |            | | | |
   | | | | Audio      |-------Media Transport------>| Stream A                   Source RTP Stream B
                 |                                     |
           +-----+---------+-------------+         +---+---+
           |               V             V         V       |
           |       +---------------+  +---------------+    |
           |       |            |<------Media Transport-------| FEC Encoder 1 |  | FEC Encoder 2 |    |
           |       +---------------+  +---------------+    |
           | +-----------++-----------------------------++-----------+  Redundancy   |     Redundancy   |            |
           |  RTP Stream 1 | +-------------+|                             |+-------------+     RTP Stream 2 |            |
           V               V                  V            V
       +----------------------------------------------------------+
       | +----------------+                             +----------------+                    Media Transport                       |
   +-------------------------------------------------------------------+
       +----------------------------------------------------------+

                      Figure 14: Centralized Conferencing 12: Example of FEC Flows

   As FEC Encoding exists in various forms, the methods for relating FEC
   Redundancy RTP Streams with Two Participants A and B
                  communicating over a Conference Bridge

   It its source information in Source RTP
   Streams are many.  The XOR based RTP FEC Payload format [RFC5109] is important to stress that
   defined in the case of Figure 14, it might
   appear such a way that a Redundancy RTP Stream has a one to one
   relation with a Source RTP Stream.  In fact, the Multi-Media Sessions context is scoped between A and
   B over M. RFC requires the
   Redundancy RTP Stream to use the same SSRC as the Source RTP Stream.
   This might not be always true and they can have contexts
   that extend further.  In requires to either use a separate RTP session or to use the
   Redundancy RTP Payload format [RFC2198].  The underlying relation
   requirement for this case FEC format and a particular Redundancy RTP
   Stream is to know the related Source RTP session, Stream, including its common SSRC
   space goes beyond what occurs between A and M and B and M
   respectively.

4.3.  Full Mesh Conferencing

   This section looks SSRC.

3.13.  RTP Stream Separation

   RTP Streams can be separated exclusively based on their SSRCs, at the case where
   RTP Session level, or at the three Participants (A, B and
   C) wish to communicate.  They establish individual Multi-Media
   Sessions and RTP sessions between themselves and Session level.

   When the other two peers.
   Thus, each providing two copies of their media to every other
   participant.  Figure 15 shows a high level representation of such RTP Streams that have a
   topology.

   +---+      +---+
   | A |<---->| B |
   +---+      +---+
     ^         ^
      \       /
       \     /
        v   v
        +---+
        | C |
        +---+

   Figure 15: Full Mesh Conferencing with three Participants A, B relationship are all sent in the
   same RTP Session and C

   In this particular case there are two aspects worth noting.  The
   first uniquely identified based on their SSRC
   only, it is there will termed an SSRC-Only Based Separation.  Such streams can
   be multiple Multi-Media Sessions per
   Communication Session between related via RTCP CNAME to identify that the participants.  This, however,
   hasn't been true streams belong to the
   same End Point.  [RFC5576]-based approaches, when used, can
   explicitly relate various such RTP Streams.

   On the other hand, when RTP Streams that are related but are sent in
   the earlier examples; 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
   to enable an implicit grouping mechanism expressing the Centralized
   Conferencing inSection 4.2 being relationship.
   The solutions have been based on using the exception.  The second aspect is
   consideration of whether one needs to maintain relationships between
   entities and concepts, for example Media Sources, between these
   different Multi-Media Sessions and between Packet Streams same SSRC value in the
   independent RTP sessions configured by those Multi-Media Sessions.

                          +-----------------------------------------+
                          | Participant A                           |
      +----------+        | +--------------------------------------+|
      | Multi-   |        | | End Point A                          ||
      | Media    |<======>| |                                      ||
      | Session  |        | |+-------+     +-------+     +-------+ ||
      | 1        |        | ||
   different RTP 1 |<----| MS A1 |---->| Sessions to implicitly indicate their relation.  That
   way, no explicit RTP 2 | ||
      +----------+        | ||       |     +-------+     |       | ||
          ^^              | +|-------|-------------------|-------|-+|
          ||              +--|-------|-------------------|-------|--+
          ||                 |       |          ^^       |       |
          VV                 |       |          ||       |       |
   +-------------------------|-------|----+     ||       |       |
   | Participant B           |       |    |     VV       |       |
   | +-----------------------|-------|---+| +----------+ |       |
   | | End Point B    +----->|       |   || | Multi-   | |       |
   | |                |      +-------+   || | level mechanism has been needed, only signaling
   level relations have been established using semantics from Grouping
   of Media    | |       |
   | | +-------+      |      +-------+   || | Session  | |       |
   | | | MS B1 |------+----->| lines framework [RFC5888].  Examples of this are RTP 3 |   || | 2        | |       |
   | | +-------+             |       |   || +----------+ |       |
   | +-----------------------|-------|---+|     ^^       |       |
   +-------------------------|-------|----+     ||       |       |
          ^^                 |       |          ||       |       |
          ||                 |       |          VV       |       |
          ||              +--|-------|-------------------|-------|--+
          VV              |  |       | Participant C     |       |  |
      +----------+        | +|-------|-------------------|-------|-+|
      | Multi-   |        | ||       | End Point C       |       | ||
      | Media    |<======>| |+-------+                   +-------+ ||
      | Session  |        | |    ^         +-------+         ^     ||
      | 3        |        | |    +---------| MS C1 |---------+     ||
      +----------+        | |              +-------+               ||
                          | +--------------------------------------+|
                          +-----------------------------------------+

   Figure 16: Full Mesh Conferencing between three Participants A, B
   Retransmission [RFC4588], SVC Multi-Session Transmission [RFC6190]
   and
                                     C

   For XOR Based FEC [RFC5109].  RTCP CNAME explicitly relates RTP
   Streams across different RTP Sessions, as explained in the sake of clarity, Figure 16 above does not include all these
   concepts.  The Media Sources (MS) from previous
   section.  Such a given End Point is sent to
   the two peers.  This requires encoding and Media Packetization relationship can be used to
   enable the Packet perform inter-media
   synchronization.

   RTP Streams that are related and need to be sent over Media Transports in the
   context associated can be part of the RTP sessions depicted.  The
   different Multimedia Sessions, rather than just different RTP
   sessions 1, 2, and 3
   are independent, and established in within the context same Multimedia Session context.  This puts
   further demand on the scope of each the mechanism(s) and its handling of
   identifiers used for expressing the Multi- relationships.

3.14.  Multiple RTP Sessions over one Media Transport

   [I-D.westerlund-avtcore-transport-multiplexing] describes a mechanism
   that allow several RTP Sessions 1, 2 and 3. to be carried over a single
   underlying Media Transport.  The joint communication session the full
   figure represents (not shown here as it was Figure 14 in order main reasons for doing this are
   related to
   save space), however, combines the received representations impact of the
   peers' using one or more Media Sources and plays them back.

   It is noteworthy that the full mesh conferencing topologies described
   here Transports.  Thus
   using a common network path or potentially have the potential different ones.
   There is reduced need for creating loops.  For example, if NAT/FW traversal resources and no need for
   flow based QoS.

   However, Multiple RTP Sessions over one
   compares the above full mesh with a mixing three party communication
   session as depicted in (Figure 17).  In this example A's Media Source
   A1 is sent to B over Transport makes it
   clear that a Multi-Media Session (A-B).  In B the Media
   Source A1 is mixed with Media Source B1 and the resulting single Media
   Source (MS AB) Transport 5-tuple is sent not sufficient to C over a Multi-Media
   express which RTP Session (B-C).  If C
   and A would establish context a Multi-Media Session (A-C) and C would act particular RTP Stream exists in.
   Complexities in the same role as B, then A would receive a relationship between Media Source from C that
   contains a mix of A, B Transports and C's individual RTP
   Session already exist as one RTP Session contains multiple Media Sources.  This would
   result in A playing out
   Transports, e.g. even a time delay version of its own signal (i.e.,
   the system has created an echo path).

   +--------------+    +--------------+    +--------------+
   | A            |    | B +-------+  |    | C            |
   |              |    |   | MS B1 |  |    |              |
   |              |    |   +-------+  |    |              |
   | +-------+    |    |     |        |    |              |
   | | MS A1 |----|--->|-----+ MS AB -|--->|              |
   | +-------+    |    |              |    |              |
   +--------------+    +--------------+    +--------------+

            Figure 17: Mixing Three Party Communication Peer-to-Peer RTP Session

   The looping issue can be avoided, detected or prevented using with RTP/RTCP
   Multiplexing requires two
   general methods. Media Transports, one in each direction.
   The first method is relationship between Media Transports and RTP Sessions as well as
   additional levels of identifiers need to use great care when setting
   up be considered in both
   signaling design and establishing the communication session if participants have
   any mixing or forwarding capacity, so that one doesn't end up getting
   back when defining terminology.

4.  Mapping from Existing Terms

   This section describes a partial or full representation selected set of one's own media believing it
   is someone else's. The other method is to maintain terms from some unique
   identifiers at relevant
   IETF RFC and Internet Drafts (at the communication session level for all time of writing), using the
   concepts from previous sections.

4.1.  Audio Capture

   Telepresence specifications from CLUE WG uses this term to describe
   an audio Media Sources
   and ensure that any Packet Streams received Source (Section 2.1.4).

4.2.  Capture Device

   Telepresence specifications from CLUE WG use this term to identify those a
   physical entity performing a Media
   Sources that contributed Capture (Section 2.1.2)
   transformation.

4.3.  Capture Encoding

   Telepresence specifications from CLUE WG uses this term to the content of the Packet Stream. describe
   an Encoded Stream (Section 2.1.7) related to CLUE specific semantic
   information.

4.4.  Source-Specific Multicast

   In one-to-many media distribution cases (e.g., IPTV), where one Media
   Sender or  Capture Scene

   Telepresence specifications from CLUE WG uses this term to describe a
   set of spatially related Media Senders is allowed Sources (Section 2.1.4).

4.5.  Endpoint

   Telepresence specifications from CLUE WG use this term to send Packet Streams on
   a particular Source-Specific Multicast (SSM) group describe
   exactly one Participant (Section 2.2.3) and one or more End Points
   (Section 2.2.1).

4.6.  Individual Encoding

   Telepresence specifications from CLUE WG use this term to many receivers
   (R), there are some different aspects describe
   the configuration information needed to consider.  Figure 18
   presents perform a high level SSM system for RTP/RTCP defined in [RFC5760].
   In this case, several Media Senders sends their Packet Streams to the
   Distribution Source, which Encoder
   (Section 2.1.6) transformation.

4.7.  Multipoint Control Unit (MCU)

   This term is the only one allowed to send commonly used to describe the SSM
   group.  The Receivers joining the SSM group can provide RTCP feedback
   on its reception by sending unicast feedback central node in any type
   of star topology [I-D.ietf-avtcore-rtp-topologies-update] conference.
   It describes a device that includes one Participant (Section 2.2.3)
   (usually corresponding to a Feedback Target
   (FT).

   +--------+       +-----+
   |Media   |       |     |       Source-Specific
   |Sender 1|<----->| D S |       Multicast (SSM)
   +--------+       | I O |  +--+----------------> R(1)
                    | S U |  |  |                    |
   +--------+       | T R |  |  +-----------> R(2)   |
   |Media   |<----->| R C |->+  |           :   |    |
   |Sender 2|       | I E |  |  +------> R(n-1) |    |
   +--------+       | B   |  |  |          |    |    |
       :            | U   |  +--+--> R(n)  |    |    |
       :            | T +-|          |     |    |    |
       :            | I | |<---------+     |    |    |
   +--------+       | O |F|<---------------+    |    |
   |Media   |       | N |T|<--------------------+    |
   |Sender M|<----->|   | |<-------------------------+
   +--------+       +-----+       RTCP Unicast

   FT = Feedback Target

        Figure 18: Source-Specific Multicast Communication Topology

   Here so-called conference focus) and one or
   more related End Points (Section 2.2.1) (sometimes one or more per
   conference participant).

4.8.  Media Capture

   Telepresence specifications from CLUE WG uses this term to describe
   either a Media Capture (Section 2.1.2) or a Media Source
   (Section 2.1.4), depending on in which context the term is used.

4.9.  Media Transport Consumer

   Telepresence specifications from CLUE WG use this term to describe
   the Distribution media receiving part of an End Point (Section 2.2.1).

4.10.  Media Description

   A single Source to Description Protocol (SDP) [RFC4566] media
   description (or media block; an m-line and all subsequent lines until
   the SSM
   receivers (R) have next m-line or the same 5-tuple, but in reality have different
   paths.  Also, end of the Multi-Media Sessions between SDP) describes part of the Distribution
   Source
   necessary configuration and identification information needed for a
   Media Encoder transformation, as well as the individual receivers are normally identical. 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
   due for example an explicit restriction in WebRTC.  However, nothing
   prevents that the same Media Description (and same RTP Session) is
   re-used for multiple Media Sources
   [I-D.ietf-avtcore-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.11.  Media Provider

   Telepresence specifications from CLUE WG use this term to one-way communication describe
   the media sending part of an End Point (Section 2.2.1).

4.12.  Media Stream

   RTP [RFC3550] uses media stream, audio stream, video stream, and
   stream of (RTP) packets interchangeably, which are all RTP Streams.

4.13.  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 End Points and the Distribution Source RTP
   Streams that flow between them.  In this memo, Multimedia Session
   also assumes those End Points belong to the
   receiver a set of configuration information.  This is information typically
   embedded Participants that
   are engaged in Electronic Program Guides (EPGs), distributed by the
   Session Announcement Protocol (SAP) [RFC2974] or other one-way
   protocols.  In some cases load balancing occurs, for example, by
   providing the receiver with communication via a set of Feedback Targets and then it
   randomly selects one out related RTP Streams.

   RTP [RFC3550] defines a multimedia session as a set of the set. 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 scenario varies significantly from previously described
   communication topologies due would correspond to the asymmetric nature a group of the Participants (each using one or
   more End Points) sharing a set of concurrent RTP Sessions.  In this
   memo, Multimedia Session context across the Distribution Source.  The Distribution
   Source forms also defines those RTP Sessions to have some
   relation and be part of a focal point in collecting the unicasted RTCP feedback
   from communication among the receivers and then re-distributing it Participants.

4.14.  Recording Device

   WebRTC specifications use this term to the refer to locally available
   entities performing a Media Senders.
   Each Capture (Section 2.1.2) transformation.

4.15.  RtcMediaStream

   A WebRTC RtcMediaStreamTrack is a set of Media Sender and Sources
   (Section 2.1.4) sharing the Distribution Source establish their own
   Multi-Media Session same Synchronization Context for the underlying
   (Section 3.1).

4.16.  RtcMediaStreamTrack

   A WebRTC RtcMediaStreamTrack is a Media Source (Section 2.1.4).

4.17.  RTP Sessions but with
   shared RTCP context across all the receivers.

   To improve Sender

   RTP [RFC3550] uses this term, which can be seen as the readability,Figure 18 intentionally hides RTP protocol
   part of a Media Packetizer (Section 2.1.9).

4.18.  RTP Session

   Within the details context of SDP, a singe m=line can map to a single RTP
   Session or multiple m=lines can map to a single RTP Session.  The
   latter is enabled via multiplexing schemes such as BUNDLE
   [I-D.ietf-mmusic-sdp-bundle-negotiation], for example, which allows
   mapping of multiple m=lines to a single RTP Session.

      Editor's note: Consider if the various entities . Expanding on this, one can think of Media
   Senders being part contents of one Section 2.2.2 should be
      moved here, or more Multi-Media Sessions grouped under
   a Communication Session.  The Media Sender in if this scenario refers section should be kept and refer to the Media Packetizer transformation Section 2.1.9.  The Packet Stream
   generated by such
      above.

4.19.  SSRC

   RTP [RFC3550] defines this as "the source of a Media Sender can be part stream of its own RTP Session
   or can be multiplexed with other Packet Streams within
   packets", which indicates that an End Point.
   The latter case requires careful consideration since SSRC is not only a unique
   identifier for the re-
   distributed RTCP packets now correspond Encoded Stream (Section 2.1.7) carried in those
   packets, but is also effectively used as a term to denote a single Media
   Packetizer (Section 2.1.9).

4.20.  Stream

   Telepresence specifications from CLUE WG use this term to describe an
   RTP Session
   Context across all the Stream (Section 2.1.10).

4.21.  Video Capture

   Telepresence specifications from CLUE WG uses this term to describe a
   video Media Senders. Source (Section 2.1.4).

5.  Security Considerations

   This document simply tries to clarify 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.

   Hopefully 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.  Acknowledgement

   This document has many concepts borrowed from several documents such
   as WebRTC [I-D.ietf-rtcweb-overview], CLUE [I-D.ietf-clue-framework],
   Multiplexing Architecture
   [I-D.westerlund-avtcore-transport-multiplexing].  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, and Alex Eleftheriadis.

7.  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.

8.  IANA Considerations

   This document makes no request of IANA.

9.  References
9.1.  Normative References

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

9.2.  Informative References

   [I-D.ietf-avtcore-clksrc]
              Williams, A., Gross, K., Brandenburg, R., and H. Stokking,
              "RTP Clock Source Signalling", draft-ietf-avtcore-
              clksrc-09
              clksrc-11 (work in progress), December 2013. March 2014.

   [I-D.ietf-avtcore-rtp-multi-stream]
              Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
              "Sending Multiple Media Streams in a Single RTP Session",
              draft-ietf-avtcore-rtp-multi-stream-04 (work in progress),
              May 2014.

   [I-D.ietf-avtcore-rtp-topologies-update]
              Westerlund, M. and S. Wenger, "RTP Topologies", draft-
              ietf-avtcore-rtp-topologies-update-01
              ietf-avtcore-rtp-topologies-update-02 (work in progress),
              October 2013.
              May 2014.

   [I-D.ietf-clue-framework]
              Duckworth, M., Pepperell, A., and S. Wenger, "Framework
              for Telepresence Multi-Streams", draft-ietf-clue-
              framework-14
              framework-15 (work in progress), February May 2014.

   [I-D.ietf-mmusic-sdp-bundle-negotiation]
              Holmberg, C., Alvestrand, H., and C. Jennings,
              "Multiplexing Negotiation
              "Negotiating Media Multiplexing Using the Session
              Description Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-
              bundle-negotiation-05 (SDP)", draft-ietf-mmusic-sdp-bundle-
              negotiation-07 (work in progress), October 2013. April 2014.

   [I-D.ietf-rtcweb-overview]
              Alvestrand, H., "Overview: Real Time Protocols for Brower-
              based
              Browser-based Applications", draft-ietf-rtcweb-overview-08 draft-ietf-rtcweb-overview-10
              (work in progress), September 2013. June 2014.

   [I-D.westerlund-avtcore-transport-multiplexing]
              Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP
              Sessions onto a Single Lower-Layer Transport", draft-
              westerlund-avtcore-transport-multiplexing-07 (work in
              progress), October 2013.

   [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,
              September 1997.

   [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
              Announcement Protocol", RFC 2974, October 2000.

   [RFC3264]  Rosenberg, J. and H.

   [RFC3550]  Schulzrinne, "An Offer/Answer Model
              with Session Description H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol (SDP)", for Real-Time
              Applications", STD 64, RFC 3264, June
              2002. 3550, July 2003.

   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", STD 65, RFC 3551,
              July 2003.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              July 2006.

   [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, April 2007.

   [RFC5109]  Li, A., "RTP Payload Format for Generic Forward Error
              Correction", RFC 5109, December 2007.

   [RFC5404]  Westerlund, M. and I. Johansson, "RTP Payload Format for
              G.719", RFC 5404, January 2009.

   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
              Media Attributes in the Session Description Protocol
              (SDP)", RFC 5576, June 2009.

   [RFC5760]  Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
              Protocol (RTCP) Extensions for Single-Source Multicast
              Sessions with Unicast Feedback", RFC 5760, February 2010.

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.

   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
              Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, June 2010.

   [RFC6190]  Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
              "RTP Payload Format for Scalable Video Coding", RFC 6190,
              May 2011.

   [RFC6222]

   [RFC7160]  Petit-Huguenin, M. and G. Zorn, "Support for Multiple
              Clock Rates in an RTP Session", RFC 7160, April 2014.

   [RFC7197]  Begen, A., Perkins, C., Cai, Y., and D. Wing, "Guidelines for
              Choosing H. Ou, "Duplication Delay
              Attribute in the Session Description Protocol", RFC 7197,
              April 2014.

   [RFC7198]  Begen, A. and C. Perkins, "Duplicating RTP Control Protocol (RTCP) Canonical Names
              (CNAMEs)", Streams", RFC 6222,
              7198, April 2011. 2014.

Appendix A.  Changes From Earlier Versions

   NOTE TO RFC EDITOR: Please remove this section prior to publication.

A.1.  Modifications Between WG Version -01 and -02

   o  Major re-structure

   o  Moved media chain Media Transport detailing up one section level

   o  Collapsed level 2 sub-sections of section 3 and thus moved level 3
      sub-sections up one level, gathering some introductory text into
      the beginning of section 3

   o  Added that not only SSRC collision, but also a clock rate change
      [RFC7160] is a valid reason to change SSRC value for an RTP stream

   o  Added a sub-section on clock source signaling

   o  Added a sub-section on RTP stream duplication

   o  Elaborated a bit in section 2.2.1 on the relation between End
      Points, Participants and CNAMEs

   o  Elaborated a bit in section 2.2.4 on Multimedia Session and
      synchronization contexts

   o  Removed the section on CLUE scenes defining an implicit
      synchronization context, since it was incorrect

   o  Clarified text on SVC SST and MST according to list discussions

   o  Removed the entire topology section to avoid possible
      inconsistencies or duplications with draft-ietf-avtcore-rtp-
      topologies-update, but saved one example overview figure of
      Communication Entities into that section

   o  Added a section 4 on mapping from existing terms with one sub-
      section per term, mainly by moving text from sections 2 and 3

   o  Changed all occurrences of Packet Stream to RTP Stream

   o  Moved all normative references to informative, since this is an
      informative document

   o  Added references to RFC 7160, RFC 7197 and RFC 7198, and removed
      unused references

A.2.  Modifications Between WG Version -00 and -03 -01

   o  WG version -00 text is identical to individual draft -03

   o  Amended description of SVC SST and MST encodings with respect to
      concepts defined in this text

   o  Removed UML as normative reference, since the text no longer uses
      any UML notation

   o  Removed a number of level 4 sections and moved out text to the
      level above

A.2.

A.3.  Modifications Between Version -02 and -03

   o  Section 4 rewritten (and new communication topologies added) to
      reflect the major updates to Sections 1-3

   o  Section 8 removed (carryover from initial -00 draft)

   o  General clean up of text, grammar and nits

A.3.

A.4.  Modifications Between Version -01 and -02

   o  Section 2 rewritten to add both streams and transformations in the
      media chain.

   o  Section 3 rewritten to focus on exposing relationships.

A.4.

A.5.  Modifications Between Version -00 and -01

   o  Too many to list

   o  Added new authors

   o  Updated content organization and presentation

Authors' Addresses

   Jonathan Lennox
   Vidyo, Inc.
   433 Hackensack Avenue
   Seventh Floor
   Hackensack, NJ  07601
   US

   Email: jonathan@vidyo.com

   Kevin Gross
   AVA Networks, LLC
   Boulder, CO
   US

   Email: kevin.gross@avanw.com
   Suhas Nandakumar
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   US

   Email: snandaku@cisco.com

   Gonzalo Salgueiro
   Cisco Systems
   7200-12 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Email: gsalguei@cisco.com

   Bo Burman
   Ericsson
   Farogatan 6
   Kistavagen 25
   SE-164 80 Kista
   Sweden

   Phone: +46 10 714 13 11
   Email: bo.burman@ericsson.com