tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7656

Informational
Pages: 46
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: AVTEXT

A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources

Part 1 of 2, p. 1 to 25
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                         J. Lennox
Request for Comments: 7656                                         Vidyo
Category: Informational                                         K. Gross
ISSN: 2070-1721                                                      AVA
                                                           S. Nandakumar
                                                            G. Salgueiro
                                                           Cisco Systems
                                                          B. Burman, Ed.
                                                                Ericsson
                                                           November 2015


               A Taxonomy of Semantics and Mechanisms for
               Real-Time Transport Protocol (RTP) Sources

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 properties and
   relationships among RTP sources and defines common terminology for
   discussing protocol entities and their relationships.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7656.

Page 2 
Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) 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.

Top       Page 3 
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Media Chain . . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.1.  Physical Stimulus . . . . . . . . . . . . . . . . . .  10
       2.1.2.  Media Capture . . . . . . . . . . . . . . . . . . . .  10
       2.1.3.  Raw Stream  . . . . . . . . . . . . . . . . . . . . .  10
       2.1.4.  Media Source  . . . . . . . . . . . . . . . . . . . .  11
       2.1.5.  Source Stream . . . . . . . . . . . . . . . . . . . .  11
       2.1.6.  Media Encoder . . . . . . . . . . . . . . . . . . . .  12
       2.1.7.  Encoded Stream  . . . . . . . . . . . . . . . . . . .  13
       2.1.8.  Dependent Stream  . . . . . . . . . . . . . . . . . .  13
       2.1.9.  Media Packetizer  . . . . . . . . . . . . . . . . . .  13
       2.1.10. RTP Stream  . . . . . . . . . . . . . . . . . . . . .  14
       2.1.11. RTP-Based Redundancy  . . . . . . . . . . . . . . . .  14
       2.1.12. Redundancy RTP Stream . . . . . . . . . . . . . . . .  15
       2.1.13. RTP-Based Security  . . . . . . . . . . . . . . . . .  15
       2.1.14. Secured RTP Stream  . . . . . . . . . . . . . . . . .  16
       2.1.15. Media Transport . . . . . . . . . . . . . . . . . . .  16
       2.1.16. Media Transport Sender  . . . . . . . . . . . . . . .  17
       2.1.17. Sent RTP Stream . . . . . . . . . . . . . . . . . . .  18
       2.1.18. Network Transport . . . . . . . . . . . . . . . . . .  18
       2.1.19. Transported RTP Stream  . . . . . . . . . . . . . . .  18
       2.1.20. Media Transport Receiver  . . . . . . . . . . . . . .  18
       2.1.21. Received Secured RTP Stream . . . . . . . . . . . . .  19
       2.1.22. RTP-Based Validation  . . . . . . . . . . . . . . . .  19
       2.1.23. Received RTP Stream . . . . . . . . . . . . . . . . .  19
       2.1.24. Received Redundancy RTP Stream  . . . . . . . . . . .  19
       2.1.25. RTP-Based Repair  . . . . . . . . . . . . . . . . . .  19
       2.1.26. Repaired RTP Stream . . . . . . . . . . . . . . . . .  19
       2.1.27. Media Depacketizer  . . . . . . . . . . . . . . . . .  20
       2.1.28. Received Encoded Stream . . . . . . . . . . . . . . .  20
       2.1.29. Media Decoder . . . . . . . . . . . . . . . . . . . .  20
       2.1.30. Received Source Stream  . . . . . . . . . . . . . . .  20
       2.1.31. Media Sink  . . . . . . . . . . . . . . . . . . . . .  21
       2.1.32. Received Raw Stream . . . . . . . . . . . . . . . . .  21
       2.1.33. Media Render  . . . . . . . . . . . . . . . . . . . .  21
     2.2.  Communication Entities  . . . . . . . . . . . . . . . . .  22
       2.2.1.  Endpoint  . . . . . . . . . . . . . . . . . . . . . .  23
       2.2.2.  RTP Session . . . . . . . . . . . . . . . . . . . . .  23
       2.2.3.  Participant . . . . . . . . . . . . . . . . . . . . .  24
       2.2.4.  Multimedia Session  . . . . . . . . . . . . . . . . .  24
       2.2.5.  Communication Session . . . . . . . . . . . . . . . .  25
   3.  Concepts of Inter-Relations . . . . . . . . . . . . . . . . .  25
     3.1.  Synchronization Context . . . . . . . . . . . . . . . . .  26
       3.1.1.  RTCP CNAME  . . . . . . . . . . . . . . . . . . . . .  26
       3.1.2.  Clock Source Signaling  . . . . . . . . . . . . . . .  26

