draft-ietf-avtext-rtp-grouping-taxonomy-07.txt   draft-ietf-avtext-rtp-grouping-taxonomy-08.txt 
Network Working Group J. Lennox Network Working Group J. Lennox
Internet-Draft Vidyo Internet-Draft Vidyo
Intended status: Informational K. Gross Intended status: Informational K. Gross
Expires: December 25, 2015 AVA Expires: January 21, 2016 AVA
S. Nandakumar S. Nandakumar
G. Salgueiro G. Salgueiro
Cisco Systems Cisco Systems
B. Burman, Ed. B. Burman, Ed.
Ericsson Ericsson
June 23, 2015 July 20, 2015
A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol
(RTP) Sources (RTP) Sources
draft-ietf-avtext-rtp-grouping-taxonomy-07 draft-ietf-avtext-rtp-grouping-taxonomy-08
Abstract Abstract
The terminology about, and associations among, Real-Time Transport The terminology about, and associations among, Real-Time Transport
Protocol (RTP) sources can be complex and somewhat opaque. This Protocol (RTP) sources can be complex and somewhat opaque. This
document describes a number of existing and proposed properties and document describes a number of existing and proposed properties and
relationships among RTP sources, and defines common terminology for relationships among RTP sources, and defines common terminology for
discussing protocol entities and their relationships. discussing protocol entities and their relationships.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 25, 2015. This Internet-Draft will expire on January 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 2, line 51
2.1.25. RTP-based Repair . . . . . . . . . . . . . . . . . . 18 2.1.25. RTP-based Repair . . . . . . . . . . . . . . . . . . 18
2.1.26. Repaired RTP Stream . . . . . . . . . . . . . . . . . 18 2.1.26. Repaired RTP Stream . . . . . . . . . . . . . . . . . 18
2.1.27. Media Depacketizer . . . . . . . . . . . . . . . . . 19 2.1.27. Media Depacketizer . . . . . . . . . . . . . . . . . 19
2.1.28. Received Encoded Stream . . . . . . . . . . . . . . . 19 2.1.28. Received Encoded Stream . . . . . . . . . . . . . . . 19
2.1.29. Media Decoder . . . . . . . . . . . . . . . . . . . . 19 2.1.29. Media Decoder . . . . . . . . . . . . . . . . . . . . 19
2.1.30. Received Source Stream . . . . . . . . . . . . . . . 19 2.1.30. Received Source Stream . . . . . . . . . . . . . . . 19
2.1.31. Media Sink . . . . . . . . . . . . . . . . . . . . . 19 2.1.31. Media Sink . . . . . . . . . . . . . . . . . . . . . 19
2.1.32. Received Raw Stream . . . . . . . . . . . . . . . . . 20 2.1.32. Received Raw Stream . . . . . . . . . . . . . . . . . 20
2.1.33. Media Render . . . . . . . . . . . . . . . . . . . . 20 2.1.33. Media Render . . . . . . . . . . . . . . . . . . . . 20
2.2. Communication Entities . . . . . . . . . . . . . . . . . 20 2.2. Communication Entities . . . . . . . . . . . . . . . . . 20
2.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 21 2.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 22
2.2.2. RTP Session . . . . . . . . . . . . . . . . . . . . . 22 2.2.2. RTP Session . . . . . . . . . . . . . . . . . . . . . 22
2.2.3. Participant . . . . . . . . . . . . . . . . . . . . . 23 2.2.3. Participant . . . . . . . . . . . . . . . . . . . . . 23
2.2.4. Multimedia Session . . . . . . . . . . . . . . . . . 23 2.2.4. Multimedia Session . . . . . . . . . . . . . . . . . 23
2.2.5. Communication Session . . . . . . . . . . . . . . . . 24 2.2.5. Communication Session . . . . . . . . . . . . . . . . 24
3. Concepts of Inter-Relations . . . . . . . . . . . . . . . . . 24 3. Concepts of Inter-Relations . . . . . . . . . . . . . . . . . 24
3.1. Synchronization Context . . . . . . . . . . . . . . . . . 24 3.1. Synchronization Context . . . . . . . . . . . . . . . . . 24
3.1.1. RTCP CNAME . . . . . . . . . . . . . . . . . . . . . 25 3.1.1. RTCP CNAME . . . . . . . . . . . . . . . . . . . . . 25
3.1.2. Clock Source Signaling . . . . . . . . . . . . . . . 25 3.1.2. Clock Source Signaling . . . . . . . . . . . . . . . 25
3.1.3. Implicitly via RtcMediaStream . . . . . . . . . . . . 25 3.1.3. Implicitly via RtcMediaStream . . . . . . . . . . . . 25
3.1.4. Explicitly via SDP Mechanisms . . . . . . . . . . . . 25 3.1.4. Explicitly via SDP Mechanisms . . . . . . . . . . . . 25
skipping to change at page 3, line 30 skipping to change at page 3, line 30
3.8. RTP Stream Duplication . . . . . . . . . . . . . . . . . 29 3.8. RTP Stream Duplication . . . . . . . . . . . . . . . . . 29
3.9. Redundancy Format . . . . . . . . . . . . . . . . . . . . 30 3.9. Redundancy Format . . . . . . . . . . . . . . . . . . . . 30
3.10. RTP Retransmission . . . . . . . . . . . . . . . . . . . 31 3.10. RTP Retransmission . . . . . . . . . . . . . . . . . . . 31
3.11. Forward Error Correction . . . . . . . . . . . . . . . . 33 3.11. Forward Error Correction . . . . . . . . . . . . . . . . 33
3.12. RTP Stream Separation . . . . . . . . . . . . . . . . . . 34 3.12. RTP Stream Separation . . . . . . . . . . . . . . . . . . 34
3.13. Multiple RTP Sessions over one Media Transport . . . . . 35 3.13. Multiple RTP Sessions over one Media Transport . . . . . 35
4. Mapping from Existing Terms . . . . . . . . . . . . . . . . . 35 4. Mapping from Existing Terms . . . . . . . . . . . . . . . . . 35
4.1. Telepresence Terms . . . . . . . . . . . . . . . . . . . 35 4.1. Telepresence Terms . . . . . . . . . . . . . . . . . . . 35
4.1.1. Audio Capture . . . . . . . . . . . . . . . . . . . . 35 4.1.1. Audio Capture . . . . . . . . . . . . . . . . . . . . 35
4.1.2. Capture Device . . . . . . . . . . . . . . . . . . . 35 4.1.2. Capture Device . . . . . . . . . . . . . . . . . . . 35
4.1.3. Capture Encoding . . . . . . . . . . . . . . . . . . 35 4.1.3. Capture Encoding . . . . . . . . . . . . . . . . . . 36
4.1.4. Capture Scene . . . . . . . . . . . . . . . . . . . . 36 4.1.4. Capture Scene . . . . . . . . . . . . . . . . . . . . 36
4.1.5. Endpoint . . . . . . . . . . . . . . . . . . . . . . 36 4.1.5. Endpoint . . . . . . . . . . . . . . . . . . . . . . 36
4.1.6. Individual Encoding . . . . . . . . . . . . . . . . . 36 4.1.6. Individual Encoding . . . . . . . . . . . . . . . . . 36
4.1.7. Media Capture . . . . . . . . . . . . . . . . . . . . 36 4.1.7. Media Capture . . . . . . . . . . . . . . . . . . . . 36
4.1.8. Media Consumer . . . . . . . . . . . . . . . . . . . 36 4.1.8. Media Consumer . . . . . . . . . . . . . . . . . . . 36
4.1.9. Media Provider . . . . . . . . . . . . . . . . . . . 36 4.1.9. Media Provider . . . . . . . . . . . . . . . . . . . 37
4.1.10. Stream . . . . . . . . . . . . . . . . . . . . . . . 37 4.1.10. Stream . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.11. Video Capture . . . . . . . . . . . . . . . . . . . . 37 4.1.11. Video Capture . . . . . . . . . . . . . . . . . . . . 37
4.2. Media Description . . . . . . . . . . . . . . . . . . . . 37 4.2. Media Description . . . . . . . . . . . . . . . . . . . . 37
4.3. Media Stream . . . . . . . . . . . . . . . . . . . . . . 37 4.3. Media Stream . . . . . . . . . . . . . . . . . . . . . . 37
4.4. Multimedia Conference . . . . . . . . . . . . . . . . . . 37 4.4. Multimedia Conference . . . . . . . . . . . . . . . . . . 37
4.5. Multimedia Session . . . . . . . . . . . . . . . . . . . 37 4.5. Multimedia Session . . . . . . . . . . . . . . . . . . . 38
4.6. Multipoint Control Unit (MCU) . . . . . . . . . . . . . . 38 4.6. Multipoint Control Unit (MCU) . . . . . . . . . . . . . . 38
4.7. Multi-Session Transmission (MST) . . . . . . . . . . . . 38 4.7. Multi-Session Transmission (MST) . . . . . . . . . . . . 38
4.8. Recording Device . . . . . . . . . . . . . . . . . . . . 38 4.8. Recording Device . . . . . . . . . . . . . . . . . . . . 39
4.9. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 38 4.9. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 39
4.10. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . . 39 4.10. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . . 39
4.11. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . 39 4.11. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . 39
4.12. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 39 4.12. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 39
4.13. Single Session Transmission (SST) . . . . . . . . . . . . 39 4.13. Single Session Transmission (SST) . . . . . . . . . . . . 39
4.14. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.14. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5. Security Considerations . . . . . . . . . . . . . . . . . . . 39 5. Security Considerations . . . . . . . . . . . . . . . . . . . 40
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 40 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 40
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
9. Informative References . . . . . . . . . . . . . . . . . . . 40 9. Informative References . . . . . . . . . . . . . . . . . . . 41
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 43 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 44
A.1. Modifications Between WG Version -06 and -07 . . . . . . 43 A.1. Modifications Between WG Version -07 and -08 . . . . . . 44
A.2. Modifications Between WG Version -05 and -06 . . . . . . 43 A.2. Modifications Between WG Version -06 and -07 . . . . . . 45
A.3. Modifications Between WG Version -04 and -05 . . . . . . 44 A.3. Modifications Between WG Version -05 and -06 . . . . . . 45
A.4. Modifications Between WG Version -03 and -04 . . . . . . 44 A.4. Modifications Between WG Version -04 and -05 . . . . . . 46
A.5. Modifications Between WG Version -02 and -03 . . . . . . 45 A.5. Modifications Between WG Version -03 and -04 . . . . . . 46
A.6. Modifications Between WG Version -01 and -02 . . . . . . 45 A.6. Modifications Between WG Version -02 and -03 . . . . . . 47
A.7. Modifications Between WG Version -00 and -01 . . . . . . 46 A.7. Modifications Between WG Version -01 and -02 . . . . . . 47
A.8. Modifications Between Version -02 and -03 . . . . . . . . 46 A.8. Modifications Between WG Version -00 and -01 . . . . . . 48
A.9. Modifications Between Version -01 and -02 . . . . . . . . 46 A.9. Modifications Between Version -02 and -03 . . . . . . . . 48
A.10. Modifications Between Version -00 and -01 . . . . . . . . 46 A.10. Modifications Between Version -01 and -02 . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 A.11. Modifications Between Version -00 and -01 . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
The existing taxonomy of sources in Real-Time Transport Protocol The existing taxonomy of sources in the Real-Time Transport Protocol
(RTP) [RFC3550] has previously often been regarded as confusing and (RTP) [RFC3550] has previously been regarded as confusing and
inconsistent. Consequently, a deep understanding of how the inconsistent. Consequently, a deep understanding of how the
different terms relate to each other becomes a real challenge. different terms relate to each other becomes a real challenge.
Frequently cited examples of this confusion are (1) how different Frequently cited examples of this confusion are (1) how different
protocols that make use of RTP use the same terms to signify protocols that make use of RTP use the same terms to signify
different things and (2) how the complexities addressed at one layer different things and (2) how the complexities addressed at one layer
are often glossed over or ignored at another. are often glossed over or ignored at another.
This document provides some clarity by reviewing the semantics of This document improves clarity by reviewing the semantics of various
various aspects of sources in RTP. As an organizing mechanism, it aspects of sources in RTP. As an organizing mechanism, it approaches
approaches this by describing various ways that RTP sources are this by describing various ways that RTP sources are transformed on
transformed on their way between sender and receiver, and how they their way between sender and receiver, and how they can be grouped
can be grouped and associated together. and associated together.
All non-specific references to ControLling mUltiple streams for All non-specific references to ControLling mUltiple streams for
tElepresence (CLUE) in this document map to [I-D.ietf-clue-framework] tElepresence (CLUE) in this document map to [I-D.ietf-clue-framework]
and all references to Web Real-Time Communications (WebRTC) map to and all references to Web Real-Time Communications (WebRTC) map to
[I-D.ietf-rtcweb-overview]. [I-D.ietf-rtcweb-overview].
2. Concepts 2. Concepts
This section defines concepts that serve to identify and name various This section defines concepts that serve to identify and name various
transformations and streams in a given RTP usage. For each concept transformations and streams in a given RTP usage. For each concept,
an attempt is made to list any alternate definitions and usages that alternate definitions and usages that co-exist today are listed along
co-exist today along with various characteristics that further with various characteristics that further describes the concept.
describes the concept. These concepts are divided into two These concepts are divided into two categories, one related to the
categories, one related to the chain of streams and transformations chain of streams and transformations that media can be subject to,
that media can be subject to, the other for entities involved in the the other for entities involved in the communication.
communication.
2.1. Media Chain 2.1. Media Chain
In the context of this memo, Media is a sequence of synthetic or In the context of this document, Media is a sequence of synthetic or
Physical Stimuli (Section 2.1.1) (sound waves, photons, key-strokes), Physical Stimuli (Section 2.1.1) (sound waves, photons, key-strokes),
represented in digital form. Synthesized Media is typically represented in digital form. Synthesized Media is typically
generated directly in the digital domain. generated directly in the digital domain.
This section contains the concepts that can be involved in taking This section contains the concepts that can be involved in taking
Media at a sender side and transporting it to a receiver, which may 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 recover a sequence of physical stimuli. This chain of concepts is of
two main types, streams and transformations. Streams are time-based two main types, streams and transformations. Streams are time-based
sequences of samples of the physical stimulus in various sequences of samples of the physical stimulus in various
representations, while transformations changes the representation of representations, while transformations changes the representation of
skipping to change at page 9, line 7 skipping to change at page 9, line 7
| Media Renderer | | Media Renderer |
+----------------------+ +----------------------+
| |
V V
Physical Stimulus Physical Stimulus
Figure 2: Receiver Side Concepts of the Media Chain Figure 2: Receiver Side Concepts of the Media Chain
2.1.1. Physical Stimulus 2.1.1. Physical Stimulus
The physical stimulus is a physical event that can be sampled and The Physical Stimulus is a physical event in the analog domain that
converted to digital form by an appropriate sensor or transducer. can be sampled and converted to digital form by an appropriate sensor
This include sound waves making up audio, photons in a light field, or transducer. This include sound waves making up audio, photons in
or other excitations or interactions with sensors, like keystrokes on a light field, or other excitations or interactions with sensors,
a keyboard. like keystrokes on a keyboard.
2.1.2. Media Capture 2.1.2. Media Capture
Media Capture is the process of transforming the Physical Stimulus Media Capture is the process of transforming the analog Physical
(Section 2.1.1) into digital Media using an appropriate sensor or Stimulus (Section 2.1.1) into digital Media using an appropriate
transducer. The Media Capture performs a digital sampling of the sensor or transducer. The Media Capture performs a digital sampling
physical stimulus, usually periodically, and outputs this in some of the physical stimulus, usually periodically, and outputs this in
representation as a Raw Stream (Section 2.1.3). This data is some representation as a Raw Stream (Section 2.1.3). This data is
considered "Media", because it includes data that is periodically considered "Media", because it includes data that is periodically
sampled, or made up of a set of timed asynchronous events. The Media 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 is normally instantiated in some type of device, i.e. media
capture device. Examples of different types of media capturing capture device. Examples of different types of media capturing
devices are digital cameras, microphones connected to A/D converters, devices are digital cameras, microphones connected to A/D converters,
or keyboards. or keyboards.
Characteristics: Characteristics:
o A Media Capture is identified either by hardware/manufacturer ID o A Media Capture is identified either by hardware/manufacturer ID
skipping to change at page 9, line 43 skipping to change at page 9, line 43
o A Media Capture can generate an Encoded Stream (Section 2.1.7) if o A Media Capture can generate an Encoded Stream (Section 2.1.7) if
the capture device supports such a configuration. the capture device supports such a configuration.
o The nature of the Media Capture may impose constraints on the o The nature of the Media Capture may impose constraints on the
clock handling in some of the subsequent steps. For example, many clock handling in some of the subsequent steps. For example, many
audio or video capture devices are not completely free in audio or video capture devices are not completely free in
selecting the sample rate. selecting the sample rate.
2.1.3. Raw Stream 2.1.3. Raw Stream
The time progressing stream of digitally sampled information, usually A Raw Stream is the time progressing stream of digitally sampled
periodically sampled and provided by a Media Capture (Section 2.1.2). information, usually periodically sampled and provided by a Media
A Raw Stream can also contain synthesized Media that may not require Capture (Section 2.1.2). A Raw Stream can also contain synthesized
any explicit Media Capture, since it is already in an appropriate Media that may not require any explicit Media Capture, since it is
digital form. already in an appropriate digital form.
2.1.4. Media Source 2.1.4. Media Source
A Media Source is the logical source of a time progressing digital A Media Source is the logical source of a time progressing digital
media stream synchronized to a reference clock. This stream is media stream synchronized to a reference clock. This stream is
called a Source Stream (Section 2.1.5). This transformation takes 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 one or more Raw Streams (Section 2.1.3) and provides a Source Stream
as output. The output is synchronized with a reference clock 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 (Section 3.1), which can be as simple as a system local wall clock or
as complex as an NTP synchronized clock. as complex as an NTP synchronized clock.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
Figure 3: Conceptual Media Source in form of Audio Mixer Figure 3: Conceptual Media Source in form of Audio Mixer
Another possible example of a conceptual Media Source is a video Another possible example of a conceptual Media Source is a video
surveillance switch, where the input is multiple Source Streams from surveillance switch, where the input is multiple Source Streams from
different cameras, and the output is one of those Source Streams different cameras, and the output is one of those Source Streams
based on some selection criteria, like a round-robin or based on some based on some selection criteria, like a round-robin or based on some
video activity measure. video activity measure.
2.1.5. Source Stream 2.1.5. Source Stream
A stream of digital samples that has been synchronized with a A Source Stream is a stream of digital samples that has been
reference clock and comes from particular Media Source synchronized with a reference clock and comes from particular Media
(Section 2.1.4). Source (Section 2.1.4).
2.1.6. Media Encoder 2.1.6. Media Encoder
A Media Encoder is a transform that is responsible for encoding the A Media Encoder is a transform that is responsible for encoding the
media data from a Source Stream (Section 2.1.5) into another media data from a Source Stream (Section 2.1.5) into another
representation, usually more compact, that is output as an Encoded representation, usually more compact, that is output as an Encoded
Stream (Section 2.1.7). Stream (Section 2.1.7).
The Media Encoder step commonly includes pre-encoding The Media Encoder step commonly includes pre-encoding
transformations, such as scaling, resampling etc. The Media Encoder transformations, such as scaling, resampling etc. The Media Encoder
skipping to change at page 11, line 43 skipping to change at page 11, line 43
| Scalable Media Encoder | | Scalable Media Encoder |
+--------------------------+ +--------------------------+
| | ... | | | ... |
V V V V V V
Encoded Dependent Dependent Encoded Dependent Dependent
Stream Stream Stream Stream Stream Stream
Figure 4: Scalable Media Encoder Input and Outputs Figure 4: Scalable Media Encoder Input and Outputs
There are also other variants of encoders, like so-called Multiple There are also other variants of encoders, like so-called Multiple
Description Coding (MDC). Such Media Encoder produce multiple Description Coding (MDC). Such Media Encoders produce multiple
independent and thus individually decodable Encoded Streams. independent and thus individually decodable Encoded Streams.
However, (logically) combining multiple of these Encoded Streams into However, (logically) combining multiple of these Encoded Streams into
a single Received Source Stream during decoding leads to an a single Received Source Stream during decoding leads to an
improvement in perceptual reproduced quality when compared to improvement in perceptual reproduced quality when compared to
decoding a single Encoded Stream. decoding a single Encoded Stream.
Creating multiple Encoded Streams from the same Source Stream, where Creating multiple Encoded Streams from the same Source Stream, where
the Encoded Streams are neither in a scalable nor in an MDC the Encoded Streams are neither in a scalable nor in an MDC
relationship is commonly utilized in Simulcast relationship is commonly utilized in Simulcast
[I-D.ietf-mmusic-sdp-simulcast] environments. [I-D.ietf-mmusic-sdp-simulcast] environments.
skipping to change at page 12, line 31 skipping to change at page 12, line 31
dependent on one or more Encoded Streams (Section 2.1.7) and zero or dependent on one or more Encoded Streams (Section 2.1.7) and zero or
more Dependent Streams to be possible to decode. more Dependent Streams to be possible to decode.
Each Dependent Stream has a set of dependencies. These dependencies Each Dependent Stream has a set of dependencies. These dependencies
must be understood by the parties in a Multimedia Session that intend must be understood by the parties in a Multimedia Session that intend
to use a Dependent Stream. to use a Dependent Stream.
2.1.9. Media Packetizer 2.1.9. Media Packetizer
The transformation of taking one or more Encoded (Section 2.1.7) or The transformation of taking one or more Encoded (Section 2.1.7) or
Dependent Streams (Section 2.1.8) and put their content into one or Dependent Streams (Section 2.1.8) and putting their content into one
more sequences of packets, normally RTP packets, and output Source or more sequences of packets, normally RTP packets, and output Source
RTP Streams (Section 2.1.10). This step includes both generating RTP RTP Streams (Section 2.1.10). This step includes both generating RTP
payloads as well as RTP packets. The Media Packetizer then selects payloads as well as RTP packets. The Media Packetizer then selects
which Synchronization source(s) (SSRC) [RFC3550] and RTP Sessions to which Synchronization source(s) (SSRC) [RFC3550] and RTP Sessions to
use. use.
The Media Packetizer can combine multiple Encoded or Dependent The Media Packetizer can combine multiple Encoded or Dependent
Streams into one or more RTP Streams: Streams into one or more RTP Streams:
o The Media Packetizer can use multiple inputs when producing a o The Media Packetizer can use multiple inputs when producing a
single RTP Stream. One such example is SRST packetization when single RTP Stream. One such example is SRST packetization when
using Scalable Video Coding (SVC) (Section 3.7). using Scalable Video Coding (SVC) (Section 3.7).
o The Media Packetizer can also produce multiple RTP Streams, for o The Media Packetizer can also produce multiple RTP Streams, for
example when Encoded and/or Dependent Streams are distributed over example when Encoded and/or Dependent Streams are distributed over
multiple RTP Streams. One example of this is MRMT packetization multiple RTP Streams. One example of this is MRMT packetization
when using SVC (Section 3.7). when using SVC (Section 3.7).
2.1.10. RTP Stream 2.1.10. RTP Stream
A stream of RTP packets containing media data, source or redundant. An RTP Stream is a stream of RTP packets containing media data,
The RTP Stream is identified by an SSRC belonging to a particular RTP source or redundant. The RTP Stream is identified by an SSRC
Session. The RTP Session is identified as discussed in belonging to a particular RTP Session. The RTP Session is identified
Section 2.2.2. as discussed in Section 2.2.2.
A Source RTP Stream is an RTP Stream containing at least some content A Source RTP Stream is an RTP Stream directly related to an Encoded
from an Encoded Stream (Section 2.1.7) at some point during its Stream (Section 2.1.7), targeted for transport over RTP without any
lifetime. Source material is any media material that is produced for additional RTP-based Redundancy (Section 2.1.11) applied.
transport over RTP without any additional RTP-based redundancy
applied. Note that RTP-based redundancy excludes the type of
redundancy that most suitable Media Encoders (Section 2.1.6) may add
to the media format of the Encoded Stream that makes it cope better
with inevitable RTP packet losses. This is further described in RTP-
based Redundancy (Section 2.1.11) and Redundancy RTP Stream
(Section 2.1.12).
Characteristics: Characteristics:
o Each RTP Stream is identified by a Synchronization source (SSRC) o Each RTP Stream is identified by a Synchronization source (SSRC)
[RFC3550] that is carried in every RTP and RTP Control Protocol [RFC3550] that is carried in every RTP and RTP Control Protocol
(RTCP) packet header. The SSRC is unique in a specific RTP (RTCP) packet header. The SSRC is unique in a specific RTP
Session context. Session context.
o At any given point in time, a RTP Stream can have one and only one o At any given point in time, a RTP Stream can have one and only one
SSRC, but SSRCs for a given RTP Stream can change over time. SSRC SSRC, but SSRCs for a given RTP Stream can change over time. SSRC
skipping to change at page 13, line 51 skipping to change at page 13, line 44
single Media Source. single Media Source.
o Several RTP Streams, each with their own SSRC, can be carried in a o Several RTP Streams, each with their own SSRC, can be carried in a
single RTP Session. single RTP Session.
2.1.11. RTP-based Redundancy 2.1.11. RTP-based Redundancy
RTP-based Redundancy is defined here as a transformation that RTP-based Redundancy is defined here as a transformation that
generates redundant or repair packets sent out as a Redundancy RTP generates redundant or repair packets sent out as a Redundancy RTP
Stream (Section 2.1.12) to mitigate network transport impairments, Stream (Section 2.1.12) to mitigate network transport impairments,
like packet loss and delay. 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 inevitable RTP packet losses.
The RTP-based Redundancy exists in many flavors; they may be The RTP-based Redundancy exists in many flavors; they may be
generating independent Repair Streams that are used in addition to generating independent Repair Streams that are used in addition to
the Source Stream (like RTP Retransmission (Section 3.10) and some the Source Stream (like RTP Retransmission (Section 3.10) and some
special types of Forward Error Correction, like RTP stream special types of Forward Error Correction, like RTP stream
duplication (Section 3.8)), they may generate a new Source Stream by duplication (Section 3.8)), they may generate a new Source Stream by
combining redundancy information with source information (Using XOR combining redundancy information with source information (Using XOR
FEC (Section 3.11) as a redundancy payload (Section 3.9)), or FEC (Section 3.11) as a redundancy payload (Section 3.9)), or
completely replace the source information with only redundancy completely replace the source information with only redundancy
packets. packets.
2.1.12. Redundancy RTP Stream 2.1.12. Redundancy RTP Stream
A RTP Stream (Section 2.1.10) that contains no original source data, A Redundancy RTP Stream is an RTP Stream (Section 2.1.10) that
only redundant data, which may either be used standalone or be contains no original source data, only redundant data, which may
combined with one or more Received RTP Streams (Section 2.1.23) to either be used standalone or be combined with one or more Received
produce Repaired RTP Streams (Section 2.1.26). RTP Streams (Section 2.1.23) to produce Repaired RTP Streams
(Section 2.1.26).
2.1.13. RTP-based Security 2.1.13. RTP-based Security
The optional RTP-based Security transformation applies security The optional RTP-based Security transformation applies security
services such as authentication, integrity protection and services such as authentication, integrity protection and
confidentiality to an input RTP Stream, like what is specified in The confidentiality to an input RTP Stream, like what is specified in The
Secure Real-time Transport Protocol (SRTP) [RFC3711], producing a Secure Real-time Transport Protocol (SRTP) [RFC3711], producing a
Secured RTP Stream (Section 2.1.14). Either an RTP Stream 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 (Section 2.1.10) or a Redundancy RTP Stream (Section 2.1.12) can be
used as input to this transformation. used as input to this transformation.
skipping to change at page 17, line 4 skipping to change at page 17, line 4
2.1.16. Media Transport Sender 2.1.16. Media Transport Sender
The first transformation within the Media Transport (Section 2.1.15) The first transformation within the Media Transport (Section 2.1.15)
is the Media Transport Sender. The sending Endpoint (Section 2.2.1) 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 takes an RTP Stream and emits the packets onto the network using the
transport association established for this Media Transport, thereby transport association established for this Media Transport, thereby
creating a Sent RTP Stream (Section 2.1.17). In the process, it creating a Sent RTP Stream (Section 2.1.17). In the process, it
transforms the RTP Stream in several ways. First, it generates the transforms the RTP Stream in several ways. First, it generates the
necessary protocol headers for the transport association, for example necessary protocol headers for the transport association, for example
IP and UDP headers, thus forming IP/UDP/RTP packets. In addition, IP and UDP headers, thus forming IP/UDP/RTP packets. In addition,
the Media Transport Sender may queue, pace or otherwise affect how the Media Transport Sender may queue, intentionally pace or otherwise
the packets are emitted onto the network, thereby potentially affect how the packets are emitted onto the network, thereby
introducing delay, jitter and inter packet spacings that characterize potentially introducing delay and delay variations [RFC5481] that
the Sent RTP Stream. characterize the Sent RTP Stream.
2.1.17. Sent RTP Stream 2.1.17. Sent RTP Stream
The Sent RTP Stream is the RTP Stream as entering the first hop of 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 the network path to its destination. The Sent RTP Stream is
identified using network transport addresses, like for IP/UDP the identified using network transport addresses, like for IP/UDP the
5-tuple (source IP address, source port, destination IP address, 5-tuple (source IP address, source port, destination IP address,
destination port, and protocol (UDP)). destination port, and protocol (UDP)).
2.1.18. Network Transport 2.1.18. Network Transport
Network Transport is the transformation that subjects the Sent RTP Network Transport is the transformation that subjects the Sent RTP
Stream (Section 2.1.17) to traveling from the source to the Stream (Section 2.1.17) to traveling from the source to the
destination through the network. This transformation can result in destination through the network. This transformation can result in
loss of some packets, varying delay on a per packet basis, packet loss of some packets, delay and delay variation on a per packet
duplication, and packet header or data corruption. This basis, packet duplication, and packet header or data corruption.
transformation produces a Transported RTP Stream (Section 2.1.19) at This transformation produces a Transported RTP Stream
the exit of the network path. (Section 2.1.19) at the exit of the network path.
2.1.19. Transported RTP Stream 2.1.19. Transported RTP Stream
The RTP Stream that is emitted out of the network path at the The Transported RTP Stream is the RTP Stream that is emitted out of
destination, subjected to the Network Transport's transformation the network path at the destination, subjected to the Network
(Section 2.1.18). Transport's transformation (Section 2.1.18).
2.1.20. Media Transport Receiver 2.1.20. Media Transport Receiver
The receiver Endpoint's (Section 2.2.1) transformation of the The Media Transport Receiver is the receiver Endpoint's
Transported RTP Stream (Section 2.1.19) by its reception process, (Section 2.2.1) transformation of the Transported RTP Stream
which results in the Received RTP Stream (Section 2.1.23). This (Section 2.1.19) by its reception process, which results in the
transformation includes transport checksums being verified. Sensible Received RTP Stream (Section 2.1.23). This transformation includes
system designs typically either discard packets with mis-matching transport checksums being verified. Sensible system designs
checksums, or pass them on while somehow marking them in the typically either discard packets with mis-matching checksums, or pass
resulting Received RTP Stream so to alert subsequent transformations them on while somehow marking them in the resulting Received RTP
about the possible corrupt state. In this context it is worth noting Stream so to alert subsequent transformations about the possible
that there is typically some probability for corrupt packets to pass corrupt state. In this context it is worth noting that there is
through undetected (with a seemingly correct checksum). Other 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 transformations can compensate for delay variations in receiving a
packet on the network interface and providing it to the application packet on the network interface and providing it to the application
(de-jitter buffer). (de-jitter buffer).
2.1.21. Received Secured RTP Stream 2.1.21. Received Secured RTP Stream
This is the Secured RTP Stream (Section 2.1.14) resulting from the This is the Secured RTP Stream (Section 2.1.14) resulting from the
Media Transport (Section 2.1.15) aggregate transformation. Media Transport (Section 2.1.15) aggregate transformation.
2.1.22. RTP-based Validation 2.1.22. RTP-based Validation
skipping to change at page 18, line 24 skipping to change at page 18, line 24
is either not usable and must be discarded, or may be usable but is either not usable and must be discarded, or may be usable but
cannot be trusted. If the transformation succeeds, the result can be cannot be trusted. If the transformation succeeds, the result can be
a Received RTP Stream (Section 2.1.23) or a Received Redundancy RTP 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 Stream (Section 2.1.24), depending on what was input to the
corresponding RTP-based Security transformation, but can also be a corresponding RTP-based Security transformation, but can also be a
Received Secured RTP Stream (Section 2.1.21) in case several RTP- Received Secured RTP Stream (Section 2.1.21) in case several RTP-
based Security transformations were applied. based Security transformations were applied.
2.1.23. Received RTP Stream 2.1.23. Received RTP Stream
The RTP Stream (Section 2.1.10) resulting from the Media Transport's The Received RTP Stream is the RTP Stream (Section 2.1.10) resulting
aggregate transformation (Section 2.1.15), i.e. subjected to packet from the Media Transport's aggregate transformation (Section 2.1.15),
loss, packet corruption, packet duplication and varying transmission i.e. subjected to packet loss, packet corruption, packet duplication,
delay from sender to receiver. delay, and delay variation from sender to receiver.
2.1.24. Received Redundancy RTP Stream 2.1.24. Received Redundancy RTP Stream
The Redundancy RTP Stream (Section 2.1.12) resulting from the Media The Received Redundancy RTP Stream is the Redundancy RTP Stream
Transport transformation, i.e. subjected to packet loss, packet (Section 2.1.12) resulting from the Media Transport transformation,
corruption, and varying transmission delay from sender to receiver. i.e. subjected to packet loss, packet corruption, delay, and delay
variation from sender to receiver.
2.1.25. RTP-based Repair 2.1.25. RTP-based Repair
RTP-based Repair is a Transformation that takes as input zero or more 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 Received RTP Streams (Section 2.1.23) and one or more Received
Redundancy RTP Streams (Section 2.1.24), and produces one or more 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 Repaired RTP Streams (Section 2.1.26) that are as close to the
corresponding sent Source RTP Streams (Section 2.1.10) as possible, corresponding sent Source RTP Streams (Section 2.1.10) as possible,
using different RTP-based repair methods, for example the ones using different RTP-based repair methods, for example the ones
referred in RTP-based Redundancy (Section 2.1.11). referred in RTP-based Redundancy (Section 2.1.11).
2.1.26. Repaired RTP Stream 2.1.26. Repaired RTP Stream
A Received RTP Stream (Section 2.1.23) for which Received Redundancy A Repaired RTP Stream is a Received RTP Stream (Section 2.1.23) for
RTP Stream (Section 2.1.24) information has been used to try to which Received Redundancy RTP Stream (Section 2.1.24) information has
recover the Source RTP Stream (Section 2.1.10) as it was before Media been used to try to recover the Source RTP Stream (Section 2.1.10) as
Transport (Section 2.1.15). it was before Media Transport (Section 2.1.15).
2.1.27. Media Depacketizer 2.1.27. Media Depacketizer
A Media Depacketizer takes one or more RTP Streams (Section 2.1.10), A Media Depacketizer takes one or more RTP Streams (Section 2.1.10),
depacketizes them, and attempts to reconstitute the Encoded Streams depacketizes them, and attempts to reconstitute the Encoded Streams
(Section 2.1.7) or Dependent Streams (Section 2.1.8) present in those (Section 2.1.7) or Dependent Streams (Section 2.1.8) present in those
RTP Streams. RTP Streams.
In practical implementations, the Media Depacketizer and the Media In practical implementations, the Media Depacketizer and the Media
Decoder may be tightly coupled and share information to improve or Decoder may be tightly coupled and share information to improve or
optimize the overall decoding and error concealment process. It is, optimize the overall decoding and error concealment process. It is,
however, not expected that there would be any benefit in defining a however, not expected that there would be any benefit in defining a
taxonomy for those detailed (and likely very implementation- taxonomy for those detailed (and likely very implementation-
dependent) steps. dependent) steps.
2.1.28. Received Encoded Stream 2.1.28. Received Encoded Stream
The received version of an Encoded Stream (Section 2.1.7). The Received Encoded Stream is the received version of an Encoded
Stream (Section 2.1.7).
2.1.29. Media Decoder 2.1.29. Media Decoder
A Media Decoder is a transformation that is responsible for decoding A Media Decoder is a transformation that is responsible for decoding
Encoded Streams (Section 2.1.7) and any Dependent Streams Encoded Streams (Section 2.1.7) and any Dependent Streams
(Section 2.1.8) into a Source Stream (Section 2.1.5). (Section 2.1.8) into a Source Stream (Section 2.1.5).
In practical implementations, the Media Decoder and the Media In practical implementations, the Media Decoder and the Media
Depacketizer may be tightly coupled and share information to improve Depacketizer may be tightly coupled and share information to improve
or optimize the overall decoding process in various ways. It is or optimize the overall decoding process in various ways. It is
skipping to change at page 19, line 43 skipping to change at page 19, line 44
taxonomy for those detailed (and likely very implementation- taxonomy for those detailed (and likely very implementation-
dependent) steps. dependent) steps.
A Media Decoder has to deal with any errors in the Encoded Streams A Media Decoder has to deal with any errors in the Encoded Streams
that resulted from corruption or failure to repair packet losses. that resulted from corruption or failure to repair packet losses.
Therefore, it commonly is robust to error and losses, and includes Therefore, it commonly is robust to error and losses, and includes
concealment methods. concealment methods.
2.1.30. Received Source Stream 2.1.30. Received Source Stream
The received version of a Source Stream (Section 2.1.5). The Received Source Stream is the received version of a Source Stream
(Section 2.1.5).
2.1.31. Media Sink 2.1.31. Media Sink
The Media Sink receives a Source Stream (Section 2.1.5) that The Media Sink receives a Source Stream (Section 2.1.5) that
contains, usually periodically, sampled media data together with contains, usually periodically, sampled media data together with
associated synchronization information. Depending on application, associated synchronization information. Depending on application,
this Source Stream then needs to be transformed into a Raw Stream 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.3) that is conveyed to the Media Render
(Section 2.1.33), synchronized with the output from other Media (Section 2.1.33), synchronized with the output from other Media
Sinks. The Media Sink may also be connected with a Media Source 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. (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 The Media Sink can further transform the Source Stream into a
representation that is suitable for rendering on the Media Render as representation that is suitable for rendering on the Media Render as
defined by the application or system-wide configuration. This defined by the application or system-wide configuration. This
include sample scaling, level adjustments etc. include sample scaling, level adjustments etc.
2.1.32. Received Raw Stream 2.1.32. Received Raw Stream
The received version of a Raw Stream (Section 2.1.3). The Received Raw Stream is the received version of a Raw Stream
(Section 2.1.3).
2.1.33. Media Render 2.1.33. Media Render
A Media Render takes a Raw Stream (Section 2.1.3) and converts it 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 into Physical Stimulus (Section 2.1.1) that a human user can
perceive. Examples of such devices are screens, and D/A converters perceive. Examples of such devices are screens, and D/A converters
connected to amplifiers and loudspeakers. connected to amplifiers and loudspeakers.
An Endpoint can potentially have multiple Media Renders for each An Endpoint can potentially have multiple Media Renders for each
media type. media type.
skipping to change at page 21, line 42 skipping to change at page 21, line 42
| | +------------+ | | +------------+ | | | | +------------+ | | +------------+ | |
| +----------------+ +----------------+ | | +----------------+ +----------------+ |
+------------------------------------------------------------+ +------------------------------------------------------------+
Figure 7: Example Point to Point Communication Session with two RTP Figure 7: Example Point to Point Communication Session with two RTP
Sessions Sessions
Figure 7 shows a high-level example representation of a very basic Figure 7 shows a high-level example representation of a very basic
point-to-point Communication Session between Participants A and B. point-to-point Communication Session between Participants A and B.
It uses two different audio and video RTP Sessions between A's and It uses two different audio and video RTP Sessions between A's and
B's Endpoints, using separate Media Transports for those RTP B's Endpoints, where each RTP Session is a group communications
Sessions. The Multimedia Session shared by the Participants can, for channel that can potentially carry a number of RTP Streams. It is
example, be established using SIP (i.e., there is a SIP Dialog using separate Media Transports for those RTP Sessions. The
between A and B). The terms used in Figure 7 are further elaborated Multimedia Session shared by the Participants can, for example, be
in the sub-sections below. established using SIP (i.e., there is a SIP Dialog between A and B).
The terms used in Figure 7 are further elaborated in the sub-sections
below.
2.2.1. Endpoint 2.2.1. Endpoint
A single addressable entity sending or receiving RTP packets. It may An Endpoint is a single addressable entity sending or receiving RTP
be decomposed into several functional blocks, but as long as it packets. It may be decomposed into several functional blocks, but as
behaves as a single RTP stack entity it is classified as a single long as it behaves as a single RTP stack entity it is classified as a
"Endpoint". single "Endpoint".
Characteristics: Characteristics:
o Endpoints can be identified in several different ways. While RTCP o Endpoints can be identified in several different ways. While RTCP
Canonical Names (CNAMEs) [RFC3550] provide a globally unique and Canonical Names (CNAMEs) [RFC3550] provide a globally unique and
stable identification mechanism for the duration of the stable identification mechanism for the duration of the
Communication Session (see Section 2.2.5), their validity applies Communication Session (see Section 2.2.5), their validity applies
exclusively within a Synchronization Context (Section 3.1). Thus exclusively within a Synchronization Context (Section 3.1). Thus
one Endpoint can handle multiple CNAMEs, each of which can be one Endpoint can handle multiple CNAMEs, each of which can be
shared among a set of Endpoints belonging to the same Participant shared among a set of Endpoints belonging to the same Participant
skipping to change at page 35, line 35 skipping to change at page 35, line 35
4. Mapping from Existing Terms 4. Mapping from Existing Terms
This section describes a selected set of terms from some relevant This section describes a selected set of terms from some relevant
IETF RFC and Internet Drafts (at the time of writing), using the IETF RFC and Internet Drafts (at the time of writing), using the
concepts from previous sections. concepts from previous sections.
4.1. Telepresence Terms 4.1. Telepresence Terms
The terms in this sub-section are used in the context of CLUE The terms in this sub-section are used in the context of CLUE
[I-D.ietf-clue-framework]. [I-D.ietf-clue-framework]. Note that some terms listed in this sub-
section use the same names as terms defined elsewhere in this
document. Unless explicitly stated (as "RTP Taxonomy") and in this
sub-section, they are to be read as references to the CLUE-specific
term within this sub-section.
4.1.1. Audio Capture 4.1.1. Audio Capture
Defined in CLUE as a Media Capture (Section 4.1.7) for audio. Defined in CLUE as a Media Capture (Section 4.1.7) for audio.
Describes an audio Media Source (Section 2.1.4). Describes an audio Media Source (Section 2.1.4).
4.1.2. Capture Device 4.1.2. Capture Device
Defined in CLUE as a device that converts physical input into an Defined in CLUE as a device that converts physical input into an
electrical signal. Identifies a physical entity performing a Media electrical signal. Identifies a physical entity performing an RTP
Capture (Section 2.1.2) transformation. Taxonomy Media Capture (Section 2.1.2) transformation.
4.1.3. Capture Encoding 4.1.3. Capture Encoding
Defined in CLUE as a specific encoding (Section 4.1.6) of a Media Defined in CLUE as a specific encoding (Section 4.1.6) of a Media
Capture (Section 4.1.7). Describes an Encoded Stream (Section 2.1.7) Capture (Section 4.1.7). Describes an Encoded Stream (Section 2.1.7)
related to CLUE specific semantic information. related to CLUE specific semantic information.
4.1.4. Capture Scene 4.1.4. Capture Scene
Defined in CLUE as a structure representing a spatial region captured Defined in CLUE as a structure representing a spatial region captured
skipping to change at page 36, line 20 skipping to change at page 36, line 26
related Media Sources (Section 2.1.4). related Media Sources (Section 2.1.4).
4.1.5. Endpoint 4.1.5. Endpoint
Defined in CLUE as a CLUE-capable device which is the logical point Defined in CLUE as a CLUE-capable device which is the logical point
of final termination through receiving, decoding and rendering and/or of final termination through receiving, decoding and rendering and/or
initiation through capturing, encoding, and sending of media streams initiation through capturing, encoding, and sending of media streams
(Section 4.1.10). CLUE further defines it to consist of one or more (Section 4.1.10). CLUE further defines it to consist of one or more
physical devices with source and sink media streams, and exactly one physical devices with source and sink media streams, and exactly one
[RFC4353] Participant. Describes exactly one Participant [RFC4353] Participant. Describes exactly one Participant
(Section 2.2.3) and one or more Endpoints (Section 2.2.1). (Section 2.2.3) and one or more RTP Taxonomy Endpoints
(Section 2.2.1).
4.1.6. Individual Encoding 4.1.6. Individual Encoding
Defined in CLUE as a set of parameters representing a way to encode a Defined in CLUE as a set of parameters representing a way to encode a
Media Capture (Section 4.1.7) to become a Capture Encoding Media Capture (Section 4.1.7) to become a Capture Encoding
(Section 4.1.3). Describes the configuration information needed to (Section 4.1.3). Describes the configuration information needed to
perform a Media Encoder (Section 2.1.6) transformation. perform a Media Encoder (Section 2.1.6) transformation.
4.1.7. Media Capture 4.1.7. Media Capture
Defined in CLUE as a source of media, such as from one or more Defined in CLUE as a source of media, such as from one or more
Capture Devices (Section 4.1.2) or constructed from other media Capture Devices (Section 4.1.2) or constructed from other media
streams (Section 4.1.10). Describes either a Media Capture streams (Section 4.1.10). Describes either an RTP Taxonomy Media
(Section 2.1.2) or a Media Source (Section 2.1.4), depending on in Capture (Section 2.1.2) or a Media Source (Section 2.1.4), depending
which context the term is used. on in which context the term is used.
4.1.8. Media Consumer 4.1.8. Media Consumer
Defined in CLUE as a CLUE-capable device that intends to receive Defined in CLUE as a CLUE-capable device that intends to receive
Capture Encodings (Section 4.1.3). Describes the media receiving Capture Encodings (Section 4.1.3). Describes the media receiving
part of an Endpoint (Section 2.2.1). part of an RTP Taxonomy Endpoint (Section 2.2.1).
4.1.9. Media Provider 4.1.9. Media Provider
Defined in CLUE as a CLUE-capable device that intends to send Capture Defined in CLUE as a CLUE-capable device that intends to send Capture
Encodings (Section 4.1.3). Describes the media sending part of an Encodings (Section 4.1.3). Describes the media sending part of an
Endpoint (Section 2.2.1). RTP Taxonomy Endpoint (Section 2.2.1).
4.1.10. Stream 4.1.10. Stream
Defined in CLUE as a Capture Encoding (Section 4.1.3) sent from a Defined in CLUE as a Capture Encoding (Section 4.1.3) sent from a
Media Provider (Section 4.1.9) to a Media Consumer (Section 4.1.8) Media Provider (Section 4.1.9) to a Media Consumer (Section 4.1.8)
via RTP. Describes an RTP Stream (Section 2.1.10). via RTP. Describes an RTP Stream (Section 2.1.10).
4.1.11. Video Capture 4.1.11. Video Capture
Defined in CLUE as a Media Capture (Section 4.1.7) for video. Defined in CLUE as a Media Capture (Section 4.1.7) for video.
skipping to change at page 37, line 50 skipping to change at page 38, line 10
A Multimedia Conference is a Communication Session (Section 2.2.5) A Multimedia Conference is a Communication Session (Section 2.2.5)
between two or more Participants (Section 2.2.3), along with the between two or more Participants (Section 2.2.3), along with the
software they are using to communicate. software they are using to communicate.
4.5. Multimedia Session 4.5. Multimedia Session
SDP [RFC4566] defines a Multimedia Session as a set of multimedia SDP [RFC4566] defines a Multimedia Session as a set of multimedia
senders and receivers and the data streams flowing from senders to senders and receivers and the data streams flowing from senders to
receivers, which would correspond to a set of Endpoints and the RTP receivers, which would correspond to a set of Endpoints and the RTP
Streams that flow between them. In this memo, Multimedia Session Streams that flow between them. In this document, Multimedia Session
(Section 2.2.4) also assumes those Endpoints belong to a set of (Section 2.2.4) also assumes those Endpoints belong to a set of
Participants that are engaged in communication via a set of related Participants that are engaged in communication via a set of related
RTP Streams. RTP Streams.
RTP [RFC3550] defines a Multimedia Session as a set of concurrent RTP RTP [RFC3550] defines a Multimedia Session as a set of concurrent RTP
Sessions among a common group of Participants. For example, a video Sessions among a common group of Participants. For example, a video
conference may contain an audio RTP Session and a video RTP Session. conference may contain an audio RTP Session and a video RTP Session.
This would correspond to a group of Participants (each using one or This would correspond to a group of Participants (each using one or
more Endpoints) sharing a set of concurrent RTP Sessions. In this more Endpoints) sharing a set of concurrent RTP Sessions. In this
memo, Multimedia Session also defines those RTP Sessions to have some document, Multimedia Session also defines those RTP Sessions to have
relation and be part of a communication among the Participants. some relation and be part of a communication among the Participants.
4.6. Multipoint Control Unit (MCU) 4.6. Multipoint Control Unit (MCU)
This term is commonly used to describe the central node in any type This term is commonly used to describe the central node in any type
of star topology [I-D.ietf-avtcore-rtp-topologies-update] conference. of star topology [I-D.ietf-avtcore-rtp-topologies-update] conference.
It describes a device that includes one Participant (Section 2.2.3) It describes a device that includes one Participant (Section 2.2.3)
(usually corresponding to a so-called conference focus) and one or (usually corresponding to a so-called conference focus) and one or
more related Endpoints (Section 2.2.1) (sometimes one or more per more related Endpoints (Section 2.2.1) (sometimes one or more per
conference Participant). conference Participant).
skipping to change at page 38, line 36 skipping to change at page 38, line 44
One of two transmission modes defined in H.264 based SVC [RFC6190], One of two transmission modes defined in H.264 based SVC [RFC6190],
the other mode being SST (Section 4.13). In Multi-Session the other mode being SST (Section 4.13). In Multi-Session
Transmission (MST), the SVC Media Encoder sends Encoded Streams and Transmission (MST), the SVC Media Encoder sends Encoded Streams and
Dependent Streams distributed across two or more RTP Streams in one Dependent Streams distributed across two or more RTP Streams in one
or more RTP Sessions. The term "MST" is ambiguous in RFC 6190, or more RTP Sessions. The term "MST" is ambiguous in RFC 6190,
especially since the name indicates the use of multiple "sessions", especially since the name indicates the use of multiple "sessions",
while MST type packetization is in fact required whenever two or more while MST type packetization is in fact required whenever two or more
RTP Streams are used for the Encoded and Dependent Streams, RTP Streams are used for the Encoded and Dependent Streams,
regardless if those are sent in one or more RTP Sessions. regardless if those are sent in one or more RTP Sessions.
Corresponds either to MRST or MRMT (Section 3.7) stream relations Corresponds either to MRST or MRMT (Section 3.7) stream relations
defined in this specification. The SVC RTP Payload RFC [RFC6190] is defined in this document. The SVC RTP Payload RFC [RFC6190] is not
not particularly explicit about how the common Media Encoder particularly explicit about how the common Media Encoder
(Section 2.1.6) relation between Encoded Streams (Section 2.1.7) and (Section 2.1.6) relation between Encoded Streams (Section 2.1.7) and
Dependent Streams (Section 2.1.8) is to be implemented. Dependent Streams (Section 2.1.8) is to be implemented.
4.8. Recording Device 4.8. Recording Device
WebRTC specifications use this term to refer to locally available WebRTC specifications use this term to refer to locally available
entities performing a Media Capture (Section 2.1.2) transformation. entities performing a Media Capture (Section 2.1.2) transformation.
4.9. RtcMediaStream 4.9. RtcMediaStream
skipping to change at page 39, line 34 skipping to change at page 39, line 44
One of two transmission modes defined in H.264 based SVC [RFC6190], One of two transmission modes defined in H.264 based SVC [RFC6190],
the other mode being MST (Section 4.7). In Single Session the other mode being MST (Section 4.7). In Single Session
Transmission (SST), the SVC Media Encoder sends Encoded Streams Transmission (SST), the SVC Media Encoder sends Encoded Streams
(Section 2.1.7) and Dependent Streams (Section 2.1.8) combined into a (Section 2.1.7) and Dependent Streams (Section 2.1.8) combined into a
single RTP Stream (Section 2.1.10) in a single RTP Session single RTP Stream (Section 2.1.10) in a single RTP Session
(Section 2.2.2), using the SVC RTP Payload format. The term "SST" is (Section 2.2.2), using the SVC RTP Payload format. The term "SST" is
ambiguous in RFC 6190, in that it sometimes refers to the use of a ambiguous in RFC 6190, in that it sometimes refers to the use of a
single RTP Stream, like in sections relating to packetization, and single RTP Stream, like in sections relating to packetization, and
sometimes appears to refer to use of a single RTP Session, like in sometimes appears to refer to use of a single RTP Session, like in
the context of discussing SDP. Closely corresponds to SRST the context of discussing SDP. Closely corresponds to SRST
(Section 3.7) defined in this specification. (Section 3.7) defined in this document.
4.14. SSRC 4.14. SSRC
RTP [RFC3550] defines this as "the source of a stream of RTP RTP [RFC3550] defines this as "the source of a stream of RTP
packets", which indicates that an SSRC is not only a unique packets", which indicates that an SSRC is not only a unique
identifier for the Encoded Stream (Section 2.1.7) carried in those identifier for the Encoded Stream (Section 2.1.7) carried in those
packets, but is also effectively used as a term to denote a Media packets, but is also effectively used as a term to denote a Media
Packetizer (Section 2.1.9). Packetizer (Section 2.1.9). In [RFC3550], it is stated that "a
synchronization source may change its data format, e.g., audio
encoding, over time". The related Encoded Stream data format in an
RTP Stream (Section 2.1.10) is identified by the RTP Payload Type.
Changing data format for an Encoded Stream effectively also changes
what Media Encoder (Section 2.1.6) that is used for the Encoded
Stream. No ambiguity is introduced to SSRC as Encoded Stream
identifier by allowing RTP Payload Type changes, as long as only a
single RTP Payload Type is valid for any given RTP Time Stamp. This
is aligned with and further described by Section 5.2 of [RFC3550].
5. Security Considerations 5. Security Considerations
This document simply tries to clarify the confusion prevalent in RTP The purpose of this document is to make clarifications and reduce the
taxonomy because of inconsistent usage by multiple technologies and confusion prevalent in RTP taxonomy because of inconsistent usage by
protocols making use of the RTP protocol. It does not introduce any multiple technologies and protocols making use of the RTP protocol.
new security considerations beyond those already well documented in It does not introduce any new security considerations beyond those
the RTP protocol [RFC3550] and each of the many respective already well documented in the RTP protocol [RFC3550] and each of the
specifications of the various protocols making use of it. many respective specifications of the various protocols making use of
it.
Hopefully having a well-defined common terminology and understanding Having a well-defined common terminology and understanding of the
of the complexities of the RTP architecture will help lead us to complexities of the RTP architecture will help lead us to better
better standards, avoiding security problems. standards, avoiding security problems.
6. Acknowledgement 6. Acknowledgement
This document has many concepts borrowed from several documents such This document has many concepts borrowed from several documents such
as WebRTC [I-D.ietf-rtcweb-overview], CLUE [I-D.ietf-clue-framework], as WebRTC [I-D.ietf-rtcweb-overview], CLUE [I-D.ietf-clue-framework],
and Multiplexing Architecture and Multiplexing Architecture
[I-D.westerlund-avtcore-transport-multiplexing]. The authors would [I-D.westerlund-avtcore-transport-multiplexing]. The authors would
like to thank all the authors of each of those documents. like to thank all the authors of each of those documents.
The authors would also like to acknowledge the insights, guidance and The authors would also like to acknowledge the insights, guidance and
skipping to change at page 40, line 39 skipping to change at page 41, line 14
8. IANA Considerations 8. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
9. Informative References 9. Informative References
[I-D.ietf-avtcore-rtp-multi-stream] [I-D.ietf-avtcore-rtp-multi-stream]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session", "Sending Multiple Media Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-07 (work in progress), draft-ietf-avtcore-rtp-multi-stream-08 (work in progress),
March 2015. July 2015.
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-08 (work in progress), ietf-avtcore-rtp-topologies-update-10 (work in progress),
June 2015. July 2015.
[I-D.ietf-clue-framework] [I-D.ietf-clue-framework]
Duckworth, M., Pepperell, A., and S. Wenger, "Framework Duckworth, M., Pepperell, A., and S. Wenger, "Framework
for Telepresence Multi-Streams", draft-ietf-clue- for Telepresence Multi-Streams", draft-ietf-clue-
framework-22 (work in progress), April 2015. framework-22 (work in progress), April 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-22 (work in progress), June 2015. negotiation-23 (work in progress), July 2015.
[I-D.ietf-mmusic-sdp-simulcast] [I-D.ietf-mmusic-sdp-simulcast]
Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
"Using Simulcast in SDP and RTP Sessions", draft-ietf- "Using Simulcast in SDP and RTP Sessions", draft-ietf-
mmusic-sdp-simulcast-00 (work in progress), January 2015. mmusic-sdp-simulcast-00 (work in progress), January 2015.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-14 Browser-based Applications", draft-ietf-rtcweb-overview-14
(work in progress), June 2015. (work in progress), June 2015.
[I-D.westerlund-avtcore-transport-multiplexing] [I-D.westerlund-avtcore-transport-multiplexing]
Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP
Sessions onto a Single Lower-Layer Transport", draft- Sessions onto a Single Lower-Layer Transport", draft-
westerlund-avtcore-transport-multiplexing-07 (work in westerlund-avtcore-transport-multiplexing-07 (work in
progress), October 2013. progress), October 2013.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997. DOI 10.17487/RFC2198, September 1997,
<http://www.rfc-editor.org/info/rfc2198>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the [RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353, February Session Initiation Protocol (SIP)", RFC 4353,
2006. DOI 10.17487/RFC4353, February 2006,
<http://www.rfc-editor.org/info/rfc4353>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>.
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
"RTP Payload Format and File Storage Format for the "RTP Payload Format and File Storage Format for the
Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband
(AMR-WB) Audio Codecs", RFC 4867, April 2007. (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867,
April 2007, <http://www.rfc-editor.org/info/rfc4867>.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5404] Westerlund, M. and I. Johansson, "RTP Payload Format for [RFC5404] Westerlund, M. and I. Johansson, "RTP Payload Format for
G.719", RFC 5404, January 2009. G.719", RFC 5404, DOI 10.17487/RFC5404, January 2009,
<http://www.rfc-editor.org/info/rfc5404>.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
March 2009, <http://www.rfc-editor.org/info/rfc5481>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
"RTP Payload Format for Scalable Video Coding", RFC 6190, "RTP Payload Format for Scalable Video Coding", RFC 6190,
May 2011. DOI 10.17487/RFC6190, May 2011,
<http://www.rfc-editor.org/info/rfc6190>.
[RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, April 2014. Clock Rates in an RTP Session", RFC 7160,
DOI 10.17487/RFC7160, April 2014,
<http://www.rfc-editor.org/info/rfc7160>.
[RFC7197] Begen, A., Cai, Y., and H. Ou, "Duplication Delay [RFC7197] Begen, A., Cai, Y., and H. Ou, "Duplication Delay
Attribute in the Session Description Protocol", RFC 7197, Attribute in the Session Description Protocol", RFC 7197,
April 2014. DOI 10.17487/RFC7197, April 2014,
<http://www.rfc-editor.org/info/rfc7197>.
[RFC7198] Begen, A. and C. Perkins, "Duplicating RTP Streams", RFC [RFC7198] Begen, A. and C. Perkins, "Duplicating RTP Streams",
7198, April 2014. RFC 7198, DOI 10.17487/RFC7198, April 2014,
<http://www.rfc-editor.org/info/rfc7198>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, April 2014. Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>.
[RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. [RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H.
Stokking, "RTP Clock Source Signalling", RFC 7273, June Stokking, "RTP Clock Source Signalling", RFC 7273,
2014. DOI 10.17487/RFC7273, June 2014,
<http://www.rfc-editor.org/info/rfc7273>.
Appendix A. Changes From Earlier Versions Appendix A. Changes From Earlier Versions
NOTE TO RFC EDITOR: Please remove this section prior to publication. NOTE TO RFC EDITOR: Please remove this section prior to publication.
A.1. Modifications Between WG Version -06 and -07 A.1. Modifications Between WG Version -07 and -08
Addresses comments from IESG evaluation.
o Made text more firm around what improvements this document
introduces.
o Clarified the distinction between analog and digital in sections
2.1.1 and 2.1.2.
o Removed the explicit requirement that a Source RTP Stream must
send at least some data from an Encoded Stream, replacing it with
a statement that it is directly related to the Encoded Stream.
o Moved the clarification that RTP-based Redundancy excludes Media
Encoder redundancy data in an Encoded Stream from Section 2.1.10
(RTP Stream) to 2.1.11 (RTP-based Redundancy), since that
statement applies to RTP-based Redundancy rather than to RTP
Stream.
o Added clarification that a Media Transport Sender can
intentionally pace packet transmission.
o Aligned text around delay variation to use this term throughout,
and added a reference to RFC 5481.
o Added that RTP Session is a group communications channel that can
potentially carry a number of RTP Streams, as an additional
clarification below Figure 7.
o Added a clarification in Section 4.1 around Telepresence Terms on
which references are to CLUE terms and which are to other sections
of this document, for terms that have the same name in CLUE as in
this document.
o Clarified in Section 4.14 what SSRC data format changes means,
since the RFC 3550 SSRC definition mentions this possibility.
o Editorial improvements.
A.2. Modifications Between WG Version -06 and -07
Addresses comments from AD review and GenArt review. Addresses comments from AD review and GenArt review.
o Added RTP-based Security and RTP-based Validation transform o Added RTP-based Security and RTP-based Validation transform
sections, as well as Secured RTP Stream and Received Secured RTP sections, as well as Secured RTP Stream and Received Secured RTP
Stream sections. Stream sections.
o Improved wording in Abstract and Introduction sections. o Improved wording in Abstract and Introduction sections.
o Clarified what is considered "media" in section 2.1.2 Media o Clarified what is considered "media" in section 2.1.2 Media
skipping to change at page 43, line 37 skipping to change at page 45, line 33
o Clarified description of Source RTP Stream in section 2.1.10. o Clarified description of Source RTP Stream in section 2.1.10.
o Clarified motivation to use separate Media Transports for o Clarified motivation to use separate Media Transports for
Simulcast in section 3.6. Simulcast in section 3.6.
o Added local descriptions of terms imported from CLUE framework. o Added local descriptions of terms imported from CLUE framework.
o Editorial improvements. o Editorial improvements.
A.2. Modifications Between WG Version -05 and -06 A.3. Modifications Between WG Version -05 and -06
o Clarified that a Redundancy RTP Stream can be used standalone to o Clarified that a Redundancy RTP Stream can be used standalone to
generate Repaired RTP Streams. generate Repaired RTP Streams.
o Clarified that (in accordance with above) RTP-based Repair takes o Clarified that (in accordance with above) RTP-based Repair takes
zero or more Received RTP Streams and one or more Received zero or more Received RTP Streams and one or more Received
Redundancy RTP Streams as input. Redundancy RTP Streams as input.
o Changed Figure 6 to more clearly show that Media Transport is o Changed Figure 6 to more clearly show that Media Transport is
terminated in the Endpoint, not in the Participant. terminated in the Endpoint, not in the Participant.
skipping to change at page 44, line 13 skipping to change at page 46, line 9
making those Endpoints share some properties. making those Endpoints share some properties.
o Merged previous section 3.5 on SST/MST with previous section 3.8 o Merged previous section 3.5 on SST/MST with previous section 3.8
on Layered Multi-Stream into a common section discussing the on Layered Multi-Stream into a common section discussing the
scalable/layered stream relation, and moved improved, descriptive scalable/layered stream relation, and moved improved, descriptive
text on SST and MST to new sub-sections 4.7 and 4.13, describing text on SST and MST to new sub-sections 4.7 and 4.13, describing
them as existing terms. them as existing terms.
o Editorial improvements. o Editorial improvements.
A.3. Modifications Between WG Version -04 and -05 A.4. Modifications Between WG Version -04 and -05
o Editorial improvements. o Editorial improvements.
A.4. Modifications Between WG Version -03 and -04 A.5. Modifications Between WG Version -03 and -04
o Changed "Media Redundancy" and "Media Repair" to "RTP-based o Changed "Media Redundancy" and "Media Repair" to "RTP-based
Redundancy" and "RTP-based Repair", since those terms are more Redundancy" and "RTP-based Repair", since those terms are more
specific and correct. specific and correct.
o Changed "End Point" to "Endpoint" and removed Editor's Note on o Changed "End Point" to "Endpoint" and removed Editor's Note on
this. this.
o Clarified that a Media Capture may impose constraints on clock o Clarified that a Media Capture may impose constraints on clock
handling. handling.
skipping to change at page 45, line 5 skipping to change at page 47, line 5
received by a Media Transport Receiver may still be corrupt. received by a Media Transport Receiver may still be corrupt.
o Clarified that a corrupt packet in a Media Transport Receiver is o Clarified that a corrupt packet in a Media Transport Receiver is
typically either discarded or somehow marked and passed on in the typically either discarded or somehow marked and passed on in the
Received RTP Stream. Received RTP Stream.
o Added Synchronization Context to Figure 6. o Added Synchronization Context to Figure 6.
o Editorial improvements and clarifications. o Editorial improvements and clarifications.
A.5. Modifications Between WG Version -02 and -03 A.6. Modifications Between WG Version -02 and -03
o Changed section 3.5, removing SST-SS/MS and MST-SS/MS, replacing o Changed section 3.5, removing SST-SS/MS and MST-SS/MS, replacing
them with SRST, MRST, and MRMT. them with SRST, MRST, and MRMT.
o Updated section 3.8 to align with terminology changes in section o Updated section 3.8 to align with terminology changes in section
3.5. 3.5.
o Added a new section 4.12, describing the term Multimedia o Added a new section 4.12, describing the term Multimedia
Conference. Conference.
o Changed reference from I-D to now published RFC 7273. o Changed reference from I-D to now published RFC 7273.
o Editorial improvements and clarifications. o Editorial improvements and clarifications.
A.6. Modifications Between WG Version -01 and -02 A.7. Modifications Between WG Version -01 and -02
o Major re-structure o Major re-structure
o Moved media chain Media Transport detailing up one section level 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 o Collapsed level 2 sub-sections of section 3 and thus moved level 3
sub-sections up one level, gathering some introductory text into sub-sections up one level, gathering some introductory text into
the beginning of section 3 the beginning of section 3
o Added that not only SSRC collision, but also a clock rate change o Added that not only SSRC collision, but also a clock rate change
skipping to change at page 46, line 16 skipping to change at page 48, line 16
section per term, mainly by moving text from sections 2 and 3 section per term, mainly by moving text from sections 2 and 3
o Changed all occurrences of Packet Stream to RTP Stream o Changed all occurrences of Packet Stream to RTP Stream
o Moved all normative references to informative, since this is an o Moved all normative references to informative, since this is an
informative document informative document
o Added references to RFC 7160, RFC 7197 and RFC 7198, and removed o Added references to RFC 7160, RFC 7197 and RFC 7198, and removed
unused references unused references
A.7. Modifications Between WG Version -00 and -01 A.8. Modifications Between WG Version -00 and -01
o WG version -00 text is identical to individual draft -03 o WG version -00 text is identical to individual draft -03
o Amended description of SVC SST and MST encodings with respect to o Amended description of SVC SST and MST encodings with respect to
concepts defined in this text concepts defined in this text
o Removed UML as normative reference, since the text no longer uses o Removed UML as normative reference, since the text no longer uses
any UML notation any UML notation
o Removed a number of level 4 sections and moved out text to the o Removed a number of level 4 sections and moved out text to the
level above level above
A.8. Modifications Between Version -02 and -03 A.9. Modifications Between Version -02 and -03
o Section 4 rewritten (and new communication topologies added) to o Section 4 rewritten (and new communication topologies added) to
reflect the major updates to Sections 1-3 reflect the major updates to Sections 1-3
o Section 8 removed (carryover from initial -00 draft) o Section 8 removed (carryover from initial -00 draft)
o General clean up of text, grammar and nits o General clean up of text, grammar and nits
A.9. Modifications Between Version -01 and -02 A.10. Modifications Between Version -01 and -02
o Section 2 rewritten to add both streams and transformations in the o Section 2 rewritten to add both streams and transformations in the
media chain. media chain.
o Section 3 rewritten to focus on exposing relationships. o Section 3 rewritten to focus on exposing relationships.
A.10. Modifications Between Version -00 and -01 A.11. Modifications Between Version -00 and -01
o Too many to list o Too many to list
o Added new authors o Added new authors
o Updated content organization and presentation o Updated content organization and presentation
Authors' Addresses Authors' Addresses
Jonathan Lennox Jonathan Lennox
 End of changes. 82 change blocks. 
190 lines changed or deleted 274 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/