draft-ietf-avtext-rtp-grouping-taxonomy-05.txt   draft-ietf-avtext-rtp-grouping-taxonomy-06.txt 
Network Working Group J. Lennox Network Working Group J. Lennox
Internet-Draft Vidyo Internet-Draft Vidyo
Intended status: Informational K. Gross Intended status: Informational K. Gross
Expires: July 26, 2015 AVA Expires: September 6, 2015 AVA
S. Nandakumar S. Nandakumar
G. Salgueiro G. Salgueiro
Cisco Systems Cisco Systems
B. Burman B. Burman
Ericsson Ericsson
January 22, 2015 March 5, 2015
A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport
Protocol (RTP) Sources Protocol (RTP) Sources
draft-ietf-avtext-rtp-grouping-taxonomy-05 draft-ietf-avtext-rtp-grouping-taxonomy-06
Abstract Abstract
The terminology about, and associations among, Real-Time Transport The terminology about, and associations among, Real-Time Transport
Protocol (RTP) sources can be complex and somewhat opaque. This Protocol (RTP) sources can be complex and somewhat opaque. This
document describes a number of existing and proposed relationships document describes a number of existing and proposed relationships
among RTP sources, and attempts to define common terminology for among RTP sources, and attempts to define common terminology for
discussing protocol entities and their relationships. discussing protocol entities and their relationships.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 26, 2015. This Internet-Draft will expire on September 6, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Media Chain . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Physical Stimulus . . . . . . . . . . . . . . . . . . 8 2.1.1. Physical Stimulus . . . . . . . . . . . . . . . . . . 8
2.1.2. Media Capture . . . . . . . . . . . . . . . . . . . . 8 2.1.2. Media Capture . . . . . . . . . . . . . . . . . . . . 9
2.1.3. Raw Stream . . . . . . . . . . . . . . . . . . . . . 8 2.1.3. Raw Stream . . . . . . . . . . . . . . . . . . . . . 9
2.1.4. Media Source . . . . . . . . . . . . . . . . . . . . 8 2.1.4. Media Source . . . . . . . . . . . . . . . . . . . . 9
2.1.5. Source Stream . . . . . . . . . . . . . . . . . . . . 9 2.1.5. Source Stream . . . . . . . . . . . . . . . . . . . . 10
2.1.6. Media Encoder . . . . . . . . . . . . . . . . . . . . 10 2.1.6. Media Encoder . . . . . . . . . . . . . . . . . . . . 10
2.1.7. Encoded Stream . . . . . . . . . . . . . . . . . . . 11 2.1.7. Encoded Stream . . . . . . . . . . . . . . . . . . . 12
2.1.8. Dependent Stream . . . . . . . . . . . . . . . . . . 11 2.1.8. Dependent Stream . . . . . . . . . . . . . . . . . . 12
2.1.9. Media Packetizer . . . . . . . . . . . . . . . . . . 11 2.1.9. Media Packetizer . . . . . . . . . . . . . . . . . . 12
2.1.10. RTP Stream . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . 13 2.1.12. Redundancy RTP Stream . . . . . . . . . . . . . . . . 14
2.1.13. Media Transport . . . . . . . . . . . . . . . . . . . 13 2.1.13. Media Transport . . . . . . . . . . . . . . . . . . . 14
2.1.14. Media Transport Sender . . . . . . . . . . . . . . . 14 2.1.14. Media Transport Sender . . . . . . . . . . . . . . . 15
2.1.15. Sent RTP Stream . . . . . . . . . . . . . . . . . . . 15 2.1.15. Sent RTP Stream . . . . . . . . . . . . . . . . . . . 15
2.1.16. Network Transport . . . . . . . . . . . . . . . . . . 15 2.1.16. Network Transport . . . . . . . . . . . . . . . . . . 16
2.1.17. Transported RTP Stream . . . . . . . . . . . . . . . 15 2.1.17. Transported RTP Stream . . . . . . . . . . . . . . . 16
2.1.18. Media Transport Receiver . . . . . . . . . . . . . . 15 2.1.18. Media Transport Receiver . . . . . . . . . . . . . . 16
2.1.19. Received RTP Stream . . . . . . . . . . . . . . . . . 15 2.1.19. Received RTP Stream . . . . . . . . . . . . . . . . . 16
2.1.20. Received Redundancy RTP Stream . . . . . . . . . . . 16 2.1.20. Received Redundancy RTP Stream . . . . . . . . . . . 16
2.1.21. RTP-based Repair . . . . . . . . . . . . . . . . . . 16 2.1.21. RTP-based Repair . . . . . . . . . . . . . . . . . . 17
2.1.22. Repaired RTP Stream . . . . . . . . . . . . . . . . . 16 2.1.22. Repaired RTP Stream . . . . . . . . . . . . . . . . . 17
2.1.23. Media Depacketizer . . . . . . . . . . . . . . . . . 16 2.1.23. Media Depacketizer . . . . . . . . . . . . . . . . . 17
2.1.24. Received Encoded Stream . . . . . . . . . . . . . . . 16 2.1.24. Received Encoded Stream . . . . . . . . . . . . . . . 17
2.1.25. Media Decoder . . . . . . . . . . . . . . . . . . . . 16 2.1.25. Media Decoder . . . . . . . . . . . . . . . . . . . . 17
2.1.26. Received Source Stream . . . . . . . . . . . . . . . 17 2.1.26. Received Source Stream . . . . . . . . . . . . . . . 18
2.1.27. Media Sink . . . . . . . . . . . . . . . . . . . . . 17 2.1.27. Media Sink . . . . . . . . . . . . . . . . . . . . . 18
2.1.28. Received Raw Stream . . . . . . . . . . . . . . . . . 17 2.1.28. Received Raw Stream . . . . . . . . . . . . . . . . . 18
2.1.29. Media Render . . . . . . . . . . . . . . . . . . . . 17 2.1.29. Media Render . . . . . . . . . . . . . . . . . . . . 18
2.2. Communication Entities . . . . . . . . . . . . . . . . . 18 2.2. Communication Entities . . . . . . . . . . . . . . . . . 19
2.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 19 2.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2. RTP Session . . . . . . . . . . . . . . . . . . . . . 19 2.2.2. RTP Session . . . . . . . . . . . . . . . . . . . . . 20
2.2.3. Participant . . . . . . . . . . . . . . . . . . . . . 20 2.2.3. Participant . . . . . . . . . . . . . . . . . . . . . 21
2.2.4. Multimedia Session . . . . . . . . . . . . . . . . . 20 2.2.4. Multimedia Session . . . . . . . . . . . . . . . . . 21
2.2.5. Communication Session . . . . . . . . . . . . . . . . 21 2.2.5. Communication Session . . . . . . . . . . . . . . . . 22
3. Concepts of Inter-Relations . . . . . . . . . . . . . . . . . 21 3. Concepts of Inter-Relations . . . . . . . . . . . . . . . . . 22
3.1. Synchronization Context . . . . . . . . . . . . . . . . . 21 3.1. Synchronization Context . . . . . . . . . . . . . . . . . 22
3.1.1. RTCP CNAME . . . . . . . . . . . . . . . . . . . . . 22 3.1.1. RTCP CNAME . . . . . . . . . . . . . . . . . . . . . 23
3.1.2. Clock Source Signaling . . . . . . . . . . . . . . . 22 3.1.2. Clock Source Signaling . . . . . . . . . . . . . . . 23
3.1.3. Implicitly via RtcMediaStream . . . . . . . . . . . . 22 3.1.3. Implicitly via RtcMediaStream . . . . . . . . . . . . 23
3.1.4. Explicitly via SDP Mechanisms . . . . . . . . . . . . 22 3.1.4. Explicitly via SDP Mechanisms . . . . . . . . . . . . 23
3.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3. Participant . . . . . . . . . . . . . . . . . . . . . . . 23 3.3. Participant . . . . . . . . . . . . . . . . . . . . . . . 24
3.4. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 23 3.4. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 24
3.5. Single- and Multi-Session Transmission of Dependent 3.5. Multi-Channel Audio . . . . . . . . . . . . . . . . . . . 24
Streams . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.6. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6. Multi-Channel Audio . . . . . . . . . . . . . . . . . . . 24 3.7. Layered Multi-Stream . . . . . . . . . . . . . . . . . . 26
3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 24 3.8. RTP Stream Duplication . . . . . . . . . . . . . . . . . 27
3.8. Layered Multi-Stream . . . . . . . . . . . . . . . . . . 25 3.9. Redundancy Format . . . . . . . . . . . . . . . . . . . . 28
3.9. RTP Stream Duplication . . . . . . . . . . . . . . . . . 27 3.10. RTP Retransmission . . . . . . . . . . . . . . . . . . . 29
3.10. Redundancy Format . . . . . . . . . . . . . . . . . . . . 27 3.11. Forward Error Correction . . . . . . . . . . . . . . . . 31
3.11. RTP Retransmission . . . . . . . . . . . . . . . . . . . 28 3.12. RTP Stream Separation . . . . . . . . . . . . . . . . . . 32
3.12. Forward Error Correction . . . . . . . . . . . . . . . . 30 3.13. Multiple RTP Sessions over one Media Transport . . . . . 33
3.13. RTP Stream Separation . . . . . . . . . . . . . . . . . . 31 4. Mapping from Existing Terms . . . . . . . . . . . . . . . . . 33
3.14. Multiple RTP Sessions over one Media Transport . . . . . 32 4.1. Telepresence Terms . . . . . . . . . . . . . . . . . . . 33
4. Mapping from Existing Terms . . . . . . . . . . . . . . . . . 32 4.1.1. Audio Capture . . . . . . . . . . . . . . . . . . . . 33
4.1. Telepresence Terms . . . . . . . . . . . . . . . . . . . 32 4.1.2. Capture Device . . . . . . . . . . . . . . . . . . . 33
4.1.1. Audio Capture . . . . . . . . . . . . . . . . . . . . 32 4.1.3. Capture Encoding . . . . . . . . . . . . . . . . . . 33
4.1.2. Capture Device . . . . . . . . . . . . . . . . . . . 32 4.1.4. Capture Scene . . . . . . . . . . . . . . . . . . . . 34
4.1.3. Capture Encoding . . . . . . . . . . . . . . . . . . 32 4.1.5. Endpoint . . . . . . . . . . . . . . . . . . . . . . 34
4.1.4. Capture Scene . . . . . . . . . . . . . . . . . . . . 33 4.1.6. Individual Encoding . . . . . . . . . . . . . . . . . 34
4.1.5. Endpoint . . . . . . . . . . . . . . . . . . . . . . 33 4.1.7. Media Capture . . . . . . . . . . . . . . . . . . . . 34
4.1.6. Individual Encoding . . . . . . . . . . . . . . . . . 33 4.1.8. Media Consumer . . . . . . . . . . . . . . . . . . . 34
4.1.7. Media Capture . . . . . . . . . . . . . . . . . . . . 33 4.1.9. Media Provider . . . . . . . . . . . . . . . . . . . 34
4.1.8. Media Consumer . . . . . . . . . . . . . . . . . . . 33 4.1.10. Stream . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.9. Media Provider . . . . . . . . . . . . . . . . . . . 33 4.1.11. Video Capture . . . . . . . . . . . . . . . . . . . . 34
4.1.10. Stream . . . . . . . . . . . . . . . . . . . . . . . 33 4.2. Media Description . . . . . . . . . . . . . . . . . . . . 34
4.1.11. Video Capture . . . . . . . . . . . . . . . . . . . . 33 4.3. Media Stream . . . . . . . . . . . . . . . . . . . . . . 35
4.2. Media Description . . . . . . . . . . . . . . . . . . . . 33 4.4. Multimedia Conference . . . . . . . . . . . . . . . . . . 35
4.3. Media Stream . . . . . . . . . . . . . . . . . . . . . . 34 4.5. Multimedia Session . . . . . . . . . . . . . . . . . . . 35
4.4. Multimedia Conference . . . . . . . . . . . . . . . . . . 34 4.6. Multipoint Control Unit (MCU) . . . . . . . . . . . . . . 35
4.5. Multimedia Session . . . . . . . . . . . . . . . . . . . 34 4.7. Multi-Session Transmission (MST) . . . . . . . . . . . . 35
4.6. Multipoint Control Unit (MCU) . . . . . . . . . . . . . . 34 4.8. Recording Device . . . . . . . . . . . . . . . . . . . . 36
4.7. Recording Device . . . . . . . . . . . . . . . . . . . . 34 4.9. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 36
4.8. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 35 4.10. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . . 36
4.9. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . . 35 4.11. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . 36
4.10. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . 35 4.12. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 36
4.11. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 35 4.13. Single Session Transmission (SST) . . . . . . . . . . . . 36
4.12. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.14. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5. Security Considerations . . . . . . . . . . . . . . . . . . . 35 5. Security Considerations . . . . . . . . . . . . . . . . . . . 37
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 36 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 37
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
9. Informative References . . . . . . . . . . . . . . . . . . . 36 9. Informative References . . . . . . . . . . . . . . . . . . . 38
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 38 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 40
A.1. Modifications Between WG Version -04 and -05 . . . . . . 38 A.1. Modifications Between WG Version -05 and -06 . . . . . . 40
A.2. Modifications Between WG Version -03 and -04 . . . . . . 38 A.2. Modifications Between WG Version -04 and -05 . . . . . . 40
A.3. Modifications Between WG Version -02 and -03 . . . . . . 39 A.3. Modifications Between WG Version -03 and -04 . . . . . . 40
A.4. Modifications Between WG Version -01 and -02 . . . . . . 39 A.4. Modifications Between WG Version -02 and -03 . . . . . . 41
A.5. Modifications Between WG Version -00 and -01 . . . . . . 40 A.5. Modifications Between WG Version -01 and -02 . . . . . . 41
A.6. Modifications Between Version -02 and -03 . . . . . . . . 40 A.6. Modifications Between WG Version -00 and -01 . . . . . . 42
A.7. Modifications Between Version -01 and -02 . . . . . . . . 41 A.7. Modifications Between Version -02 and -03 . . . . . . . . 43
A.8. Modifications Between Version -00 and -01 . . . . . . . . 41 A.8. Modifications Between Version -01 and -02 . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 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 RTP is often regarded as
confusing and inconsistent. Consequently, a deep understanding of confusing and inconsistent. Consequently, a deep understanding of
how the different terms relate to each other becomes a real how the different terms relate to each other becomes a real
challenge. Frequently cited examples of this confusion are (1) how challenge. Frequently cited examples of this confusion are (1) how
different protocols that make use of RTP use the same terms to different protocols that make use of RTP use the same terms to
signify different things and (2) how the complexities addressed at signify different things and (2) how the complexities addressed at
one layer are often glossed over or ignored at another. one layer are often glossed over or ignored at another.
skipping to change at page 10, line 28 skipping to change at page 11, line 16
an important factor in many communication systems. an important factor in many communication systems.
Scalable Media Encoders need special attention as they produce Scalable Media Encoders need special attention as they produce
multiple outputs that are potentially of different types. 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.8. document discusses further in Section 3.7.
Source Stream Source Stream
| |
V V
+--------------------------+ +--------------------------+
| Scalable Media Encoder | | Scalable Media Encoder |
+--------------------------+ +--------------------------+
| | ... | | | ... |
V V V V V V
Encoded Dependent Dependent Encoded Dependent Dependent
skipping to change at page 11, line 7 skipping to change at page 11, line 41
There are also other variants of encoders, like so-called Multiple There are also other variants of encoders, like so-called Multiple
Description Coding (MDC). Such Media Encoder produce multiple Description Coding (MDC). Such Media Encoder produce multiple
independent and thus individually decodable Encoded Streams. independent and thus individually decodable Encoded Streams.
However, (logically) combining multiple of these Encoded Streams into However, (logically) combining multiple of these Encoded Streams into
a single Received Source Stream during decoding leads to an a single Received Source Stream during decoding leads to an
improvement in perceptual reproduced quality when compared to improvement in perceptual reproduced quality when compared to
decoding a single Encoded Stream. decoding a single Encoded Stream.
Creating multiple Encoded Streams from the same Source Stream, where Creating multiple Encoded Streams from the same Source Stream, where
the Encoded Streams are neither in a scalable nor in an MDC the Encoded Streams are neither in a scalable nor in an MDC
relationship is commonly utilized in Simulcast environments. relationship is commonly utilized in Simulcast
[I-D.ietf-mmusic-sdp-simulcast] environments.
Characteristics: Characteristics:
o A Media Source can be multiply encoded by different Media Encoders o A Media Source can be multiply encoded by different Media Encoders
to provide various encoded representations. to provide various encoded representations.
2.1.7. Encoded Stream 2.1.7. Encoded Stream
A stream of time synchronized encoded media that can be independently A stream of time synchronized encoded media that can be independently
decoded. decoded.
skipping to change at page 11, line 49 skipping to change at page 12, line 40
2.1.9. Media Packetizer 2.1.9. Media Packetizer
The transformation of taking one or more Encoded (Section 2.1.7) or The transformation of taking one or more Encoded (Section 2.1.7) or
Dependent Streams (Section 2.1.8) and put their content into one or Dependent Streams (Section 2.1.8) and put their content into one or
more sequences of packets, normally RTP packets, and output Source more sequences of packets, normally RTP packets, and output Source
RTP Streams (Section 2.1.10). This step includes both generating RTP RTP Streams (Section 2.1.10). This step includes both generating RTP
payloads as well as RTP packets. payloads as well as RTP packets.
The Media Packetizer can use multiple inputs when producing a single The Media Packetizer can use multiple inputs when producing a single
RTP Stream. One such example is SRST packetization when using RTP Stream. One such example is SRST packetization when using
Scalable Video Coding (SVC) (Section 3.5). Scalable Video Coding (SVC) (Section 3.7).
The Media Packetizer can also produce multiple RTP Streams, for The Media Packetizer can also produce multiple RTP Streams, for
example when Encoded and/or Dependent Streams are distributed over example when Encoded and/or Dependent Streams are distributed over
multiple RTP Streams. One example of this is MRMT packetization when multiple RTP Streams. One example of this is MRMT packetization when
using SVC (Section 3.5). using SVC (Section 3.7).
Characteristics: Characteristics:
o The Media Packetizer will select which Synchronization source(s) o The Media Packetizer will select which Synchronization source(s)
(SSRC) [RFC3550] in which RTP Sessions that are used. (SSRC) [RFC3550] in which RTP Sessions that are used.
o Media Packetizer can combine multiple Encoded or Dependent Streams o Media Packetizer can combine multiple Encoded or Dependent Streams
into one or more RTP Streams. into one or more RTP Streams.
2.1.10. RTP Stream 2.1.10. RTP Stream
skipping to change at page 13, line 17 skipping to change at page 14, line 9
2.1.11. RTP-based Redundancy 2.1.11. RTP-based Redundancy
RTP-based Redundancy is defined here as a transformation that RTP-based Redundancy is defined here as a transformation that
generates redundant or repair packets sent out as a Redundancy RTP generates redundant or repair packets sent out as a Redundancy RTP
Stream (Section 2.1.12) to mitigate network transport impairments, Stream (Section 2.1.12) to mitigate network transport impairments,
like packet loss and delay. like packet loss and delay.
The RTP-based Redundancy exists in many flavors; they may be The RTP-based Redundancy exists in many flavors; they may be
generating independent Repair Streams that are used in addition to generating independent Repair Streams that are used in addition to
the Source Stream (like RTP Retransmission (Section 3.11) and some the Source Stream (like RTP Retransmission (Section 3.10) and some
special types of Forward Error Correction, like RTP stream special types of Forward Error Correction, like RTP stream
duplication (Section 3.9)), 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.12) as a redundancy payload (Section 3.10)), 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 that may be combined with one or more Received only redundant data, which may either be used standalone or be
RTP Stream (Section 2.1.19) to produce Repaired RTP Streams combined with one or more Received RTP Streams (Section 2.1.19) to
(Section 2.1.22). produce Repaired RTP Streams (Section 2.1.22).
2.1.13. Media Transport 2.1.13. 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
skipping to change at page 16, line 13 skipping to change at page 17, line 7
receiver. receiver.
2.1.20. Received Redundancy RTP Stream 2.1.20. Received Redundancy RTP Stream
The Redundancy RTP Stream (Section 2.1.12) resulting from the Media The Redundancy RTP Stream (Section 2.1.12) resulting from the Media
Transport transformation, i.e. subjected to packet loss, packet Transport transformation, i.e. subjected to packet loss, packet
corruption, and varying transmission delay from sender to receiver. corruption, and varying transmission delay from sender to receiver.
2.1.21. RTP-based Repair 2.1.21. RTP-based Repair
RTP-based Repair is a Transformation that takes as input one or more RTP-based Repair is a Transformation that takes as input zero or more
Received RTP Streams (Section 2.1.19) and Received Redundancy RTP Received RTP Streams (Section 2.1.19) and one or more Received
Streams (Section 2.1.20), and produces one or more Repaired RTP Redundancy RTP Streams (Section 2.1.20), and produces one or more
Streams (Section 2.1.22) that are as close to the corresponding sent Repaired RTP Streams (Section 2.1.22) that are as close to the
Source RTP Streams (Section 2.1.10) as possible, using different RTP- corresponding sent Source RTP Streams (Section 2.1.10) as possible,
based repair methods, for example the ones referred in RTP-based using different RTP-based repair methods, for example the ones
Redundancy (Section 2.1.11). referred in RTP-based Redundancy (Section 2.1.11).
2.1.22. Repaired RTP Stream 2.1.22. Repaired RTP Stream
A Received RTP Stream (Section 2.1.19) for which Received Redundancy A Received RTP Stream (Section 2.1.19) for which Received Redundancy
RTP Stream (Section 2.1.20) information has been used to try to RTP Stream (Section 2.1.20) 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.13).
2.1.23. Media Depacketizer 2.1.23. Media Depacketizer
skipping to change at page 18, line 10 skipping to change at page 19, line 7
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: Characteristics:
o An Endpoint can potentially have multiple Media Renders for each o An Endpoint can potentially have multiple Media Renders for each
media type. media type.
2.2. Communication Entities 2.2. Communication Entities
This section contains concept for entities involved in the This section contains concepts for entities involved in the
communication. communication.
+------------------------------------------------------------+ +------------------------------------------------------------+
| Communication Session | | Communication Session |
| | | |
| +----------------+ +----------------+ | | +----------------+ +----------------+ |
| | Participant A | +------------+ | Participant B | | | | Participant A | +------------+ | Participant B | |
| | | | Multimedia | | | | | | | | Multimedia | | | |
| | +-------------+|<==>| Session |<==>|+-------------+ | | | | +------------+ |<==>| Session |<==>| +------------+ | |
| | | Endpoint A || | | || Endpoint B | | | | | | Endpoint A | | | | | | Endpoint B | | |
| | | || +------------+ || | | | | | | | | +------------+ | | | | |
| | | +-----------++----------------------++-----------+ | | | | | | +----------+-+----------------------+-+----------+ | | |
| | | | | | | | | | | | | | RTP | | | | | | | |
| | | | RTP Session|---Media Transport--->| | | | | | | | | Session |-+---Media Transport----+>| | | | |
| | | | Audio |<---Media Transport---| | | | | | | | | Audio |<+---Media Transport----+-| | | | |
| | | | | ^ | | | | | | | | | | | ^ | | | | | |
| | | +-----------++----------|-----------++-----------+ | | | | | | +----------+-+----------|-----------+-+----------+ | | |
| | | || v || | | | | | | | | v | | | | |
| | | || +-----------------+ || | | | | | | | | +-----------------+ | | | | |
| | | || | Synchronization | || | | | | | | | | | Synchronization | | | | | |
| | | || | Context | || | | | | | | | | | Context | | | | | |
| | | || +-----------------+ || | | | | | | | | +-----------------+ | | | | |
| | | || ^ || | | | | | | | | ^ | | | | |
| | | +-----------++----------|-----------++-----------+ | | | | | | +----------+-+----------|-----------+-+----------+ | | |
| | | | | v | | | | | | | | | RTP | | v | | | | | |
| | | | RTP Session|<---Media Transport---| | | | | | | | | Session |<+---Media Transport----+-| | | | |
| | | | Video |---Media Transport--->| | | | | | | | | Video |-+---Media Transport----+>| | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | +-----------++----------------------++-----------+ | | | | | | +----------+-+----------------------+-+----------+ | | |
| | +-------------+| |+-------------+ | | | | +------------+ | | +------------+ | |
| +----------------+ +----------------+ | | +----------------+ +----------------+ |
+------------------------------------------------------------+ +------------------------------------------------------------+
Figure 6: Example Point to Point Communication Session with two RTP Figure 6: Example Point to Point Communication Session with two RTP
Sessions Sessions
Figure 6 shows a high-level example representation of a very basic Figure 6 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
skipping to change at page 19, line 32 skipping to change at page 20, line 30
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 ensure
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. interface and being used by a single human user. In other
contexts, a single "host" can serve multiple Participants, in
which case each Participant's Endpoint may share properties, for
example the IP address part of a transport address.
2.2.2. RTP Session 2.2.2. RTP Session
An RTP Session is an association among a group of Participants An RTP Session is an association among a group of Participants
communicating with RTP. It is a group communications channel which communicating with RTP. It is a group communications channel which
can potentially carry a number of RTP Streams. Within an RTP can potentially carry a number of RTP Streams. Within an RTP
Session, every Participant can find meta-data and control information Session, every Participant can find meta-data and control information
(over RTCP) about all the RTP Streams in the RTP Session. The (over RTCP) about all the RTP Streams in the RTP Session. The
bandwidth of the RTCP control channel is shared between all bandwidth of the RTCP control channel is shared between all
Participants within an RTP Session. Participants within an RTP Session.
skipping to change at page 21, line 42 skipping to change at page 22, line 42
the Communication Session consists of a set of Multimedia Sessions the Communication Session consists of a set of Multimedia Sessions
between each Participant and the conference handler. between each Participant and the conference handler.
3. Concepts of Inter-Relations 3. Concepts of Inter-Relations
This section uses the concepts from previous sections, and looks at This section uses the concepts from previous sections, and looks at
different types of relationships among them. These relationships different types of relationships among them. These relationships
occur at different abstraction levels and for different purposes, but occur at different abstraction levels and for different purposes, but
the reason for the needed relationship at a certain step in the media the reason for the needed relationship at a certain step in the media
handling chain may exist at another step. For example, the use of handling chain may exist at another step. For example, the use of
Simulcast (Section 3.7)) implies a need to determine relations at RTP Simulcast (Section 3.6)) implies a need to determine relations at RTP
Stream level, but the underlying reason is that multiple Media Stream level, but the underlying reason is that multiple Media
Encoders use the same Media Source, i.e. to be able to identify a Encoders use the same Media Source, i.e. to be able to identify a
common Media Source. common Media Source.
3.1. Synchronization Context 3.1. Synchronization Context
A Synchronization Context defines a requirement on a strong timing A Synchronization Context defines a requirement on a strong timing
relationship between the Media Sources, typically requiring alignment relationship between the Media Sources, typically requiring alignment
of clock sources. Such a relationship can be identified in multiple of clock sources. Such a relationship can be identified in multiple
ways as listed below. A single Media Source can only belong to a ways as listed below. A single Media Source can only belong to a
skipping to change at page 23, line 40 skipping to change at page 24, line 40
varying set of origins and Participants. RTP contains the concept of varying set of origins and Participants. RTP contains the concept of
CSRC that carry information about the previous step origin of the CSRC that carry information about the previous step origin of the
included media content on RTP level. included media content on RTP level.
3.4. RtcMediaStream 3.4. RtcMediaStream
An RtcMediaStream in WebRTC is an explicit grouping of a set of Media An RtcMediaStream in WebRTC is an explicit grouping of a set of Media
Sources (RtcMediaStreamTracks) that share a common identifier and a Sources (RtcMediaStreamTracks) that share a common identifier and a
single Synchronization Context (Section 3.1). single Synchronization Context (Section 3.1).
3.5. Single- and Multi-Session Transmission of Dependent Streams 3.5. Multi-Channel Audio
Scalable media coding formats such as, for example, H.264 based SVC
[RFC6190] has two modes of operation:
1. In Single Session Transmission (SST), the SVC Media Encoder sends
Encoded Streams (Section 2.1.7) and Dependent Streams
(Section 2.1.8) as a single RTP Stream (Section 2.1.10) in a
single RTP Session (Section 2.2.2), using the SVC RTP Payload
format.
2. In Multi-Session Transmission (MST), the SVC Media Encoder sends
Encoded Streams and Dependent Streams distributed across multiple
RTP Streams in one or more RTP Sessions.
SST denotes one RTP Stream (SSRC) per Media Source in a single RTP
Session. MST denotes one or more RTP Streams (SSRC) per Media Source
in each of multiple RTP Sessions. The above is not unambiguously
specified in the SVC payload format text [RFC6190], but it is what
existing deployments of that RFC have implemented.
The use of the term "RTP Session" in the SST/MST definition is
somewhat misleading, since a single RTP Session can contain multiple
RTP Streams. Also, it is sometimes useful to make a distinction
between using a single Media Transport or multiple separate Media
Transports when (in both cases) using multiple RTP Streams to carry
Encoded Streams and Dependent Streams for a Media Source. Therefore,
herein the following new terminology is defined:
SRST: Single RTP Stream on a Single Media Transport
MRST: Multiple RTP Streams on a Single Media Transport
MRMT: Multiple RTP Streams on Multiple Media Transports
3.6. Multi-Channel Audio
There exist a number of RTP payload formats that can carry multi- There exist a number of RTP payload formats that can carry multi-
channel audio, despite the codec being a mono encoder. Multi-channel channel audio, despite the codec being a mono encoder. Multi-channel
audio can be viewed as multiple Media Sources sharing a common audio can be viewed as multiple Media Sources sharing a common
Synchronization Context. These are independently encoded by a Media Synchronization Context. These are independently encoded by a Media
Encoder and the different Encoded Streams are packetized together in Encoder and the different Encoded Streams are packetized together in
a time synchronized way into a single Source RTP Stream, using the a time synchronized way into a single Source RTP Stream, using the
used codec's RTP Payload format. Examples of codecs that support used codec's RTP Payload format. Examples of codecs that support
multi-channel audio are PCMA and PCMU [RFC3551], AMR [RFC4867], and multi-channel audio are PCMA and PCMU [RFC3551], AMR [RFC4867], and
G.719 [RFC5404]. G.719 [RFC5404].
3.7. Simulcast 3.6. Simulcast
A Media Source represented as multiple independent Encoded Streams A Media Source represented as multiple independent Encoded Streams
constitutes a Simulcast or MDC of that Media Source. Figure 7 shows constitutes a Simulcast [I-D.ietf-mmusic-sdp-simulcast] or MDC of
an example of a Media Source that is encoded into three separate that Media Source. Figure 7 shows an example of a Media Source that
Simulcast streams, that are in turn sent on the same Media Transport is encoded into three separate Simulcast streams, that are in turn
flow. When using Simulcast, the RTP Streams may be sharing RTP sent on the same Media Transport flow. When using Simulcast, the RTP
Session and Media Transport, or be separated on different RTP Streams may be sharing RTP Session and Media Transport, or be
Sessions and Media Transports, or any combination of these two. It separated on different RTP Sessions and Media Transports, or any
is other considerations that affect which usage is desirable, as combination of these two. It is other considerations that affect
discussed in Section 3.13. which usage is desirable, as 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 40 skipping to change at page 26, line 5
Figure 7: Example of Media Source Simulcast Figure 7: 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 to enable selection of the stream that is most
useful in the application at that moment. useful in the application at that moment.
3.8. 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 encoding of a Source Stream are sent using separate RTP of a layered or scalable encoding of a Source Stream are sent using
Streams (sometimes in separate RTP Sessions). LMSs are useful for separate RTP Streams (sometimes in separate RTP Sessions). LMSs are
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 8 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, the same Media Transport using different RTP Streams, i.e. SSRCs, and
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
+---------------------------------------------------------+ +---------------------------------------------------------+
| Media Encoder | | Media Encoder |
+---------------------------------------------------------+ +---------------------------------------------------------+
skipping to change at page 26, line 33 skipping to change at page 26, line 47
| | | | | |
+------+ +------+ | +------+ +------+ |
| | | | | |
V V V V V V
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| Media Transport | | Media Transport | | Media Transport | | Media Transport |
+-----------------+ +-----------------+ +-----------------+ +-----------------+
Figure 8: Example of Media Source Layered Dependency Figure 8: Example of Media Source Layered Dependency
As an example, the SVC MRST and MRMT (Section 3.5) relations needs to It is sometimes useful to make a distinction between using a single
identify the common Media Encoder origin for the Encoded and Media Transport or multiple separate Media Transports when (in both
Dependent Streams. The SVC RTP Payload RFC [RFC6190] is not cases) using multiple RTP Streams to carry Encoded Streams and
particularly explicit about how this relation is to be implemented. Dependent Streams for a Media Source. Therefore, the following new
When using different RTP Sessions, thus different Media Transports terminology is defined here:
(MRMT (Section 3.5)), and as long as there is only one RTP Stream per
Media Encoder and a single Media Source in each RTP Session (MRMT),
common SSRC and CNAMEs can be used to identify the common Media
Source. When multiple RTP Streams are sent from one Media Encoder in
the same RTP Session (MRST), then CNAME is the only currently
specified RTP identifier that can be used. In cases where multiple
Media Encoders use multiple Media Sources sharing Synchronization
Context, and thus having a common CNAME, additional heuristics or
identification need to be applied to create the MRST or MRMT
relationships between the RTP Streams.
3.9. RTP Stream Duplication SRST: Single RTP Stream on a Single Media Transport
MRST: Multiple RTP Streams on a Single Media Transport
MRMT: Multiple RTP Streams on Multiple Media Transports
MRST and MRMT relations needs to identify the common Media Encoder
origin for the Encoded and Dependent Streams. When using different
RTP Sessions, thus different Media Transports, and as long as there
is only one RTP Stream per Media Encoder and a single Media Source in
each RTP Session (MRMT), common SSRC and CNAMEs can be used to
identify the common Media Source. When multiple RTP Streams are sent
from one Media Encoder in the same RTP Session (MRST), then CNAME is
the only currently specified RTP identifier that can be used. In
cases where multiple Media Encoders use multiple Media Sources
sharing Synchronization Context, and thus having a common CNAME,
additional heuristics or identification need to be applied to create
the MRST or MRMT relationships between the RTP Streams.
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 9). It is a specific type of redundancy and 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 can
also be seen as a specific type of Simulcast (Section 3.7) that 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 27, line 47 skipping to change at page 28, line 35
| | | |
+-----------+-----------+ +-----------+-----------+
| |
V V
+-------------------+ +-------------------+
| Media Transport | | Media Transport |
+-------------------+ +-------------------+
Figure 9: Example of RTP Stream Duplication Figure 9: Example of RTP Stream Duplication
3.10. Redundancy Format 3.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 10.
+--------------------+ +--------------------+
| Media Source | | Media Source |
skipping to change at page 28, line 42 skipping to change at page 29, line 40
Figure 10: Concept for usage of Audio Redundancy with different Media Figure 10: 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, or in the case depicted above (Figure 10) relate the Received
Source Stream fragments coming out of different Media Decoders to be Source Stream fragments coming out of different Media Decoders to be
able to combine them together into a less erroneous Source Stream. able to combine them together into a less erroneous Source Stream.
3.11. RTP Retransmission 3.10. RTP Retransmission
Figure 11 shows an example where a Media Source's Source RTP Stream Figure 11 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 |
+--------------------+ +--------------------+
| |
skipping to change at page 30, line 5 skipping to change at page 31, line 5
Redundancy RTP Stream needs to be associated with its Source RTP Redundancy RTP Stream needs to be associated with its Source RTP
Stream. This is done based on CNAME selectors and heuristics to Stream. This is done based on CNAME selectors and heuristics to
match requested packets for a given Source RTP Stream with the match requested packets for a given Source RTP Stream with the
original sequence number in the payload of any new Redundancy RTP original sequence number in the payload of any new Redundancy RTP
Stream using the RTX payload format. In cases where the Redundancy Stream using the RTX payload format. In cases where the Redundancy
RTP Stream is sent in a separate RTP Session from the Source RTP RTP Stream is sent in a separate RTP Session from the Source RTP
Stream, these sessions are related, which is signaled by using the Stream, these sessions are related, which is signaled by using the
SDP Media Grouping's [RFC5888] Flow Identification (FID SDP Media Grouping's [RFC5888] Flow Identification (FID
identification-tag) semantics. identification-tag) semantics.
3.12. Forward Error Correction 3.11. Forward Error Correction
Figure 12 shows an example where two Media Sources' Source RTP Figure 12 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 12 all RTP Streams are sent on the same Media Transport.
This is however not the only possible choice. Numerous combinations This is however not the only possible choice. Numerous combinations
exist for spreading these RTP Streams over different Media Transports exist for spreading these RTP Streams over different Media Transports
to achieve the communication application's goal. to achieve the communication application's goal.
+--------------------+ +--------------------+ +--------------------+ +--------------------+
skipping to change at page 31, line 16 skipping to change at page 32, line 16
Redundancy RTP Streams with its source information in Source RTP Redundancy RTP Streams with its source information in Source RTP
Streams are many. The XOR based RTP FEC Payload format [RFC5109] is Streams are many. The XOR based RTP FEC Payload format [RFC5109] is
defined in such a way that a Redundancy RTP Stream has a one to one defined in such a way that a Redundancy RTP Stream has a one to one
relation with a Source RTP Stream. In fact, the RFC requires the relation with a Source RTP Stream. In fact, the RFC requires the
Redundancy RTP Stream to use the same SSRC as the Source RTP Stream. Redundancy RTP Stream to use the same SSRC as the Source RTP Stream.
This requires to either use a separate RTP Session or to use the This requires to either use a separate RTP Session or to use the
Redundancy RTP Payload format [RFC2198]. The underlying relation Redundancy RTP Payload format [RFC2198]. The underlying relation
requirement for this FEC format and a particular Redundancy RTP requirement for this FEC format and a particular Redundancy RTP
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.13. 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.
skipping to change at page 32, line 5 skipping to change at page 33, line 5
Streams across different RTP Sessions, as explained in the previous Streams across different RTP Sessions, as explained in the previous
section. Such a relationship can be used to perform inter-media section. Such a relationship can be used to perform inter-media
synchronization. synchronization.
RTP Streams that are related and need to be associated can be part of RTP Streams that are related and need to be associated can be part of
different Multimedia Sessions, rather than just different RTP different Multimedia Sessions, rather than just different RTP
Sessions within the same Multimedia Session context. This puts Sessions within the same Multimedia Session context. This puts
further demand on the scope of the mechanism(s) and its handling of further demand on the scope of the mechanism(s) and its handling of
identifiers used for expressing the relationships. identifiers used for expressing the relationships.
3.14. Multiple RTP Sessions over one Media Transport 3.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 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
skipping to change at page 34, line 47 skipping to change at page 35, line 47
4.6. Multipoint Control Unit (MCU) 4.6. Multipoint Control Unit (MCU)
This term is commonly used to describe the central node in any type This term is commonly used to describe the central node in any type
of star topology [I-D.ietf-avtcore-rtp-topologies-update] conference. of star topology [I-D.ietf-avtcore-rtp-topologies-update] conference.
It describes a device that includes one Participant (Section 2.2.3) It describes a device that includes one Participant (Section 2.2.3)
(usually corresponding to a so-called conference focus) and one or (usually corresponding to a so-called conference focus) and one or
more related Endpoints (Section 2.2.1) (sometimes one or more per more related Endpoints (Section 2.2.1) (sometimes one or more per
conference Participant). conference Participant).
4.7. Recording Device 4.7. Multi-Session Transmission (MST)
One of two transmission modes defined in H.264 based SVC [RFC6190],
the other mode being SST (Section 4.13). In Multi-Session
Transmission (MST), the SVC Media Encoder sends Encoded Streams and
Dependent Streams distributed across two or more RTP Streams in one
or more RTP Sessions. The term "MST" is ambiguous in RFC 6190,
especially since the name indicates the use of multiple "sessions",
while MST type packetization is in fact required whenever two or more
RTP Streams are used for the Encoded and Dependent Streams,
regardless if those are sent in one or more RTP Sessions.
Corresponds either to MRST or MRMT (Section 3.7) stream relations
defined in this specification. The SVC RTP Payload RFC [RFC6190] is
not particularly explicit about how the common Media Encoder
(Section 2.1.6) relation between Encoded Streams (Section 2.1.7) and
Dependent Streams (Section 2.1.8) is to be implemented.
4.8. Recording Device
WebRTC specifications use this term to refer to locally available WebRTC specifications use this term to refer to locally available
entities performing a Media Capture (Section 2.1.2) transformation. entities performing a Media Capture (Section 2.1.2) transformation.
4.8. RtcMediaStream 4.9. RtcMediaStream
A WebRTC RtcMediaStreamTrack is a set of Media Sources A WebRTC RtcMediaStream is a set of Media Sources (Section 2.1.4)
(Section 2.1.4) sharing the same Synchronization Context sharing the same Synchronization Context (Section 3.1).
(Section 3.1).
4.9. RtcMediaStreamTrack 4.10. RtcMediaStreamTrack
A WebRTC RtcMediaStreamTrack is a Media Source (Section 2.1.4). A WebRTC RtcMediaStreamTrack is a Media Source (Section 2.1.4).
4.10. RTP Sender 4.11. RTP Sender
RTP [RFC3550] uses this term, which can be seen as the RTP protocol RTP [RFC3550] uses this term, which can be seen as the RTP protocol
part of a Media Packetizer (Section 2.1.9). part of a Media Packetizer (Section 2.1.9).
4.11. RTP Session 4.12. RTP Session
Within the context of SDP, a singe m= line can map to a single RTP Within the context of SDP, a singe m= line can map to a single RTP
Session (Section 2.2.2) or multiple m= lines can map to a single RTP Session (Section 2.2.2) or multiple m= lines can map to a single RTP
Session. The latter is enabled via multiplexing schemes such as Session. The latter is enabled via multiplexing schemes such as
BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], for example, which BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], for example, which
allows mapping of multiple m= lines to a single RTP Session. allows mapping of multiple m= lines to a single RTP Session.
4.12. SSRC 4.13. Single Session Transmission (SST)
One of two transmission modes defined in H.264 based SVC [RFC6190],
the other mode being MST (Section 4.7). In Single Session
Transmission (SST), the SVC Media Encoder sends Encoded Streams
(Section 2.1.7) and Dependent Streams (Section 2.1.8) combined into a
single RTP Stream (Section 2.1.10) in a single RTP Session
(Section 2.2.2), using the SVC RTP Payload format. The term "SST" is
ambiguous in RFC 6190, in that it sometimes refers to the use of a
single RTP Stream, like in sections relating to packetization, and
sometimes appears to refer to use of a single RTP Session, like in
the context of discussing SDP. Closely corresponds to SRST
(Section 3.7) defined in this specification.
4.14. SSRC
RTP [RFC3550] defines this as "the source of a stream of RTP RTP [RFC3550] defines this as "the source of a stream of RTP
packets", which indicates that an SSRC is not only a unique packets", which indicates that an SSRC is not only a unique
identifier for the Encoded Stream (Section 2.1.7) carried in those identifier for the Encoded Stream (Section 2.1.7) carried in those
packets, but is also effectively used as a term to denote a Media packets, but is also effectively used as a term to denote a Media
Packetizer (Section 2.1.9). Packetizer (Section 2.1.9).
5. Security Considerations 5. Security Considerations
This document simply tries to clarify the confusion prevalent in RTP This document simply tries to clarify the confusion prevalent in RTP
skipping to change at page 36, line 9 skipping to change at page 37, line 34
specifications of the various protocols making use of it. specifications of the various protocols making use of it.
Hopefully having a well-defined common terminology and understanding Hopefully having a well-defined common terminology and understanding
of the complexities of the RTP architecture will help lead us to of the complexities of the RTP architecture will help lead us to
better standards, avoiding security problems. better standards, avoiding security problems.
6. Acknowledgement 6. Acknowledgement
This document has many concepts borrowed from several documents such This document has many concepts borrowed from several documents such
as WebRTC [I-D.ietf-rtcweb-overview], CLUE [I-D.ietf-clue-framework], as WebRTC [I-D.ietf-rtcweb-overview], CLUE [I-D.ietf-clue-framework],
Multiplexing Architecture and Multiplexing Architecture
[I-D.westerlund-avtcore-transport-multiplexing]. The authors would [I-D.westerlund-avtcore-transport-multiplexing]. The authors would
like to thank all the authors of each of those documents. like to thank all the authors of each of those documents.
The authors would also like to acknowledge the insights, guidance and The authors would also like to acknowledge the insights, guidance and
contributions of Magnus Westerlund, Roni Even, Paul Kyzivat, Colin contributions of Magnus Westerlund, Roni Even, Paul Kyzivat, Colin
Perkins, Keith Drage, Harald Alvestrand, Alex Eleftheriadis, Mo Perkins, Keith Drage, Harald Alvestrand, Alex Eleftheriadis, Mo
Zanaty, and Stephan Wenger. Zanaty, Stephan Wenger, and Bernard Aboba.
7. Contributors 7. Contributors
Magnus Westerlund has contributed the concept model for the media Magnus Westerlund has contributed the concept model for the media
chain using transformations and streams model, including rewriting chain using transformations and streams model, including rewriting
pre-existing concepts into this model and adding missing concepts. pre-existing concepts into this model and adding missing concepts.
The first proposal for updating the relationships and the topologies The first proposal for updating the relationships and the topologies
based on this concept was also performed by Magnus. based on this concept was also performed by Magnus.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 36, line 40 skipping to change at page 38, line 19
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-06 (work in progress),
October 2014. October 2014.
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-05 (work in progress), ietf-avtcore-rtp-topologies-update-06 (work in progress),
November 2014. March 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-20 (work in progress), January 2015. framework-21 (work in progress), March 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-15 (work in progress), January 2015. negotiation-17 (work in progress), March 2015.
[I-D.ietf-mmusic-sdp-simulcast]
Westerlund, M., Nandakumar, S., and M. Zanaty, "Using
Simulcast in SDP and RTP Sessions", draft-ietf-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-13
(work in progress), November 2014. (work in progress), November 2014.
[I-D.westerlund-avtcore-transport-multiplexing] [I-D.westerlund-avtcore-transport-multiplexing]
Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP
Sessions onto a Single Lower-Layer Transport", draft- Sessions onto a Single Lower-Layer Transport", draft-
westerlund-avtcore-transport-multiplexing-07 (work in westerlund-avtcore-transport-multiplexing-07 (work in
skipping to change at page 38, line 31 skipping to change at page 40, line 16
7198, April 2014. 7198, April 2014.
[RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. [RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H.
Stokking, "RTP Clock Source Signalling", RFC 7273, June Stokking, "RTP Clock Source Signalling", RFC 7273, June
2014. 2014.
Appendix A. Changes From Earlier Versions Appendix A. Changes From Earlier Versions
NOTE TO RFC EDITOR: Please remove this section prior to publication. NOTE TO RFC EDITOR: Please remove this section prior to publication.
A.1. Modifications Between WG Version -04 and -05 A.1. Modifications Between WG Version -05 and -06
o Editorial improvements o Clarified that a Redundancy RTP Stream can be used standalone to
generate Repaired RTP Streams.
A.2. Modifications Between WG Version -03 and -04 o Clarified that (in accordance with above) RTP-based Repair takes
zero or more Received RTP Streams and one or more Received
Redundancy RTP Streams as input.
o Changed Figure 6 to more clearly show that Media Transport is
terminated in the Endpoint, not in the Particpiant.
o Added a sentence to Endpoint section that clarifies there may be
contexts where a single "host" can serve multiple Participants,
making those Endpoints share some properties.
o Merged previous section 3.5 on SST/MST with previous section 3.8
on Layered Multi-Stream into a common section discussing the
scalable/layered stream relation, and moved improved, descriptive
text on SST and MST to new sub-sections 4.7 and 4.13, describing
them as existing terms.
o Editorial improvements.
A.2. Modifications Between WG Version -04 and -05
o Editorial improvements.
A.3. Modifications Between WG Version -03 and -04
o Changed "Media Redundancy" and "Media Repair" to "RTP-based o Changed "Media Redundancy" and "Media Repair" to "RTP-based
Redundancy" and "RTP-based Repair", since those terms are more Redundancy" and "RTP-based Repair", since those terms are more
specific and correct. specific and correct.
o Changed "End Point" to "Endpoint" and removed Editor's Note on o Changed "End Point" to "Endpoint" and removed Editor's Note on
this. this.
o Clarified that a Media Capture may impose constraints on clock o Clarified that a Media Capture may impose constraints on clock
handling. handling.
skipping to change at page 39, line 24 skipping to change at page 41, line 32
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.3. Modifications Between WG Version -02 and -03 A.4. 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.4. Modifications Between WG Version -01 and -02 A.5. 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
o Elaborated a bit in section 2.2.1 on the relation between End o Elaborated a bit in section 2.2.1 on the relation between End
Points, Participants and CNAMEs Points, Participants and CNAMEs
o Elaborated a bit in section 2.2.4 on Multimedia Session and o Elaborated a bit in section 2.2.4 on Multimedia Session and
synchronization contexts synchronization contexts
o Removed the section on CLUE scenes defining an implicit o Removed the section on CLUE scenes defining an implicit
synchronization context, since it was incorrect synchronization context, since it was incorrect
skipping to change at page 40, line 33 skipping to change at page 42, line 42
section per term, mainly by moving text from sections 2 and 3 section per term, mainly by moving text from sections 2 and 3
o Changed all occurrences of Packet Stream to RTP Stream o Changed all occurrences of Packet Stream to RTP Stream
o Moved all normative references to informative, since this is an o Moved all normative references to informative, since this is an
informative document informative document
o Added references to RFC 7160, RFC 7197 and RFC 7198, and removed o Added references to RFC 7160, RFC 7197 and RFC 7198, and removed
unused references unused references
A.5. Modifications Between WG Version -00 and -01 A.6. 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.6. Modifications Between Version -02 and -03 A.7. 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.7. Modifications Between Version -01 and -02 A.8. 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.8. Modifications Between Version -00 and -01 A.9. 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 42, line 18 skipping to change at page 44, line 26
US US
Email: gsalguei@cisco.com Email: gsalguei@cisco.com
Bo Burman Bo Burman
Ericsson Ericsson
Kistavagen 25 Kistavagen 25
SE-164 80 Stockholm SE-164 80 Stockholm
Sweden Sweden
Phone: +46 10 714 13 11
Email: bo.burman@ericsson.com Email: bo.burman@ericsson.com
 End of changes. 64 change blocks. 
236 lines changed or deleted 274 lines changed or added

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