Top      ToC       Page 4 
       3.1.3.  Implicitly via RtcMediaStream . . . . . . . . . . . .  26
       3.1.4.  Explicitly via SDP Mechanisms . . . . . . . . . . . .  26
     3.2.  Endpoint  . . . . . . . . . . . . . . . . . . . . . . . .  27
     3.3.  Participant . . . . . . . . . . . . . . . . . . . . . . .  27
     3.4.  RtcMediaStream  . . . . . . . . . . . . . . . . . . . . .  27
     3.5.  Multi-Channel Audio . . . . . . . . . . . . . . . . . . .  28
     3.6.  Simulcast . . . . . . . . . . . . . . . . . . . . . . . .  28
     3.7.  Layered Multi-Stream  . . . . . . . . . . . . . . . . . .  30
     3.8.  RTP Stream Duplication  . . . . . . . . . . . . . . . . .  32
     3.9.  Redundancy Format . . . . . . . . . . . . . . . . . . . .  33
     3.10. RTP Retransmission  . . . . . . . . . . . . . . . . . . .  33
     3.11. Forward Error Correction  . . . . . . . . . . . . . . . .  35
     3.12. RTP Stream Separation . . . . . . . . . . . . . . . . . .  36
     3.13. Multiple RTP Sessions over one Media Transport  . . . . .  37
   4.  Mapping from Existing Terms . . . . . . . . . . . . . . . . .  37
     4.1.  Telepresence Terms  . . . . . . . . . . . . . . . . . . .  37
       4.1.1.  Audio Capture . . . . . . . . . . . . . . . . . . . .  37
       4.1.2.  Capture Device  . . . . . . . . . . . . . . . . . . .  37
       4.1.3.  Capture Encoding  . . . . . . . . . . . . . . . . . .  38
       4.1.4.  Capture Scene . . . . . . . . . . . . . . . . . . . .  38
       4.1.5.  Endpoint  . . . . . . . . . . . . . . . . . . . . . .  38
       4.1.6.  Individual Encoding . . . . . . . . . . . . . . . . .  38
       4.1.7.  Media Capture . . . . . . . . . . . . . . . . . . . .  38
       4.1.8.  Media Consumer  . . . . . . . . . . . . . . . . . . .  38
       4.1.9.  Media Provider  . . . . . . . . . . . . . . . . . . .  39
       4.1.10. Stream  . . . . . . . . . . . . . . . . . . . . . . .  39
       4.1.11. Video Capture . . . . . . . . . . . . . . . . . . . .  39
     4.2.  Media Description . . . . . . . . . . . . . . . . . . . .  39
     4.3.  Media Stream  . . . . . . . . . . . . . . . . . . . . . .  39
     4.4.  Multimedia Conference . . . . . . . . . . . . . . . . . .  39
     4.5.  Multimedia Session  . . . . . . . . . . . . . . . . . . .  40
     4.6.  Multipoint Control Unit (MCU) . . . . . . . . . . . . . .  40
     4.7.  Multi-Session Transmission (MST)  . . . . . . . . . . . .  40
     4.8.  Recording Device  . . . . . . . . . . . . . . . . . . . .  41
     4.9.  RtcMediaStream  . . . . . . . . . . . . . . . . . . . . .  41
     4.10. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . .  41
     4.11. RTP Receiver  . . . . . . . . . . . . . . . . . . . . . .  41
     4.12. RTP Sender  . . . . . . . . . . . . . . . . . . . . . . .  41
     4.13. RTP Session . . . . . . . . . . . . . . . . . . . . . . .  41
     4.14. Single-Session Transmission (SST) . . . . . . . . . . . .  41
     4.15. SSRC  . . . . . . . . . . . . . . . . . . . . . . . . . .  42
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  42
   6.  Informative References  . . . . . . . . . . . . . . . . . . .  42
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  45
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  45
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  46

