draft-ietf-avtext-rtp-grouping-taxonomy-02.txt   draft-ietf-avtext-rtp-grouping-taxonomy-03.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 29, 2014 AVA Expires: May 18, 2015 AVA
S. Nandakumar S. Nandakumar
G. Salgueiro G. Salgueiro
Cisco Systems Cisco Systems
B. Burman B. Burman
Ericsson Ericsson
June 27, 2014 November 14, 2014
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-02 draft-ietf-avtext-rtp-grouping-taxonomy-03
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 December 29, 2014. This Internet-Draft will expire on May 18, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 28 skipping to change at page 2, line 28
2.1.2. Media Capture . . . . . . . . . . . . . . . . . . . . 8 2.1.2. Media Capture . . . . . . . . . . . . . . . . . . . . 8
2.1.3. Raw Stream . . . . . . . . . . . . . . . . . . . . . 8 2.1.3. Raw Stream . . . . . . . . . . . . . . . . . . . . . 8
2.1.4. Media Source . . . . . . . . . . . . . . . . . . . . 8 2.1.4. Media Source . . . . . . . . . . . . . . . . . . . . 8
2.1.5. Source Stream . . . . . . . . . . . . . . . . . . . . 9 2.1.5. Source Stream . . . . . . . . . . . . . . . . . . . . 9
2.1.6. Media Encoder . . . . . . . . . . . . . . . . . . . . 9 2.1.6. Media Encoder . . . . . . . . . . . . . . . . . . . . 9
2.1.7. Encoded Stream . . . . . . . . . . . . . . . . . . . 10 2.1.7. Encoded Stream . . . . . . . . . . . . . . . . . . . 10
2.1.8. Dependent Stream . . . . . . . . . . . . . . . . . . 11 2.1.8. Dependent Stream . . . . . . . . . . . . . . . . . . 11
2.1.9. Media Packetizer . . . . . . . . . . . . . . . . . . 11 2.1.9. Media Packetizer . . . . . . . . . . . . . . . . . . 11
2.1.10. RTP Stream . . . . . . . . . . . . . . . . . . . . . 11 2.1.10. RTP Stream . . . . . . . . . . . . . . . . . . . . . 11
2.1.11. Media Redundancy . . . . . . . . . . . . . . . . . . 12 2.1.11. Media Redundancy . . . . . . . . . . . . . . . . . . 12
2.1.12. Redundancy RTP Stream . . . . . . . . . . . . . . . . 12 2.1.12. Redundancy RTP Stream . . . . . . . . . . . . . . . . 13
2.1.13. Media Transport . . . . . . . . . . . . . . . . . . . 13 2.1.13. Media Transport . . . . . . . . . . . . . . . . . . . 13
2.1.14. Media Transport Sender . . . . . . . . . . . . . . . 14 2.1.14. Media Transport Sender . . . . . . . . . . . . . . . 14
2.1.15. Sent RTP Stream . . . . . . . . . . . . . . . . . . . 14 2.1.15. Sent RTP Stream . . . . . . . . . . . . . . . . . . . 14
2.1.16. Network Transport . . . . . . . . . . . . . . . . . . 14 2.1.16. Network Transport . . . . . . . . . . . . . . . . . . 15
2.1.17. Transported RTP Stream . . . . . . . . . . . . . . . 14 2.1.17. Transported RTP Stream . . . . . . . . . . . . . . . 15
2.1.18. Media Transport Receiver . . . . . . . . . . . . . . 14 2.1.18. Media Transport Receiver . . . . . . . . . . . . . . 15
2.1.19. Received RTP Stream . . . . . . . . . . . . . . . . . 15 2.1.19. Received RTP Stream . . . . . . . . . . . . . . . . . 15
2.1.20. Received Redundancy RTP Stream . . . . . . . . . . . 15 2.1.20. Received Redundancy RTP Stream . . . . . . . . . . . 15
2.1.21. Media Repair . . . . . . . . . . . . . . . . . . . . 15 2.1.21. Media Repair . . . . . . . . . . . . . . . . . . . . 15
2.1.22. Repaired RTP Stream . . . . . . . . . . . . . . . . . 15 2.1.22. Repaired RTP Stream . . . . . . . . . . . . . . . . . 16
2.1.23. Media Depacketizer . . . . . . . . . . . . . . . . . 15 2.1.23. Media Depacketizer . . . . . . . . . . . . . . . . . 16
2.1.24. Received Encoded Stream . . . . . . . . . . . . . . . 16 2.1.24. Received Encoded Stream . . . . . . . . . . . . . . . 16
2.1.25. Media Decoder . . . . . . . . . . . . . . . . . . . . 16 2.1.25. Media Decoder . . . . . . . . . . . . . . . . . . . . 16
2.1.26. Received Source Stream . . . . . . . . . . . . . . . 16 2.1.26. Received Source Stream . . . . . . . . . . . . . . . 17
2.1.27. Media Sink . . . . . . . . . . . . . . . . . . . . . 16 2.1.27. Media Sink . . . . . . . . . . . . . . . . . . . . . 17
2.1.28. Received Raw Stream . . . . . . . . . . . . . . . . . 17 2.1.28. Received Raw Stream . . . . . . . . . . . . . . . . . 17
2.1.29. Media Render . . . . . . . . . . . . . . . . . . . . 17 2.1.29. Media Render . . . . . . . . . . . . . . . . . . . . 17
2.2. Communication Entities . . . . . . . . . . . . . . . . . 17 2.2. Communication Entities . . . . . . . . . . . . . . . . . 17
2.2.1. End Point . . . . . . . . . . . . . . . . . . . . . . 18 2.2.1. End Point . . . . . . . . . . . . . . . . . . . . . . 18
2.2.2. RTP Session . . . . . . . . . . . . . . . . . . . . . 18 2.2.2. RTP Session . . . . . . . . . . . . . . . . . . . . . 19
2.2.3. Participant . . . . . . . . . . . . . . . . . . . . . 19 2.2.3. Participant . . . . . . . . . . . . . . . . . . . . . 20
2.2.4. Multimedia Session . . . . . . . . . . . . . . . . . 20 2.2.4. Multimedia Session . . . . . . . . . . . . . . . . . 20
2.2.5. Communication Session . . . . . . . . . . . . . . . . 20 2.2.5. Communication Session . . . . . . . . . . . . . . . . 21
3. Relations at Different Levels . . . . . . . . . . . . . . . . 21 3. Concept Inter-Relations . . . . . . . . . . . . . . . . . . . 21
3.1. Synchronization Context . . . . . . . . . . . . . . . . . 22 3.1. Synchronization Context . . . . . . . . . . . . . . . . . 22
3.1.1. RTCP CNAME . . . . . . . . . . . . . . . . . . . . . 22 3.1.1. RTCP CNAME . . . . . . . . . . . . . . . . . . . . . 22
3.1.2. Clock Source Signaling . . . . . . . . . . . . . . . 22 3.1.2. Clock Source Signaling . . . . . . . . . . . . . . . 22
3.1.3. Implicitly via RtcMediaStream . . . . . . . . . . . . 22 3.1.3. Implicitly via RtcMediaStream . . . . . . . . . . . . 23
3.1.4. Explicitly via SDP Mechanisms . . . . . . . . . . . . 22 3.1.4. Explicitly via SDP Mechanisms . . . . . . . . . . . . 23
3.2. End Point . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2. End Point . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3. Participant . . . . . . . . . . . . . . . . . . . . . . . 23 3.3. Participant . . . . . . . . . . . . . . . . . . . . . . . 23
3.4. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 23 3.4. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 24
3.5. Single- and Multi-Session Transmission of SVC . . . . . . 23 3.5. Single- and Multi-Session Transmission of Dependent
3.6. Multi-Channel Audio . . . . . . . . . . . . . . . . . . . 24 Streams . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 24 3.6. Multi-Channel Audio . . . . . . . . . . . . . . . . . . . 25
3.8. Layered Multi-Stream . . . . . . . . . . . . . . . . . . 25 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 25
3.9. RTP Stream Duplication . . . . . . . . . . . . . . . . . 27 3.8. Layered Multi-Stream . . . . . . . . . . . . . . . . . . 26
3.10. Redundancy Format . . . . . . . . . . . . . . . . . . . . 27 3.9. RTP Stream Duplication . . . . . . . . . . . . . . . . . 28
3.11. RTP Retransmission . . . . . . . . . . . . . . . . . . . 28 3.10. Redundancy Format . . . . . . . . . . . . . . . . . . . . 28
3.12. Forward Error Correction . . . . . . . . . . . . . . . . 29 3.11. RTP Retransmission . . . . . . . . . . . . . . . . . . . 29
3.13. RTP Stream Separation . . . . . . . . . . . . . . . . . . 31 3.12. Forward Error Correction . . . . . . . . . . . . . . . . 30
3.14. Multiple RTP Sessions over one Media Transport . . . . . 32 3.13. RTP Stream Separation . . . . . . . . . . . . . . . . . . 32
4. Mapping from Existing Terms . . . . . . . . . . . . . . . . . 32 3.14. Multiple RTP Sessions over one Media Transport . . . . . 33
4.1. Audio Capture . . . . . . . . . . . . . . . . . . . . . . 32 4. Mapping from Existing Terms . . . . . . . . . . . . . . . . . 33
4.2. Capture Device . . . . . . . . . . . . . . . . . . . . . 32 4.1. Telepresence Terms . . . . . . . . . . . . . . . . . . . 33
4.3. Capture Encoding . . . . . . . . . . . . . . . . . . . . 32 4.1.1. Audio Capture . . . . . . . . . . . . . . . . . . . . 33
4.4. Capture Scene . . . . . . . . . . . . . . . . . . . . . . 33 4.1.2. Capture Device . . . . . . . . . . . . . . . . . . . 33
4.5. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.3. Capture Encoding . . . . . . . . . . . . . . . . . . 33
4.6. Individual Encoding . . . . . . . . . . . . . . . . . . . 33 4.1.4. Capture Scene . . . . . . . . . . . . . . . . . . . . 34
4.7. Multipoint Control Unit (MCU) . . . . . . . . . . . . . . 33 4.1.5. Endpoint . . . . . . . . . . . . . . . . . . . . . . 34
4.8. Media Capture . . . . . . . . . . . . . . . . . . . . . . 33 4.1.6. Individual Encoding . . . . . . . . . . . . . . . . . 34
4.9. Media Consumer . . . . . . . . . . . . . . . . . . . . . 33 4.1.7. Media Capture . . . . . . . . . . . . . . . . . . . . 34
4.10. Media Description . . . . . . . . . . . . . . . . . . . . 33 4.1.8. Media Consumer . . . . . . . . . . . . . . . . . . . 34
4.11. Media Provider . . . . . . . . . . . . . . . . . . . . . 34 4.1.9. Media Provider . . . . . . . . . . . . . . . . . . . 34
4.12. Media Stream . . . . . . . . . . . . . . . . . . . . . . 34 4.1.10. Stream . . . . . . . . . . . . . . . . . . . . . . . 34
4.13. Multimedia Session . . . . . . . . . . . . . . . . . . . 34 4.1.11. Video Capture . . . . . . . . . . . . . . . . . . . . 34
4.14. Recording Device . . . . . . . . . . . . . . . . . . . . 34 4.2. Media Description . . . . . . . . . . . . . . . . . . . . 34
4.15. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 34 4.3. Media Stream . . . . . . . . . . . . . . . . . . . . . . 35
4.16. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . . 35 4.4. Multimedia Conference . . . . . . . . . . . . . . . . . . 35
4.17. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . 35 4.5. Multimedia Session . . . . . . . . . . . . . . . . . . . 35
4.18. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 35 4.6. Multipoint Control Unit (MCU) . . . . . . . . . . . . . . 35
4.19. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.7. Recording Device . . . . . . . . . . . . . . . . . . . . 35
4.20. Stream . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.8. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 36
4.21. Video Capture . . . . . . . . . . . . . . . . . . . . . . 35 4.9. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . . 36
5. Security Considerations . . . . . . . . . . . . . . . . . . . 35 4.10. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . 36
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 36 4.11. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 36
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 4.12. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 5. Security Considerations . . . . . . . . . . . . . . . . . . . 36
9. Informative References . . . . . . . . . . . . . . . . . . . 36 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 37
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 38 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37
A.1. Modifications Between WG Version -01 and -02 . . . . . . 38 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
A.2. Modifications Between WG Version -00 and -01 . . . . . . 39 9. Informative References . . . . . . . . . . . . . . . . . . . 37
A.3. Modifications Between Version -02 and -03 . . . . . . . . 40 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 39
A.4. Modifications Between Version -01 and -02 . . . . . . . . 40 A.1. Modifications Between WG Version -02 and -03 . . . . . . 39
A.5. Modifications Between Version -00 and -01 . . . . . . . . 40 A.2. Modifications Between WG Version -01 and -02 . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 A.3. Modifications Between WG Version -00 and -01 . . . . . . 40
A.4. Modifications Between Version -02 and -03 . . . . . . . . 41
A.5. Modifications Between Version -01 and -02 . . . . . . . . 41
A.6. Modifications Between Version -00 and -01 . . . . . . . . 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
one layer are often glossed over or ignored at another. one layer are often glossed over or ignored at another.
skipping to change at page 5, line 16 skipping to change at page 5, line 21
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.
o A stream is of some type. o A stream is of some type, such as audio, video, real-time text,
etc.
o A stream has one source transformation and one or more sink o A stream has one source transformation and one or more sink
transformations (with the exception of Physical Stimulus transformations (with the exception of Physical Stimulus
(Section 2.1.1) that may lack source or sink transformation). (Section 2.1.1) that may lack source or sink transformation).
o Streams can be forwarded from a transformation output to any o Streams can be forwarded from a transformation output to any
number of inputs on other transformations that support that type. number of inputs on other transformations that support that type.
o If the output of a transformation is sent to multiple o If the output of a transformation is sent to multiple
transformations, those streams will be identical; it takes a transformations, those streams will be identical; it takes a
skipping to change at page 6, line 45 skipping to change at page 6, line 45
+--------------------+ +--------------------+ +--------------------+ +--------------------+
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 below
in Section 2.1.13. in Section 2.1.13.
Below we review a receiver media chain (Figure 2) matching the sender Below we review a receiver media chain (Figure 2) 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 possibly identical streams as in the sender chain. Note that recover identical streams as in the sender chain, subject to what may
the streams out of a reverse transformation, like the Source Stream be lossy compression and imperfect Media Transport. Note that the
out the Media Decoder are in many cases not the same as the streams out of a reverse transformation, like the Source Stream out
corresponding ones on the sender side, thus they are prefixed with a the Media Decoder are in many cases not the same as the corresponding
"Received" to denote a potentially modified version. The reason for ones on the sender side, thus they are prefixed with a "Received" to
not being the same lies in the transformations that can be of denote a potentially modified version. The reason for not being the
irreversible type. For example, lossy source coding in the Media same lies in the transformations that can be of irreversible type.
Encoder prevents the Source Stream out of the Media Decoder to be the
same as the one fed into the Media Encoder. Other reasons include For example, lossy source coding in the Media Encoder prevents the
packet loss or late loss in the Media Transport transformation that Source Stream out of the Media Decoder to be the same as the one fed
even Media Repair, if used, fails to repair. It should be noted that into the Media Encoder. Other reasons include packet loss or late
some transformations are not always present, like Media Repair that loss in the Media Transport transformation that even Media Repair, if
cannot operate without Redundancy RTP Streams. used, fails to repair. It should be noted that some transformations
are not always present, like Media Repair that cannot operate without
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 8, line 7 skipping to change at page 8, 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 measured and The physical stimulus is a physical event that can be sampled and
converted to digital form by an appropriate sensor or transducer. converted to digital form by an appropriate sensor or transducer.
This include sound waves making up audio, photons in a light field This include sound waves making up audio, photons in a light field,
that is visible, or other excitations or interactions with sensors, or other excitations or interactions with sensors, like keystrokes on
like keystrokes on a keyboard. 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 Physical Stimulus
(Section 2.1.1) into digital Media using an appropriate sensor or (Section 2.1.1) into digital Media using an appropriate sensor or
transducer. The Media Capture performs a digital sampling of the transducer. The Media Capture performs a digital sampling of the
physical stimulus, usually periodically, and outputs this in some physical stimulus, usually periodically, and outputs this in some
representation as a Raw Stream (Section 2.1.3). This data is due to representation as a Raw Stream (Section 2.1.3). This data is due to
its periodical sampling, or at least being timed asynchronous events, its periodical sampling, or at least being timed asynchronous events,
some form of a stream of media data. The Media Capture is normally some form of a stream of media data. The Media Capture is normally
skipping to change at page 8, line 48 skipping to change at page 8, line 48
periodically sampled and provided by a Media Capture (Section 2.1.2). periodically sampled and provided by a Media Capture (Section 2.1.2).
A Raw Stream can also contain synthesized Media that may not require A Raw Stream can also contain synthesized Media that may not require
any explicit Media Capture, since it is already in an appropriate any explicit Media Capture, since it is already in an appropriate
digital form. digital form.
2.1.4. Media Source 2.1.4. Media Source
A Media Source is the logical source of a reference clock A Media Source is the logical source of a reference clock
synchronized, time progressing, digital media stream, called a Source synchronized, time progressing, digital media stream, called a Source
Stream (Section 2.1.5). This transformation takes one or more Raw Stream (Section 2.1.5). This transformation takes one or more Raw
Streams (Section 2.1.3) and provides a Source Stream as output. This Streams (Section 2.1.3) and provides a Source Stream as output. The
output has been synchronized with some reference clock, even if just output is synchronized with a reference clock, which can be as simple
a system local wall clock. as a system local wall clock or as complex as NTP 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 Raw Streams more conceptual sources, like an audio mix of multiple Raw Streams
(Figure 3), a mixed selection of the three loudest inputs regarding (Figure 3), a mixed selection of the three loudest inputs regarding
speech activity, a selection of a particular video based on the speech activity, a selection of a particular video based on the
current speaker, i.e. typically based on other Media Sources. current speaker, i.e. typically based on other Media Sources.
Raw Raw Raw Raw Raw Raw
Stream Stream Stream Stream Stream Stream
skipping to change at page 9, line 50 skipping to change at page 9, line 50
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
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, not only its an important factor in many communication systems.
parameters.
Scalable Media Encoders need special mentioning 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. A scalable
Media Encoder takes one input Source Stream and encodes it into Media Encoder takes one input Source Stream and encodes it into
multiple output streams of two different types; at least one Encoded multiple output streams of two different types; at least one Encoded
Stream that is independently decodable and one or more Dependent Stream that is independently decodable and one or more Dependent
Streams (Section 2.1.8) that requires at least one Encoded Stream and Streams (Section 2.1.8). Decoding requires at least one Encoded
zero or more Dependent Streams to be possible to decode. A Dependent Stream and zero or more Dependent Streams. A Dependent Stream's
Stream's dependency is one of the grouping relations this document dependency is one of the grouping relations this document discusses
discusses further in Section 3.8. 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
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 Encoder produce multiple
independent and thus individually decodable Encoded Streams that are independent and thus individually decodable Encoded Streams.
possible to combine into a Received Source Stream that is somehow a However, (logically) combining multiple of these Encoded Streams into
better representation of the original Source Stream than using only a a single Received Source Stream during decoding leads to an
single Encoded Stream. improvement in perceptual reproduced quality when compared to
decoding a single Encoded Stream.
Creating multiple Encoded Streams from the same Source Stream, where
the Encoded Streams are neither in a scalable nor in an MDC
relationship is commonly utilized in simulcast environments.
Characteristics: Characteristics:
o A Media Source can be multiply encoded by different Media Encoders o A Media Source can be multiply encoded by different Media Encoders
to provide various encoded representations. to provide various encoded representations.
2.1.7. Encoded Stream 2.1.7. Encoded Stream
A stream of time synchronized encoded media that can be independently A stream of time synchronized encoded media that can be independently
decoded. decoded.
skipping to change at page 11, line 20 skipping to change at page 11, line 26
Characteristics: Characteristics:
o Each Dependent Stream has a set of dependencies. These o Each Dependent Stream has a set of dependencies. These
dependencies must be understood by the parties in a multi-media dependencies must be understood by the parties in a multi-media
session that intend to use a Dependent Stream. session that intend 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 Stream (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 SST packetization when using SVC RTP Stream. One such example is SRST packetization when using SVC
(Section 3.5). (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 MST 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.
o Media Packetizer can combine multiple Encoded or Dependent Streams o Media Packetizer can combine multiple Encoded or Dependent Streams
into one or more RTP Streams. into one or more RTP Streams.
2.1.10. RTP Stream 2.1.10. RTP Stream
A stream of RTP packets containing media data, source or redundant. A stream of RTP packets containing media data, source or redundant.
The RTP Stream is identified by an SSRC belonging to a particular RTP The RTP Stream is identified by an SSRC belonging to a particular RTP
session. The RTP session is identified as discussed in session. The RTP session is identified as discussed in
Section 2.2.2. Section 2.2.2.
A Source RTP Stream is a RTP Stream containing at least some content A Source RTP Stream is a RTP Stream containing at least some content
from an Encoded Stream. Source material is any media material that from an Encoded Stream. Source material is any media material that
is produced for transport over RTP without any additional redundancy is produced for transport over RTP without any additional redundancy
applied to cope with network transport losses. Compare this with the applied (outside what is generally there in the media format of the
Redundancy RTP Stream (Section 2.1.12). Encoded Stream) to cope with network transport losses. Compare this
with the Redundancy RTP Stream (Section 2.1.12).
Characteristics: Characteristics:
o Each RTP Stream is identified by a unique Synchronization source o Each RTP Stream is identified by a Synchronization source (SSRC)
(SSRC) [RFC3550] that is carried in every RTP and RTP Control [RFC3550] that is carried in every RTP and RTP Control Protocol
Protocol (RTCP) packet header in a specific RTP session context. (RTCP) packet header. The SSRC is unique in a specific RTP
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. SSRC collision and clock rate change [RFC7160] are examples SSRC, but SSRCs for a given RTP Stream can change over time. SSRC
of valid reasons to change SSRC for a RTP Stream, since the RTP collision and clock rate change [RFC7160] are examples of valid
reasons to change SSRC for an RTP Stream. In those cases, the RTP
Stream itself is not changed in any significant way, only the Stream itself is not changed in any significant way, only the
identifying SSRC number. identifying SSRC number.
o Each RTP Stream defines a unique RTP sequence numbering and timing o Each RTP Stream defines a unique RTP sequence numbering and timing
space. space.
o Several RTP Streams may map to a single Media Source via the o Several RTP Streams may represent a single Media Source.
source transformations.
o Several RTP Streams can be carried over a single RTP Session. o Several RTP Streams can be carried in a single RTP Session.
2.1.11. Media Redundancy 2.1.11. Media Redundancy
Media redundancy is a transformation that generates redundant or Media redundancy is defined here as a transformation that generates
repair packets sent out as a Redundancy RTP Stream to mitigate redundant or repair packets sent out as a Redundancy RTP Stream to
network transport impairments, like packet loss and delay. mitigate network transport impairments, like packet loss and delay.
The Media Redundancy exists in many flavors; they may be generating The Media Redundancy exists in many flavors; they may be generating
independent Repair Streams that are used in addition to the Source independent Repair Streams that are used in addition to the Source
Stream (RTP Retransmission [RFC4588] and some FEC [RFC5109]), they Stream (RTP Retransmission [RFC4588] and some FEC [RFC5109]), they
may generate a new Source Stream by combining redundancy information may generate a new Source Stream by combining redundancy information
with source information (Using XOR FEC [RFC5109] as a redundancy with source information (Using XOR FEC [RFC5109] as a redundancy
payload [RFC2198]), or completely replace the source information with payload [RFC2198]), or completely replace the source information with
only redundancy packets. only redundancy packets.
2.1.12. Redundancy RTP Stream 2.1.12. Redundancy RTP Stream
skipping to change at page 14, line 8 skipping to change at page 14, line 32
+--------------------------+ +--------------------------+
| |
V V
Received RTP Stream Received RTP Stream
Figure 5: Decomposition of Media Transport Figure 5: Decomposition of Media Transport
2.1.14. Media Transport Sender 2.1.14. Media Transport Sender
The first transformation within the Media Transport (Section 2.1.13) The first transformation within the Media Transport (Section 2.1.13)
is the Media Transport Sender, where the sending End-Point is the Media Transport Sender. The sending End Point (Section 2.2.1)
(Section 2.2.1) takes a RTP Stream and emits the packets onto the takes an RTP Stream and emits the packets onto the network using the
network using the transport association established for this Media transport association established for this Media Transport, thereby
Transport thus creating a Sent RTP Stream (Section 2.1.15). In this creating a Sent RTP Stream (Section 2.1.15). In the process, it
process it transforms the RTP Stream in several ways. First, it transforms the RTP Stream in several ways. First, it generates the
gains the necessary protocol headers for the transport association, necessary protocol headers for the transport association, for example
for example IP and UDP headers, thus forming IP/UDP/RTP packets. In IP and UDP headers, thus forming IP/UDP/RTP packets. In addition,
addition, the Media Transport Sender may queue, pace or otherwise the Media Transport Sender may queue, pace or otherwise affect how
affect how the packets are emitted onto the network. Thus adding the packets are emitted onto the network, thereby potentially
delay, jitter and inter packet spacings that characterize the Sent introducing delay, jitter and inter packet spacings that characterize
RTP Stream. the Sent RTP Stream.
2.1.15. Sent RTP Stream 2.1.15. 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.16. Network Transport 2.1.16. Network Transport
Network Transport is the transformation that the Sent RTP Stream Network Transport is the transformation that subjects the Sent RTP
(Section 2.1.15) is subjected to by traveling from the source to the Stream (Section 2.1.15) to traveling from the source to the
destination through the network. These transformations include, loss destination through the network. This transformation can result in
of some packets, varying delay on a per packet basis, packet loss of some packets, varying delay on a per packet basis, packet
duplication, and packet header or data corruption. These duplication, and packet header or data corruption. This
transformations produces a Transported RTP Stream (Section 2.1.17) at transformation produces a Transported RTP Stream (Section 2.1.17) at
the exit of the network path. the exit of the network path.
2.1.17. Transported RTP Stream 2.1.17. Transported RTP Stream
The RTP Stream that is emitted out of the network path at the The RTP Stream that is emitted out of the network path at the
destination, subjected to the Network Transport's transformation destination, subjected to the Network Transport's transformation
(Section 2.1.16). (Section 2.1.16).
2.1.18. Media Transport Receiver 2.1.18. Media Transport Receiver
The receiver End-Point's (Section 2.2.1) transformation of the The receiver End Point's (Section 2.2.1) transformation of the
Transported RTP Stream (Section 2.1.17) by its reception process that Transported RTP Stream (Section 2.1.17) by its reception process,
result in the Received RTP Stream (Section 2.1.19). This which results in the Received RTP Stream (Section 2.1.19). This
transformation includes transport checksums being verified and if transformation includes transport checksums being verified and, if
non-matching, causing discarding of the corrupted packet. Other non-matching, may cause discarding of the corrupted packet. Other
transformations can include delay variations in receiving a packet on transformations can compensate for delay variations in receiving a
the network interface and providing it to the application. packet on the network interface and providing it to the application
(de-jitter buffer).
2.1.19. Received RTP Stream 2.1.19. Received RTP Stream
The RTP Stream (Section 2.1.10) resulting from the Media Transport's The RTP Stream (Section 2.1.10) resulting from the Media Transport's
transformation, i.e. subjected to packet loss, packet corruption, transformation, i.e. subjected to packet loss, packet corruption,
packet duplication and varying transmission delay from sender to packet duplication and varying transmission delay from sender to
receiver. receiver.
2.1.20. Received Redundancy RTP Stream 2.1.20. Received Redundancy RTP Stream
The Redundancy RTP Stream (Section 2.1.12) resulting from the Media The Redundancy RTP Stream (Section 2.1.12) resulting from the Media
Transport transformation, i.e. subjected to packet loss, packet Transport transformation, i.e. subjected to packet loss, packet
corruption, and varying transmission delay from sender to receiver. corruption, and varying transmission delay from sender to receiver.
2.1.21. Media Repair 2.1.21. Media Repair
A Transformation that takes as input one or more Source RTP Streams A Transformation that takes as input one or more Received RTP Streams
(Section 2.1.10) as well as Redundancy RTP Streams (Section 2.1.12) (Section 2.1.19) as well as Redundancy RTP Streams (Section 2.1.20)
and attempts to combine them to counter the transformations and attempts to combine them to counter the transformations
introduced by the Media Transport (Section 2.1.13) to minimize the introduced by the Media Transport (Section 2.1.13) to minimize the
difference between the Source Stream (Section 2.1.5) and the Received difference between the Source RTP Stream (Section 2.1.10) and the
Source Stream (Section 2.1.26) after Media Decoder (Section 2.1.25). Repaired RTP Stream (Section 2.1.22). The output is a Repaired RTP
The output is a Repaired RTP Stream (Section 2.1.22). Stream (Section 2.1.22).
2.1.22. Repaired RTP Stream 2.1.22. Repaired RTP Stream
A Received RTP Stream (Section 2.1.19) for which Received Redundancy A Received RTP Stream (Section 2.1.19) for which Received Redundancy
RTP Stream (Section 2.1.20) information has been used to try to re- RTP Stream (Section 2.1.20) information has been used to try to re-
create the RTP Stream (Section 2.1.10) as it was before Media create the 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),
and depacketizes them and attempts to reconstitute the Encoded depacketizes them, and attempts to reconstitute the Encoded Streams
Streams (Section 2.1.7) or Dependent Streams (Section 2.1.8) present (Section 2.1.7) or Dependent Streams (Section 2.1.8) present in those
in those RTP Streams. RTP Streams.
It should be noted that in practical implementations, the Media It should be noted that in practical implementations, the Media
Depacketizer and the Media Decoder may be tightly coupled and share Depacketizer and the Media Decoder may be tightly coupled and share
information to improve or optimize the overall decoding process in information to improve or optimize the overall decoding and error
various ways. It is however not expected that there would be any concealment process. It is, however, not expected that there would
benefit in defining a taxonomy for those detailed (and likely very be any benefit in defining a taxonomy for those detailed (and likely
implementation-dependent) steps. very implementation-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 It should be noted that in practical implementations, the Media
Decoder and the Media Depacketizer may be tightly coupled and share Decoder and the Media Depacketizer may be tightly coupled and share
information to improve or optimize the overall decoding process in information to improve or optimize the overall decoding process in
various ways. It is however not expected that there would be any various ways. It is however not expected that there would be any
benefit in defining a taxonomy for those detailed (and likely very benefit in defining a taxonomy for those detailed (and likely very
implementation-dependent) steps. implementation-dependent) steps.
Characteristics: Characteristics:
o A Media Decoder is the entity that will have to deal with any o A Media Decoder has to deal with any errors in the encoded streams
errors in the encoded streams that resulted from corruptions or that resulted from corruption or failure to repair packet losses.
failures to repair packet losses. This as a media decoder Therefore, it commonly is robust to error and losses, and includes
generally is forced to produce some output periodically. It thus concealment methods.
commonly includes concealment methods.
2.1.26. Received Source Stream 2.1.26. Received Source Stream
The received version of a Source Stream (Section 2.1.5). The received version of a Source Stream (Section 2.1.5).
2.1.27. Media Sink 2.1.27. 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 sent in synchronization with the output from (Section 2.1.3) that is conveyed to the Media Render
other Media Sinks to a Media Render (Section 2.1.29). The media sink (Section 2.1.29), synchronized with the output from other Media
may also be connected with a Media Source (Section 2.1.4) and be used Sinks. The media sink may also be connected with a Media Source
as part of a conceptual Media Source. (Section 2.1.4) and be used as part of a conceptual Media Source.
Characteristics: Characteristics:
o The Media Sink can further transform the Source Stream into a o The Media Sink can further transform the Source Stream into a
representation that is suitable for rendering on the Media Render representation that is suitable for rendering on the Media Render
as defined by the application or system-wide configuration. This as defined by the application or system-wide configuration. This
include sample scaling, level adjustments etc. include sample scaling, level adjustments etc.
2.1.28. Received Raw Stream 2.1.28. Received Raw Stream
The received version of a Raw Stream (Section 2.1.3). The received version of a Raw Stream (Section 2.1.3).
2.1.29. Media Render 2.1.29. 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, D/A converters perceive. Examples of such devices are screens, and D/A converters
connected to amplifiers and loudspeakers. connected to amplifiers and loudspeakers.
Characteristics: Characteristics:
o An End Point can potentially have multiple Media Renders for each o An End Point can potentially have multiple Media Renders for each
media type. media type.
2.2. Communication Entities 2.2. Communication Entities
This section contains concept for entities involved in the This section contains concept for entities involved in the
skipping to change at page 18, line 9 skipping to change at page 18, line 36
| +----------------+ +----------------+ | | +----------------+ +----------------+ |
+----------------------------------------------------------+ +----------------------------------------------------------+
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 The figure above shows a high-level example representation of a very
basic point-to-point Communication Session between Participants A and basic point-to-point Communication Session between Participants A and
B. It uses two different audio and video RTP Sessions between A's B. It uses two different audio and video RTP Sessions between A's
and B's End Points, using separate Media Transports for those RTP and B's End Points, 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 between example, be established using SIP (i.e., there is a SIP Dialog
A and B). The terms used in that figure are further elaborated in between A and B). The terms used in that figure are further
the sub-sections below. elaborated in the sub-sections below.
2.2.1. End Point 2.2.1. End Point
Editor's note: Consider if a single word, "Endpoint", is Editor's note: Consider if a single word, "Endpoint", is
preferable preferable
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
"End Point". "End Point".
skipping to change at page 18, line 41 skipping to change at page 19, line 20
one End Point can handle multiple CNAMEs, each of which can be one End Point can handle multiple CNAMEs, each of which can be
shared among a set of End Points belonging to the same Participant shared among a set of End Points belonging to the same Participant
(Section 2.2.3). Therefore, mechanisms outside the scope of RTP, (Section 2.2.3). Therefore, mechanisms outside the scope of RTP,
such as application defined mechanisms, must be used to ensure End such as application defined mechanisms, must be used to ensure End
Point identification when outside this Synchronization Context. Point identification when outside this Synchronization Context.
o An End Point can be associated with at most one Participant o An End Point can be associated with at most one Participant
(Section 2.2.3) at any single point in time. (Section 2.2.3) at any single point in time.
o In some contexts, an End Point would typically correspond to a o In some contexts, an End Point would typically correspond to a
single "host". single "host", for example a computer using a single network
interface and being used by a single human user.
2.2.2. RTP Session 2.2.2. RTP Session
Editor's note: Re-consider if this is really a Communication Editor's note: Re-consider if this is really a Communication
Entity, or if it is rather an existing concept that should be Entity, or if it is rather an existing concept that should be
described in Section 4. described in Section 4.
An RTP session is an association among a group of participants An RTP session is an association among a group of participants
communicating with RTP. It is a group communications channel which communicating with RTP. It is a group communications channel which
can potentially carry a number of RTP Streams. Within an RTP can potentially carry a number of RTP Streams. Within an RTP
session, every participant can find meta-data and control information session, every participant can find meta-data and control information
(over RTCP) about all the RTP Streams in the RTP session. The (over RTCP) about all the RTP Streams in the RTP session. The
bandwidth of the RTCP control channel is shared between all bandwidth of the RTCP control channel is shared between all
participants within an RTP Session. participants within an RTP Session.
Characteristics: Characteristics:
o Typically, an RTP Session can carry one ore more RTP Streams. o An RTP Session can carry one ore more RTP Streams.
o An RTP Session shares a single SSRC space as defined in RFC3550 o An RTP Session shares a single SSRC space as defined in RFC3550
[RFC3550]. That is, the End Points participating in an RTP [RFC3550]. That is, the End Points participating in an RTP
Session can see an SSRC identifier transmitted by any of the other Session can see an SSRC identifier transmitted by any of the other
End Points. An End Point can receive an SSRC either as SSRC or as End Points. An End Point can receive an SSRC either as SSRC or as
a Contributing source (CSRC) in RTP and RTCP packets, as defined a Contributing source (CSRC) in RTP and RTCP packets, as defined
by the endpoints' network interconnection topology. by the endpoints' network interconnection topology.
o An RTP Session uses at least two Media Transports o An RTP Session uses at least two Media Transports
(Section 2.1.13), one for sending and one for receiving. (Section 2.1.13), one for sending and one for receiving.
Commonly, the receiving one is the reverse direction of the same Commonly, the receiving Media Transport is the reverse direction
one as used for sending. An RTP Session may use many Media of the Media Transport used for sending. An RTP Session may use
Transports and these define the session's network interconnection many Media Transports and these define the session's network
topology. A single Media Transport can normally not transport interconnection topology. A single Media Transport can normally
more than one RTP Session, unless a solution for multiplexing not transport more than one RTP Session, unless a solution for
multiple RTP sessions over a single Media Transport is used. One multiplexing multiple RTP sessions over a single Media Transport
example of such a scheme is Multiple RTP Sessions on a Single is used. One example of such a scheme is Multiple RTP Sessions on
Lower-Layer Transport a Single Lower-Layer Transport
[I-D.westerlund-avtcore-transport-multiplexing]. [I-D.westerlund-avtcore-transport-multiplexing].
o Multiple RTP Sessions can be related. o Multiple RTP Sessions can be related.
2.2.3. Participant 2.2.3. Participant
A Participant is an entity reachable by a single signaling address, A Participant is an entity reachable by a single signaling address,
and is thus related more to the signaling context than to the media and is thus related more to the signaling context than to the media
context. context.
skipping to change at page 20, line 14 skipping to change at page 20, line 39
2.2.4. Multimedia Session 2.2.4. Multimedia Session
A multimedia session is an association among a group of participants A multimedia session is an association among a group of participants
engaged in the communication via one or more RTP Sessions engaged in the communication via one or more RTP Sessions
(Section 2.2.2). It defines logical relationships among Media (Section 2.2.2). It defines logical relationships among Media
Sources (Section 2.1.4) that appear in multiple RTP Sessions. Sources (Section 2.1.4) that appear in multiple RTP Sessions.
Characteristics: Characteristics:
o A Multimedia Session can be composed of several parallel RTP o A Multimedia Session can be composed of several RTP Sessions with
Sessions with potentially multiple RTP Streams per RTP Session. potentially multiple RTP Streams per RTP Session.
o Each participant in a Multimedia Session can have a multitude of o Each participant in a Multimedia Session can have a multitude of
Media Captures and Media Rendering devices. Media Captures and Media Rendering devices.
o A single Multimedia Session can contain media from one or more o A single Multimedia Session can contain media from one or more
Synchronization Contexts (Section 3.1). An example of that is a Synchronization Contexts (Section 3.1). An example of that is a
Multimedia Session containing one set of audio and video for Multimedia Session containing one set of audio and video for
communication purposes belonging to one Synchronization Context, communication purposes belonging to one Synchronization Context,
and another set of audio and video for presentation purposes (like and another set of audio and video for presentation purposes (like
playing a video file) with a separate Synchronization Context that playing a video file) with a separate Synchronization Context that
skipping to change at page 21, line 5 skipping to change at page 21, line 27
o A Communication Session is composed of at least one Multimedia o A Communication Session is composed of at least one Multimedia
Session per participant, involving one or more parallel RTP Session per participant, involving one or more parallel RTP
Sessions with potentially multiple RTP Streams per RTP Session. Sessions with potentially multiple RTP Streams per RTP Session.
For example, in a full mesh communication, the Communication Session For example, in a full mesh communication, the Communication Session
consists of a set of separate Multimedia Sessions between each pair consists of a set of separate Multimedia Sessions between each pair
of Participants. Another example is a centralized conference, where of Participants. Another example is a centralized conference, where
the Communication Session consists of a set of Multimedia Sessions the Communication Session consists of a set of Multimedia Sessions
between each Participant and the conference handler. between each Participant and the conference handler.
3. Relations at Different Levels 3. Concept Inter-Relations
This section uses the concepts from previous section and look at This section uses the concepts from previous sections, and looks at
different types of relationships among them. These relationships different types of relationships among them. These relationships
occur at different levels and for different purposes. The section is occur at different abstraction levels and for different purposes.
organized such as to look at the level where a relation is required. The section is organized such as to look at the level where a
The reason for the relationship may exist at another step in the relation is required. The reason for the relationship may exist at
media handling chain. For example, using Simulcast (discussed in another step in the media handling chain. For example, the use of
Section 3.7) needs to determine relations at RTP Stream level, Simulcast (discussed in Section 3.7) implies a need to determine
however the reason to relate RTP Streams is that multiple Media relations at RTP Stream level. However the reason to relate RTP
Encoders use the same Media Source, i.e. to be able to identify a Streams in this context is not bound to RTP Streams, but is that
common Media Source. multiple Media Encoders use the same Media Source, i.e. to be able to
identify a common Media Source.
Media Sources (Section 2.1.4) are commonly grouped and related to an Media Sources (Section 2.1.4) are commonly grouped and related to an
End Point (Section 2.2.1) or a Participant (Section 2.2.3). This End Point (Section 2.2.1) or a Participant (Section 2.2.3) for a
occurs for several reasons; both due to application logic as well as number of reasons, for example application logic and media handling
for media handling purposes. purposes.
At RTP Packetization time, there exists a possibility for a number of At RTP Packetization time, a Media Packetizer has options to
different types of relationships between Encoded Streams packetize according to a number of different types of relationships
(Section 2.1.7), Dependent Streams (Section 2.1.8) and RTP Streams between Encoded Streams (Section 2.1.7), Dependent Streams
(Section 2.1.10). These are caused by grouping together or (Section 2.1.8) and RTP Streams (Section 2.1.10). These are caused
distributing these different types of streams into RTP Streams. by grouping together or distributing these different types of streams
into RTP Streams.
The resulting RTP Streams will thus also have relations. This is a While RTP Streams are generally separate, with independent sequence
common relation to handle in RTP due to that RTP Streams are separate number and timestamp spaces, they may have underlying relationships
and have their own SSRC, implying independent sequence numbers and that comes from a different level of abstraction.
timestamp spaces. The underlying reasons for the RTP Stream
relationships are different, as can be seen in the sub-sections
below.
RTP Streams may be protected by Redundancy RTP Streams during RTP Streams may be protected by Redundancy RTP Streams during
transport. Several approaches listed below can be used to create transport. Several approaches listed below can be used to create
Redundancy RTP Streams; Redundancy RTP Streams;
o Duplication of the original RTP Stream o Duplication of the original RTP Stream
o Duplication of the original RTP Stream with a time offset, o Duplication of the original RTP Stream with a time offset,
o Forward Error Correction (FEC) techniques, and o Forward Error Correction (FEC) techniques, and
skipping to change at page 22, line 9 skipping to change at page 22, line 30
The different RTP Streams can be transported within the same RTP The different RTP Streams can be transported within the same RTP
Session or in different RTP Sessions to accomplish different Session or in different RTP Sessions to accomplish different
transport goals. This explicit separation of RTP Streams is further transport goals. This explicit separation of RTP Streams is further
discussed in Section 3.13. discussed in Section 3.13.
3.1. Synchronization Context 3.1. Synchronization Context
A Synchronization Context defines a requirement on a strong timing A Synchronization Context defines a requirement on a strong timing
relationship between the Media Sources, typically requiring alignment relationship between the Media Sources, typically requiring alignment
of clock sources. Such relationship can be identified in multiple of clock sources. Such a relationship can be identified in multiple
ways as listed below. A single Media Source can only belong to a ways as listed below. A single Media Source can only belong to a
single Synchronization Context, since it is assumed that a single single Synchronization Context, since it is assumed that a single
Media Source can only have a single media clock and requiring Media Source can only have a single media clock and requiring
alignment to several Synchronization Contexts (and thus reference alignment to several Synchronization Contexts (and thus reference
clocks) will effectively merge those into a single Synchronization clocks) will effectively merge those into a single Synchronization
Context. Context.
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
[I-D.ietf-avtcore-clksrc], despite using NTP format timestamps, it is [RFC7273], despite using NTP format timestamps, it is not required
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
[I-D.ietf-avtcore-clksrc] provides a mechanism to signal the clock [RFC7273] provides a mechanism to signal the clock source in SDP both
source in SDP both for the reference clock as well as the media for the reference clock as well as the media clock, thus allowing a
clock, thus allowing a Synchronization Context to be defined beyond Synchronization Context to be defined beyond the one defined by the
the one defined by the usage of CNAME source descriptions. 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 The WebRTC WG defines "RtcMediaStream" with one or more
"RtcMediaStreamTracks". All tracks in a "RtcMediaStream" are "RtcMediaStreamTracks". All tracks in a "RtcMediaStream" are
intended to be possible to synchronize when rendered. intended to be synchronized when rendered, implying that they must be
generated such that synchronization is possible.
3.1.4. Explicitly via SDP Mechanisms 3.1.4. Explicitly via SDP Mechanisms
RFC5888 [RFC5888] defines m=line grouping mechanism called "Lip RFC5888 [RFC5888] defines m=line grouping mechanism called "Lip
Synchronization (LS)" for establishing the synchronization Synchronization (LS)" for establishing the synchronization
requirement across m=lines when they map to individual sources. requirement across m=lines when they map to individual sources.
RFC5576 [RFC5576] extends the above mechanism when multiple media RFC5576 [RFC5576] extends the above mechanism when multiple media
sources are described by a single m=line. sources are described by a single m=line.
3.2. End Point 3.2. End Point
Some applications requires knowledge of what Media Sources originate Some applications requires knowledge of what Media Sources originate
from a particular End Point (Section 2.2.1). This can include such from a particular End Point (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
the End Point origin of the RTP Streams. the End Point origin of the RTP Streams.
In RTP, this identification has been overloaded with the In RTP, this identification has been overloaded with the
Synchronization Context (Section 3.1) through the usage of the RTCP Synchronization Context (Section 3.1) through the usage of the RTCP
source description CNAME (Section 3.1.1) item. This works for some source description CNAME (Section 3.1.1). This works for some
usages, but sometimes it breaks down. For example, if an End Point usages, but in others it breaks down. For example, if an End Point
has two sets of Media Sources that have different Synchronization has two sets of Media Sources that have different Synchronization
Contexts, like the audio and video of the human participant as well Contexts, like the audio and video of the human participant as well
as a set of Media Sources of audio and video for a shared movie. as a set of Media Sources of audio and video for a shared movie,
Thus, an End Point may have multiple CNAMEs. The CNAMEs or the Media CNAME would not be an appropriate identification for that End Point.
Sources themselves can be related to the End Point. Therefore, an End Point may have multiple CNAMEs. The CNAMEs or the
Media Sources themselves can be related to the End Point.
3.3. Participant 3.3. Participant
In communication scenarios, it is commonly needed to know which Media In communication scenarios, it is commonly needed to know which Media
Sources that originate from which Participant (Section 2.2.3). Thus Sources originate from which Participant (Section 2.2.3). One reason
enabling the application to for example display Participant Identity is, for example, to enable the application to display Participant
information correctly associated with the Media Sources. This Identity information correctly associated with the Media Sources.
association is currently handled through the signaling solution to This association is handled through the signaling solution to point
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 End Point. explicitly or implicitly tied to a particular End Point.
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 carries such information about the Contributing Sources (CSRC) that carry information about the previous
previous step origin of the included media content on RTP level. step origin of the 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 SVC 3.5. Single- and Multi-Session Transmission of Dependent Streams
Scalable Video Coding [RFC6190] has a mode of operation called Single Scalable media coding formats such as, for example, H.264 based
Session Transmission (SST), where Encoded Streams and Dependent Scalable Video Coding [RFC6190] has two modes of operation:
Streams from the SVC Media Encoder are sent in a single RTP Session
(Section 2.2.2) using the SVC RTP Payload format. There is another
mode of operation where Encoded Streams and Dependent Streams are
distributed across multiple RTP Sessions, called Multi-Session
Transmission (MST). SST denotes one or more RTP Streams (SSRC) per
Media Source in a single RTP Session. MST denotes one or more RTP
Streams (SSRC) per Media Source in each of multiple RTP Sessions.
This is not always clear from the SVC payload format text [RFC6190],
but is what existing deployments of that RFC have implemented.
To elaborate, what could be called SST-SingleStream (SST-SS) uses a 1. In Single Session Transmission (SST), the SVC Media Encoder sends
single RTP Stream in a single RTP Session to send all Encoded and Encoded Streams (Section 2.1.7) and Dependent Streams
Dependent Streams from a single Media Source. Similarly, SST- (Section 2.1.8) as a single RTP Stream (Section 2.1.10) in a
MultiStream (SST-MS) uses a single RTP Stream per Media Source in a single RTP Session (Section 2.2.2), using the SVC RTP Payload
single RTP Session to send the Encoded and Dependent Streams. MST-SS format.
uses a single RTP Stream in each of multiple RTP Sessions, where each
RTP Stream can originate from any one of possibly multiple Media
Sources. Finally, MST-MS uses multiple RTP Streams in each of the
multiple RTP Sessions, where each RTP Stream can originate from any
one of possibly multiple Media Sources. This is summarized below:
+--------------------------+------------------+---------------------+ 2. In Multi-Session Transmission (MST), the SVC Media Encoder sends
| RTP Streams per Media | Single RTP | Multiple RTP | Encoded Streams and Dependent Streams distributed across multiple
| Source | Session | Sessions | RTP Streams in one or more RTP Sessions.
+--------------------------+------------------+---------------------+
| Single | SST-SS | MST-SS |
| Multiple | SST-MS | MST-MS |
+--------------------------+------------------+---------------------+
Table 1: SST / MST Summary SST denotes one RTP Stream (SSRC) per Media Source in a single RTP
Session. MST denotes one or more RTP Streams (SSRC) per Media Source
in each of multiple RTP Sessions. The above is not unambiguously
specified in the SVC payload format text [RFC6190], but it is what
existing deployments of that RFC have implemented.
The use of the term "RTP Session" in the SST/MST definition is
somewhat misleading, since a single RTP Session can contain multiple
RTP Streams. Also, it is sometimes useful to make a distinction
between using a single Transport or multiple separate Transports when
(in both cases) using multiple RTP Streams to carry Encoded Streams
and Dependent Streams for a Media Source. Therefore, herein the
following new terminology is defined:
SRST: Single RTP stream on a Single Transport
MRST: Multiple RTP streams on a Single Transport
MRMT: Multiple RTP streams on Multiple Transports
3.6. Multi-Channel Audio 3.6. Multi-Channel Audio
There exist a number of RTP payload formats that can carry multi- There exist a number of RTP payload formats that can carry multi-
channel audio, despite the codec being a mono encoder. Multi-channel channel audio, despite the codec being a mono encoder. Multi-channel
audio can be viewed as multiple Media Sources sharing a common audio can be viewed as multiple Media Sources sharing a common
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 then packetized Encoder and the different Encoded Streams are packetized together in
together in a time synchronized way into a single Source RTP Stream a time synchronized way into a single Source RTP Stream, using the
using the used codec's RTP Payload format. Example of such codecs used codec's RTP Payload format. Example of such codecs are, PCMA
are, PCMA and PCMU [RFC3551], AMR [RFC4867], and G.719 [RFC5404]. and PCMU [RFC3551], AMR [RFC4867], and 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 of that Media Source. Figure 7 below constitutes a simulcast or Multiple Description Coding of that Media
represents an example of a Media Source that is encoded into three Source. Figure 7 below shows an example of a Media Source that is
separate and different Simulcast streams, that are in turn sent on encoded into three separate Simulcast streams, that are in turn sent
the same Media Transport flow. When using Simulcast, the RTP Streams on the same Media Transport flow. When using Simulcast, the RTP
may be sharing RTP Session and Media Transport, or be separated on Streams may be sharing RTP Session and Media Transport, or be
different RTP Sessions and Media Transports, or be any combination of separated on different RTP Sessions and Media Transports, or any
these two. It is other considerations that affect which usage is combination of these two. It is other considerations that affect
desirable, as discussed in Section 3.13. which usage is desirable, as 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 26, line 35 skipping to change at page 27, line 35
| | | | | |
+------+ +------+ | +------+ +------+ |
| | | | | |
V V V V V V
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| Media Transport | | Media Transport | | Media Transport | | Media Transport |
+-----------------+ +-----------------+ +-----------------+ +-----------------+
Figure 8: Example of Media Source Layered Dependency Figure 8: Example of Media Source Layered Dependency
As an example, the SVC MST (Section 3.5) relation needs to identify As an example, the SVC MRST and MRMT (Section 3.5) relations needs to
the common Media Encoder origin for the Encoded and Dependent identify the common Media Encoder origin for the Encoded and
Streams. The SVC RTP Payload RFC is not particularly explicit about Dependent Streams. The SVC RTP Payload RFC [RFC6190] is not
how this relation is to be implemented. When using different RTP particularly explicit about how this relation is to be implemented.
Sessions, thus different Media Transports, and as long as there is When using different RTP Sessions, thus different Media Transports
only one RTP Stream per Media Encoder and a single Media Source in (MRMT (Section 3.5)), and as long as there is only one RTP Stream per
each RTP Session (MST-SS (Section 3.5)), common SSRC and CNAMEs can Media Encoder and a single Media Source in each RTP Session (MRMT),
be used to identify the common Media Source. When multiple RTP common SSRC and CNAMEs can be used to identify the common Media
Streams are sent from one Media Encoder in the same RTP Session (SST- Source. When multiple RTP Streams are sent from one Media Encoder in
MS), then CNAME is the only currently specified RTP identifier that the same RTP Session (MRST), then CNAME is the only currently
can be used. In cases where multiple Media Encoders use multiple specified RTP identifier that can be used. In cases where multiple
Media Sources sharing Synchronization Context, and thus having a Media Encoders use multiple Media Sources sharing Synchronization
common CNAME, additional heuristics need to be applied to create the Context, and thus having a common CNAME, additional heuristics or
MST relationship between the RTP Streams. identification need to be applied to create the MRST or MRMT
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. It is a specific type of redundancy and all but one Source
RTP Stream (Section 2.1.10) are effectively Redundancy RTP Streams RTP Stream (Section 2.1.10) are effectively Redundancy RTP Streams
(Section 2.1.12), but since both Source and Redundant RTP Streams are (Section 2.1.12), but since both Source and Redundant RTP Streams are
the same it does not matter which is which. This can also be seen as the same it does not matter which one is which. This can also be
a specific type of Simulcast (Section 3.7) that transmits the same seen as a specific type of Simulcast (Section 3.7) that transmits the
Encoded Stream (Section 2.1.7) multiple times. 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 27, line 49 skipping to change at page 28, line 49
| |
V V
+-------------------+ +-------------------+
| Media Transport | | Media Transport |
+-------------------+ +-------------------+
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 how one The RTP Payload for Redundant Audio Data [RFC2198] defines a
can transport 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 below in Figure 10.
+--------------------+ +--------------------+
| Media Source | | Media Source |
+--------------------+ +--------------------+
| |
Source Stream Source Stream
skipping to change at page 28, line 44 skipping to change at page 29, line 44
Encoders Encoders
The Redundancy format is thus providing the necessary meta The Redundancy format is thus providing the necessary meta
information to correctly relate different parts of the same Encoded information to correctly relate different parts of the same Encoded
Stream, or in the case depicted above (Figure 10) relate the Received Stream, or in the case depicted above (Figure 10) relate the Received
Source Stream fragments coming out of different Media Decoders to be Source Stream fragments coming out of different Media Decoders to be
able to combine them together into a less erroneous Source Stream. able to combine them together into a less erroneous Source Stream.
3.11. RTP Retransmission 3.11. RTP Retransmission
The figure below (Figure 11) represents an example where a Media Figure 11 shows an example where a Media Source's Source RTP Stream
Source's Source RTP Stream is protected by a retransmission (RTX) is protected by a retransmission (RTX) flow [RFC4588]. In this
flow [RFC4588]. In this example the Source RTP Stream and the example the Source RTP Stream and the Redundancy RTP Stream share the
Redundancy RTP Stream share the same Media Transport. same Media Transport.
+--------------------+ +--------------------+
| Media Source | | Media Source |
+--------------------+ +--------------------+
| |
V V
+--------------------+ +--------------------+
| Media Encoder | | Media Encoder |
+--------------------+ +--------------------+
| Retransmission | Retransmission
skipping to change at page 29, line 32 skipping to change at page 30, line 32
| | | |
+---------+ +---------+ +---------+ +---------+
| | | |
V V V V
+-----------------+ +-----------------+
| Media Transport | | Media Transport |
+-----------------+ +-----------------+
Figure 11: Example of Media Source Retransmission Flows Figure 11: Example of Media Source Retransmission Flows
The RTP Retransmission example (Figure 11) helps illustrate that this The RTP Retransmission example (Figure 11) illustrates that this
mechanism works purely on the Source RTP Stream. The RTP mechanism works purely on the Source RTP Stream. The RTP
Retransmission transform buffers the sent Source RTP Stream and upon Retransmission transform buffers the sent Source RTP Stream and, upon
requests emits a retransmitted packet with some extra payload header request, emits a retransmitted packet with an extra payload header as
as a Redundancy RTP Stream. The RTP Retransmission mechanism a Redundancy RTP Stream. The RTP Retransmission mechanism [RFC4588]
[RFC4588] is specified so that there is a one to one relation between is specified such that there is a one to one relation between the
the Source RTP Stream and the Redundancy RTP Stream. Thus 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 upon being received. This is done based on CNAME selectors Stream. This is done based on CNAME selectors and heuristics to
and heuristics to match requested packets for a given Source RTP match requested packets for a given Source RTP Stream with the
Stream with the original sequence number in the payload of any new original sequence number in the payload of any new Redundancy RTP
Redundancy RTP Stream using the RTX payload format. In cases where Stream using the RTX payload format. In cases where the Redundancy
the Redundancy RTP Stream is sent in a separate RTP Session from the RTP Stream is sent in a separate RTP Session from the Source RTP
Source RTP Stream, these sessions are related, e.g. using the SDP Stream, these sessions are related, which is signaled by using the
Media Grouping's [RFC5888] FID semantics. SDP Media Grouping's [RFC5888] FID semantics.
3.12. Forward Error Correction 3.12. Forward Error Correction
The figure below (Figure 12) represents an example where two Media The figure below (Figure 12) shows an example where two Media
Sources' Source RTP Streams are protected by FEC. Source RTP Stream Sources' Source RTP Streams are protected by FEC. Source RTP Stream
A has a Media Redundancy transformation in FEC Encoder 1. This A has a Media Redundancy transformation in FEC Encoder 1. This
produces a Redundancy RTP Stream 1, that is only related to Source produces a Redundancy RTP Stream 1, that is only related to Source
RTP Stream A. The FEC Encoder 2, however takes two Source RTP RTP Stream A. The FEC Encoder 2, however, takes two Source RTP
Streams (A and B) and produces a Redundancy RTP Stream 2 that Streams (A and B) and produces a Redundancy RTP Stream 2 that
protects them together, i.e. Redundancy RTP Stream 2 relate 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 30, line 46 skipping to change at page 31, line 46
| +---------------+ +---------------+ | | +---------------+ +---------------+ |
| | FEC Encoder 1 | | FEC Encoder 2 | | | | FEC Encoder 1 | | FEC Encoder 2 | |
| +---------------+ +---------------+ | | +---------------+ +---------------+ |
| Redundancy | Redundancy | | | Redundancy | Redundancy | |
| RTP Stream 1 | RTP Stream 2 | | | RTP Stream 1 | RTP Stream 2 | |
V V V V V V V V
+----------------------------------------------------------+ +----------------------------------------------------------+
| Media Transport | | Media Transport |
+----------------------------------------------------------+ +----------------------------------------------------------+
Figure 12: Example of FEC Flows Figure 12: Example of FEC Redundancy RTP Streams
As FEC Encoding exists in various forms, the methods for relating FEC As FEC Encoding exists in various forms, the methods for relating FEC
Redundancy RTP Streams with its source information in Source RTP Redundancy RTP Streams with its source information in Source RTP
Streams are many. The XOR based RTP FEC Payload format [RFC5109] is Streams are many. The XOR based RTP FEC Payload format [RFC5109] is
defined in such a way that a Redundancy RTP Stream has a one to one defined in such a way that a Redundancy RTP Stream has a one to one
relation with a Source RTP Stream. In fact, the RFC requires the relation with a Source RTP Stream. In fact, the RFC requires the
Redundancy RTP Stream to use the same SSRC as the Source RTP Stream. Redundancy RTP Stream to use the same SSRC as the Source RTP Stream.
This requires to either use a separate RTP session or to use the This requires to either use a separate RTP session or to use the
Redundancy RTP Payload format [RFC2198]. The underlying relation Redundancy RTP Payload format [RFC2198]. The underlying relation
requirement for this FEC format and a particular Redundancy RTP requirement for this FEC format and a particular Redundancy RTP
skipping to change at page 31, line 20 skipping to change at page 32, line 20
3.13. RTP Stream Separation 3.13. RTP Stream Separation
RTP Streams can be separated exclusively based on their SSRCs, at the RTP Streams can be separated exclusively based on their SSRCs, at the
RTP Session level, or at the Multi-Media Session level. RTP Session level, or at the Multi-Media Session level.
When the RTP Streams that have a relationship are all sent in the When the RTP Streams that have a relationship are all sent in the
same RTP Session and are uniquely identified based on their SSRC same RTP Session and are uniquely identified based on their SSRC
only, it is termed an SSRC-Only Based Separation. Such streams can only, it is termed an SSRC-Only Based Separation. Such streams can
be related via RTCP CNAME to identify that the streams belong to the be related via RTCP CNAME to identify that the streams belong to the
same End Point. [RFC5576]-based approaches, when used, can same End Point. SSRC-based approaches [RFC5576], when used, can
explicitly relate various such RTP Streams. explicitly relate various such RTP Streams.
On the other hand, when RTP Streams that are related but are sent in On the other hand, when RTP Streams that are related but are sent in
the context of different RTP Sessions to achieve separation, it is the context of different RTP Sessions to achieve separation, it is
known as RTP Session-based separation. This is commonly used when known as RTP Session-based separation. This is commonly used when
the different RTP Streams are intended for different Media the different RTP Streams are intended for different Media
Transports. Transports.
Several mechanisms that use RTP Session-based separation rely on it Several mechanisms that use RTP Session-based separation rely on it
to enable an implicit grouping mechanism expressing the relationship. to enable an implicit grouping mechanism expressing the relationship.
skipping to change at page 32, line 8 skipping to change at page 33, line 8
RTP Streams that are related and need to be associated can be part of RTP Streams that are related and need to be associated can be part of
different Multimedia Sessions, rather than just different RTP different Multimedia Sessions, rather than just different RTP
sessions within the same Multimedia Session context. This puts sessions within the same Multimedia Session context. This puts
further demand on the scope of the mechanism(s) and its handling of further demand on the scope of the mechanism(s) and its handling of
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 allow 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. Thus related to the impact of using one or more Media Transports (using a
using a common network path or potentially have different ones. common network path or potentially have different ones). The fewer
There is reduced need for NAT/FW traversal resources and no need for Media Transports used, the less need for NAT/FW traversal resources
flow based QoS. and number of flow based QoS.
However, Multiple RTP Sessions over one Media Transport makes it However, Multiple RTP Sessions over one Media Transport imply that a
clear that a single Media Transport 5-tuple is not sufficient to single Media Transport 5-tuple is not sufficient to express in which
express which RTP Session context a particular RTP Stream exists in. RTP Session context a particular RTP Stream exists. Complexities in
Complexities in the relationship between Media Transports and RTP the relationship between Media Transports and RTP Session already
Session already exist as one RTP Session contains multiple Media exist as one RTP Session contains multiple Media Transports, e.g.
Transports, e.g. even a Peer-to-Peer RTP Session with RTP/RTCP even a Peer-to-Peer RTP Session with RTP/RTCP Multiplexing requires
Multiplexing requires two Media Transports, one in each direction. two Media Transports, one in each direction. The relationship
The relationship between Media Transports and RTP Sessions as well as between Media Transports and RTP Sessions as well as additional
additional levels of identifiers need to be considered in both levels of identifiers need to be considered in both signaling design
signaling design and when defining terminology. and when defining terminology.
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. Audio Capture 4.1. Telepresence Terms
Telepresence specifications from CLUE WG uses this term to describe The terms in this sub-section are used in the context of CLUE
an audio Media Source (Section 2.1.4). Telepresence [I-D.ietf-clue-framework].
4.2. Capture Device 4.1.1. Audio Capture
Telepresence specifications from CLUE WG use this term to identify a Describes an audio Media Source (Section 2.1.4).
physical entity performing a Media Capture (Section 2.1.2)
transformation.
4.3. Capture Encoding 4.1.2. Capture Device
Telepresence specifications from CLUE WG uses this term to describe Identifies a physical entity performing a Media Capture
an Encoded Stream (Section 2.1.7) related to CLUE specific semantic (Section 2.1.2) transformation.
information.
4.4. Capture Scene 4.1.3. Capture Encoding
Telepresence specifications from CLUE WG uses this term to describe a Describes an Encoded Stream (Section 2.1.7) related to CLUE specific
set of spatially related Media Sources (Section 2.1.4). semantic information.
4.5. Endpoint 4.1.4. Capture Scene
Telepresence specifications from CLUE WG use this term to describe Describes a set of spatially related Media Sources (Section 2.1.4).
exactly one Participant (Section 2.2.3) and one or more End Points
(Section 2.2.1).
4.6. Individual Encoding 4.1.5. Endpoint
Telepresence specifications from CLUE WG use this term to describe Describes exactly one Participant (Section 2.2.3) and one or more End
the configuration information needed to perform a Media Encoder Points (Section 2.2.1).
(Section 2.1.6) transformation.
4.7. Multipoint Control Unit (MCU) 4.1.6. Individual Encoding
This term is commonly used to describe the central node in any type Describes the configuration information needed to perform a Media
of star topology [I-D.ietf-avtcore-rtp-topologies-update] conference. Encoder (Section 2.1.6) transformation.
It describes a device that includes one Participant (Section 2.2.3)
(usually corresponding to a so-called conference focus) and one or
more related End Points (Section 2.2.1) (sometimes one or more per
conference participant).
4.8. Media Capture 4.1.7. Media Capture
Telepresence specifications from CLUE WG uses this term to describe Describes either a Media Capture (Section 2.1.2) or a Media Source
either a Media Capture (Section 2.1.2) or a Media Source
(Section 2.1.4), depending on in which context the term is used. (Section 2.1.4), depending on in which context the term is used.
4.9. Media Consumer 4.1.8. Media Consumer
Telepresence specifications from CLUE WG use this term to describe Describes the media receiving part of an End Point (Section 2.2.1).
the media receiving part of an End Point (Section 2.2.1).
4.10. Media Description 4.1.9. Media Provider
Describes the media sending part of an End Point (Section 2.2.1).
4.1.10. Stream
Describes an RTP Stream (Section 2.1.10).
4.1.11. Video Capture
Describes a video Media Source (Section 2.1.4).
4.2. Media Description
A single Source Description Protocol (SDP) [RFC4566] media A single Source 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
re-used for multiple Media Sources re-used for multiple Media Sources
[I-D.ietf-avtcore-rtp-multi-stream]. It can thus describe properties [I-D.ietf-avtcore-rtp-multi-stream]. It can thus describe properties
of one or more RTP Streams, and can also describe properties valid of one or more RTP Streams, and can also describe properties valid
for an entire RTP Session (via [RFC5576] mechanisms, for example). for an entire RTP Session (via [RFC5576] mechanisms, for example).
4.11. Media Provider 4.3. Media Stream
Telepresence specifications from CLUE WG use this term to describe
the media sending part of an End Point (Section 2.2.1).
4.12. Media Stream
RTP [RFC3550] uses media stream, audio stream, video stream, and RTP [RFC3550] uses media stream, audio stream, video stream, and
stream of (RTP) packets interchangeably, which are all RTP Streams. stream of (RTP) packets interchangeably, which are all RTP Streams.
4.13. Multimedia Session 4.4. Multimedia Conference
A Multimedia Conference is a Communication Session (Section 2.2.5)
between two or more Participants (Section 2.2.3), along with the
software they are using to communicate.
4.5. Multimedia Session
SDP [RFC4566] defines a multimedia session as a set of multimedia 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 End Points and the RTP receivers, which would correspond to a set of End Points and the RTP
Streams that flow between them. In this memo, Multimedia Session Streams that flow between them. In this memo, Multimedia Session
also assumes those End Points belong to a set of Participants that (Section 2.2.4) also assumes those End Points belong to a set of
are engaged in communication via a set of related RTP Streams. Participants that are engaged in communication via a set of related
RTP Streams.
RTP [RFC3550] defines a multimedia session as a set of concurrent RTP 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 End Points) sharing a set of concurrent RTP Sessions. In this more End Points) sharing a set of concurrent RTP Sessions. In this
memo, Multimedia Session also defines those RTP Sessions to have some memo, Multimedia Session also defines those RTP Sessions to have some
relation and be part of a communication among the Participants. relation and be part of a communication among the Participants.
4.14. Recording Device 4.6. Multipoint Control Unit (MCU)
This term is commonly used to describe the central node in any type
of star topology [I-D.ietf-avtcore-rtp-topologies-update] conference.
It describes a device that includes one Participant (Section 2.2.3)
(usually corresponding to a so-called conference focus) and one or
more related End Points (Section 2.2.1) (sometimes one or more per
conference participant).
4.7. 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.15. RtcMediaStream 4.8. RtcMediaStream
A WebRTC RtcMediaStreamTrack is a set of Media Sources A WebRTC RtcMediaStreamTrack is a set of Media Sources
(Section 2.1.4) sharing the same Synchronization Context (Section 2.1.4) sharing the same Synchronization Context
(Section 3.1). (Section 3.1).
4.16. RtcMediaStreamTrack 4.9. RtcMediaStreamTrack
A WebRTC RtcMediaStreamTrack is a Media Source (Section 2.1.4). A WebRTC RtcMediaStreamTrack is a Media Source (Section 2.1.4).
4.17. RTP Sender 4.10. RTP Sender
RTP [RFC3550] uses this term, which can be seen as the RTP protocol RTP [RFC3550] uses this term, which can be seen as the RTP protocol
part of a Media Packetizer (Section 2.1.9). part of a Media Packetizer (Section 2.1.9).
4.18. RTP Session 4.11. RTP Session
Within the context of SDP, a singe m=line can map to a single RTP Within the context of SDP, a singe m=line can map to a single RTP
Session or multiple m=lines can map to a single RTP Session. The Session or multiple m=lines can map to a single RTP Session. The
latter is enabled via multiplexing schemes such as BUNDLE latter is enabled via multiplexing schemes such as BUNDLE
[I-D.ietf-mmusic-sdp-bundle-negotiation], for example, which allows [I-D.ietf-mmusic-sdp-bundle-negotiation], for example, which allows
mapping of multiple m=lines to a single RTP Session. mapping of multiple m=lines to a single RTP Session.
Editor's note: Consider if the contents of Section 2.2.2 should be Editor's note: Consider if the contents of Section 2.2.2 should be
moved here, or if this section should be kept and refer to the moved here, or if this section should be kept and refer to the
above. above.
4.19. SSRC 4.12. 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).
4.20. Stream
Telepresence specifications from CLUE WG use this term to describe an
RTP Stream (Section 2.1.10).
4.21. Video Capture
Telepresence specifications from CLUE WG uses this term to describe a
video Media Source (Section 2.1.4).
5. Security Considerations 5. Security Considerations
This document simply tries to clarify the confusion prevalent in RTP This document simply tries to clarify the confusion prevalent in RTP
taxonomy because of inconsistent usage by multiple technologies and taxonomy because of inconsistent usage by multiple technologies and
protocols making use of the RTP protocol. It does not introduce any protocols making use of the RTP protocol. It does not introduce any
new security considerations beyond those already well documented in new security considerations beyond those already well documented in
the RTP protocol [RFC3550] and each of the many respective the RTP protocol [RFC3550] and each of the many respective
specifications of the various protocols making use of it. specifications of the various protocols making use of it.
Hopefully having a well-defined common terminology and understanding Hopefully having a well-defined common terminology and understanding
skipping to change at page 36, line 19 skipping to change at page 37, line 15
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],
Multiplexing Architecture 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
contributions of Magnus Westerlund, Roni Even, Paul Kyzivat, Colin contributions of Magnus Westerlund, Roni Even, Paul Kyzivat, Colin
Perkins, Keith Drage, Harald Alvestrand, and Alex Eleftheriadis. Perkins, Keith Drage, Harald Alvestrand, Alex Eleftheriadis, Mo
Zanaty, and Stephan Wenger.
7. Contributors 7. Contributors
Magnus Westerlund has contributed the concept model for the media Magnus Westerlund has contributed the concept model for the media
chain using transformations and streams model, including rewriting chain using transformations and streams model, including rewriting
pre-existing concepts into this model and adding missing concepts. pre-existing concepts into this model and adding missing concepts.
The first proposal for updating the relationships and the topologies The first proposal for updating the relationships and the topologies
based on this concept was also performed by Magnus. based on this concept was also performed by Magnus.
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-clksrc]
Williams, A., Gross, K., Brandenburg, R., and H. Stokking,
"RTP Clock Source Signalling", draft-ietf-avtcore-
clksrc-11 (work in progress), March 2014.
[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-04 (work in progress), draft-ietf-avtcore-rtp-multi-stream-06 (work in progress),
May 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-02 (work in progress), ietf-avtcore-rtp-topologies-update-05 (work in progress),
May 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-15 (work in progress), May 2014. framework-18 (work in progress), October 2014.
[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-07 (work in progress), April 2014. negotiation-12 (work in progress), October 2014.
[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-10 Browser-based Applications", draft-ietf-rtcweb-overview-12
(work in progress), June 2014. (work in progress), October 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
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,
skipping to change at page 38, line 36 skipping to change at page 39, line 23
[RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, April 2014. Clock Rates in an RTP Session", RFC 7160, April 2014.
[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. April 2014.
[RFC7198] Begen, A. and C. Perkins, "Duplicating RTP Streams", RFC [RFC7198] Begen, A. and C. Perkins, "Duplicating RTP Streams", RFC
7198, April 2014. 7198, April 2014.
[RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H.
Stokking, "RTP Clock Source Signalling", RFC 7273, June
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 -01 and -02 A.1. Modifications Between WG Version -02 and -03
o Changed section 3.5, removing SST-SS/MS and MST-SS/MS, replacing
them with SRST, MRST, and MRMT.
o Updated section 3.8 to align with terminology changes in section
3.5.
o Added a new section 4.12, describing the term Multimedia
Conference.
o Changed reference from I-D to now published RFC 7273.
o Editorial improvements and clarifications.
A.2. 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
[RFC7160] is a valid reason to change SSRC value for an RTP stream [RFC7160] is a valid reason to change SSRC value for an RTP stream
o Added a sub-section on clock source signaling o Added a sub-section on clock source signaling
o Added a sub-section on RTP stream duplication o Added a sub-section on RTP stream duplication
skipping to change at page 39, line 36 skipping to change at page 40, line 42
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.2. Modifications Between WG Version -00 and -01 A.3. 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.3. Modifications Between Version -02 and -03 A.4. 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.4. Modifications Between Version -01 and -02 A.5. 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.5. Modifications Between Version -00 and -01 A.6. 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. 125 change blocks. 
399 lines changed or deleted 430 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/