draft-ietf-avtext-rtp-grouping-taxonomy-04.txt   draft-ietf-avtext-rtp-grouping-taxonomy-05.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: July 20, 2015 AVA Expires: July 26, 2015 AVA
S. Nandakumar S. Nandakumar
G. Salgueiro G. Salgueiro
Cisco Systems Cisco Systems
B. Burman B. Burman
Ericsson Ericsson
January 16, 2015 January 22, 2015
A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport
Protocol (RTP) Sources Protocol (RTP) Sources
draft-ietf-avtext-rtp-grouping-taxonomy-04 draft-ietf-avtext-rtp-grouping-taxonomy-05
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 relationships document describes a number of existing and proposed relationships
among RTP sources, and attempts to define common terminology for among RTP sources, and attempts to define 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 July 20, 2015. This Internet-Draft will expire on July 26, 2015.
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 3, line 22 skipping to change at page 3, line 22
3.3. Participant . . . . . . . . . . . . . . . . . . . . . . . 23 3.3. Participant . . . . . . . . . . . . . . . . . . . . . . . 23
3.4. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 23 3.4. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 23
3.5. Single- and Multi-Session Transmission of Dependent 3.5. Single- and Multi-Session Transmission of Dependent
Streams . . . . . . . . . . . . . . . . . . . . . . . . . 23 Streams . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6. Multi-Channel Audio . . . . . . . . . . . . . . . . . . . 24 3.6. Multi-Channel Audio . . . . . . . . . . . . . . . . . . . 24
3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 24 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 24
3.8. Layered Multi-Stream . . . . . . . . . . . . . . . . . . 25 3.8. Layered Multi-Stream . . . . . . . . . . . . . . . . . . 25
3.9. RTP Stream Duplication . . . . . . . . . . . . . . . . . 27 3.9. RTP Stream Duplication . . . . . . . . . . . . . . . . . 27
3.10. Redundancy Format . . . . . . . . . . . . . . . . . . . . 27 3.10. Redundancy Format . . . . . . . . . . . . . . . . . . . . 27
3.11. RTP Retransmission . . . . . . . . . . . . . . . . . . . 28 3.11. RTP Retransmission . . . . . . . . . . . . . . . . . . . 28
3.12. Forward Error Correction . . . . . . . . . . . . . . . . 29 3.12. Forward Error Correction . . . . . . . . . . . . . . . . 30
3.13. RTP Stream Separation . . . . . . . . . . . . . . . . . . 31 3.13. RTP Stream Separation . . . . . . . . . . . . . . . . . . 31
3.14. Multiple RTP Sessions over one Media Transport . . . . . 32 3.14. Multiple RTP Sessions over one Media Transport . . . . . 32
4. Mapping from Existing Terms . . . . . . . . . . . . . . . . . 32 4. Mapping from Existing Terms . . . . . . . . . . . . . . . . . 32
4.1. Telepresence Terms . . . . . . . . . . . . . . . . . . . 32 4.1. Telepresence Terms . . . . . . . . . . . . . . . . . . . 32
4.1.1. Audio Capture . . . . . . . . . . . . . . . . . . . . 32 4.1.1. Audio Capture . . . . . . . . . . . . . . . . . . . . 32
4.1.2. Capture Device . . . . . . . . . . . . . . . . . . . 32 4.1.2. Capture Device . . . . . . . . . . . . . . . . . . . 32
4.1.3. Capture Encoding . . . . . . . . . . . . . . . . . . 32 4.1.3. Capture Encoding . . . . . . . . . . . . . . . . . . 32
4.1.4. Capture Scene . . . . . . . . . . . . . . . . . . . . 33 4.1.4. Capture Scene . . . . . . . . . . . . . . . . . . . . 33
4.1.5. Endpoint . . . . . . . . . . . . . . . . . . . . . . 33 4.1.5. Endpoint . . . . . . . . . . . . . . . . . . . . . . 33
4.1.6. Individual Encoding . . . . . . . . . . . . . . . . . 33 4.1.6. Individual Encoding . . . . . . . . . . . . . . . . . 33
skipping to change at page 4, line 6 skipping to change at page 4, line 6
4.9. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . . 35 4.9. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . . 35
4.10. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . 35 4.10. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . 35
4.11. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 35 4.11. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 35
4.12. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.12. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5. Security Considerations . . . . . . . . . . . . . . . . . . . 35 5. Security Considerations . . . . . . . . . . . . . . . . . . . 35
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 36 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 36
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. Informative References . . . . . . . . . . . . . . . . . . . 36 9. Informative References . . . . . . . . . . . . . . . . . . . 36
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 38 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 38
A.1. Modifications Between WG Version -03 and -04 . . . . . . 38 A.1. Modifications Between WG Version -04 and -05 . . . . . . 38
A.2. Modifications Between WG Version -02 and -03 . . . . . . 39 A.2. Modifications Between WG Version -03 and -04 . . . . . . 38
A.3. Modifications Between WG Version -01 and -02 . . . . . . 39 A.3. Modifications Between WG Version -02 and -03 . . . . . . 39
A.4. Modifications Between WG Version -00 and -01 . . . . . . 40 A.4. Modifications Between WG Version -01 and -02 . . . . . . 39
A.5. Modifications Between Version -02 and -03 . . . . . . . . 40 A.5. Modifications Between WG Version -00 and -01 . . . . . . 40
A.6. Modifications Between Version -01 and -02 . . . . . . . . 41 A.6. Modifications Between Version -02 and -03 . . . . . . . . 40
A.7. Modifications Between Version -00 and -01 . . . . . . . . 41 A.7. Modifications Between Version -01 and -02 . . . . . . . . 41
A.8. Modifications Between Version -00 and -01 . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
The existing taxonomy of sources in RTP is often regarded as The existing taxonomy of sources in RTP is often regarded as
confusing and inconsistent. Consequently, a deep understanding of confusing and inconsistent. Consequently, a deep understanding of
how the different terms relate to each other becomes a real how the different terms relate to each other becomes a real
challenge. Frequently cited examples of this confusion are (1) how challenge. Frequently cited examples of this confusion are (1) how
different protocols that make use of RTP use the same terms to different protocols that make use of RTP use the same terms to
signify different things and (2) how the complexities addressed at signify different things and (2) how the complexities addressed at
skipping to change at page 4, line 49 skipping to change at page 4, line 50
an attempt is made to list any alternate definitions and usages that an attempt is made to list any alternate definitions and usages that
co-exist today along with various characteristics that further co-exist today along with various characteristics that further
describes the concept. These concepts are divided into two describes the concept. These concepts are divided into two
categories, one related to the chain of streams and transformations categories, one related to the chain of streams and transformations
that media can be subject to, the other for entities involved in the that media can be subject to, 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 memo, Media is a sequence of synthetic or
Physical Stimulus (Section 2.1.1) (sound waves, photons, key- Physical Stimuli (Section 2.1.1) (sound waves, photons, key-strokes),
strokes), represented in digital form. Synthesized Media is represented in digital form. Synthesized Media is typically
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 stimulus. This chain of concepts is recover a sequence of physical stimuli. This chain of concepts is of
of two main types, streams and transformations. Streams are time- two main types, streams and transformations. Streams are time-based
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
the streams in some way. the streams in some way.
The below examples are basic ones and it is important to keep in mind 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 that this conceptual model enables more complex usages. Some will be
further discussed in later sections of this document. In general the further discussed in later sections of this document. In general the
following applies to this model: following applies to this model:
o A transformation may have zero or more inputs and one or more o A transformation may have zero or more inputs and one or more
outputs. outputs.
skipping to change at page 5, line 44 skipping to change at page 5, line 46
o There are no formal limitations on how streams are connected to o There are no formal limitations on how streams are connected to
transformations, this may include loops if required by a transformations, this may include loops if required by a
particular transformation. particular transformation.
It is also important to remember that this is a conceptual model. It is also important to remember that this is a conceptual model.
Thus real-world implementations may look different and have different Thus real-world implementations may look different and have different
structure. structure.
To provide a basic understanding of the relationships in the chain we To provide a basic understanding of the relationships in the chain we
below first introduce the concepts for the sender side (Figure 1). first introduce the concepts for the sender side (Figure 1). This
This covers physical stimulus until media packets are emitted onto covers physical stimuli until media packets are emitted onto the
the network. network.
Physical Stimulus Physical Stimulus
| |
V V
+--------------------+ +--------------------+
| Media Capture | | Media Capture |
+--------------------+ +--------------------+
| |
Raw Stream Raw Stream
V V
skipping to change at page 6, line 41 skipping to change at page 6, line 41
Source RTP Stream | Source RTP Stream |
V V V V
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| Media Transport | | Media Transport | | Media Transport | | Media Transport |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
Figure 1: Sender Side Concepts in the Media Chain Figure 1: Sender Side Concepts in the Media Chain
In Figure 1 we have included a branched chain to cover the concepts In Figure 1 we have included a branched chain to cover the concepts
for using redundancy to improve the reliability of the transport. for using redundancy to improve the reliability of the transport.
The Media Transport concept is an aggregate that is decomposed below The Media Transport concept is an aggregate that is decomposed in
in Section 2.1.13. Section 2.1.13.
Below we review a receiver media chain (Figure 2) matching the sender In Figure 2 we review a receiver media chain matching the sender
side, to look at the inverse transformations and their attempts to side, to look at the inverse transformations and their attempts to
recover identical streams as in the sender chain, subject to what may recover identical streams as in the sender chain, subject to what may
be lossy compression and imperfect Media Transport. Note that the be lossy compression and imperfect Media Transport. Note that the
streams out of a reverse transformation, like the Source Stream out streams out of a reverse transformation, like the Source Stream out
the Media Decoder are in many cases not the same as the corresponding 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 ones on the sender side, thus they are prefixed with a "Received" to
denote a potentially modified version. The reason for not being the denote a potentially modified version. The reason for not being the
same lies in the transformations that can be of irreversible type. same lies in the transformations that can be of irreversible type.
For example, lossy source coding in the Media Encoder prevents the For example, lossy source coding in the Media Encoder prevents the
Source Stream out of the Media Decoder to be the same as the one fed Source Stream out of the Media Decoder to be the same as the one fed
into the Media Encoder. Other reasons include packet loss or late into the Media Encoder. Other reasons include packet loss or late
loss in the Media Transport transformation that even RTP-based loss in the Media Transport transformation that even RTP-based
Repair, if used, fails to repair. It should be noted that some Repair, if used, fails to repair. However, some transformations are
transformations are not always present, like RTP-based Repair that not always present, like RTP-based Repair that cannot operate without
cannot operate without Redundancy RTP Streams. Redundancy RTP Streams.
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| Media Transport | | Media Transport | | Media Transport | | Media Transport |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| | | |
Received RTP Stream Received Redundancy RTP Stream Received RTP Stream Received Redundancy RTP Stream
| | | |
| +-------------------+ | +-------------------+
V V V V
+--------------------+ +--------------------+
skipping to change at page 9, line 14 skipping to change at page 9, line 14
Streams (Section 2.1.3) and provides a Source Stream as output. The Streams (Section 2.1.3) and provides a Source Stream as output. The
output is synchronized with a reference clock (Section 3.1), which 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 NTP can be as simple as a system local wall clock or as complex as NTP
synchronized. synchronized.
The output can be of different types. One type is directly The output can be of different types. One type is directly
associated with a particular Media Capture's Raw Stream. Others are associated with a particular Media Capture's Raw Stream. Others are
more conceptual sources, like an audio mix of multiple Source Streams more conceptual sources, like an audio mix of multiple Source Streams
(Figure 3). Mixing multiple streams typically requires that the (Figure 3). Mixing multiple streams typically requires that the
input streams are possible to relate in time, meaning that they have 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 the to be Source Streams (Section 2.1.5) rather than Raw Streams. In
below example, the generated Source Stream is a mix of the three Figure 3, the generated Source Stream is a mix of the three input
input Source Streams. Source Streams.
Source Source Source Source Source Source
Stream Stream Stream Stream Stream Stream
| | | | | |
V V V V V V
+--------------------------+ +--------------------------+
| Media Source |<-- Reference Clock | Media Source |<-- Reference Clock
| Mixer | | Mixer |
+--------------------------+ +--------------------------+
| |
skipping to change at page 10, line 21 skipping to change at page 10, line 21
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
can have a significant number of configuration options that affects can have a significant number of configuration options that affects
the properties of the Encoded Stream. This include properties such the properties of the Encoded Stream. This include properties such
as bit-rate, start points for decoding, resolution, bandwidth or as bit-rate, start points for decoding, resolution, bandwidth or
other fidelity affecting properties. The actually used codec is also other fidelity affecting properties. The actually used codec is also
an important factor in many communication systems. an important factor in many communication systems.
Scalable Media Encoders need special attention as they produce Scalable Media Encoders need special attention as they produce
multiple outputs that are potentially of different types. A scalable multiple outputs that are potentially of different types. As shown
Media Encoder takes one input Source Stream and encodes it into in Figure 4, a scalable Media Encoder takes one input Source Stream
multiple output streams of two different types; at least one Encoded and encodes it into multiple output streams of two different types;
Stream that is independently decodable and one or more Dependent at least one Encoded Stream that is independently decodable and one
Streams (Section 2.1.8). Decoding requires at least one Encoded or more Dependent Streams (Section 2.1.8). Decoding requires at
Stream and zero or more Dependent Streams. A Dependent Stream's least one Encoded Stream and zero or more Dependent Streams. A
dependency is one of the grouping relations this document discusses Dependent Stream's dependency is one of the grouping relations this
further in Section 3.8. document discusses further in Section 3.8.
Source Stream Source Stream
| |
V V
+--------------------------+ +--------------------------+
| Scalable Media Encoder | | Scalable Media Encoder |
+--------------------------+ +--------------------------+
| | ... | | | ... |
V V V V V V
Encoded Dependent Dependent Encoded Dependent Dependent
skipping to change at page 11, line 48 skipping to change at page 11, line 48
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 put their content into one or
more sequences of packets, normally RTP packets, and output Source 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. payloads as well as RTP packets.
The Media Packetizer can use multiple inputs when producing a single The Media Packetizer can use multiple inputs when producing a single
RTP Stream. One such example is SRST packetization when using SVC RTP Stream. One such example is SRST packetization when using
(Section 3.5). Scalable Video Coding (SVC) (Section 3.5).
The Media Packetizer can also produce multiple RTP Streams, for 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 when multiple RTP Streams. One example of this is MRMT packetization when
using SVC (Section 3.5). using SVC (Section 3.5).
Characteristics: Characteristics:
o The Media Packetizer will select which Synchronization source(s) o The Media Packetizer will select which Synchronization source(s)
(SSRC) [RFC3550] in which RTP Sessions that are used. (SSRC) [RFC3550] in which RTP Sessions that are used.
skipping to change at page 16, line 35 skipping to change at page 16, line 35
recover the Source RTP Stream (Section 2.1.10) as it was before Media recover the Source RTP Stream (Section 2.1.10) as it was before Media
Transport (Section 2.1.13). Transport (Section 2.1.13).
2.1.23. Media Depacketizer 2.1.23. 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.
It should be noted that in practical implementations, the Media In practical implementations, the Media Depacketizer and the Media
Depacketizer and the Media Decoder may be tightly coupled and share Decoder may be tightly coupled and share information to improve or
information to improve or optimize the overall decoding and error optimize the overall decoding and error concealment process. It is,
concealment process. It is, however, not expected that there would however, not expected that there would be any benefit in defining a
be any benefit in defining a taxonomy for those detailed (and likely taxonomy for those detailed (and likely very implementation-
very implementation-dependent) steps. dependent) steps.
2.1.24. Received Encoded Stream 2.1.24. Received Encoded Stream
The received version of an Encoded Stream (Section 2.1.7). The received version of an Encoded Stream (Section 2.1.7).
2.1.25. Media Decoder 2.1.25. 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).
It should be noted that in practical implementations, the Media In practical implementations, the Media Decoder and the Media
Decoder and the Media Depacketizer may be tightly coupled and share Depacketizer may be tightly coupled and share information to improve
information to improve or optimize the overall decoding process in or optimize the overall decoding process in various ways. It is
various ways. It is however not expected that there would be any however not expected that there would be any benefit in defining a
benefit in defining a taxonomy for those detailed (and likely very taxonomy for those detailed (and likely very implementation-
implementation-dependent) steps. dependent) steps.
Characteristics: Characteristics:
o A Media Decoder has to deal with any errors in the Encoded Streams o 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.26. Received Source Stream 2.1.26. Received Source Stream
skipping to change at page 18, line 47 skipping to change at page 18, line 47
| | | | Video |---Media Transport--->| | | | | | | | | Video |---Media Transport--->| | | | |
| | | | | | | | | | | | | | | | | | | |
| | | +-----------++----------------------++-----------+ | | | | | | +-----------++----------------------++-----------+ | | |
| | +-------------+| |+-------------+ | | | | +-------------+| |+-------------+ | |
| +----------------+ +----------------+ | | +----------------+ +----------------+ |
+------------------------------------------------------------+ +------------------------------------------------------------+
Figure 6: Example Point to Point Communication Session with two RTP Figure 6: Example Point to Point Communication Session with two RTP
Sessions Sessions
The figure above shows a high-level example representation of a very Figure 6 shows a high-level example representation of a very basic
basic point-to-point Communication Session between Participants A and point-to-point Communication Session between Participants A and B.
B. It uses two different audio and video RTP Sessions between A's It uses two different audio and video RTP Sessions between A's and
and B's Endpoints, using separate Media Transports for those RTP B's Endpoints, using separate Media Transports for those RTP
Sessions. The Multimedia Session shared by the Participants can, for Sessions. The Multimedia Session shared by the Participants can, for
example, be established using SIP (i.e., there is a SIP Dialog example, be established using SIP (i.e., there is a SIP Dialog
between A and B). The terms used in that figure are further between A and B). The terms used in Figure 6 are further elaborated
elaborated in the sub-sections below. in the sub-sections below.
2.2.1. Endpoint 2.2.1. Endpoint
A single addressable entity sending or receiving RTP packets. It may A single addressable entity sending or receiving RTP packets. It may
be decomposed into several functional blocks, but as long as it be decomposed into several functional blocks, but as long as it
behaves as a single RTP stack entity it is classified as a single behaves as a single RTP stack entity it is classified as a single
"Endpoint". "Endpoint".
Characteristics: Characteristics:
skipping to change at page 22, line 20 skipping to change at page 22, line 20
3.1.1. RTCP CNAME 3.1.1. RTCP CNAME
RFC3550 [RFC3550] describes Inter-media synchronization between RTP RFC3550 [RFC3550] describes Inter-media synchronization between RTP
Sessions based on RTCP CNAME, RTP and Network Time Protocol (NTP) Sessions based on RTCP CNAME, RTP and Network Time Protocol (NTP)
[RFC5905] formatted timestamps of a reference clock. As indicated in [RFC5905] formatted timestamps of a reference clock. As indicated in
[RFC7273], despite using NTP format timestamps, it is not required [RFC7273], despite using NTP format timestamps, it is not required
that the clock be synchronized to an NTP source. that the clock be synchronized to an NTP source.
3.1.2. Clock Source Signaling 3.1.2. Clock Source Signaling
[RFC7273] provides a mechanism to signal the clock source in SDP both [RFC7273] provides a mechanism to signal the clock source in Session
for the reference clock as well as the media clock, thus allowing a Description Protocol (SDP) [RFC4566] both for the reference clock as
Synchronization Context to be defined beyond the one defined by the well as the media clock, thus allowing a Synchronization Context to
usage of CNAME source descriptions. be defined beyond the one defined by the usage of CNAME source
descriptions.
3.1.3. Implicitly via RtcMediaStream 3.1.3. Implicitly via RtcMediaStream
The WebRTC WG defines "RtcMediaStream" with one or more WebRTC defines "RtcMediaStream" with one or more
"RtcMediaStreamTracks". All tracks in a "RtcMediaStream" are "RtcMediaStreamTracks". All tracks in a "RtcMediaStream" are
intended to be synchronized when rendered, implying that they must be intended to be synchronized when rendered, implying that they must be
generated such that synchronization is possible. generated such that synchronization is possible.
3.1.4. Explicitly via SDP Mechanisms 3.1.4. Explicitly via SDP Mechanisms
The SDP Grouping Framework [RFC5888] defines an m= line (Section 4.2) The SDP Grouping Framework [RFC5888] defines an m= line (Section 4.2)
grouping mechanism called "Lip Synchronization (LS)" for establishing grouping mechanism called "Lip Synchronization" (with LS
the synchronization requirement across m= lines when they map to identification-tag) for establishing the synchronization requirement
individual sources. across m= lines when they map to individual sources.
Source-Specific Media Attributes in SDP [RFC5576] extends the above Source-Specific Media Attributes in SDP [RFC5576] extends the above
mechanism when multiple Media Sources are described by a single m= mechanism when multiple Media Sources are described by a single m=
line. line.
3.2. Endpoint 3.2. Endpoint
Some applications requires knowledge of what Media Sources originate Some applications requires knowledge of what Media Sources originate
from a particular Endpoint (Section 2.2.1). This can include such from a particular Endpoint (Section 2.2.1). This can include such
decisions as packet routing between parts of the topology, knowing decisions as packet routing between parts of the topology, knowing
skipping to change at page 23, line 28 skipping to change at page 23, line 31
Identity information correctly associated with the Media Sources. Identity information correctly associated with the Media Sources.
This association is handled through the signaling solution to point This association is handled through the signaling solution to point
at a specific Multimedia Session where the Media Sources may be at a specific Multimedia Session where the Media Sources may be
explicitly or implicitly tied to a particular Endpoint. explicitly or implicitly tied to a particular Endpoint.
Participant information becomes more problematic due to Media Sources Participant information becomes more problematic due to Media Sources
that are generated through mixing or other conceptual processing of that are generated through mixing or other conceptual processing of
Raw Streams or Source Streams that originate from different Raw Streams or Source Streams that originate from different
Participants. This type of Media Sources can thus have a dynamically Participants. This type of Media Sources can thus have a dynamically
varying set of origins and Participants. RTP contains the concept of varying set of origins and Participants. RTP contains the concept of
Contributing Sources (CSRC) that carry information about the previous CSRC that carry information about the previous step origin of the
step origin of the included media content on RTP level. included media content on RTP level.
3.4. RtcMediaStream 3.4. RtcMediaStream
An RtcMediaStream in WebRTC is an explicit grouping of a set of Media An RtcMediaStream in WebRTC is an explicit grouping of a set of Media
Sources (RtcMediaStreamTracks) that share a common identifier and a Sources (RtcMediaStreamTracks) that share a common identifier and a
single Synchronization Context (Section 3.1). single Synchronization Context (Section 3.1).
3.5. Single- and Multi-Session Transmission of Dependent Streams 3.5. Single- and Multi-Session Transmission of Dependent Streams
Scalable media coding formats such as, for example, H.264 based Scalable media coding formats such as, for example, H.264 based SVC
Scalable Video Coding [RFC6190] has two modes of operation: [RFC6190] has two modes of operation:
1. In Single Session Transmission (SST), the SVC Media Encoder sends 1. In Single Session Transmission (SST), the SVC Media Encoder sends
Encoded Streams (Section 2.1.7) and Dependent Streams Encoded Streams (Section 2.1.7) and Dependent Streams
(Section 2.1.8) as a single RTP Stream (Section 2.1.10) in a (Section 2.1.8) as a single RTP Stream (Section 2.1.10) in a
single RTP Session (Section 2.2.2), using the SVC RTP Payload single RTP Session (Section 2.2.2), using the SVC RTP Payload
format. format.
2. In Multi-Session Transmission (MST), the SVC Media Encoder sends 2. In Multi-Session Transmission (MST), the SVC Media Encoder sends
Encoded Streams and Dependent Streams distributed across multiple Encoded Streams and Dependent Streams distributed across multiple
RTP Streams in one or more RTP Sessions. RTP Streams in one or more RTP Sessions.
skipping to change at page 24, line 40 skipping to change at page 24, line 44
Synchronization Context. These are independently encoded by a Media Synchronization Context. These are independently encoded by a Media
Encoder and the different Encoded Streams are packetized together in Encoder and the different Encoded Streams are packetized together in
a time synchronized way into a single Source RTP Stream, using the a time synchronized way into a single Source RTP Stream, using the
used codec's RTP Payload format. Examples of codecs that support used codec's RTP Payload format. Examples of codecs that support
multi-channel audio are PCMA and PCMU [RFC3551], AMR [RFC4867], and multi-channel audio are PCMA and PCMU [RFC3551], AMR [RFC4867], and
G.719 [RFC5404]. G.719 [RFC5404].
3.7. Simulcast 3.7. Simulcast
A Media Source represented as multiple independent Encoded Streams A Media Source represented as multiple independent Encoded Streams
constitutes a Simulcast or Multiple Description Coding of that Media constitutes a Simulcast or MDC of that Media Source. Figure 7 shows
Source. Figure 7 below shows an example of a Media Source that is an example of a Media Source that is encoded into three separate
encoded into three separate Simulcast streams, that are in turn sent Simulcast streams, that are in turn sent on the same Media Transport
on the same Media Transport flow. When using Simulcast, the RTP flow. When using Simulcast, the RTP Streams may be sharing RTP
Streams may be sharing RTP Session and Media Transport, or be Session and Media Transport, or be separated on different RTP
separated on different RTP Sessions and Media Transports, or any Sessions and Media Transports, or any combination of these two. It
combination of these two. It is other considerations that affect is other considerations that affect which usage is desirable, as
which usage is desirable, as discussed in Section 3.13. discussed in Section 3.13.
+----------------+ +----------------+
| Media Source | | Media Source |
+----------------+ +----------------+
Source Stream | Source Stream |
+----------------------+----------------------+ +----------------------+----------------------+
| | | | | |
V V V V V V
+------------------+ +------------------+ +------------------+ +------------------+ +------------------+ +------------------+
| Media Encoder | | Media Encoder | | Media Encoder | | Media Encoder | | Media Encoder | | Media Encoder |
skipping to change at page 25, line 49 skipping to change at page 25, line 49
3.8. Layered Multi-Stream 3.8. Layered Multi-Stream
Layered Multi-Stream (LMS) is a mechanism by which different portions Layered Multi-Stream (LMS) is a mechanism by which different portions
of a layered encoding of a Source Stream are sent using separate RTP of a layered encoding of a Source Stream are sent using separate RTP
Streams (sometimes in separate RTP Sessions). LMSs are useful for Streams (sometimes in separate RTP Sessions). LMSs are useful for
receiver control of layered media. receiver control of layered media.
A Media Source represented as an Encoded Stream and multiple A Media Source represented as an Encoded Stream and multiple
Dependent Streams constitutes a Media Source that has layered Dependent Streams constitutes a Media Source that has layered
dependencies. The figure below represents an example of a Media dependencies. Figure 8 represents an example of a Media Source that
Source that is encoded into three dependent layers, where two layers is encoded into three dependent layers, where two layers are sent on
are sent on the same Media Transport using different RTP Streams, the same Media Transport using different RTP Streams, i.e. SSRCs,
i.e. SSRCs, and the third layer is sent on a separate Media and the third layer is sent on a separate Media Transport.
Transport.
+----------------+ +----------------+
| Media Source | | Media Source |
+----------------+ +----------------+
| |
| |
V V
+---------------------------------------------------------+ +---------------------------------------------------------+
| Media Encoder | | Media Encoder |
+---------------------------------------------------------+ +---------------------------------------------------------+
skipping to change at page 27, line 10 skipping to change at page 27, line 10
Media Encoders use multiple Media Sources sharing Synchronization Media Encoders use multiple Media Sources sharing Synchronization
Context, and thus having a common CNAME, additional heuristics or Context, and thus having a common CNAME, additional heuristics or
identification need to be applied to create the MRST or MRMT identification need to be applied to create the MRST or MRMT
relationships between the RTP Streams. relationships between the RTP Streams.
3.9. RTP Stream Duplication 3.9. RTP Stream Duplication
RTP Stream Duplication [RFC7198], using the same or different Media RTP Stream Duplication [RFC7198], using the same or different Media
Transports, and optionally also delaying the duplicate [RFC7197], Transports, and optionally also delaying the duplicate [RFC7197],
offers a simple way to protect media flows from packet loss in some offers a simple way to protect media flows from packet loss in some
cases. It is a specific type of redundancy and all but one Source cases (see Figure 9). It is a specific type of redundancy and all
RTP Stream (Section 2.1.10) are effectively Redundancy RTP Streams but one Source RTP Stream (Section 2.1.10) are effectively Redundancy
(Section 2.1.12), but since both Source and Redundant RTP Streams are RTP Streams (Section 2.1.12), but since both Source and Redundant RTP
the same it does not matter which one is which. This can also be Streams are the same it does not matter which one is which. This can
seen as a specific type of Simulcast (Section 3.7) that transmits the also be seen as a specific type of Simulcast (Section 3.7) that
same Encoded Stream (Section 2.1.7) multiple times. transmits the same Encoded Stream (Section 2.1.7) multiple times.
+----------------+ +----------------+
| Media Source | | Media Source |
+----------------+ +----------------+
Source Stream | Source Stream |
V V
+----------------+ +----------------+
| Media Encoder | | Media Encoder |
+----------------+ +----------------+
Encoded Stream | Encoded Stream |
skipping to change at page 28, line 5 skipping to change at page 28, line 5
Figure 9: Example of RTP Stream Duplication Figure 9: Example of RTP Stream Duplication
3.10. Redundancy Format 3.10. Redundancy Format
The RTP Payload for Redundant Audio Data [RFC2198] defines a The RTP Payload for Redundant Audio Data [RFC2198] defines a
transport for redundant audio data together with primary data in the transport for redundant audio data together with primary data in the
same RTP payload. The redundant data can be a time delayed version same RTP payload. The redundant data can be a time delayed version
of the primary or another time delayed Encoded Stream using a of the primary or another time delayed Encoded Stream using a
different Media Encoder to encode the same Media Source as the different Media Encoder to encode the same Media Source as the
primary, as depicted below in Figure 10. primary, as depicted in Figure 10.
+--------------------+ +--------------------+
| Media Source | | Media Source |
+--------------------+ +--------------------+
| |
Source Stream Source Stream
| |
+------------------------+ +------------------------+
| | | |
V V V V
skipping to change at page 29, line 46 skipping to change at page 29, line 46
a Redundancy RTP Stream. The RTP Retransmission mechanism [RFC4588] a Redundancy RTP Stream. The RTP Retransmission mechanism [RFC4588]
is specified such that there is a one to one relation between the is specified such that there is a one to one relation between the
Source RTP Stream and the Redundancy RTP Stream. Therefore, a Source RTP Stream and the Redundancy RTP Stream. Therefore, a
Redundancy RTP Stream needs to be associated with its Source RTP Redundancy RTP Stream needs to be associated with its Source RTP
Stream. This is done based on CNAME selectors and heuristics to Stream. This is done based on CNAME selectors and heuristics to
match requested packets for a given Source RTP Stream with the match requested packets for a given Source RTP Stream with the
original sequence number in the payload of any new Redundancy RTP original sequence number in the payload of any new Redundancy RTP
Stream using the RTX payload format. In cases where the Redundancy Stream using the RTX payload format. In cases where the Redundancy
RTP Stream is sent in a separate RTP Session from the Source RTP RTP Stream is sent in a separate RTP Session from the Source RTP
Stream, these sessions are related, which is signaled by using the Stream, these sessions are related, which is signaled by using the
SDP Media Grouping's [RFC5888] FID semantics. SDP Media Grouping's [RFC5888] Flow Identification (FID
identification-tag) semantics.
3.12. Forward Error Correction 3.12. Forward Error Correction
The figure below (Figure 12) shows an example where two Media Figure 12 shows an example where two Media Sources' Source RTP
Sources' Source RTP Streams are protected by FEC. Source RTP Stream Streams are protected by Forward Error Correction (FEC). Source RTP
A has a RTP-based Redundancy transformation in FEC Encoder 1. This Stream A has a RTP-based Redundancy transformation in FEC Encoder 1.
produces a Redundancy RTP Stream 1, that is only related to Source This produces a Redundancy RTP Stream 1, that is only related to
RTP Stream A. The FEC Encoder 2, however, takes two Source RTP Source RTP Stream A. The FEC Encoder 2, however, takes two Source
Streams (A and B) and produces a Redundancy RTP Stream 2 that RTP Streams (A and B) and produces a Redundancy RTP Stream 2 that
protects them jointly, i.e. Redundancy RTP Stream 2 relates to two protects them jointly, i.e. Redundancy RTP Stream 2 relates to two
Source RTP Streams (a FEC group). FEC decoding, when needed due to Source RTP Streams (a FEC group). FEC decoding, when needed due to
packet loss or packet corruption at the receiver, requires knowledge packet loss or packet corruption at the receiver, requires knowledge
about which Source RTP Streams that the FEC encoding was based on. about which Source RTP Streams that the FEC encoding was based on.
In Figure 12 all RTP Streams are sent on the same Media Transport. In Figure 12 all RTP Streams are sent on the same Media Transport.
This is however not the only possible choice. Numerous combinations This is however not the only possible choice. Numerous combinations
exist for spreading these RTP Streams over different Media Transports exist for spreading these RTP Streams over different Media Transports
to achieve the communication application's goal. to achieve the communication application's goal.
skipping to change at page 32, line 13 skipping to change at page 32, line 13
identifiers used for expressing the relationships. identifiers used for expressing the relationships.
3.14. Multiple RTP Sessions over one Media Transport 3.14. Multiple RTP Sessions over one Media Transport
[I-D.westerlund-avtcore-transport-multiplexing] describes a mechanism [I-D.westerlund-avtcore-transport-multiplexing] describes a mechanism
that allows several RTP Sessions to be carried over a single that allows several RTP Sessions to be carried over a single
underlying Media Transport. The main reasons for doing this are underlying Media Transport. The main reasons for doing this are
related to the impact of using one or more Media Transports (using a related to the impact of using one or more Media Transports (using a
common network path or potentially have different ones). The fewer common network path or potentially have different ones). The fewer
Media Transports used, the less need for NAT/FW traversal resources Media Transports used, the less need for NAT/FW traversal resources
and number of flow based QoS. and number of flow based Quality of Service (QoS).
However, Multiple RTP Sessions over one Media Transport imply that a However, Multiple RTP Sessions over one Media Transport imply that a
single Media Transport 5-tuple is not sufficient to express in which single Media Transport 5-tuple is not sufficient to express in which
RTP Session context a particular RTP Stream exists. Complexities in RTP Session context a particular RTP Stream exists. Complexities in
the relationship between Media Transports and RTP Session already the relationship between Media Transports and RTP Session already
exist as one RTP Session contains multiple Media Transports, e.g. exist as one RTP Session contains multiple Media Transports, e.g.
even a Peer-to-Peer RTP Session with RTP/RTCP Multiplexing requires even a Peer-to-Peer RTP Session with RTP/RTCP Multiplexing requires
two Media Transports, one in each direction. The relationship two Media Transports, one in each direction. The relationship
between Media Transports and RTP Sessions as well as additional between Media Transports and RTP Sessions as well as additional
levels of identifiers need to be considered in both signaling design levels of identifiers need to be considered in both signaling design
skipping to change at page 32, line 35 skipping to change at page 32, 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
Telepresence [I-D.ietf-clue-framework]. [I-D.ietf-clue-framework].
4.1.1. Audio Capture 4.1.1. Audio Capture
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
Identifies a physical entity performing a Media Capture Identifies a physical entity performing a Media Capture
(Section 2.1.2) transformation. (Section 2.1.2) transformation.
skipping to change at page 33, line 42 skipping to change at page 33, line 42
4.1.10. Stream 4.1.10. Stream
Describes an RTP Stream (Section 2.1.10). Describes an RTP Stream (Section 2.1.10).
4.1.11. Video Capture 4.1.11. Video Capture
Describes a video Media Source (Section 2.1.4). Describes a video Media Source (Section 2.1.4).
4.2. Media Description 4.2. Media Description
A single Source Description Protocol (SDP) [RFC4566] media A single Session Description Protocol (SDP) [RFC4566] media
description (or media block; an m-line and all subsequent lines until description (or media block; an m-line and all subsequent lines until
the next m-line or the end of the SDP) describes part of the the next m-line or the end of the SDP) describes part of the
necessary configuration and identification information needed for a necessary configuration and identification information needed for a
Media Encoder transformation, as well as the necessary configuration Media Encoder transformation, as well as the necessary configuration
and identification information for the Media Decoder to be able to and identification information for the Media Decoder to be able to
correctly interpret a received RTP Stream. correctly interpret a received RTP Stream.
A Media Description typically relates to a single Media Source. This A Media Description typically relates to a single Media Source. This
is for example an explicit restriction in WebRTC. However, nothing is for example an explicit restriction in WebRTC. However, nothing
prevents that the same Media Description (and same RTP Session) is prevents that the same Media Description (and same RTP Session) is
skipping to change at page 36, line 46 skipping to change at page 36, line 46
October 2014. October 2014.
[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-05 (work in progress), ietf-avtcore-rtp-topologies-update-05 (work in progress),
November 2014. November 2014.
[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-19 (work in progress), December 2014. framework-20 (work in progress), January 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-14 (work in progress), December 2014. negotiation-15 (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-13 Browser-based Applications", draft-ietf-rtcweb-overview-13
(work in progress), November 2014. (work in progress), November 2014.
[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
skipping to change at page 38, line 31 skipping to change at page 38, line 31
7198, April 2014. 7198, April 2014.
[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, June
2014. 2014.
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 -03 and -04 A.1. Modifications Between WG Version -04 and -05
o Editorial improvements
A.2. 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 39, line 20 skipping to change at page 39, line 24
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.2. Modifications Between WG Version -02 and -03 A.3. 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.3. Modifications Between WG Version -01 and -02 A.4. 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 40, line 31 skipping to change at page 40, line 33
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.4. Modifications Between WG Version -00 and -01 A.5. 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.5. Modifications Between Version -02 and -03 A.6. 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.6. Modifications Between Version -01 and -02 A.7. 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.7. Modifications Between Version -00 and -01 A.8. 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. 43 change blocks. 
110 lines changed or deleted 115 lines changed or added

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