Top      ToC       Page 5 
1.  Introduction

   The existing taxonomy of sources in the Real-time Transport Protocol
   (RTP) [RFC3550] has previously been 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 improves clarity by reviewing the semantics of various
   aspects of sources in RTP.  As an organizing mechanism, it approaches
   this by describing various ways that RTP sources are transformed on
   their way between sender and receiver, and how they can be grouped
   and associated together.

   All non-specific references to ControLling mUltiple streams for
   tElepresence (CLUE) in this document map to [CLUE-FRAME], and all
   references to Web Real-time Communications (WebRTC) map to
   [WEBRTC-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,
   alternate definitions and usages that coexist today are listed along
   with various characteristics that further describe the concept.
   These concepts are divided into two categories: one is related to the
   chain of streams and transformations that Media can be subject to,
   and the other is for entities involved in the communication.

2.1.  Media Chain

   In the context of this document, media is a sequence of synthetic or
   Physical Stimuli (Section 2.1.1) -- for example, 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 stimuli.  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 change the representation of
   the streams in some way.

Top      ToC       Page 6 
   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, such as audio, video, real-time text,
      etc.

   o  A stream has one source transformation and one or more sink
      transformations (with the exception of physical stimulus
      (Section 2.1.1) that may lack source or sink transformation).

   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.

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

   To provide a basic understanding of the relationships in the chain,
   we first introduce the concepts for the sender side (Figure 1).  This
   covers physical stimuli until media packets are emitted onto the
   network.

Top      ToC       Page 7 
               Physical Stimulus
                      |
                      V
           +----------------------+
           |     Media Capture    |
           +----------------------+
                      |
                 Raw Stream
                      V
           +----------------------+
           |     Media Source     |<- Synchronization Timing
           +----------------------+
                      |
                Source Stream
                      V
           +----------------------+
           |    Media Encoder     |
           +----------------------+
                      |
                Encoded Stream      +------------+
                      V             |            V
           +----------------------+ | +----------------------+
           |   Media Packetizer   | | | RTP-Based Redundancy |
           +----------------------+ | +----------------------+
                      |             |            |
                      +-------------+  Redundancy RTP Stream
               Source RTP Stream                 |
                      V                          V
           +----------------------+   +----------------------+
           |  RTP-Based Security  |   |  RTP-Based Security  |
           +----------------------+   +----------------------+
                      |                          |
              Secured RTP Stream   Secured Redundancy RTP Stream
                      V                          V
           +----------------------+   +----------------------+
           |   Media Transport    |   |   Media Transport    |
           +----------------------+   +----------------------+

             Figure 1: Sender Side Concepts in the Media 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 in
   Section 2.1.15.

Top      ToC       Page 8 
   In Figure 2, we review a receiver media chain matching the sender
   side, to look at the inverse transformations and their attempts to
   recover identical streams as in the sender chain, subject to what may
   be lossy compression and imperfect media transport.  Note that the
   streams out of a reverse transformation, like the Source Stream out
   of 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 from
   being the same as the one fed into the media encoder.  Other reasons
   include packet loss in the media transport transformation that even
   RTP-based Repair, if used, fails to repair.

Top      ToC       Page 9 
          +----------------------+   +----------------------+
          |   Media Transport    |   |   Media Transport    |
          +----------------------+   +----------------------+
            Received |                 Received | Secured
            Secured RTP Stream       Redundancy RTP Stream
                     V                          V
          +----------------------+   +----------------------+
          | RTP-Based Validation |   | RTP-Based Validation |
          +----------------------+   +----------------------+
                     |                          |
            Received RTP Stream   Received Redundancy RTP Stream
                     |                          |
                     |     +--------------------+
                     V     V
          +----------------------+
          |   RTP-Based Repair   |
          +----------------------+
                     |
            Repaired RTP Stream
                     V
          +----------------------+
          |  Media Depacketizer  |
          +----------------------+
                     |
           Received Encoded Stream
                     V
          +----------------------+
          |    Media Decoder     |
          +----------------------+
                     |
           Received Source Stream
                     V
          +----------------------+
          |      Media Sink      |--> Synchronization Information
          +----------------------+
                     |
            Received Raw Stream
                     V
          +----------------------+
          |     Media Render     |
          +----------------------+
                     |
                     V
             Physical Stimulus

            Figure 2: Receiver Side Concepts of the Media Chain

Top      ToC       Page 10 
2.1.1.  Physical Stimulus

   The physical stimulus is a physical event in the analog domain that
   can be sampled and converted to digital form by an appropriate sensor
   or transducer.  This includes sound waves making up audio, photons in
   a light field, or other excitations or interactions with sensors,
   like keystrokes on a keyboard.

2.1.2.  Media Capture

   Media Capture is the process of transforming the analog physical
   stimulus (Section 2.1.1) into digital media using an appropriate
   sensor or transducer.  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
   considered "media", because it includes data that is periodically
   sampled or made up of a set of timed asynchronous events.  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.

   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 supports such a configuration.

   o  The nature of the media capture may impose constraints on the
      clock handling in some of the subsequent steps.  For example, many
      audio or video capture devices are not completely free in
      selecting the sample rate.

2.1.3.  Raw Stream

   A raw stream is the time progressing stream of digitally sampled
   information, usually periodically sampled and provided by a media
   capture (Section 2.1.2).  A raw stream can also contain synthesized
   media that may not require any explicit media capture, since it is
   already in an appropriate digital form.

Top      ToC       Page 11 
2.1.4.  Media Source

   A Media Source is the logical source of a time progressing digital
   media stream synchronized to a reference clock.  This stream is
   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.  The output is synchronized with a reference clock
   (Section 3.1), which can be as simple as a system local wall clock or
   as complex as an NTP synchronized clock.

   The output can 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 source streams
   (Figure 3).  Mixing multiple streams typically requires that the
   input streams are possible to relate in time, meaning that they have
   to be source streams (Section 2.1.5) rather than raw streams.  In
   Figure 3, the generated source stream is a mix of the three input
   source streams.

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

      Figure 3: Conceptual Media Source in the form of an Audio Mixer

   Another possible example of a conceptual media source is a video
   surveillance switch, where the input is multiple source streams from
   different cameras, and the output is one of those source streams
   based on some selection criteria, such as round robin or some video
   activity measure.

2.1.5.  Source Stream

   A source stream is a stream of digital samples that has been
   synchronized with a reference clock and comes from a particular media
   source (Section 2.1.4).

Top      ToC       Page 12 
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 includes properties such
   as codec, bitrate, start points for decoding, resolution, bandwidth,
   or other fidelity affecting properties.

   Scalable media encoders need special attention as they produce
   multiple outputs that are potentially of different types.  As shown
   in Figure 4, a scalable media encoder takes one input source stream
   and encodes it into multiple output streams of two different types:
   at least one encoded stream that is independently decodable and one
   or more Dependent Streams (Section 2.1.8).  Decoding requires at
   least one encoded stream and zero or more dependent streams.  A
   dependent stream's dependency is one of the grouping relations this
   document discusses further in Section 3.7.

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

            Figure 4: Scalable Media Encoder Input and Outputs

   There are also other variants of encoders, like so-called Multiple
   Description Coding (MDC).  Such media encoders produce multiple
   independent and thus individually decodable encoded streams.
   However, (logically) combining multiple of these encoded streams into
   a single Received Source Stream during decoding leads to an
   improvement in perceptual reproduced quality when compared to
   decoding a single encoded stream.

   Creating multiple encoded streams from the same source stream, where
   the encoded streams are neither in a scalable nor in an MDC

Top      ToC       Page 13 
   relationship is commonly utilized in simulcast [SDP-SIMULCAST]
   environments.

2.1.7.  Encoded Stream

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

   Due to temporal dependencies, an encoded stream may have limitations
   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.

   Each dependent stream has a set of dependencies.  These dependencies
   must be understood by the parties in a Multimedia Session
   (Section 2.2.4) that intend to use a dependent stream.

2.1.9.  Media Packetizer

   The transformation of taking one or more encoded (Section 2.1.7) or
   dependent streams (Section 2.1.8) and putting their content into one
   or more sequences of packets, normally RTP Packets, and output Source
   RTP Streams (Section 2.1.10).  This step includes both generating RTP
   Payloads as well as RTP packets.  The Media Packetizer then selects
   which synchronization source(s) (SSRC) [RFC3550] and RTP Sessions
   (Section 2.2.2) to use.

   The media packetizer can combine multiple encoded or dependent
   streams into one or more RTP Streams:

   o  The media packetizer can use multiple inputs when producing a
      single RTP stream.  One such example is Single RTP stream on a
      Single media Transport (SRST) packetization when using Scalable
      Video Coding (SVC) (Section 3.7).

   o  The media packetizer can also produce multiple RTP streams, for
      example, when encoded and/or dependent streams are distributed
      over multiple RTP streams.  One example of this is Multiple RTP
      streams on Multiple media Transports (MRMT) packetization when
      using SVC (Section 3.7).

Top      ToC       Page 14 
2.1.10.  RTP Stream

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

   A source RTP stream is an RTP stream directly related to an encoded
   stream (Section 2.1.7), targeted for transport over RTP without any
   additional RTP-based Redundancy (Section 2.1.11) applied.

   Characteristics:

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

   o  At any given point in time, an RTP stream can have one and only
      one SSRC, but SSRCs for a given RTP stream can change over time.
      SSRC collision and clock rate change [RFC7160] are examples of
      valid reasons to change SSRC for an RTP stream.  In those cases,
      the RTP stream itself is not changed in any significant way, only
      the identifying SSRC number.

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

   o  Several RTP streams, each with their own SSRC, may represent a
      single media source.

   o  Several RTP streams, each with their own SSRC, can be carried in a
      single RTP session.

2.1.11.  RTP-Based Redundancy

   RTP-based redundancy is defined here as a transformation that
   generates redundant or repair packets sent out as a Redundancy RTP
   Stream (Section 2.1.12) to mitigate Network Transport
   (Section 2.1.18) impairments, like packet loss and delay.  Note that
   this excludes the type of redundancy that most suitable media
   encoders (Section 2.1.6) may add to the media format of the encoded
   stream (Section 2.1.7) that makes it cope better with RTP packet
   losses.

   The RTP-based redundancy exists in many flavors: they may generate
   independent repair streams that are used in addition to the source
   stream (like RTP Retransmission (Section 3.10) and some special types
   of Forward Error Correction (FEC) (Section 3.11), like RTP stream

Top      ToC       Page 15 
   duplication (Section 3.8)); they may generate a new source stream by
   combining redundancy information with source information (using XOR
   FEC as a redundancy payload (Section 3.9)); or they may completely
   replace the source information with only redundancy packets.

2.1.12.  Redundancy RTP Stream

   A redundancy RTP stream is an RTP stream (Section 2.1.10) that
   contains no original source data, only redundant data, which may
   either be used as standalone or be combined with one or more Received
   RTP Streams (Section 2.1.23) to produce Repaired RTP Streams
   (Section 2.1.26).

2.1.13.  RTP-Based Security

   The optional RTP-based Security transformation applies security
   services such as authentication, integrity protection, and
   confidentiality to an input RTP stream, like what is specified in
   "The Secure Real-time Transport Protocol (SRTP)" [RFC3711], producing
   a Secured RTP Stream (Section 2.1.14).  Either an RTP stream
   (Section 2.1.10) or a redundancy RTP stream (Section 2.1.12) can be
   used as input to this transformation.

   In SRTP and the related Secure RTCP (SRTCP), all of the above-
   mentioned security services are optional, except for integrity
   protection of SRTCP, which is mandatory.  Also confidentiality
   (encryption) is effectively optional in SRTP, since it is possible to
   use a NULL encryption algorithm.  As described in [RFC7201], the
   strength of SRTP data origin authentication depends on the
   cryptographic transform and key management used.  For example, in
   group communication, where it is sometimes possible to authenticate
   group membership but not the actual RTP stream sender.

   RTP-based security and RTP-based redundancy can be combined in a few
   different ways.  One way is depicted in Figure 1, where an RTP stream
   and its corresponding redundancy RTP stream are protected by separate
   RTP-based security transforms.  In other cases, like when a Media
   Translator is adding FEC in Section 3.2.1.3 of [RTP-TOPOLOGIES], a
   middlebox can apply RTP-based redundancy to an already secured RTP
   stream instead of a source RTP stream.  One example of that is
   depicted in Figure 5 below.

Top      ToC       Page 16 
               Source RTP Stream    +------------+
                      V             |            V
           +----------------------+ | +----------------------+
           |  RTP-Based Security  | | | RTP-Based Redundancy |
           +----------------------+ | +----------------------+
                      |             |            |
                      |             |  Redundancy RTP Stream
                      +-------------+            |
                      |                          V
                      |               +----------------------+
              Secured RTP Stream      |  RTP-Based Security  |
                      |               +----------------------+
                      |                          |
                      |            Secured Redundancy RTP Stream
                      V                          V
           +----------------------+   +----------------------+
           |   Media Transport    |   |   Media Transport    |
           +----------------------+   +----------------------+

            Figure 5: Adding Redundancy to a Secured RTP Stream

   In this case, the redundancy RTP stream may already have been secured
   for confidentiality (encrypted) by the first RTP-based security, and
   it may therefore not be necessary to apply additional confidentiality
   protection in the second RTP-based security.  To avoid attacks and
   negative impact on RTP-based Repair (Section 2.1.25) and the
   resulting repaired RTP stream (Section 2.1.26), it is, however, still
   necessary to have this second RTP-based security apply both
   authentication and integrity protection to the redundancy RTP stream.

2.1.14.  Secured RTP Stream

   A secured RTP stream is a source or redundancy RTP stream that is
   protected through RTP-based security (Section 2.1.13) by one or more
   of the confidentiality, integrity, or authentication security
   services.

2.1.15.  Media Transport

   A media transport defines the transformation that the RTP streams
   (Section 2.1.10) are subjected to by the end-to-end transport from
   one RTP Sender (Section 4.12) to one specific RTP Receiver
   (Section 4.11) (an RTP session (Section 2.2.2) may contain multiple
   RTP receivers per sender).  Each media transport is defined by a
   transport association that is normally identified by a 5-tuple
   (source address, source port, destination address, destination port,
   transport protocol), but a proposal exists for sending multiple
   transport associations on a single 5-tuple [TRANSPORT-MULTIPLEX].

Top      ToC       Page 17 
   Characteristics:

   o  Media transport transmits RTP streams of RTP packets from a source
      transport address to a destination transport address.

   o  Each media transport contains only a single RTP session.

   o  A single RTP session can span multiple media transports.

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

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

                Figure 6: Decomposition of Media Transport

2.1.16.  Media Transport Sender

   The first transformation within the media transport (Section 2.1.15)
   is the Media Transport Sender.  The sending Endpoint (Section 2.2.1)
   takes an RTP stream and emits the packets onto the network using the
   transport association established for this media transport, thereby
   creating a Sent RTP Stream (Section 2.1.17).  In the process, it
   transforms the RTP stream in several ways.  First, it generates the
   necessary protocol headers for the transport association, for
   example, IP and UDP headers, thus forming IP/UDP/RTP packets.  In

Top      ToC       Page 18 
   addition, the media transport sender may queue, intentionally pace,
   or otherwise affect how the packets are emitted onto the network,
   thereby potentially introducing delay and delay variations [RFC5481]
   that characterize the sent RTP stream.

2.1.17.  Sent RTP Stream

   The sent RTP stream is the RTP stream as entering the first hop of
   the network path to its destination.  The sent RTP stream is
   identified using network transport addresses, like the 5-tuple
   (source IP address, source port, destination IP address, destination
   port, and protocol (UDP)) for IP/UDP.

2.1.18.  Network Transport

   Network transport is the transformation that subjects the sent RTP
   stream (Section 2.1.17) to traveling from the source to the
   destination through the network.  This transformation can result in
   loss of some packets, delay, and delay variation on a per-packet
   basis, packet duplication, and packet header or data corruption.
   This transformation produces a Transported RTP Stream
   (Section 2.1.19) at the exit of the network path.

2.1.19.  Transported RTP Stream

   The transported RTP stream is the RTP stream that is emitted out of
   the network path at the destination, subjected to the network
   transport's transformation (Section 2.1.18).

2.1.20.  Media Transport Receiver

   The Media Transport Receiver is the receiver endpoint's
   (Section 2.2.1) transformation of the transported RTP stream
   (Section 2.1.19) by its reception process, which results in the
   received RTP stream (Section 2.1.23).  This transformation includes
   transport checksums being verified.  Sensible system designs
   typically either discard packets with mismatching checksums or pass
   them on while somehow marking them in the resulting received RTP
   stream so to alert subsequent transformations about the possible
   corrupt state.  In this context, it is worth noting that there is
   typically some probability for corrupt packets to pass through
   undetected (with a seemingly correct checksum).  Other
   transformations can compensate for delay variations in receiving a
   packet on the network interface and providing it to the application
   (de-jitter buffer).

Top      ToC       Page 19 
2.1.21.  Received Secured RTP Stream

   This is the secured RTP stream (Section 2.1.14) resulting from the
   media transport (Section 2.1.15) aggregate transformation.

2.1.22.  RTP-Based Validation

   RTP-based Validation is the reverse transformation of RTP-based
   security (Section 2.1.13).  If this transformation fails, the result
   is either not usable and must be discarded or may be usable but
   cannot be trusted.  If the transformation succeeds, the result can be
   a received RTP stream (Section 2.1.23) or a Received Redundancy RTP
   Stream (Section 2.1.24), depending on what was input to the
   corresponding RTP-based security transformation, but it can also be a
   Received Secured RTP Stream (Section 2.1.21) in case several RTP-
   based security transformations were applied.

2.1.23.  Received RTP Stream

   The received RTP stream is the RTP stream (Section 2.1.10) resulting
   from the media transport's aggregate transformation (Section 2.1.15),
   i.e., subjected to packet loss, packet corruption, packet
   duplication, delay, and delay variation from sender to receiver.

2.1.24.  Received Redundancy RTP Stream

   The received redundancy RTP stream is the redundancy RTP stream
   (Section 2.1.12) resulting from the media transport's aggregate
   transformation, i.e., subjected to packet loss, packet corruption,
   packet duplication, delay, and delay variation from sender to
   receiver.

2.1.25.  RTP-Based Repair

   RTP-based repair is a transformation that takes as input zero or more
   received RTP streams (Section 2.1.23) and one or more received
   redundancy RTP streams (Section 2.1.24) and produces one or more
   repaired RTP streams (Section 2.1.26) that are as close to the
   corresponding sent source RTP streams (Section 2.1.10) as possible,
   using different RTP-based repair methods, for example, the ones
   referred to in RTP-based redundancy (Section 2.1.11).

2.1.26.  Repaired RTP Stream

   A repaired RTP stream is a received RTP stream (Section 2.1.23) for
   which received redundancy RTP stream (Section 2.1.24) information has
   been used to try to recover the source RTP stream (Section 2.1.10) as
   it was before media transport (Section 2.1.15).

Top      ToC       Page 20 
2.1.27.  Media Depacketizer

   A Media Depacketizer takes one or more RTP streams (Section 2.1.10),
   depacketizes them, and attempts to reconstitute the encoded streams
   (Section 2.1.7) or dependent streams (Section 2.1.8) present in those
   RTP streams.

   In practical implementations, the media depacketizer and the media
   decoder may be tightly coupled and share information to improve or
   optimize the overall decoding and error concealment process.  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.28.  Received Encoded Stream

   The Received Encoded Stream is the received version of an encoded
   stream (Section 2.1.7).

2.1.29.  Media Decoder

   A media decoder is a transformation that 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).

   In practical implementations, the media decoder and the media
   depacketizer may be tightly coupled and share information to 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.

   A media decoder has to deal with any errors in the encoded streams
   that resulted from corruption or failure to repair packet losses.
   Therefore, it commonly is robust to error and losses, and includes
   concealment methods.

