draft-ietf-avtext-rtp-grouping-taxonomy-06.txt   draft-ietf-avtext-rtp-grouping-taxonomy-07.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: September 6, 2015 AVA Expires: December 25, 2015 AVA
S. Nandakumar S. Nandakumar
G. Salgueiro G. Salgueiro
Cisco Systems Cisco Systems
B. Burman B. Burman, Ed.
Ericsson Ericsson
March 5, 2015 June 23, 2015
A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol
Protocol (RTP) Sources (RTP) Sources
draft-ietf-avtext-rtp-grouping-taxonomy-06 draft-ietf-avtext-rtp-grouping-taxonomy-07
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 properties and
among RTP sources, and attempts to define common terminology for relationships among RTP sources, and defines common terminology for
discussing protocol entities and their relationships. discussing protocol entities and their relationships.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 6, 2015. This Internet-Draft will expire on December 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Media Chain . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Media Chain . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Physical Stimulus . . . . . . . . . . . . . . . . . . 8 2.1.1. Physical Stimulus . . . . . . . . . . . . . . . . . . 9
2.1.2. Media Capture . . . . . . . . . . . . . . . . . . . . 9 2.1.2. Media Capture . . . . . . . . . . . . . . . . . . . . 9
2.1.3. Raw Stream . . . . . . . . . . . . . . . . . . . . . 9 2.1.3. Raw Stream . . . . . . . . . . . . . . . . . . . . . 9
2.1.4. Media Source . . . . . . . . . . . . . . . . . . . . 9 2.1.4. Media Source . . . . . . . . . . . . . . . . . . . . 10
2.1.5. Source Stream . . . . . . . . . . . . . . . . . . . . 10 2.1.5. Source Stream . . . . . . . . . . . . . . . . . . . . 10
2.1.6. Media Encoder . . . . . . . . . . . . . . . . . . . . 10 2.1.6. Media Encoder . . . . . . . . . . . . . . . . . . . . 11
2.1.7. Encoded Stream . . . . . . . . . . . . . . . . . . . 12 2.1.7. Encoded Stream . . . . . . . . . . . . . . . . . . . 12
2.1.8. Dependent Stream . . . . . . . . . . . . . . . . . . 12 2.1.8. Dependent Stream . . . . . . . . . . . . . . . . . . 12
2.1.9. Media Packetizer . . . . . . . . . . . . . . . . . . 12 2.1.9. Media Packetizer . . . . . . . . . . . . . . . . . . 12
2.1.10. RTP Stream . . . . . . . . . . . . . . . . . . . . . 13 2.1.10. RTP Stream . . . . . . . . . . . . . . . . . . . . . 13
2.1.11. RTP-based Redundancy . . . . . . . . . . . . . . . . 13 2.1.11. RTP-based Redundancy . . . . . . . . . . . . . . . . 13
2.1.12. Redundancy RTP Stream . . . . . . . . . . . . . . . . 14 2.1.12. Redundancy RTP Stream . . . . . . . . . . . . . . . . 14
2.1.13. Media Transport . . . . . . . . . . . . . . . . . . . 14 2.1.13. RTP-based Security . . . . . . . . . . . . . . . . . 14
2.1.14. Media Transport Sender . . . . . . . . . . . . . . . 15 2.1.14. Secured RTP Stream . . . . . . . . . . . . . . . . . 15
2.1.15. Sent RTP Stream . . . . . . . . . . . . . . . . . . . 15 2.1.15. Media Transport . . . . . . . . . . . . . . . . . . . 15
2.1.16. Network Transport . . . . . . . . . . . . . . . . . . 16 2.1.16. Media Transport Sender . . . . . . . . . . . . . . . 16
2.1.17. Transported RTP Stream . . . . . . . . . . . . . . . 16 2.1.17. Sent RTP Stream . . . . . . . . . . . . . . . . . . . 17
2.1.18. Media Transport Receiver . . . . . . . . . . . . . . 16 2.1.18. Network Transport . . . . . . . . . . . . . . . . . . 17
2.1.19. Received RTP Stream . . . . . . . . . . . . . . . . . 16 2.1.19. Transported RTP Stream . . . . . . . . . . . . . . . 17
2.1.20. Received Redundancy RTP Stream . . . . . . . . . . . 16 2.1.20. Media Transport Receiver . . . . . . . . . . . . . . 17
2.1.21. RTP-based Repair . . . . . . . . . . . . . . . . . . 17 2.1.21. Received Secured RTP Stream . . . . . . . . . . . . . 18
2.1.22. Repaired RTP Stream . . . . . . . . . . . . . . . . . 17 2.1.22. RTP-based Validation . . . . . . . . . . . . . . . . 18
2.1.23. Media Depacketizer . . . . . . . . . . . . . . . . . 17 2.1.23. Received RTP Stream . . . . . . . . . . . . . . . . . 18
2.1.24. Received Encoded Stream . . . . . . . . . . . . . . . 17 2.1.24. Received Redundancy RTP Stream . . . . . . . . . . . 18
2.1.25. Media Decoder . . . . . . . . . . . . . . . . . . . . 17 2.1.25. RTP-based Repair . . . . . . . . . . . . . . . . . . 18
2.1.26. Received Source Stream . . . . . . . . . . . . . . . 18 2.1.26. Repaired RTP Stream . . . . . . . . . . . . . . . . . 18
2.1.27. Media Sink . . . . . . . . . . . . . . . . . . . . . 18 2.1.27. Media Depacketizer . . . . . . . . . . . . . . . . . 19
2.1.28. Received Raw Stream . . . . . . . . . . . . . . . . . 18 2.1.28. Received Encoded Stream . . . . . . . . . . . . . . . 19
2.1.29. Media Render . . . . . . . . . . . . . . . . . . . . 18 2.1.29. Media Decoder . . . . . . . . . . . . . . . . . . . . 19
2.2. Communication Entities . . . . . . . . . . . . . . . . . 19 2.1.30. Received Source Stream . . . . . . . . . . . . . . . 19
2.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 20 2.1.31. Media Sink . . . . . . . . . . . . . . . . . . . . . 19
2.2.2. RTP Session . . . . . . . . . . . . . . . . . . . . . 20 2.1.32. Received Raw Stream . . . . . . . . . . . . . . . . . 20
2.2.3. Participant . . . . . . . . . . . . . . . . . . . . . 21 2.1.33. Media Render . . . . . . . . . . . . . . . . . . . . 20
2.2.4. Multimedia Session . . . . . . . . . . . . . . . . . 21 2.2. Communication Entities . . . . . . . . . . . . . . . . . 20
2.2.5. Communication Session . . . . . . . . . . . . . . . . 22 2.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2. RTP Session . . . . . . . . . . . . . . . . . . . . . 22
2.2.3. Participant . . . . . . . . . . . . . . . . . . . . . 23
2.2.4. Multimedia Session . . . . . . . . . . . . . . . . . 23
2.2.5. Communication Session . . . . . . . . . . . . . . . . 24
3. Concepts of Inter-Relations . . . . . . . . . . . . . . . . . 24
3.1. Synchronization Context . . . . . . . . . . . . . . . . . 24
3.1.1. RTCP CNAME . . . . . . . . . . . . . . . . . . . . . 25
3.1.2. Clock Source Signaling . . . . . . . . . . . . . . . 25
3.1.3. Implicitly via RtcMediaStream . . . . . . . . . . . . 25
3.1.4. Explicitly via SDP Mechanisms . . . . . . . . . . . . 25
3.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3. Participant . . . . . . . . . . . . . . . . . . . . . . . 26
3.4. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 26
3.5. Multi-Channel Audio . . . . . . . . . . . . . . . . . . . 26
3.6. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7. Layered Multi-Stream . . . . . . . . . . . . . . . . . . 28
3.8. RTP Stream Duplication . . . . . . . . . . . . . . . . . 29
3.9. Redundancy Format . . . . . . . . . . . . . . . . . . . . 30
3.10. RTP Retransmission . . . . . . . . . . . . . . . . . . . 31
3.11. Forward Error Correction . . . . . . . . . . . . . . . . 33
3.12. RTP Stream Separation . . . . . . . . . . . . . . . . . . 34
3.13. Multiple RTP Sessions over one Media Transport . . . . . 35
4. Mapping from Existing Terms . . . . . . . . . . . . . . . . . 35
4.1. Telepresence Terms . . . . . . . . . . . . . . . . . . . 35
4.1.1. Audio Capture . . . . . . . . . . . . . . . . . . . . 35
4.1.2. Capture Device . . . . . . . . . . . . . . . . . . . 35
4.1.3. Capture Encoding . . . . . . . . . . . . . . . . . . 35
4.1.4. Capture Scene . . . . . . . . . . . . . . . . . . . . 36
4.1.5. Endpoint . . . . . . . . . . . . . . . . . . . . . . 36
4.1.6. Individual Encoding . . . . . . . . . . . . . . . . . 36
4.1.7. Media Capture . . . . . . . . . . . . . . . . . . . . 36
4.1.8. Media Consumer . . . . . . . . . . . . . . . . . . . 36
4.1.9. Media Provider . . . . . . . . . . . . . . . . . . . 36
4.1.10. Stream . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.11. Video Capture . . . . . . . . . . . . . . . . . . . . 37
4.2. Media Description . . . . . . . . . . . . . . . . . . . . 37
4.3. Media Stream . . . . . . . . . . . . . . . . . . . . . . 37
4.4. Multimedia Conference . . . . . . . . . . . . . . . . . . 37
4.5. Multimedia Session . . . . . . . . . . . . . . . . . . . 37
4.6. Multipoint Control Unit (MCU) . . . . . . . . . . . . . . 38
4.7. Multi-Session Transmission (MST) . . . . . . . . . . . . 38
4.8. Recording Device . . . . . . . . . . . . . . . . . . . . 38
4.9. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 38
4.10. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . . 39
4.11. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . 39
4.12. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 39
4.13. Single Session Transmission (SST) . . . . . . . . . . . . 39
4.14. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3. Concepts of Inter-Relations . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 39
3.1. Synchronization Context . . . . . . . . . . . . . . . . . 22 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 40
3.1.1. RTCP CNAME . . . . . . . . . . . . . . . . . . . . . 23 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40
3.1.2. Clock Source Signaling . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
3.1.3. Implicitly via RtcMediaStream . . . . . . . . . . . . 23 9. Informative References . . . . . . . . . . . . . . . . . . . 40
3.1.4. Explicitly via SDP Mechanisms . . . . . . . . . . . . 23 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 43
3.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 23 A.1. Modifications Between WG Version -06 and -07 . . . . . . 43
3.3. Participant . . . . . . . . . . . . . . . . . . . . . . . 24 A.2. Modifications Between WG Version -05 and -06 . . . . . . 43
3.4. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 24 A.3. Modifications Between WG Version -04 and -05 . . . . . . 44
3.5. Multi-Channel Audio . . . . . . . . . . . . . . . . . . . 24 A.4. Modifications Between WG Version -03 and -04 . . . . . . 44
3.6. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 25 A.5. Modifications Between WG Version -02 and -03 . . . . . . 45
3.7. Layered Multi-Stream . . . . . . . . . . . . . . . . . . 26 A.6. Modifications Between WG Version -01 and -02 . . . . . . 45
3.8. RTP Stream Duplication . . . . . . . . . . . . . . . . . 27 A.7. Modifications Between WG Version -00 and -01 . . . . . . 46
3.9. Redundancy Format . . . . . . . . . . . . . . . . . . . . 28 A.8. Modifications Between Version -02 and -03 . . . . . . . . 46
3.10. RTP Retransmission . . . . . . . . . . . . . . . . . . . 29 A.9. Modifications Between Version -01 and -02 . . . . . . . . 46
3.11. Forward Error Correction . . . . . . . . . . . . . . . . 31 A.10. Modifications Between Version -00 and -01 . . . . . . . . 46
3.12. RTP Stream Separation . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
3.13. Multiple RTP Sessions over one Media Transport . . . . . 33
4. Mapping from Existing Terms . . . . . . . . . . . . . . . . . 33
4.1. Telepresence Terms . . . . . . . . . . . . . . . . . . . 33
4.1.1. Audio Capture . . . . . . . . . . . . . . . . . . . . 33
4.1.2. Capture Device . . . . . . . . . . . . . . . . . . . 33
4.1.3. Capture Encoding . . . . . . . . . . . . . . . . . . 33
4.1.4. Capture Scene . . . . . . . . . . . . . . . . . . . . 34
4.1.5. Endpoint . . . . . . . . . . . . . . . . . . . . . . 34
4.1.6. Individual Encoding . . . . . . . . . . . . . . . . . 34
4.1.7. Media Capture . . . . . . . . . . . . . . . . . . . . 34
4.1.8. Media Consumer . . . . . . . . . . . . . . . . . . . 34
4.1.9. Media Provider . . . . . . . . . . . . . . . . . . . 34
4.1.10. Stream . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.11. Video Capture . . . . . . . . . . . . . . . . . . . . 34
4.2. Media Description . . . . . . . . . . . . . . . . . . . . 34
4.3. Media Stream . . . . . . . . . . . . . . . . . . . . . . 35
4.4. Multimedia Conference . . . . . . . . . . . . . . . . . . 35
4.5. Multimedia Session . . . . . . . . . . . . . . . . . . . 35
4.6. Multipoint Control Unit (MCU) . . . . . . . . . . . . . . 35
4.7. Multi-Session Transmission (MST) . . . . . . . . . . . . 35
4.8. Recording Device . . . . . . . . . . . . . . . . . . . . 36
4.9. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 36
4.10. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . . 36
4.11. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . 36
4.12. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 36
4.13. Single Session Transmission (SST) . . . . . . . . . . . . 36
4.14. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5. Security Considerations . . . . . . . . . . . . . . . . . . . 37
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 37
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
9. Informative References . . . . . . . . . . . . . . . . . . . 38
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 40
A.1. Modifications Between WG Version -05 and -06 . . . . . . 40
A.2. Modifications Between WG Version -04 and -05 . . . . . . 40
A.3. Modifications Between WG Version -03 and -04 . . . . . . 40
A.4. Modifications Between WG Version -02 and -03 . . . . . . 41
A.5. Modifications Between WG Version -01 and -02 . . . . . . 41
A.6. Modifications Between WG Version -00 and -01 . . . . . . 42
A.7. Modifications Between Version -02 and -03 . . . . . . . . 43
A.8. Modifications Between Version -01 and -02 . . . . . . . . 43
A.9. Modifications Between Version -00 and -01 . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The existing taxonomy of sources in RTP is often regarded as The existing taxonomy of sources in Real-Time Transport Protocol
confusing and inconsistent. Consequently, a deep understanding of (RTP) [RFC3550] has previously often been regarded as confusing and
how the different terms relate to each other becomes a real inconsistent. Consequently, a deep understanding of how the
challenge. Frequently cited examples of this confusion are (1) how different terms relate to each other becomes a real challenge.
different protocols that make use of RTP use the same terms to Frequently cited examples of this confusion are (1) how different
signify different things and (2) how the complexities addressed at protocols that make use of RTP use the same terms to signify
one layer are often glossed over or ignored at another. different things and (2) how the complexities addressed at one layer
are often glossed over or ignored at another.
This document attempts to provide some clarity by reviewing the This document provides some clarity by reviewing the semantics of
semantics of various aspects of sources in RTP. As an organizing various aspects of sources in RTP. As an organizing mechanism, it
mechanism, it approaches this by describing various ways that RTP approaches this by describing various ways that RTP sources are
sources can be grouped and associated together. transformed on their way between sender and receiver, and how they
can be grouped and associated together.
All non-specific references to ControLling mUltiple streams for All non-specific references to ControLling mUltiple streams for
tElepresence (CLUE) in this document map to [I-D.ietf-clue-framework] tElepresence (CLUE) in this document map to [I-D.ietf-clue-framework]
and all references to Web Real-Time Communications (WebRTC) map to and all references to Web Real-Time Communications (WebRTC) map to
[I-D.ietf-rtcweb-overview]. [I-D.ietf-rtcweb-overview].
2. Concepts 2. Concepts
This section defines concepts that serve to identify and name various This section defines concepts that serve to identify and name various
transformations and streams in a given RTP usage. For each concept transformations and streams in a given RTP usage. For each concept
skipping to change at page 5, line 43 skipping to change at page 5, line 45
(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
transformation to make them different. transformation to make them different.
o There are no formal limitations on how streams are connected to o There are no formal limitations on how streams are connected to
transformations, this may include loops if required by a transformations.
particular transformation.
It is also important to remember that this is a conceptual model. It is also important to remember that this is a conceptual model.
Thus real-world implementations may look different and have different Thus real-world implementations may look different and have different
structure. structure.
To provide a basic understanding of the relationships in the chain we To provide a basic understanding of the relationships in the chain we
first introduce the concepts for the sender side (Figure 1). This first introduce the concepts for the sender side (Figure 1). This
covers physical stimuli until media packets are emitted onto the covers physical stimuli until media packets are emitted onto the
network. network.
Physical Stimulus Physical Stimulus
| |
V V
+--------------------+ +----------------------+
| Media Capture | | Media Capture |
+--------------------+ +----------------------+
| |
Raw Stream Raw Stream
V V
+--------------------+ +----------------------+
| Media Source |<- Synchronization Timing | Media Source |<- Synchronization Timing
+--------------------+ +----------------------+
| |
Source Stream Source Stream
V V
+--------------------+ +----------------------+
| Media Encoder | | Media Encoder |
+--------------------+ +----------------------+
| |
Encoded Stream +------------+ Encoded Stream +------------+
V | V V | V
+--------------------+ | +----------------------+ +----------------------+ | +----------------------+
| Media Packetizer | | | RTP-based Redundancy | | Media Packetizer | | | RTP-based Redundancy |
+--------------------+ | +----------------------+ +----------------------+ | +----------------------+
| | | | | |
+------------+ Redundancy RTP Stream +-------------+ Redundancy RTP Stream
Source RTP Stream | Source RTP Stream |
V V V V
+--------------------+ +--------------------+ +----------------------+ +----------------------+
| Media Transport | | Media Transport | | RTP-based Security | | RTP-based Security |
+--------------------+ +--------------------+ +----------------------+ +----------------------+
| |
Secured RTP Stream Secured Redundancy RTP Stream
V V
+----------------------+ +----------------------+
| Media Transport | | Media Transport |
+----------------------+ +----------------------+
Figure 1: Sender Side Concepts in the Media Chain 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 in The Media Transport concept is an aggregate that is decomposed in
Section 2.1.13. Section 2.1.15.
In Figure 2 we review a receiver media chain matching the sender In Figure 2 we review a receiver media chain matching the sender
side, to look at the inverse transformations and their attempts to side, to look at the inverse transformations and their attempts to
recover identical streams as in the sender chain, subject to what may recover identical streams as in the sender chain, subject to what may
be lossy compression and imperfect Media Transport. Note that the be lossy compression and imperfect Media Transport. Note that the
streams out of a reverse transformation, like the Source Stream out streams out of a reverse transformation, like the Source Stream out
the Media Decoder are in many cases not the same as the corresponding the Media Decoder are in many cases not the same as the corresponding
ones on the sender side, thus they are prefixed with a "Received" to ones on the sender side, thus they are prefixed with a "Received" to
denote a potentially modified version. The reason for not being the denote a potentially modified version. The reason for not being the
same lies in the transformations that can be of irreversible type. same lies in the transformations that can be of irreversible type.
For example, lossy source coding in the Media Encoder prevents the For example, lossy source coding in the Media Encoder prevents the
Source Stream out of the Media Decoder to be the same as the one fed Source Stream out of the Media Decoder to be the same as the one fed
into the Media Encoder. Other reasons include packet loss or late into the Media Encoder. Other reasons include packet loss or late
loss in the Media Transport transformation that even RTP-based loss in the Media Transport transformation that even RTP-based
Repair, if used, fails to repair. However, some transformations are Repair, if used, fails to repair. However, some transformations are
not always present, like RTP-based Repair that cannot operate without not always present, like RTP-based Repair that cannot operate without
Redundancy RTP Streams. Redundancy RTP Streams.
+--------------------+ +--------------------+ +----------------------+ +----------------------+
| Media Transport | | Media Transport | | Media Transport | | Media Transport |
+--------------------+ +--------------------+ +----------------------+ +----------------------+
| | Received | Received | Secured
Received RTP Stream Received Redundancy RTP Stream Secured RTP Stream Redundancy RTP Stream
| | V V
| +-------------------+ +----------------------+ +----------------------+
V V | RTP-based Validation | | RTP-based Validation |
+--------------------+ +----------------------+ +----------------------+
| RTP-based Repair | | |
+--------------------+ Received RTP Stream Received Redundancy RTP Stream
| |
| +--------------------+
V V
+----------------------+
| RTP-based Repair |
+----------------------+
| |
Repaired RTP Stream Repaired RTP Stream
V V
+--------------------+ +----------------------+
| Media Depacketizer | | Media Depacketizer |
+--------------------+ +----------------------+
| |
Received Encoded Stream Received Encoded Stream
V V
+--------------------+ +----------------------+
| Media Decoder | | Media Decoder |
+--------------------+ +----------------------+
| |
Received Source Stream Received Source Stream
V V
+--------------------+ +----------------------+
| Media Sink |--> Synchronization Information | Media Sink |--> Synchronization Information
+--------------------+ +----------------------+
| |
Received Raw Stream Received Raw Stream
V V
+--------------------+ +----------------------+
| Media Renderer | | Media Renderer |
+--------------------+ +----------------------+
| |
V V
Physical Stimulus Physical Stimulus
Figure 2: Receiver Side Concepts of the Media Chain Figure 2: Receiver Side Concepts of the Media Chain
2.1.1. Physical Stimulus 2.1.1. Physical Stimulus
The physical stimulus is a physical event that can be sampled and The physical stimulus is a physical event 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,
or other excitations or interactions with sensors, like keystrokes on or other excitations or interactions with sensors, 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
its periodical sampling, or at least being timed asynchronous events, considered "Media", because it includes data that is periodically
some form of a stream of media data. The Media Capture is normally sampled, or made up of a set of timed asynchronous events. The Media
instantiated in some type of device, i.e. media capture device. Capture is normally instantiated in some type of device, i.e. media
Examples of different types of media capturing devices are digital capture device. Examples of different types of media capturing
cameras, microphones connected to A/D converters, or keyboards. devices are digital cameras, microphones connected to A/D converters,
or keyboards.
Characteristics: Characteristics:
o A Media Capture is identified either by hardware/manufacturer ID o A Media Capture is identified either by hardware/manufacturer ID
or via a session-scoped device identifier as mandated by the or via a session-scoped device identifier as mandated by the
application usage. application usage.
o A Media Capture can generate an Encoded Stream (Section 2.1.7) if o A Media Capture can generate an Encoded Stream (Section 2.1.7) if
the capture device support such a configuration. the capture device supports such a configuration.
o The nature of the Media Capture may impose constraints on the o The nature of the Media Capture may impose constraints on the
clock handling in some of the subsequent steps. For example, many clock handling in some of the subsequent steps. For example, many
audio or video capture devices are not completely free in audio or video capture devices are not completely free in
selecting the sample rate. selecting the sample rate.
2.1.3. Raw Stream 2.1.3. Raw Stream
The time progressing stream of digitally sampled information, usually The time progressing stream of digitally sampled information, usually
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 time progressing digital
synchronized, time progressing, digital media stream, called a Source media stream synchronized to a reference clock. This stream is
Stream (Section 2.1.5). This transformation takes one or more Raw called a Source Stream (Section 2.1.5). This transformation takes
Streams (Section 2.1.3) and provides a Source Stream as output. The one or more Raw Streams (Section 2.1.3) and provides a Source Stream
output is synchronized with a reference clock (Section 3.1), which as output. The output is synchronized with a reference clock
can be as simple as a system local wall clock or as complex as NTP (Section 3.1), which can be as simple as a system local wall clock or
synchronized. as complex as an NTP synchronized clock.
The output can be of different types. One type is directly The output can be of different types. One type is directly
associated with a particular Media Capture's Raw Stream. Others are associated with a particular Media Capture's Raw Stream. Others are
more conceptual sources, like an audio mix of multiple Source Streams more conceptual sources, like an audio mix of multiple Source Streams
(Figure 3). Mixing multiple streams typically requires that the (Figure 3). Mixing multiple streams typically requires that the
input streams are possible to relate in time, meaning that they have input streams are possible to relate in time, meaning that they have
to be Source Streams (Section 2.1.5) rather than Raw Streams. In to be Source Streams (Section 2.1.5) rather than Raw Streams. In
Figure 3, the generated Source Stream is a mix of the three input Figure 3, the generated Source Stream is a mix of the three input
Source Streams. Source Streams.
skipping to change at page 10, line 30 skipping to change at page 10, line 44
Source Stream Source Stream
Figure 3: Conceptual Media Source in form of Audio Mixer Figure 3: Conceptual Media Source in form of Audio Mixer
Another possible example of a conceptual Media Source is a video Another possible example of a conceptual Media Source is a video
surveillance switch, where the input is multiple Source Streams from surveillance switch, where the input is multiple Source Streams from
different cameras, and the output is one of those Source Streams different cameras, and the output is one of those Source Streams
based on some selection criteria, like a round-robin or based on some based on some selection criteria, like a round-robin or based on some
video activity measure. video activity measure.
Characteristics:
o At any point, it can represent a physical captured source or
conceptual source.
2.1.5. Source Stream 2.1.5. Source Stream
A time progressing stream of digital samples that has been A stream of digital samples that has been synchronized with a
synchronized with a reference clock and comes from particular Media reference clock and comes from particular Media Source
Source (Section 2.1.4). (Section 2.1.4).
2.1.6. Media Encoder 2.1.6. Media Encoder
A Media Encoder is a transform that is responsible for encoding the A Media Encoder is a transform that is responsible for encoding the
media data from a Source Stream (Section 2.1.5) into another media data from a Source Stream (Section 2.1.5) into another
representation, usually more compact, that is output as an Encoded representation, usually more compact, that is output as an Encoded
Stream (Section 2.1.7). Stream (Section 2.1.7).
The Media Encoder step commonly includes pre-encoding The Media Encoder step commonly includes pre-encoding
transformations, such as scaling, resampling etc. The Media Encoder transformations, such as scaling, resampling etc. The Media Encoder
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 codec, bit-rate, start points for decoding, resolution, bandwidth
other fidelity affecting properties. The actually used codec is also or other fidelity affecting properties.
an important factor in many communication systems.
Scalable Media Encoders need special attention as they produce Scalable Media Encoders need special attention as they produce
multiple outputs that are potentially of different types. As shown multiple outputs that are potentially of different types. As shown
in Figure 4, a scalable Media Encoder takes one input Source Stream in Figure 4, a scalable Media Encoder takes one input Source Stream
and encodes it into multiple output streams of two different types; and encodes it into multiple output streams of two different types;
at least one Encoded Stream that is independently decodable and one at least one Encoded Stream that is independently decodable and one
or more Dependent Streams (Section 2.1.8). Decoding requires at or more Dependent Streams (Section 2.1.8). Decoding requires at
least one Encoded Stream and zero or more Dependent Streams. A least one Encoded Stream and zero or more Dependent Streams. A
Dependent Stream's dependency is one of the grouping relations this Dependent Stream's dependency is one of the grouping relations this
document discusses further in Section 3.7. document discusses further in Section 3.7.
skipping to change at page 11, line 44 skipping to change at page 12, line 7
However, (logically) combining multiple of these Encoded Streams into However, (logically) combining multiple of these Encoded Streams into
a single Received Source Stream during decoding leads to an a single Received Source Stream during decoding leads to an
improvement in perceptual reproduced quality when compared to improvement in perceptual reproduced quality when compared to
decoding a single Encoded Stream. decoding a single Encoded Stream.
Creating multiple Encoded Streams from the same Source Stream, where Creating multiple Encoded Streams from the same Source Stream, where
the Encoded Streams are neither in a scalable nor in an MDC the Encoded Streams are neither in a scalable nor in an MDC
relationship is commonly utilized in Simulcast relationship is commonly utilized in Simulcast
[I-D.ietf-mmusic-sdp-simulcast] environments. [I-D.ietf-mmusic-sdp-simulcast] environments.
Characteristics:
o A Media Source can be multiply encoded by different Media Encoders
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.
Characteristics: Due to temporal dependencies, an Encoded Stream may have limitations
in where decoding can be started. These entry points, for example
o Due to temporal dependencies, an Encoded Stream may have Intra frames from a video encoder, may require identification and
limitations in where decoding can be started. These entry points, their generation may be event based or configured to occur
for example Intra frames from a video encoder, may require periodically.
identification and their generation may be event based or
configured to occur periodically.
2.1.8. Dependent Stream 2.1.8. Dependent Stream
A stream of time synchronized encoded media fragments that are A stream of time synchronized encoded media fragments that are
dependent on one or more Encoded Streams (Section 2.1.7) and zero or dependent on one or more Encoded Streams (Section 2.1.7) and zero or
more Dependent Streams to be possible to decode. more Dependent Streams to be possible to decode.
Characteristics: Each Dependent Stream has a set of dependencies. These dependencies
must be understood by the parties in a Multimedia Session that intend
o Each Dependent Stream has a set of dependencies. These to use a Dependent Stream.
dependencies must be understood by the parties in a Multimedia
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 Streams (Section 2.1.8) and put their content into one or Dependent Streams (Section 2.1.8) and put their content into one or
more sequences of packets, normally RTP packets, and output Source more sequences of packets, normally RTP packets, and output Source
RTP Streams (Section 2.1.10). This step includes both generating RTP RTP Streams (Section 2.1.10). This step includes both generating RTP
payloads as well as RTP packets. payloads as well as RTP packets. The Media Packetizer then selects
which Synchronization source(s) (SSRC) [RFC3550] and RTP Sessions to
The Media Packetizer can use multiple inputs when producing a single use.
RTP Stream. One such example is SRST packetization when using
Scalable Video Coding (SVC) (Section 3.7).
The Media Packetizer can also produce multiple RTP Streams, for
example when Encoded and/or Dependent Streams are distributed over
multiple RTP Streams. One example of this is MRMT packetization when
using SVC (Section 3.7).
Characteristics: The Media Packetizer can combine multiple Encoded or Dependent
Streams into one or more RTP Streams:
o The Media Packetizer will select which Synchronization source(s) o The Media Packetizer can use multiple inputs when producing a
(SSRC) [RFC3550] in which RTP Sessions that are used. single RTP Stream. One such example is SRST packetization when
using Scalable Video Coding (SVC) (Section 3.7).
o Media Packetizer can combine multiple Encoded or Dependent Streams o The Media Packetizer can also produce multiple RTP Streams, for
into one or more RTP Streams. example when Encoded and/or Dependent Streams are distributed over
multiple RTP Streams. One example of this is MRMT packetization
when using SVC (Section 3.7).
2.1.10. RTP Stream 2.1.10. RTP Stream
A stream of RTP packets containing media data, source or redundant. 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 an RTP Stream containing at least some content
from an Encoded Stream (Section 2.1.7). Source material is any media from an Encoded Stream (Section 2.1.7) at some point during its
material that is produced for transport over RTP without any lifetime. Source material is any media material that is produced for
additional RTP-based redundancy applied. Note that RTP-based transport over RTP without any additional RTP-based redundancy
redundancy excludes the type of redundancy that most suitable Media applied. Note that RTP-based redundancy excludes the type of
Encoders (Section 2.1.6) may add to the media format of the Encoded redundancy that most suitable Media Encoders (Section 2.1.6) may add
Stream that makes it cope better with inevitable RTP packet losses. to the media format of the Encoded Stream that makes it cope better
This is further described in RTP-based Redundancy (Section 2.1.11) with inevitable RTP packet losses. This is further described in RTP-
and Redundancy RTP Stream (Section 2.1.12). based Redundancy (Section 2.1.11) and Redundancy RTP Stream
(Section 2.1.12).
Characteristics: Characteristics:
o Each RTP Stream is identified by a Synchronization source (SSRC) o Each RTP Stream is identified by a Synchronization source (SSRC)
[RFC3550] that is carried in every RTP and RTP Control Protocol [RFC3550] that is carried in every RTP and RTP Control Protocol
(RTCP) packet header. The SSRC is unique in a specific RTP (RTCP) packet header. The SSRC is unique in a specific RTP
Session context. Session context.
o At any given point in time, a RTP Stream can have one and only one o At any given point in time, a RTP Stream can have one and only one
SSRC, but SSRCs for a given RTP Stream can change over time. SSRC SSRC, but SSRCs for a given RTP Stream can change over time. SSRC
skipping to change at page 14, line 21 skipping to change at page 14, line 19
duplication (Section 3.8)), they may generate a new Source Stream by duplication (Section 3.8)), they may generate a new Source Stream by
combining redundancy information with source information (Using XOR combining redundancy information with source information (Using XOR
FEC (Section 3.11) as a redundancy payload (Section 3.9)), or FEC (Section 3.11) as a redundancy payload (Section 3.9)), or
completely replace the source information with only redundancy completely replace the source information with only redundancy
packets. packets.
2.1.12. Redundancy RTP Stream 2.1.12. Redundancy RTP Stream
A RTP Stream (Section 2.1.10) that contains no original source data, A RTP Stream (Section 2.1.10) that contains no original source data,
only redundant data, which may either be used standalone or be only redundant data, which may either be used standalone or be
combined with one or more Received RTP Streams (Section 2.1.19) to combined with one or more Received RTP Streams (Section 2.1.23) to
produce Repaired RTP Streams (Section 2.1.22). produce Repaired RTP Streams (Section 2.1.26).
2.1.13. Media Transport 2.1.13. RTP-based Security
The optional RTP-based Security transformation applies security
services such as authentication, integrity protection and
confidentiality to an input RTP Stream, like what is specified in The
Secure Real-time Transport Protocol (SRTP) [RFC3711], producing a
Secured RTP Stream (Section 2.1.14). Either an RTP Stream
(Section 2.1.10) or a Redundancy RTP Stream (Section 2.1.12) can be
used as input to this transformation.
In SRTP and the related Secure RTCP (SRTCP), all of the above
mentioned security services are optional, except for integrity
protection of SRTCP, which is mandatory. Also confidentiality
(encryption) is effectively optional in SRTP, since it is possible to
use a NULL encryption algorithm. As described in [RFC7201], the
strength of SRTP data origin authentication depends on the
cryptographic transform and key management used, for example in group
communication where it is sometimes possible to authenticate group
membership but not the actual RTP Stream sender.
RTP-based Security and RTP-based Redundancy can be combined in a few
different ways. One way is depicted in Figure 1, where an RTP Stream
and its corresponding Redundancy RTP Stream are protected by separate
RTP-based Security transforms. In other cases, like when a Media
Translator is adding FEC in Section 3.2.1.3 of
[I-D.ietf-avtcore-rtp-topologies-update], a middlebox can apply RTP-
based Redundancy to an already Secured RTP Stream instead of a Source
RTP Stream. One example of that is depicted in Figure 5 below.
Source RTP Stream +------------+
V | V
+----------------------+ | +----------------------+
| RTP-based Security | | | RTP-based Redundancy |
+----------------------+ | +----------------------+
| | |
| | Redundancy RTP Stream
+-------------+ |
| V
| +----------------------+
Secured RTP Stream | RTP-based Security |
| +----------------------+
| |
| Secured Redundancy RTP Stream
V V
+----------------------+ +----------------------+
| Media Transport | | Media Transport |
+----------------------+ +----------------------+
Figure 5: Adding Redundancy to a Secured RTP Stream
In this case, the Redundancy RTP Stream may already have been secured
for confidentiality (encrypted) by the first RTP-based Security, and
it may therefore not be necessary to apply additional confidentiality
protection in the second RTP-based Security. To avoid attacks and
negative impact on RTP-based Repair (Section 2.1.25) and the
resulting Repaired RTP Stream (Section 2.1.26), it is however still
necessary to have this second RTP-based Security apply both
authentication and integrity protection to the Redundancy RTP Stream.
2.1.14. Secured RTP Stream
A Secured RTP Stream is a Source or Redundancy RTP Stream that is
protected through RTP-based Security (Section 2.1.13) by one or more
of the confidentiality, integrity, or authentication security
services.
2.1.15. Media Transport
A Media Transport defines the transformation that the RTP Streams A Media Transport defines the transformation that the RTP Streams
(Section 2.1.10) are subjected to by the end-to-end transport from (Section 2.1.10) are subjected to by the end-to-end transport from
one RTP sender to one specific RTP receiver (an RTP Session one RTP sender to one specific RTP receiver (an RTP Session
(Section 2.2.2) may contain multiple RTP receivers per sender). Each (Section 2.2.2) may contain multiple RTP receivers per sender). Each
Media Transport is defined by a transport association that is Media Transport is defined by a transport association that is
normally identified by a 5-tuple (source address, source port, normally identified by a 5-tuple (source address, source port,
destination address, destination port, transport protocol), but a destination address, destination port, transport protocol), but a
proposal exists for sending multiple transport associations on a proposal exists for sending multiple transport associations on a
single 5-tuple [I-D.westerlund-avtcore-transport-multiplexing]. single 5-tuple [I-D.westerlund-avtcore-transport-multiplexing].
skipping to change at page 14, line 48 skipping to change at page 16, line 17
o Media Transport transmits RTP Streams of RTP Packets from a source o Media Transport transmits RTP Streams of RTP Packets from a source
transport address to a destination transport address. transport address to a destination transport address.
o Each Media Transport contains only a single RTP Session. o Each Media Transport contains only a single RTP Session.
o A single RTP Session can span multiple Media Transports. o A single RTP Session can span multiple Media Transports.
The Media Transport concept sometimes needs to be decomposed into The Media Transport concept sometimes needs to be decomposed into
more steps to enable discussion of what a sender emits that gets more steps to enable discussion of what a sender emits that gets
transformed by the network before it is received by the receiver. transformed by the network before it is received by the receiver.
Thus we provide also this Media Transport decomposition (Figure 5). Thus we provide also this Media Transport decomposition (Figure 6).
RTP Stream RTP Stream
| |
V V
+--------------------------+ +--------------------------+
| Media Transport Sender | | Media Transport Sender |
+--------------------------+ +--------------------------+
| |
Sent RTP Stream Sent RTP Stream
V V
skipping to change at page 15, line 27 skipping to change at page 16, line 41
| |
Transported RTP Stream Transported RTP Stream
V V
+--------------------------+ +--------------------------+
| Media Transport Receiver | | Media Transport Receiver |
+--------------------------+ +--------------------------+
| |
V V
Received RTP Stream Received RTP Stream
Figure 5: Decomposition of Media Transport Figure 6: Decomposition of Media Transport
2.1.14. Media Transport Sender 2.1.16. Media Transport Sender
The first transformation within the Media Transport (Section 2.1.13) The first transformation within the Media Transport (Section 2.1.15)
is the Media Transport Sender. The sending Endpoint (Section 2.2.1) is the Media Transport Sender. The sending Endpoint (Section 2.2.1)
takes an RTP Stream and emits the packets onto the network using the takes an RTP Stream and emits the packets onto the network using the
transport association established for this Media Transport, thereby transport association established for this Media Transport, thereby
creating a Sent RTP Stream (Section 2.1.15). In the process, it creating a Sent RTP Stream (Section 2.1.17). In the process, it
transforms the RTP Stream in several ways. First, it generates the transforms the RTP Stream in several ways. First, it generates the
necessary protocol headers for the transport association, for example necessary protocol headers for the transport association, for example
IP and UDP headers, thus forming IP/UDP/RTP packets. In addition, IP and UDP headers, thus forming IP/UDP/RTP packets. In addition,
the Media Transport Sender may queue, pace or otherwise affect how the Media Transport Sender may queue, pace or otherwise affect how
the packets are emitted onto the network, thereby potentially the packets are emitted onto the network, thereby potentially
introducing delay, jitter and inter packet spacings that characterize introducing delay, jitter and inter packet spacings that characterize
the Sent RTP Stream. the Sent RTP Stream.
2.1.15. Sent RTP Stream 2.1.17. Sent RTP Stream
The Sent RTP Stream is the RTP Stream as entering the first hop of The Sent RTP Stream is the RTP Stream as entering the first hop of
the network path to its destination. The Sent RTP Stream is the network path to its destination. The Sent RTP Stream is
identified using network transport addresses, like for IP/UDP the identified using network transport addresses, like for IP/UDP the
5-tuple (source IP address, source port, destination IP address, 5-tuple (source IP address, source port, destination IP address,
destination port, and protocol (UDP)). destination port, and protocol (UDP)).
2.1.16. Network Transport 2.1.18. Network Transport
Network Transport is the transformation that subjects the Sent RTP Network Transport is the transformation that subjects the Sent RTP
Stream (Section 2.1.15) to traveling from the source to the Stream (Section 2.1.17) to traveling from the source to the
destination through the network. This transformation can result in destination through the network. This transformation can result in
loss of some packets, varying delay on a per packet basis, packet loss of some packets, varying delay on a per packet basis, packet
duplication, and packet header or data corruption. This duplication, and packet header or data corruption. This
transformation produces a Transported RTP Stream (Section 2.1.17) at transformation produces a Transported RTP Stream (Section 2.1.19) at
the exit of the network path. the exit of the network path.
2.1.17. Transported RTP Stream 2.1.19. 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.18).
2.1.18. Media Transport Receiver 2.1.20. Media Transport Receiver
The receiver Endpoint's (Section 2.2.1) transformation of the The receiver Endpoint's (Section 2.2.1) transformation of the
Transported RTP Stream (Section 2.1.17) by its reception process, Transported RTP Stream (Section 2.1.19) by its reception process,
which results in the Received RTP Stream (Section 2.1.19). This which results in the Received RTP Stream (Section 2.1.23). This
transformation includes transport checksums being verified. Sensible transformation includes transport checksums being verified. Sensible
system designs typically either discard packets with mis-matching system designs typically either discard packets with mis-matching
checksums, or pass them on while somehow marking them in the checksums, or pass them on while somehow marking them in the
resulting Received RTP Stream so to alarm subsequent transformations resulting Received RTP Stream so to alert subsequent transformations
about the possible corrupt state. In this context it is worth noting about the possible corrupt state. In this context it is worth noting
that there is typically some probability for corrupt packets to pass that there is typically some probability for corrupt packets to pass
through undetected (with a seemingly correct checksum). Other through undetected (with a seemingly correct checksum). Other
transformations can compensate for delay variations in receiving a transformations can compensate for delay variations in receiving a
packet on the network interface and providing it to the application packet on the network interface and providing it to the application
(de-jitter buffer). (de-jitter buffer).
2.1.19. Received RTP Stream 2.1.21. Received Secured RTP Stream
This is the Secured RTP Stream (Section 2.1.14) resulting from the
Media Transport (Section 2.1.15) aggregate transformation.
2.1.22. RTP-based Validation
RTP-based Validation is the reverse transformation of RTP-based
Security (Section 2.1.13). If this transformation fails, the result
is either not usable and must be discarded, or may be usable but
cannot be trusted. If the transformation succeeds, the result can be
a Received RTP Stream (Section 2.1.23) or a Received Redundancy RTP
Stream (Section 2.1.24), depending on what was input to the
corresponding RTP-based Security transformation, but can also be a
Received Secured RTP Stream (Section 2.1.21) in case several RTP-
based Security transformations were applied.
2.1.23. Received RTP Stream
The 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, aggregate transformation (Section 2.1.15), i.e. subjected to packet
packet duplication and varying transmission delay from sender to loss, packet corruption, packet duplication and varying transmission
receiver. delay from sender to receiver.
2.1.20. Received Redundancy RTP Stream 2.1.24. 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. RTP-based Repair 2.1.25. RTP-based Repair
RTP-based Repair is a Transformation that takes as input zero or more RTP-based Repair is a Transformation that takes as input zero or more
Received RTP Streams (Section 2.1.19) and one or more Received Received RTP Streams (Section 2.1.23) and one or more Received
Redundancy RTP Streams (Section 2.1.20), and produces one or more Redundancy RTP Streams (Section 2.1.24), and produces one or more
Repaired RTP Streams (Section 2.1.22) that are as close to the Repaired RTP Streams (Section 2.1.26) that are as close to the
corresponding sent Source RTP Streams (Section 2.1.10) as possible, corresponding sent Source RTP Streams (Section 2.1.10) as possible,
using different RTP-based repair methods, for example the ones using different RTP-based repair methods, for example the ones
referred in RTP-based Redundancy (Section 2.1.11). referred in RTP-based Redundancy (Section 2.1.11).
2.1.22. Repaired RTP Stream 2.1.26. Repaired RTP Stream
A Received RTP Stream (Section 2.1.19) for which Received Redundancy A Received RTP Stream (Section 2.1.23) for which Received Redundancy
RTP Stream (Section 2.1.20) information has been used to try to RTP Stream (Section 2.1.24) information has been used to try to
recover the Source RTP Stream (Section 2.1.10) as it was before Media recover the Source RTP Stream (Section 2.1.10) as it was before Media
Transport (Section 2.1.13). Transport (Section 2.1.15).
2.1.23. Media Depacketizer 2.1.27. Media Depacketizer
A Media Depacketizer takes one or more RTP Streams (Section 2.1.10), A Media Depacketizer takes one or more RTP Streams (Section 2.1.10),
depacketizes them, and attempts to reconstitute the Encoded Streams depacketizes them, and attempts to reconstitute the Encoded Streams
(Section 2.1.7) or Dependent Streams (Section 2.1.8) present in those (Section 2.1.7) or Dependent Streams (Section 2.1.8) present in those
RTP Streams. RTP Streams.
In practical implementations, the Media Depacketizer and the Media In practical implementations, the Media Depacketizer and the Media
Decoder may be tightly coupled and share information to improve or Decoder may be tightly coupled and share information to improve or
optimize the overall decoding and error concealment process. It is, optimize the overall decoding and error concealment process. It is,
however, not expected that there would be any benefit in defining a however, not expected that there would be any benefit in defining a
taxonomy for those detailed (and likely very implementation- taxonomy for those detailed (and likely very implementation-
dependent) steps. dependent) steps.
2.1.24. Received Encoded Stream 2.1.28. 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.29. Media Decoder
A Media Decoder is a transformation that is responsible for decoding A Media Decoder is a transformation that is responsible for decoding
Encoded Streams (Section 2.1.7) and any Dependent Streams Encoded Streams (Section 2.1.7) and any Dependent Streams
(Section 2.1.8) into a Source Stream (Section 2.1.5). (Section 2.1.8) into a Source Stream (Section 2.1.5).
In practical implementations, the Media Decoder and the Media In practical implementations, the Media Decoder and the Media
Depacketizer may be tightly coupled and share information to improve Depacketizer may be tightly coupled and share information to improve
or optimize the overall decoding process in various ways. It is or optimize the overall decoding process in various ways. It is
however not expected that there would be any benefit in defining a however not expected that there would be any benefit in defining a
taxonomy for those detailed (and likely very implementation- taxonomy for those detailed (and likely very implementation-
dependent) steps. dependent) steps.
Characteristics: A Media Decoder has to deal with any errors in the Encoded Streams
that resulted from corruption or failure to repair packet losses.
o A Media Decoder has to deal with any errors in the Encoded Streams Therefore, it commonly is robust to error and losses, and includes
that resulted from corruption or failure to repair packet losses. concealment methods.
Therefore, it commonly is robust to error and losses, and includes
concealment methods.
2.1.26. Received Source Stream 2.1.30. 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.31. Media Sink
The Media Sink receives a Source Stream (Section 2.1.5) that The Media Sink receives a Source Stream (Section 2.1.5) that
contains, usually periodically, sampled media data together with contains, usually periodically, sampled media data together with
associated synchronization information. Depending on application, associated synchronization information. Depending on application,
this Source Stream then needs to be transformed into a Raw Stream this Source Stream then needs to be transformed into a Raw Stream
(Section 2.1.3) that is conveyed to the Media Render (Section 2.1.3) that is conveyed to the Media Render
(Section 2.1.29), synchronized with the output from other Media (Section 2.1.33), synchronized with the output from other Media
Sinks. The Media Sink may also be connected with a Media Source Sinks. The Media Sink may also be connected with a Media Source
(Section 2.1.4) and be used as part of a conceptual Media Source. (Section 2.1.4) and be used as part of a conceptual Media Source.
Characteristics: The Media Sink can further transform the Source Stream into a
representation that is suitable for rendering on the Media Render as
o The Media Sink can further transform the Source Stream into a defined by the application or system-wide configuration. This
representation that is suitable for rendering on the Media Render include sample scaling, level adjustments etc.
as defined by the application or system-wide configuration. This
include sample scaling, level adjustments etc.
2.1.28. Received Raw Stream 2.1.32. 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.33. Media Render
A Media Render takes a Raw Stream (Section 2.1.3) and converts it A Media Render takes a Raw Stream (Section 2.1.3) and converts it
into Physical Stimulus (Section 2.1.1) that a human user can into Physical Stimulus (Section 2.1.1) that a human user can
perceive. Examples of such devices are screens, and D/A converters perceive. Examples of such devices are screens, and D/A converters
connected to amplifiers and loudspeakers. connected to amplifiers and loudspeakers.
Characteristics: An Endpoint can potentially have multiple Media Renders for each
media type.
o An Endpoint can potentially have multiple Media Renders for each
media type.
2.2. Communication Entities 2.2. Communication Entities
This section contains concepts for entities involved in the This section contains concepts for entities involved in the
communication. communication.
+------------------------------------------------------------+ +------------------------------------------------------------+
| Communication Session | | Communication Session |
| | | |
| +----------------+ +----------------+ | | +----------------+ +----------------+ |
skipping to change at page 19, line 41 skipping to change at page 21, line 36
| | | +----------+-+----------|-----------+-+----------+ | | | | | | +----------+-+----------|-----------+-+----------+ | | |
| | | | RTP | | v | | | | | | | | | | RTP | | v | | | | | |
| | | | Session |<+---Media Transport----+-| | | | | | | | | Session |<+---Media Transport----+-| | | | |
| | | | Video |-+---Media Transport----+>| | | | | | | | | Video |-+---Media Transport----+>| | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
| | | +----------+-+----------------------+-+----------+ | | | | | | +----------+-+----------------------+-+----------+ | | |
| | +------------+ | | +------------+ | | | | +------------+ | | +------------+ | |
| +----------------+ +----------------+ | | +----------------+ +----------------+ |
+------------------------------------------------------------+ +------------------------------------------------------------+
Figure 6: Example Point to Point Communication Session with two RTP Figure 7: Example Point to Point Communication Session with two RTP
Sessions Sessions
Figure 6 shows a high-level example representation of a very basic Figure 7 shows a high-level example representation of a very basic
point-to-point Communication Session between Participants A and B. point-to-point Communication Session between Participants A and B.
It uses two different audio and video RTP Sessions between A's and It uses two different audio and video RTP Sessions between A's and
B's Endpoints, using separate Media Transports for those RTP B's Endpoints, using separate Media Transports for those RTP
Sessions. The Multimedia Session shared by the Participants can, for Sessions. The Multimedia Session shared by the Participants can, for
example, be established using SIP (i.e., there is a SIP Dialog example, be established using SIP (i.e., there is a SIP Dialog
between A and B). The terms used in Figure 6 are further elaborated between A and B). The terms used in Figure 7 are further elaborated
in the sub-sections below. in the sub-sections below.
2.2.1. Endpoint 2.2.1. Endpoint
A single addressable entity sending or receiving RTP packets. It may A single addressable entity sending or receiving RTP packets. It may
be decomposed into several functional blocks, but as long as it be decomposed into several functional blocks, but as long as it
behaves as a single RTP stack entity it is classified as a single behaves as a single RTP stack entity it is classified as a single
"Endpoint". "Endpoint".
Characteristics: Characteristics:
o Endpoints can be identified in several different ways. While RTCP o Endpoints can be identified in several different ways. While RTCP
Canonical Names (CNAMEs) [RFC3550] provide a globally unique and Canonical Names (CNAMEs) [RFC3550] provide a globally unique and
stable identification mechanism for the duration of the stable identification mechanism for the duration of the
Communication Session (see Section 2.2.5), their validity applies Communication Session (see Section 2.2.5), their validity applies
exclusively within a Synchronization Context (Section 3.1). Thus exclusively within a Synchronization Context (Section 3.1). Thus
one Endpoint can handle multiple CNAMEs, each of which can be one Endpoint can handle multiple CNAMEs, each of which can be
shared among a set of Endpoints belonging to the same Participant shared among a set of Endpoints belonging to the same Participant
(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 such as application defined mechanisms, must be used to provide
Endpoint identification when outside this Synchronization Context. Endpoint identification when outside this Synchronization Context.
o An Endpoint can be associated with at most one Participant o An Endpoint 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 Endpoint would typically correspond to a o In some contexts, an Endpoint would typically correspond to a
single "host", for example a computer using a single network single "host", for example a computer using a single network
interface and being used by a single human user. In other interface and being used by a single human user. In other
contexts, a single "host" can serve multiple Participants, in contexts, a single "host" can serve multiple Participants, in
which case each Participant's Endpoint may share properties, for which case each Participant's Endpoint may share properties, for
skipping to change at page 21, line 8 skipping to change at page 23, line 6
o 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 Endpoints participating in an RTP Session [RFC3550]. That is, the Endpoints participating in an RTP Session
can see an SSRC identifier transmitted by any of the other can see an SSRC identifier transmitted by any of the other
Endpoints. An Endpoint can receive an SSRC either as SSRC or as a Endpoints. An Endpoint can receive an SSRC either as SSRC or as a
Contributing source (CSRC) in RTP and RTCP packets, as defined by Contributing source (CSRC) in RTP and RTCP packets, as defined by
the Endpoints' network interconnection topology. 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.15), one for sending and one for receiving.
Commonly, the receiving Media Transport is the reverse direction Commonly, the receiving Media Transport is the reverse direction
of the Media Transport used for sending. An RTP Session may use of the Media Transport used for sending. An RTP Session may use
many Media Transports and these define the session's network many Media Transports and these define the session's network
interconnection topology. interconnection topology.
o A single Media Transport always carries a single RTP Session. o A single Media Transport always carries a single RTP Session.
o Multiple RTP Sessions can be conceptually related, for example o Multiple RTP Sessions can be conceptually related, for example
originating from or targeted for the same Participant originating from or targeted for the same Participant
(Section 2.2.3) or Endpoint (Section 2.2.1), or by containing RTP (Section 2.2.3) or Endpoint (Section 2.2.1), or by containing RTP
skipping to change at page 24, line 43 skipping to change at page 26, line 39
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. Multi-Channel Audio 3.5. 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 single-channel (mono)
audio can be viewed as multiple Media Sources sharing a common encoder. Multi-channel audio can be viewed as multiple Media Sources
Synchronization Context. These are independently encoded by a Media sharing a common Synchronization Context. These are independently
Encoder and the different Encoded Streams are packetized together in encoded by a Media Encoder and the different Encoded Streams are
a time synchronized way into a single Source RTP Stream, using the packetized together in a time synchronized way into a single Source
used codec's RTP Payload format. Examples of codecs that support RTP Stream, using the used codec's RTP Payload format. Examples of
multi-channel audio are PCMA and PCMU [RFC3551], AMR [RFC4867], and codecs that support multi-channel audio are PCMA and PCMU [RFC3551],
G.719 [RFC5404]. AMR [RFC4867], and G.719 [RFC5404].
3.6. Simulcast 3.6. Simulcast
A Media Source represented as multiple independent Encoded Streams A Media Source represented as multiple independent Encoded Streams
constitutes a Simulcast [I-D.ietf-mmusic-sdp-simulcast] or MDC of constitutes a Simulcast [I-D.ietf-mmusic-sdp-simulcast] or MDC of
that Media Source. Figure 7 shows an example of a Media Source that that Media Source. Figure 8 shows an example of a Media Source that
is encoded into three separate Simulcast streams, that are in turn is encoded into three separate Simulcast streams, that are in turn
sent on the same Media Transport flow. When using Simulcast, the RTP sent on the same Media Transport flow. When using Simulcast, the RTP
Streams may be sharing RTP Session and Media Transport, or be Streams may be sharing RTP Session and Media Transport, or be
separated on different RTP Sessions and Media Transports, or any separated on different RTP Sessions and Media Transports, or any
combination of these two. It is other considerations that affect combination of these two. One major reason to use separate Media
which usage is desirable, as discussed in Section 3.12. Transports is to make use of different Quality of Service for the
different Source RTP Streams. Some considerations on separating
related RTP Streams are discussed in Section 3.12.
+----------------+ +----------------+
| Media Source | | Media Source |
+----------------+ +----------------+
Source Stream | Source Stream |
+----------------------+----------------------+ +----------------------+----------------------+
| | | | | |
V V V V V V
+------------------+ +------------------+ +------------------+ +------------------+ +------------------+ +------------------+
| Media Encoder | | Media Encoder | | Media Encoder | | Media Encoder | | Media Encoder | | Media Encoder |
skipping to change at page 25, line 43 skipping to change at page 27, line 45
| Source | Source | Source | Source | Source | Source
| RTP | RTP | RTP | RTP | RTP | RTP
| Stream | Stream | Stream | Stream | Stream | Stream
+-----------------+ | +-----------------+ +-----------------+ | +-----------------+
| | | | | |
V V V V V V
+-------------------+ +-------------------+
| Media Transport | | Media Transport |
+-------------------+ +-------------------+
Figure 7: Example of Media Source Simulcast Figure 8: Example of Media Source Simulcast
The Simulcast relation between the RTP Streams is the common Media The Simulcast relation between the RTP Streams is the common Media
Source. In addition, to be able to identify the common Media Source, Source. In addition, to be able to identify the common Media Source,
a receiver of the RTP Stream may need to know which configuration or a receiver of the RTP Stream may need to know which configuration or
encoding goals that lay behind the produced Encoded Stream and its encoding goals that lay behind the produced Encoded Stream and its
properties. This to enable selection of the stream that is most properties. This enables selection of the stream that is most useful
useful in the application at that moment. in the application at that moment.
3.7. Layered Multi-Stream 3.7. Layered Multi-Stream
Layered Multi-Stream (LMS) is a mechanism by which different portions Layered Multi-Stream (LMS) is a mechanism by which different portions
of a layered or scalable encoding of a Source Stream are sent using of a layered or scalable encoding of a Source Stream are sent using
separate RTP Streams (sometimes in separate RTP Sessions). LMSs are separate RTP Streams (sometimes in separate RTP Sessions). LMSs are
useful for receiver control of layered media. useful for receiver control of layered media.
A Media Source represented as an Encoded Stream and multiple A Media Source represented as an Encoded Stream and multiple
Dependent Streams constitutes a Media Source that has layered Dependent Streams constitutes a Media Source that has layered
dependencies. Figure 8 represents an example of a Media Source that dependencies. Figure 9 represents an example of a Media Source that
is encoded into three dependent layers, where two layers are sent on is encoded into three dependent layers, where two layers are sent on
the same Media Transport using different RTP Streams, i.e. SSRCs, and the same Media Transport using different RTP Streams, i.e. SSRCs, and
the third layer is sent on a separate Media Transport. the third layer is sent on a separate Media Transport.
+----------------+ +----------------+
| Media Source | | Media Source |
+----------------+ +----------------+
| |
| |
V V
skipping to change at page 26, line 45 skipping to change at page 28, line 45
| | | | | |
RTP Stream RTP Stream RTP Stream RTP Stream RTP Stream RTP Stream
| | | | | |
+------+ +------+ | +------+ +------+ |
| | | | | |
V V V V V V
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| Media Transport | | Media Transport | | Media Transport | | Media Transport |
+-----------------+ +-----------------+ +-----------------+ +-----------------+
Figure 8: Example of Media Source Layered Dependency Figure 9: Example of Media Source Layered Dependency
It is sometimes useful to make a distinction between using a single It is sometimes useful to make a distinction between using a single
Media Transport or multiple separate Media Transports when (in both Media Transport or multiple separate Media Transports when (in both
cases) using multiple RTP Streams to carry Encoded Streams and cases) using multiple RTP Streams to carry Encoded Streams and
Dependent Streams for a Media Source. Therefore, the following new Dependent Streams for a Media Source. Therefore, the following new
terminology is defined here: terminology is defined here:
SRST: Single RTP Stream on a Single Media Transport SRST: Single RTP Stream on a Single Media Transport
MRST: Multiple RTP Streams on a Single Media Transport MRST: Multiple RTP Streams on a Single Media Transport
MRMT: Multiple RTP Streams on Multiple Media Transports MRMT: Multiple RTP Streams on Multiple Media Transports
MRST and MRMT relations needs to identify the common Media Encoder MRST and MRMT relations needs to identify the common Media Encoder
origin for the Encoded and Dependent Streams. When using different origin for the Encoded and Dependent Streams. When using different
RTP Sessions, thus different Media Transports, and as long as there RTP Sessions (MRMT), a single RTP Stream per Media Encoder, and a
is only one RTP Stream per Media Encoder and a single Media Source in single Media Source in each RTP Session, common SSRC and CNAMEs can
each RTP Session (MRMT), common SSRC and CNAMEs can be used to be used to identify the common Media Source. When multiple RTP
identify the common Media Source. When multiple RTP Streams are sent Streams are sent from one Media Encoder in the same RTP Session
from one Media Encoder in the same RTP Session (MRST), then CNAME is (MRST), then CNAME is the only currently specified RTP identifier
the only currently specified RTP identifier that can be used. In that can be used. In cases where multiple Media Encoders use
cases where multiple Media Encoders use multiple Media Sources multiple Media Sources sharing Synchronization Context, and thus
sharing Synchronization Context, and thus having a common CNAME, having a common CNAME, additional heuristics or identification need
additional heuristics or identification need to be applied to create to be applied to create the MRST or MRMT relationships between the
the MRST or MRMT relationships between the RTP Streams. RTP Streams.
3.8. RTP Stream Duplication 3.8. 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 (see Figure 9). It is a specific type of redundancy and all cases (see Figure 10). This is a specific type of redundancy. All
but one Source RTP Stream (Section 2.1.10) are effectively Redundancy but one Source RTP Stream (Section 2.1.10) are effectively Redundancy
RTP Streams (Section 2.1.12), but since both Source and Redundant RTP RTP Streams (Section 2.1.12), but since both Source and Redundant RTP
Streams are the same it does not matter which one is which. This can Streams are the same, it does not matter which one is which. This
also be seen as a specific type of Simulcast (Section 3.6) that can also be seen as a specific type of Simulcast (Section 3.6) that
transmits the same Encoded Stream (Section 2.1.7) multiple times. transmits the same Encoded Stream (Section 2.1.7) multiple times.
+----------------+ +----------------+
| Media Source | | Media Source |
+----------------+ +----------------+
Source Stream | Source Stream |
V V
+----------------+ +----------------+
| Media Encoder | | Media Encoder |
+----------------+ +----------------+
skipping to change at page 28, line 33 skipping to change at page 30, line 33
| | Delay (opt) | | | Delay (opt) |
| +-------------+ | +-------------+
| | | |
+-----------+-----------+ +-----------+-----------+
| |
V V
+-------------------+ +-------------------+
| Media Transport | | Media Transport |
+-------------------+ +-------------------+
Figure 9: Example of RTP Stream Duplication Figure 10: Example of RTP Stream Duplication
3.9. Redundancy Format 3.9. Redundancy Format
The RTP Payload for Redundant Audio Data [RFC2198] defines a The RTP Payload for Redundant Audio Data [RFC2198] defines a
transport for redundant audio data together with primary data in the transport for redundant audio data together with primary data in the
same RTP payload. The redundant data can be a time delayed version same RTP payload. The redundant data can be a time delayed version
of the primary or another time delayed Encoded Stream using a of the primary or another time delayed Encoded Stream using a
different Media Encoder to encode the same Media Source as the different Media Encoder to encode the same Media Source as the
primary, as depicted in Figure 10. primary, as depicted in Figure 11.
+--------------------+ +--------------------+
| Media Source | | Media Source |
+--------------------+ +--------------------+
| |
Source Stream Source Stream
| |
+------------------------+ +------------------------+
| | | |
V V V V
skipping to change at page 29, line 31 skipping to change at page 31, line 31
| | | |
| +------------------+ | +------------------+
V V V V
+--------------------+ +--------------------+
| Media Packetizer | | Media Packetizer |
+--------------------+ +--------------------+
| |
V V
RTP Stream RTP Stream
Figure 10: Concept for usage of Audio Redundancy with different Media Figure 11: Concept for usage of Audio Redundancy with different Media
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. The case depicted above (Figure 11) relates 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.10. RTP Retransmission 3.10. RTP Retransmission
Figure 11 shows an example where a Media Source's Source RTP Stream Figure 12 shows an example where a Media Source's Source RTP Stream
is protected by a retransmission (RTX) flow [RFC4588]. In this is protected by a retransmission (RTX) flow [RFC4588]. In this
example the Source RTP Stream and the Redundancy RTP Stream share the example the Source RTP Stream and the Redundancy RTP Stream share the
same Media Transport. same Media Transport.
+--------------------+ +--------------------+
| Media Source | | Media Source |
+--------------------+ +--------------------+
| |
V V
+--------------------+ +--------------------+
skipping to change at page 30, line 30 skipping to change at page 32, line 30
+------------+ Redundancy RTP Stream +------------+ Redundancy RTP Stream
Source RTP Stream | Source RTP Stream |
| | | |
+---------+ +---------+ +---------+ +---------+
| | | |
V V V V
+-----------------+ +-----------------+
| Media Transport | | Media Transport |
+-----------------+ +-----------------+
Figure 11: Example of Media Source Retransmission Flows Figure 12: Example of Media Source Retransmission Flows
The RTP Retransmission example (Figure 11) illustrates that this The RTP Retransmission example (Figure 12) 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
request, emits a retransmitted packet with an extra payload header as request, emits a retransmitted packet with an extra payload header as
a Redundancy RTP Stream. The RTP Retransmission mechanism [RFC4588] a Redundancy RTP Stream. The RTP Retransmission mechanism [RFC4588]
is specified such that there is a one to one relation between the is specified such that there is a one to one relation between the
Source RTP Stream and the Redundancy RTP Stream. Therefore, a Source RTP Stream and the Redundancy RTP Stream. Therefore, a
Redundancy RTP Stream needs to be associated with its Source RTP Redundancy RTP Stream needs to be associated with its Source RTP
Stream. This is done based on CNAME selectors and heuristics to Stream. This is done based on CNAME selectors and heuristics to
match requested packets for a given Source RTP Stream with the match requested packets for a given Source RTP Stream with the
original sequence number in the payload of any new Redundancy RTP original sequence number in the payload of any new Redundancy RTP
Stream using the RTX payload format. In cases where the Redundancy Stream using the RTX payload format. In cases where the Redundancy
RTP Stream is sent in a separate RTP Session from the Source RTP RTP Stream is sent in a different RTP Session than the Source RTP
Stream, these sessions are related, which is signaled by using the Stream, the RTP Session relation is signaled by using the SDP Media
SDP Media Grouping's [RFC5888] Flow Identification (FID Grouping's [RFC5888] Flow Identification (FID identification-tag)
identification-tag) semantics. semantics.
3.11. Forward Error Correction 3.11. Forward Error Correction
Figure 12 shows an example where two Media Sources' Source RTP Figure 13 shows an example where two Media Sources' Source RTP
Streams are protected by Forward Error Correction (FEC). Source RTP Streams are protected by Forward Error Correction (FEC). Source RTP
Stream A has a RTP-based Redundancy transformation in FEC Encoder 1. Stream A has a RTP-based Redundancy transformation in FEC Encoder 1.
This produces a Redundancy RTP Stream 1, that is only related to This produces a Redundancy RTP Stream 1, that is only related to
Source RTP Stream A. The FEC Encoder 2, however, takes two Source Source RTP Stream A. The FEC Encoder 2, however, takes two Source
RTP Streams (A and B) and produces a Redundancy RTP Stream 2 that RTP Streams (A and B) and produces a Redundancy RTP Stream 2 that
protects them jointly, i.e. Redundancy RTP Stream 2 relates to two protects them jointly, i.e. Redundancy RTP Stream 2 relates to two
Source RTP Streams (a FEC group). FEC decoding, when needed due to Source RTP Streams (a FEC group). FEC decoding, when needed due to
packet loss or packet corruption at the receiver, requires knowledge packet loss or packet corruption at the receiver, requires knowledge
about which Source RTP Streams that the FEC encoding was based on. about which Source RTP Streams that the FEC encoding was based on.
In Figure 12 all RTP Streams are sent on the same Media Transport. In Figure 13 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.
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| Media Source A | | Media Source B | | Media Source A | | Media Source B |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| | | |
V V V V
+--------------------+ +--------------------+ +--------------------+ +--------------------+
skipping to change at page 31, line 52 skipping to change at page 33, line 52
| +---------------+ +---------------+ | | +---------------+ +---------------+ |
| | 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 Redundancy RTP Streams Figure 13: 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 the use of either a separate RTP Session, or 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
Stream is to know the related Source RTP Stream, including its SSRC. Stream is to know the related Source RTP Stream, including its SSRC.
3.12. RTP Stream Separation 3.12. 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 Endpoint. SSRC-based approaches [RFC5576], when used, can same Endpoint. 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 are sent in the
the context of different RTP Sessions to achieve separation, it is context of different RTP Sessions to achieve separation, it is known
known as RTP Session-based separation. This is commonly used when as RTP Session-based separation. This is commonly used when the
the different RTP Streams are intended for different Media 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.
The solutions have been based on using the same SSRC value in the The solutions have been based on using the same SSRC value in the
different RTP Sessions to implicitly indicate their relation. That different RTP Sessions to implicitly indicate their relation. That
way, no explicit RTP level mechanism has been needed, only signaling way, no explicit RTP level mechanism has been needed, only signaling
level relations have been established using semantics from Grouping level relations have been established using semantics from Grouping
of Media lines framework [RFC5888]. Examples of this are RTP of Media lines framework [RFC5888]. Examples of this are RTP
Retransmission [RFC4588], SVC Multi-Session Transmission [RFC6190] Retransmission [RFC4588], SVC Multi-Session Transmission [RFC6190]
and XOR Based FEC [RFC5109]. RTCP CNAME explicitly relates RTP and XOR Based FEC [RFC5109]. RTCP CNAME explicitly relates RTP
skipping to change at page 33, line 13 skipping to change at page 35, line 13
identifiers used for expressing the relationships. identifiers used for expressing the relationships.
3.13. Multiple RTP Sessions over one Media Transport 3.13. Multiple RTP Sessions over one Media Transport
[I-D.westerlund-avtcore-transport-multiplexing] describes a mechanism [I-D.westerlund-avtcore-transport-multiplexing] describes a mechanism
that allows several RTP Sessions to be carried over a single that allows several RTP Sessions to be carried over a single
underlying Media Transport. The main reasons for doing this are underlying Media Transport. The main reasons for doing this are
related to the impact of using one or more Media Transports (using a related to the impact of using one or more Media Transports (using a
common network path or potentially have different ones). The fewer common network path or potentially have different ones). The fewer
Media Transports used, the less need for NAT/FW traversal resources Media Transports used, the less need for NAT/FW traversal resources
and number of flow based Quality of Service (QoS). and smaller number of flow based Quality of Service (QoS).
However, Multiple RTP Sessions over one Media Transport imply that a However, Multiple RTP Sessions over one Media Transport imply that a
single Media Transport 5-tuple is not sufficient to express in which single Media Transport 5-tuple is not sufficient to express in which
RTP Session context a particular RTP Stream exists. Complexities in RTP Session context a particular RTP Stream exists. Complexities in
the relationship between Media Transports and RTP Session already the relationship between Media Transports and RTP Session already
exist as one RTP Session contains multiple Media Transports, e.g. exist as one RTP Session contains multiple Media Transports, e.g.
even a Peer-to-Peer RTP Session with RTP/RTCP Multiplexing requires even a Peer-to-Peer RTP Session with RTP/RTCP Multiplexing requires
two Media Transports, one in each direction. The relationship two Media Transports, one in each direction. The relationship
between Media Transports and RTP Sessions as well as additional between Media Transports and RTP Sessions as well as additional
levels of identifiers need to be considered in both signaling design levels of identifiers need to be considered in both signaling design
skipping to change at page 33, line 39 skipping to change at page 35, line 39
IETF RFC and Internet Drafts (at the time of writing), using the IETF RFC and Internet Drafts (at the time of writing), using the
concepts from previous sections. concepts from previous sections.
4.1. Telepresence Terms 4.1. Telepresence Terms
The terms in this sub-section are used in the context of CLUE The terms in this sub-section are used in the context of CLUE
[I-D.ietf-clue-framework]. [I-D.ietf-clue-framework].
4.1.1. Audio Capture 4.1.1. Audio Capture
Defined in CLUE as a Media Capture (Section 4.1.7) for audio.
Describes an audio Media Source (Section 2.1.4). Describes an audio Media Source (Section 2.1.4).
4.1.2. Capture Device 4.1.2. Capture Device
Identifies a physical entity performing a Media Capture Defined in CLUE as a device that converts physical input into an
(Section 2.1.2) transformation. electrical signal. Identifies a physical entity performing a Media
Capture (Section 2.1.2) transformation.
4.1.3. Capture Encoding 4.1.3. Capture Encoding
Describes an Encoded Stream (Section 2.1.7) related to CLUE specific Defined in CLUE as a specific encoding (Section 4.1.6) of a Media
semantic information. Capture (Section 4.1.7). Describes an Encoded Stream (Section 2.1.7)
related to CLUE specific semantic information.
4.1.4. Capture Scene 4.1.4. Capture Scene
Describes a set of spatially related Media Sources (Section 2.1.4). Defined in CLUE as a structure representing a spatial region captured
by one or more Capture Devices (Section 4.1.2), each capturing media
representing a portion of the region. Describes a set of spatially
related Media Sources (Section 2.1.4).
4.1.5. Endpoint 4.1.5. Endpoint
Describes exactly one Participant (Section 2.2.3) and one or more Defined in CLUE as a CLUE-capable device which is the logical point
Endpoints (Section 2.2.1). of final termination through receiving, decoding and rendering and/or
initiation through capturing, encoding, and sending of media streams
(Section 4.1.10). CLUE further defines it to consist of one or more
physical devices with source and sink media streams, and exactly one
[RFC4353] Participant. Describes exactly one Participant
(Section 2.2.3) and one or more Endpoints (Section 2.2.1).
4.1.6. Individual Encoding 4.1.6. Individual Encoding
Describes the configuration information needed to perform a Media Defined in CLUE as a set of parameters representing a way to encode a
Encoder (Section 2.1.6) transformation. Media Capture (Section 4.1.7) to become a Capture Encoding
(Section 4.1.3). Describes the configuration information needed to
perform a Media Encoder (Section 2.1.6) transformation.
4.1.7. Media Capture 4.1.7. Media Capture
Describes either a Media Capture (Section 2.1.2) or a Media Source Defined in CLUE as a source of media, such as from one or more
(Section 2.1.4), depending on in which context the term is used. Capture Devices (Section 4.1.2) or constructed from other media
streams (Section 4.1.10). Describes either a Media Capture
(Section 2.1.2) or a Media Source (Section 2.1.4), depending on in
which context the term is used.
4.1.8. Media Consumer 4.1.8. Media Consumer
Describes the media receiving part of an Endpoint (Section 2.2.1). Defined in CLUE as a CLUE-capable device that intends to receive
Capture Encodings (Section 4.1.3). Describes the media receiving
part of an Endpoint (Section 2.2.1).
4.1.9. Media Provider 4.1.9. Media Provider
Describes the media sending part of an Endpoint (Section 2.2.1). Defined in CLUE as a CLUE-capable device that intends to send Capture
Encodings (Section 4.1.3). Describes the media sending part of an
Endpoint (Section 2.2.1).
4.1.10. Stream 4.1.10. Stream
Describes an RTP Stream (Section 2.1.10). Defined in CLUE as a Capture Encoding (Section 4.1.3) sent from a
Media Provider (Section 4.1.9) to a Media Consumer (Section 4.1.8)
via RTP. Describes an RTP Stream (Section 2.1.10).
4.1.11. Video Capture 4.1.11. Video Capture
Defined in CLUE as a Media Capture (Section 4.1.7) for video.
Describes a video Media Source (Section 2.1.4). Describes a video Media Source (Section 2.1.4).
4.2. Media Description 4.2. Media Description
A single Session Description Protocol (SDP) [RFC4566] media A single Session Description Protocol (SDP) [RFC4566] media
description (or media block; an m-line and all subsequent lines until description (or media block; an m-line and all subsequent lines until
the next m-line or the end of the SDP) describes part of the the next m-line or the end of the SDP) describes part of the
necessary configuration and identification information needed for a necessary configuration and identification information needed for a
Media Encoder transformation, as well as the necessary configuration Media Encoder transformation, as well as the necessary configuration
and identification information for the Media Decoder to be able to and identification information for the Media Decoder to be able to
skipping to change at page 38, line 14 skipping to change at page 40, line 39
8. IANA Considerations 8. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
9. Informative References 9. Informative References
[I-D.ietf-avtcore-rtp-multi-stream] [I-D.ietf-avtcore-rtp-multi-stream]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session", "Sending Multiple Media Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-06 (work in progress), draft-ietf-avtcore-rtp-multi-stream-07 (work in progress),
October 2014. March 2015.
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-06 (work in progress), ietf-avtcore-rtp-topologies-update-08 (work in progress),
March 2015. June 2015.
[I-D.ietf-clue-framework] [I-D.ietf-clue-framework]
Duckworth, M., Pepperell, A., and S. Wenger, "Framework Duckworth, M., Pepperell, A., and S. Wenger, "Framework
for Telepresence Multi-Streams", draft-ietf-clue- for Telepresence Multi-Streams", draft-ietf-clue-
framework-21 (work in progress), March 2015. framework-22 (work in progress), April 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-17 (work in progress), March 2015. negotiation-22 (work in progress), June 2015.
[I-D.ietf-mmusic-sdp-simulcast] [I-D.ietf-mmusic-sdp-simulcast]
Westerlund, M., Nandakumar, S., and M. Zanaty, "Using Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
Simulcast in SDP and RTP Sessions", draft-ietf-mmusic-sdp- "Using Simulcast in SDP and RTP Sessions", draft-ietf-
simulcast-00 (work in progress), January 2015. mmusic-sdp-simulcast-00 (work in progress), January 2015.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-13 Browser-based Applications", draft-ietf-rtcweb-overview-14
(work in progress), November 2014. (work in progress), June 2015.
[I-D.westerlund-avtcore-transport-multiplexing] [I-D.westerlund-avtcore-transport-multiplexing]
Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP
Sessions onto a Single Lower-Layer Transport", draft- Sessions onto a Single Lower-Layer Transport", draft-
westerlund-avtcore-transport-multiplexing-07 (work in westerlund-avtcore-transport-multiplexing-07 (work in
progress), October 2013. progress), October 2013.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997. September 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353, February
2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
"RTP Payload Format and File Storage Format for the "RTP Payload Format and File Storage Format for the
Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband
skipping to change at page 40, line 8 skipping to change at page 42, line 45
[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.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, April 2014.
[RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. [RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H.
Stokking, "RTP Clock Source Signalling", RFC 7273, June Stokking, "RTP Clock Source Signalling", RFC 7273, June
2014. 2014.
Appendix A. Changes From Earlier Versions Appendix A. Changes From Earlier Versions
NOTE TO RFC EDITOR: Please remove this section prior to publication. NOTE TO RFC EDITOR: Please remove this section prior to publication.
A.1. Modifications Between WG Version -05 and -06 A.1. Modifications Between WG Version -06 and -07
Addresses comments from AD review and GenArt review.
o Added RTP-based Security and RTP-based Validation transform
sections, as well as Secured RTP Stream and Received Secured RTP
Stream sections.
o Improved wording in Abstract and Introduction sections.
o Clarified what is considered "media" in section 2.1.2 Media
Capture.
o Changed a number of "Characteristics" lists to more suitable prose
text.
o Re-worded text around use of Encoded and Dependent RTP Streams in
section 2.1.9 Media Packetizer.
o Clarified description of Source RTP Stream in section 2.1.10.
o Clarified motivation to use separate Media Transports for
Simulcast in section 3.6.
o Added local descriptions of terms imported from CLUE framework.
o Editorial improvements.
A.2. Modifications Between WG Version -05 and -06
o Clarified that a Redundancy RTP Stream can be used standalone to o Clarified that a Redundancy RTP Stream can be used standalone to
generate Repaired RTP Streams. generate Repaired RTP Streams.
o Clarified that (in accordance with above) RTP-based Repair takes o Clarified that (in accordance with above) RTP-based Repair takes
zero or more Received RTP Streams and one or more Received zero or more Received RTP Streams and one or more Received
Redundancy RTP Streams as input. Redundancy RTP Streams as input.
o Changed Figure 6 to more clearly show that Media Transport is o Changed Figure 6 to more clearly show that Media Transport is
terminated in the Endpoint, not in the Particpiant. terminated in the Endpoint, not in the Participant.
o Added a sentence to Endpoint section that clarifies there may be o Added a sentence to Endpoint section that clarifies there may be
contexts where a single "host" can serve multiple Participants, contexts where a single "host" can serve multiple Participants,
making those Endpoints share some properties. making those Endpoints share some properties.
o Merged previous section 3.5 on SST/MST with previous section 3.8 o Merged previous section 3.5 on SST/MST with previous section 3.8
on Layered Multi-Stream into a common section discussing the on Layered Multi-Stream into a common section discussing the
scalable/layered stream relation, and moved improved, descriptive scalable/layered stream relation, and moved improved, descriptive
text on SST and MST to new sub-sections 4.7 and 4.13, describing text on SST and MST to new sub-sections 4.7 and 4.13, describing
them as existing terms. them as existing terms.
o Editorial improvements. o Editorial improvements.
A.2. Modifications Between WG Version -04 and -05 A.3. Modifications Between WG Version -04 and -05
o Editorial improvements. o Editorial improvements.
A.3. Modifications Between WG Version -03 and -04 A.4. Modifications Between WG Version -03 and -04
o Changed "Media Redundancy" and "Media Repair" to "RTP-based o Changed "Media Redundancy" and "Media Repair" to "RTP-based
Redundancy" and "RTP-based Repair", since those terms are more Redundancy" and "RTP-based Repair", since those terms are more
specific and correct. specific and correct.
o Changed "End Point" to "Endpoint" and removed Editor's Note on o Changed "End Point" to "Endpoint" and removed Editor's Note on
this. this.
o Clarified that a Media Capture may impose constraints on clock o Clarified that a Media Capture may impose constraints on clock
handling. handling.
skipping to change at page 41, line 32 skipping to change at page 45, line 5
received by a Media Transport Receiver may still be corrupt. received by a Media Transport Receiver may still be corrupt.
o Clarified that a corrupt packet in a Media Transport Receiver is o Clarified that a corrupt packet in a Media Transport Receiver is
typically either discarded or somehow marked and passed on in the typically either discarded or somehow marked and passed on in the
Received RTP Stream. Received RTP Stream.
o Added Synchronization Context to Figure 6. o Added Synchronization Context to Figure 6.
o Editorial improvements and clarifications. o Editorial improvements and clarifications.
A.4. Modifications Between WG Version -02 and -03 A.5. Modifications Between WG Version -02 and -03
o Changed section 3.5, removing SST-SS/MS and MST-SS/MS, replacing o Changed section 3.5, removing SST-SS/MS and MST-SS/MS, replacing
them with SRST, MRST, and MRMT. them with SRST, MRST, and MRMT.
o Updated section 3.8 to align with terminology changes in section o Updated section 3.8 to align with terminology changes in section
3.5. 3.5.
o Added a new section 4.12, describing the term Multimedia o Added a new section 4.12, describing the term Multimedia
Conference. Conference.
o Changed reference from I-D to now published RFC 7273. o Changed reference from I-D to now published RFC 7273.
o Editorial improvements and clarifications. o Editorial improvements and clarifications.
A.5. Modifications Between WG Version -01 and -02 A.6. 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 42, line 42 skipping to change at page 46, line 16
section per term, mainly by moving text from sections 2 and 3 section per term, mainly by moving text from sections 2 and 3
o Changed all occurrences of Packet Stream to RTP Stream o Changed all occurrences of Packet Stream to RTP Stream
o Moved all normative references to informative, since this is an o Moved all normative references to informative, since this is an
informative document informative document
o Added references to RFC 7160, RFC 7197 and RFC 7198, and removed o Added references to RFC 7160, RFC 7197 and RFC 7198, and removed
unused references unused references
A.6. Modifications Between WG Version -00 and -01 A.7. 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.7. Modifications Between Version -02 and -03 A.8. 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.8. Modifications Between Version -01 and -02 A.9. 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.9. Modifications Between Version -00 and -01 A.10. 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
skipping to change at page 44, line 20 skipping to change at page 47, line 39
Email: snandaku@cisco.com Email: snandaku@cisco.com
Gonzalo Salgueiro Gonzalo Salgueiro
Cisco Systems Cisco Systems
7200-12 Kit Creek Road 7200-12 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US US
Email: gsalguei@cisco.com Email: gsalguei@cisco.com
Bo Burman Bo Burman (editor)
Ericsson Ericsson
Kistavagen 25 Kistavagen 25
SE-164 80 Stockholm SE-16480 Stockholm
Sweden Sweden
Email: bo.burman@ericsson.com Email: bo.burman@ericsson.com
 End of changes. 132 change blocks. 
377 lines changed or deleted 521 lines changed or added

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