2.1.30.  Received Source Stream

   The received source stream is the received version of a source stream
   (Section 2.1.5).

Top      ToC       Page 21 
2.1.31.  Media Sink

   The Media Sink receives a source stream (Section 2.1.5) that
   contains, usually periodically, sampled media data together with
   associated synchronization information.  Depending on application,
   this source stream then needs to be transformed into a raw stream
   (Section 2.1.3) that is conveyed to the Media Render (Section 2.1.33)
   and synchronized with the output from other media sinks.  The media
   sink may also be connected with a media source (Section 2.1.4) and be
   used as part of a conceptual media source.

   The media sink can further transform the source stream into a
   representation that is suitable for rendering on the media render as
   defined by the application or system-wide configuration.  This
   includes sample scaling, level adjustments, etc.

2.1.32.  Received Raw Stream

   The Received Raw Stream is the received version of a raw stream
   (Section 2.1.3).

2.1.33.  Media Render

   A media render takes a raw stream (Section 2.1.3) and converts it
   into physical stimulus (Section 2.1.1) that a human user can
   perceive.  Examples of such devices are screens and D/A converters
   connected to amplifiers and loudspeakers.

   An endpoint can potentially have multiple media renders for each
   media type.

Top      ToC       Page 22 
2.2.  Communication Entities

   This section contains concepts for entities involved in the
   communication.

      +------------------------------------------------------------+
      | Communication Session                                      |
      |                                                            |
      | +----------------+                      +----------------+ |
      | | Participant A  |    +------------+    | Participant B  | |
      | |                |    | Multimedia |    |                | |
      | | +------------+ |<==>| Session    |<==>| +------------+ | |
      | | | Endpoint A | |    |            |    | | Endpoint B | | |
      | | |            | |    +------------+    | |            | | |
      | | | +----------+-+----------------------+-+----------+ | | |
      | | | | RTP      | |                      | |          | | | |
      | | | | Session  |-+---Media Transport----+>|          | | | |
      | | | | Audio    |<+---Media Transport----+-|          | | | |
      | | | |          | |          ^           | |          | | | |
      | | | +----------+-+----------|-----------+-+----------+ | | |
      | | |            | |          v           | |            | | |
      | | |            | | +-----------------+  | |            | | |
      | | |            | | | Synchronization |  | |            | | |
      | | |            | | |     Context     |  | |            | | |
      | | |            | | +-----------------+  | |            | | |
      | | |            | |          ^           | |            | | |
      | | | +----------+-+----------|-----------+-+----------+ | | |
      | | | | RTP      | |          v           | |          | | | |
      | | | | Session  |<+---Media Transport----+-|          | | | |
      | | | | Video    |-+---Media Transport----+>|          | | | |
      | | | |          | |                      | |          | | | |
      | | | +----------+-+----------------------+-+----------+ | | |
      | | +------------+ |                      | +------------+ | |
      | +----------------+                      +----------------+ |
      +------------------------------------------------------------+

    Figure 7: Example Point-to-Point Communication Session with Two RTP
                                 Sessions

   Figure 7 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 endpoints, where each RTP session is a group communications
   channel that can potentially carry a number of RTP streams.  It is
   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).

Top      ToC       Page 23 
   The terms used in Figure 7 are further elaborated in the subsections
   below.

2.2.1.  Endpoint

   An endpoint is 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 "endpoint".

   Characteristics:

   o  Endpoints 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 endpoint can handle multiple CNAMEs, each of which can be
      shared among a set of endpoints belonging to the same participant
      (Section 2.2.3).  Therefore, mechanisms outside the scope of RTP,
      such as application-defined mechanisms, must be used to provide
      endpoint identification when outside this synchronization context.

   o  An endpoint can be associated with at most one participant
      (Section 2.2.3) at any single point in time.

   o  In some contexts, an endpoint would typically correspond to a
      single "host", for example, a computer using a single network
      interface and being used by a single human user.  In other
      contexts, a single "host" can serve multiple participants, in
      which case each participant's endpoint may share properties, for
      example, the IP address part of a transport address.

2.2.2.  RTP Session

   An RTP session is an association among a group of participants
   communicating with RTP.  It is a group communications channel that
   can potentially carry a number of RTP streams.  Within an RTP
   session, every participant can find metadata and control information
   (over RTCP) about all the RTP streams in the RTP session.  The
   bandwidth of the RTCP control channel is shared between all
   participants within an RTP session.

   Characteristics:

   o  An RTP session can carry one or more RTP streams.

Top      ToC       Page 24 
   o  An RTP session shares a single SSRC space as defined in [RFC3550].
      That is, the endpoints participating in an RTP session can see an
      SSRC identifier transmitted by any of the other endpoints.  An
      endpoint can receive an SSRC either as SSRC or as a contributing
      source (CSRC) in RTP and RTCP packets, as defined by the
      endpoints' network interconnection topology.

   o  An RTP session uses at least two media transports
      (Section 2.1.15): one for sending and one for receiving.
      Commonly, the receiving media transport is the reverse direction
      of the media transport used for sending.  An RTP session may use
      many media transports and these define the session's network
      interconnection topology.

   o  A single media transport always carries a single RTP session.

   o  Multiple RTP sessions can be conceptually related, for example,
      originating from or targeted for the same participant
      (Section 2.2.3) or endpoint (Section 2.2.1), or by containing RTP
      streams that are somehow related (Section 3).

2.2.3.  Participant

   A participant is an entity reachable by a single signaling address
   and is thus related more to the signaling context than to the 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 participate in several multimedia sessions
      (Section 2.2.4).

   o  A participant can be comprised of several associated endpoints
      (Section 2.2.1).

2.2.4.  Multimedia Session

   A multimedia session is an association among a group of participants
   (Section 2.2.3) engaged in the 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.

Top      ToC       Page 25 
   Characteristics:

   o  A multimedia session can be composed of several RTP sessions with
      potentially multiple RTP streams per RTP session.

   o  Each participant in a multimedia session can have a multitude of
      media captures and media rendering devices.

   o  A single multimedia session can contain media from one or more
      synchronization contexts (Section 3.1).  An example of that is a
      multimedia session containing one set of audio and video for
      communication purposes belonging to one synchronization context,
      and another set of audio and video for presentation purposes (like
      playing a video file) with a separate synchronization context that
      has no strong timing relationship and need not be strictly
      synchronized with the audio and video used for communication.

2.2.5.  Communication Session

   A communication session is an association among two or more
   participants (Section 2.2.3) communicating with each other via one or
   more multimedia sessions (Section 2.2.4).

   Characteristics:

   o  Each participant in a communication session is identified via an
      application-specific signaling address.

   o  A communication session is composed of participants that share at
      least one multimedia session, involving one or more parallel RTP
      sessions with potentially multiple RTP 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.



(page 25 continued on part 2)

Next RFC Part