--- 1/draft-ietf-avtext-rtp-grouping-taxonomy-05.txt 2015-03-05 05:14:40.604313994 -0800 +++ 2/draft-ietf-avtext-rtp-grouping-taxonomy-06.txt 2015-03-05 05:14:40.692316122 -0800 @@ -1,25 +1,25 @@ Network Working Group J. Lennox Internet-Draft Vidyo Intended status: Informational K. Gross -Expires: July 26, 2015 AVA +Expires: September 6, 2015 AVA S. Nandakumar G. Salgueiro Cisco Systems B. Burman Ericsson - January 22, 2015 + March 5, 2015 A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources - draft-ietf-avtext-rtp-grouping-taxonomy-05 + draft-ietf-avtext-rtp-grouping-taxonomy-06 Abstract The terminology about, and associations among, Real-Time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed relationships among RTP sources, and attempts to define common terminology for discussing protocol entities and their relationships. Status of This Memo @@ -30,137 +30,138 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Media Chain . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Media Chain . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Physical Stimulus . . . . . . . . . . . . . . . . . . 8 - 2.1.2. Media Capture . . . . . . . . . . . . . . . . . . . . 8 - 2.1.3. Raw Stream . . . . . . . . . . . . . . . . . . . . . 8 - 2.1.4. Media Source . . . . . . . . . . . . . . . . . . . . 8 - 2.1.5. Source Stream . . . . . . . . . . . . . . . . . . . . 9 + 2.1.2. Media Capture . . . . . . . . . . . . . . . . . . . . 9 + 2.1.3. Raw Stream . . . . . . . . . . . . . . . . . . . . . 9 + 2.1.4. Media Source . . . . . . . . . . . . . . . . . . . . 9 + 2.1.5. Source Stream . . . . . . . . . . . . . . . . . . . . 10 2.1.6. Media Encoder . . . . . . . . . . . . . . . . . . . . 10 - 2.1.7. Encoded Stream . . . . . . . . . . . . . . . . . . . 11 - 2.1.8. Dependent Stream . . . . . . . . . . . . . . . . . . 11 - 2.1.9. Media Packetizer . . . . . . . . . . . . . . . . . . 11 - 2.1.10. RTP Stream . . . . . . . . . . . . . . . . . . . . . 12 + 2.1.7. Encoded Stream . . . . . . . . . . . . . . . . . . . 12 + 2.1.8. Dependent Stream . . . . . . . . . . . . . . . . . . 12 + 2.1.9. Media Packetizer . . . . . . . . . . . . . . . . . . 12 + 2.1.10. RTP Stream . . . . . . . . . . . . . . . . . . . . . 13 2.1.11. RTP-based Redundancy . . . . . . . . . . . . . . . . 13 - 2.1.12. Redundancy RTP Stream . . . . . . . . . . . . . . . . 13 - 2.1.13. Media Transport . . . . . . . . . . . . . . . . . . . 13 - 2.1.14. Media Transport Sender . . . . . . . . . . . . . . . 14 + 2.1.12. Redundancy RTP Stream . . . . . . . . . . . . . . . . 14 + 2.1.13. Media Transport . . . . . . . . . . . . . . . . . . . 14 + 2.1.14. Media Transport Sender . . . . . . . . . . . . . . . 15 2.1.15. Sent RTP Stream . . . . . . . . . . . . . . . . . . . 15 - 2.1.16. Network Transport . . . . . . . . . . . . . . . . . . 15 - 2.1.17. Transported RTP Stream . . . . . . . . . . . . . . . 15 - 2.1.18. Media Transport Receiver . . . . . . . . . . . . . . 15 - 2.1.19. Received RTP Stream . . . . . . . . . . . . . . . . . 15 + 2.1.16. Network Transport . . . . . . . . . . . . . . . . . . 16 + 2.1.17. Transported RTP Stream . . . . . . . . . . . . . . . 16 + 2.1.18. Media Transport Receiver . . . . . . . . . . . . . . 16 + 2.1.19. Received RTP Stream . . . . . . . . . . . . . . . . . 16 2.1.20. Received Redundancy RTP Stream . . . . . . . . . . . 16 - 2.1.21. RTP-based Repair . . . . . . . . . . . . . . . . . . 16 - 2.1.22. Repaired RTP Stream . . . . . . . . . . . . . . . . . 16 - 2.1.23. Media Depacketizer . . . . . . . . . . . . . . . . . 16 - 2.1.24. Received Encoded Stream . . . . . . . . . . . . . . . 16 - 2.1.25. Media Decoder . . . . . . . . . . . . . . . . . . . . 16 - 2.1.26. Received Source Stream . . . . . . . . . . . . . . . 17 - 2.1.27. Media Sink . . . . . . . . . . . . . . . . . . . . . 17 - 2.1.28. Received Raw Stream . . . . . . . . . . . . . . . . . 17 - 2.1.29. Media Render . . . . . . . . . . . . . . . . . . . . 17 - 2.2. Communication Entities . . . . . . . . . . . . . . . . . 18 - 2.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 19 - 2.2.2. RTP Session . . . . . . . . . . . . . . . . . . . . . 19 - 2.2.3. Participant . . . . . . . . . . . . . . . . . . . . . 20 - 2.2.4. Multimedia Session . . . . . . . . . . . . . . . . . 20 - 2.2.5. Communication Session . . . . . . . . . . . . . . . . 21 + 2.1.21. RTP-based Repair . . . . . . . . . . . . . . . . . . 17 + 2.1.22. Repaired RTP Stream . . . . . . . . . . . . . . . . . 17 + 2.1.23. Media Depacketizer . . . . . . . . . . . . . . . . . 17 + 2.1.24. Received Encoded Stream . . . . . . . . . . . . . . . 17 + 2.1.25. Media Decoder . . . . . . . . . . . . . . . . . . . . 17 + 2.1.26. Received Source Stream . . . . . . . . . . . . . . . 18 + 2.1.27. Media Sink . . . . . . . . . . . . . . . . . . . . . 18 + 2.1.28. Received Raw Stream . . . . . . . . . . . . . . . . . 18 + 2.1.29. Media Render . . . . . . . . . . . . . . . . . . . . 18 + 2.2. Communication Entities . . . . . . . . . . . . . . . . . 19 + 2.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 20 + 2.2.2. RTP Session . . . . . . . . . . . . . . . . . . . . . 20 + 2.2.3. Participant . . . . . . . . . . . . . . . . . . . . . 21 + 2.2.4. Multimedia Session . . . . . . . . . . . . . . . . . 21 + 2.2.5. Communication Session . . . . . . . . . . . . . . . . 22 - 3. Concepts of Inter-Relations . . . . . . . . . . . . . . . . . 21 - 3.1. Synchronization Context . . . . . . . . . . . . . . . . . 21 - 3.1.1. RTCP CNAME . . . . . . . . . . . . . . . . . . . . . 22 - 3.1.2. Clock Source Signaling . . . . . . . . . . . . . . . 22 - 3.1.3. Implicitly via RtcMediaStream . . . . . . . . . . . . 22 - 3.1.4. Explicitly via SDP Mechanisms . . . . . . . . . . . . 22 - 3.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 22 - 3.3. Participant . . . . . . . . . . . . . . . . . . . . . . . 23 - 3.4. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 23 - 3.5. Single- and Multi-Session Transmission of Dependent - Streams . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 3.6. Multi-Channel Audio . . . . . . . . . . . . . . . . . . . 24 - 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 24 - 3.8. Layered Multi-Stream . . . . . . . . . . . . . . . . . . 25 - 3.9. RTP Stream Duplication . . . . . . . . . . . . . . . . . 27 - 3.10. Redundancy Format . . . . . . . . . . . . . . . . . . . . 27 - 3.11. RTP Retransmission . . . . . . . . . . . . . . . . . . . 28 - 3.12. Forward Error Correction . . . . . . . . . . . . . . . . 30 - 3.13. RTP Stream Separation . . . . . . . . . . . . . . . . . . 31 - 3.14. Multiple RTP Sessions over one Media Transport . . . . . 32 - 4. Mapping from Existing Terms . . . . . . . . . . . . . . . . . 32 - 4.1. Telepresence Terms . . . . . . . . . . . . . . . . . . . 32 - 4.1.1. Audio Capture . . . . . . . . . . . . . . . . . . . . 32 - 4.1.2. Capture Device . . . . . . . . . . . . . . . . . . . 32 - 4.1.3. Capture Encoding . . . . . . . . . . . . . . . . . . 32 - 4.1.4. Capture Scene . . . . . . . . . . . . . . . . . . . . 33 - 4.1.5. Endpoint . . . . . . . . . . . . . . . . . . . . . . 33 - 4.1.6. Individual Encoding . . . . . . . . . . . . . . . . . 33 - 4.1.7. Media Capture . . . . . . . . . . . . . . . . . . . . 33 - 4.1.8. Media Consumer . . . . . . . . . . . . . . . . . . . 33 - 4.1.9. Media Provider . . . . . . . . . . . . . . . . . . . 33 - 4.1.10. Stream . . . . . . . . . . . . . . . . . . . . . . . 33 - 4.1.11. Video Capture . . . . . . . . . . . . . . . . . . . . 33 - 4.2. Media Description . . . . . . . . . . . . . . . . . . . . 33 - 4.3. Media Stream . . . . . . . . . . . . . . . . . . . . . . 34 - 4.4. Multimedia Conference . . . . . . . . . . . . . . . . . . 34 - 4.5. Multimedia Session . . . . . . . . . . . . . . . . . . . 34 - 4.6. Multipoint Control Unit (MCU) . . . . . . . . . . . . . . 34 - 4.7. Recording Device . . . . . . . . . . . . . . . . . . . . 34 - 4.8. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 35 - 4.9. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . . 35 - 4.10. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . 35 - 4.11. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 35 - 4.12. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 35 - 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 36 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 - 9. Informative References . . . . . . . . . . . . . . . . . . . 36 - Appendix A. Changes From Earlier Versions . . . . . . . . . . . 38 - A.1. Modifications Between WG Version -04 and -05 . . . . . . 38 - A.2. Modifications Between WG Version -03 and -04 . . . . . . 38 - A.3. Modifications Between WG Version -02 and -03 . . . . . . 39 - A.4. Modifications Between WG Version -01 and -02 . . . . . . 39 - A.5. Modifications Between WG Version -00 and -01 . . . . . . 40 - A.6. Modifications Between Version -02 and -03 . . . . . . . . 40 - A.7. Modifications Between Version -01 and -02 . . . . . . . . 41 - A.8. Modifications Between Version -00 and -01 . . . . . . . . 41 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 + 3. Concepts of Inter-Relations . . . . . . . . . . . . . . . . . 22 + 3.1. Synchronization Context . . . . . . . . . . . . . . . . . 22 + 3.1.1. RTCP CNAME . . . . . . . . . . . . . . . . . . . . . 23 + 3.1.2. Clock Source Signaling . . . . . . . . . . . . . . . 23 + 3.1.3. Implicitly via RtcMediaStream . . . . . . . . . . . . 23 + 3.1.4. Explicitly via SDP Mechanisms . . . . . . . . . . . . 23 + 3.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 23 + 3.3. Participant . . . . . . . . . . . . . . . . . . . . . . . 24 + 3.4. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 24 + 3.5. Multi-Channel Audio . . . . . . . . . . . . . . . . . . . 24 + 3.6. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 25 + 3.7. Layered Multi-Stream . . . . . . . . . . . . . . . . . . 26 + 3.8. RTP Stream Duplication . . . . . . . . . . . . . . . . . 27 + 3.9. Redundancy Format . . . . . . . . . . . . . . . . . . . . 28 + 3.10. RTP Retransmission . . . . . . . . . . . . . . . . . . . 29 + 3.11. Forward Error Correction . . . . . . . . . . . . . . . . 31 + 3.12. RTP Stream Separation . . . . . . . . . . . . . . . . . . 32 + 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 The existing taxonomy of sources in RTP is often regarded as confusing and inconsistent. Consequently, a deep understanding of how the different terms relate to each other becomes a real challenge. Frequently cited examples of this confusion are (1) how different protocols that make use of RTP use the same terms to signify different things and (2) how the complexities addressed at one layer are often glossed over or ignored at another. @@ -443,21 +443,21 @@ an important factor in many communication systems. Scalable Media Encoders need special attention as they produce multiple outputs that are potentially of different types. As shown in Figure 4, a scalable Media Encoder takes one input Source Stream and encodes it into multiple output streams of two different types; at least one Encoded Stream that is independently decodable and one or more Dependent Streams (Section 2.1.8). Decoding requires at least one Encoded Stream and zero or more Dependent Streams. A 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 | V +--------------------------+ | Scalable Media Encoder | +--------------------------+ | | ... | V V V Encoded Dependent Dependent @@ -468,21 +468,22 @@ There are also other variants of encoders, like so-called Multiple Description Coding (MDC). Such Media Encoder produce multiple independent and thus individually decodable Encoded Streams. However, (logically) combining multiple of these Encoded Streams into a single Received Source Stream during decoding leads to an improvement in perceptual reproduced quality when compared to decoding a single Encoded Stream. Creating multiple Encoded Streams from the same Source Stream, where the Encoded Streams are neither in a scalable nor in an MDC - relationship is commonly utilized in Simulcast environments. + relationship is commonly utilized in Simulcast + [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 A stream of time synchronized encoded media that can be independently decoded. @@ -510,26 +511,26 @@ 2.1.9. Media Packetizer 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 more sequences of packets, normally RTP packets, and output Source RTP Streams (Section 2.1.10). This step includes both generating RTP payloads as well as RTP packets. The Media Packetizer can use multiple inputs when producing a single 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 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.5). + using SVC (Section 3.7). Characteristics: o The Media Packetizer will select which Synchronization source(s) (SSRC) [RFC3550] in which RTP Sessions that are used. o Media Packetizer can combine multiple Encoded or Dependent Streams into one or more RTP Streams. 2.1.10. RTP Stream @@ -574,34 +575,34 @@ 2.1.11. RTP-based Redundancy RTP-based Redundancy is defined here as a transformation that generates redundant or repair packets sent out as a Redundancy RTP Stream (Section 2.1.12) to mitigate network transport impairments, like packet loss and delay. The RTP-based Redundancy exists in many flavors; they may be 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 - 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 - 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 packets. 2.1.12. Redundancy RTP Stream 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 - RTP Stream (Section 2.1.19) to produce Repaired RTP Streams - (Section 2.1.22). + only redundant data, which may either be used standalone or be + combined with one or more Received RTP Streams (Section 2.1.19) to + produce Repaired RTP Streams (Section 2.1.22). 2.1.13. Media Transport A Media Transport defines the transformation that the RTP Streams (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 (Section 2.2.2) may contain multiple RTP receivers per sender). Each Media Transport is defined by a transport association that is normally identified by a 5-tuple (source address, source port, destination address, destination port, transport protocol), but a @@ -709,27 +710,27 @@ receiver. 2.1.20. Received Redundancy RTP Stream The Redundancy RTP Stream (Section 2.1.12) resulting from the Media Transport transformation, i.e. subjected to packet loss, packet corruption, and varying transmission delay from sender to receiver. 2.1.21. RTP-based Repair - RTP-based Repair is a Transformation that takes as input one or more - Received RTP Streams (Section 2.1.19) and Received Redundancy RTP - Streams (Section 2.1.20), and produces one or more Repaired RTP - Streams (Section 2.1.22) that are as close to the corresponding sent - Source RTP Streams (Section 2.1.10) as possible, using different RTP- - based repair methods, for example the ones referred in RTP-based - Redundancy (Section 2.1.11). + 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 + Redundancy RTP Streams (Section 2.1.20), and produces one or more + Repaired RTP Streams (Section 2.1.22) that are as close to the + corresponding sent Source RTP Streams (Section 2.1.10) as possible, + using different RTP-based repair methods, for example the ones + referred in RTP-based Redundancy (Section 2.1.11). 2.1.22. Repaired RTP Stream 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 recover the Source RTP Stream (Section 2.1.10) as it was before Media Transport (Section 2.1.13). 2.1.23. Media Depacketizer @@ -802,51 +803,51 @@ perceive. Examples of such devices are screens, and D/A converters connected to amplifiers and loudspeakers. Characteristics: o An Endpoint can potentially have multiple Media Renders for each media type. 2.2. Communication Entities - This section contains concept for entities involved in the + This section contains concepts for entities involved in the communication. +------------------------------------------------------------+ | Communication Session | | | | +----------------+ +----------------+ | | | Participant A | +------------+ | Participant B | | | | | | Multimedia | | | | - | | +-------------+|<==>| Session |<==>|+-------------+ | | + | | +------------+ |<==>| Session |<==>| +------------+ | | | | | Endpoint A || | | || Endpoint B | | | | | | || +------------+ || | | | - | | | +-----------++----------------------++-----------+ | | | - | | | | | | | | | | - | | | | RTP Session|---Media Transport--->| | | | | - | | | | Audio |<---Media Transport---| | | | | - | | | | | ^ | | | | | - | | | +-----------++----------|-----------++-----------+ | | | + | | | +----------+-+----------------------+-+----------+ | | | + | | | | RTP | | | | | | | | + | | | | Session |-+---Media Transport----+>| | | | | + | | | | Audio |<+---Media Transport----+-| | | | | + | | | | | | ^ | | | | | | + | | | +----------+-+----------|-----------+-+----------+ | | | | | | || v || | | | | | | || +-----------------+ || | | | | | | || | Synchronization | || | | | | | | || | Context | || | | | | | | || +-----------------+ || | | | | | | || ^ || | | | - | | | +-----------++----------|-----------++-----------+ | | | - | | | | | v | | | | | - | | | | RTP Session|<---Media Transport---| | | | | - | | | | Video |---Media Transport--->| | | | | - | | | | | | | | | | - | | | +-----------++----------------------++-----------+ | | | - | | +-------------+| |+-------------+ | | + | | | +----------+-+----------|-----------+-+----------+ | | | + | | | | RTP | | v | | | | | | + | | | | Session |<+---Media Transport----+-| | | | | + | | | | Video |-+---Media Transport----+>| | | | | + | | | | | | | | | | | | + | | | +----------+-+----------------------+-+----------+ | | | + | | +------------+ | | +------------+ | | | +----------------+ +----------------+ | +------------------------------------------------------------+ Figure 6: Example Point to Point Communication Session with two RTP Sessions Figure 6 shows a high-level example representation of a very basic point-to-point Communication Session between Participants A and B. It uses two different audio and video RTP Sessions between A's and B's Endpoints, using separate Media Transports for those RTP @@ -873,21 +874,24 @@ shared among a set of Endpoints belonging to the same Participant (Section 2.2.3). Therefore, mechanisms outside the scope of RTP, such as application defined mechanisms, must be used to ensure Endpoint identification when outside this Synchronization Context. o An Endpoint can be associated with at most one Participant (Section 2.2.3) at any single point in time. o In some contexts, an Endpoint would typically correspond to a 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 An RTP Session is an association among a group of Participants communicating with RTP. It is a group communications channel which can potentially carry a number of RTP Streams. Within an RTP Session, every Participant can find meta-data and control information (over RTCP) about all the RTP Streams in the RTP Session. The bandwidth of the RTCP control channel is shared between all Participants within an RTP Session. @@ -979,21 +983,21 @@ the Communication Session consists of a set of Multimedia Sessions between each Participant and the conference handler. 3. Concepts of Inter-Relations This section uses the concepts from previous sections, and looks at different types of relationships among them. These relationships occur at different abstraction levels and for different purposes, but 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 - 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 Encoders use the same Media Source, i.e. to be able to identify a common Media Source. 3.1. Synchronization Context A Synchronization Context defines a requirement on a strong timing relationship between the Media Sources, typically requiring alignment of clock sources. Such a relationship can be identified in multiple ways as listed below. A single Media Source can only belong to a @@ -1072,78 +1076,43 @@ varying set of origins and Participants. RTP contains the concept of CSRC that carry information about the previous step origin of the included media content on RTP level. 3.4. RtcMediaStream An RtcMediaStream in WebRTC is an explicit grouping of a set of Media Sources (RtcMediaStreamTracks) that share a common identifier and a single Synchronization Context (Section 3.1). -3.5. Single- and Multi-Session Transmission of Dependent Streams - - 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 +3.5. Multi-Channel Audio There exist a number of RTP payload formats that can carry multi- channel audio, despite the codec being a mono encoder. Multi-channel audio can be viewed as multiple Media Sources sharing a common Synchronization Context. These are independently encoded by a Media Encoder and the different Encoded Streams are packetized together in a time synchronized way into a single Source RTP Stream, using the used codec's RTP Payload format. Examples of codecs that support multi-channel audio are PCMA and PCMU [RFC3551], AMR [RFC4867], and G.719 [RFC5404]. -3.7. Simulcast +3.6. Simulcast A Media Source represented as multiple independent Encoded Streams - constitutes a Simulcast or MDC of that Media Source. Figure 7 shows - an example of a Media Source that is encoded into three separate - Simulcast streams, that are in turn sent on the same Media Transport - flow. When using Simulcast, the RTP Streams may be sharing RTP - Session and Media Transport, or be separated on different RTP - Sessions and Media Transports, or any combination of these two. It - is other considerations that affect which usage is desirable, as - discussed in Section 3.13. + 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 + is encoded into three separate Simulcast streams, that are in turn + sent on the same Media Transport flow. When using Simulcast, the RTP + Streams may be sharing RTP Session and Media Transport, or be + separated on different RTP Sessions and Media Transports, or any + combination of these two. It is other considerations that affect + which usage is desirable, as discussed in Section 3.12. +----------------+ | Media Source | +----------------+ Source Stream | +----------------------+----------------------+ | | | V V V +------------------+ +------------------+ +------------------+ | Media Encoder | | Media Encoder | | Media Encoder | @@ -1166,33 +1135,33 @@ Figure 7: Example of Media Source Simulcast The Simulcast relation between the RTP Streams is the common Media 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 encoding goals that lay behind the produced Encoded Stream and its properties. This to enable selection of the stream that is most 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 - of a layered encoding of a Source Stream are sent using separate RTP - Streams (sometimes in separate RTP Sessions). LMSs are useful for - receiver control of layered media. + of a layered or scalable encoding of a Source Stream are sent using + separate RTP Streams (sometimes in separate RTP Sessions). LMSs are + useful for receiver control of layered media. A Media Source represented as an Encoded Stream and multiple Dependent Streams constitutes a Media Source that has layered dependencies. Figure 8 represents an example of a Media Source that 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 third layer is sent on a separate Media Transport. + the same Media Transport using different RTP Streams, i.e. SSRCs, and + the third layer is sent on a separate Media Transport. +----------------+ | Media Source | +----------------+ | | V +---------------------------------------------------------+ | Media Encoder | +---------------------------------------------------------+ @@ -1208,46 +1177,55 @@ | | | +------+ +------+ | | | | V V V +-----------------+ +-----------------+ | Media Transport | | Media Transport | +-----------------+ +-----------------+ Figure 8: Example of Media Source Layered Dependency - As an example, the SVC MRST and MRMT (Section 3.5) relations needs to - identify the common Media Encoder origin for the Encoded and - Dependent Streams. The SVC RTP Payload RFC [RFC6190] is not - particularly explicit about how this relation is to be implemented. - When using different RTP Sessions, thus different Media Transports - (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. + 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, the following new + terminology is defined here: -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 Transports, and optionally also delaying the duplicate [RFC7197], 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 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 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. +----------------+ | Media Source | +----------------+ Source Stream | V +----------------+ | Media Encoder | +----------------+ @@ -1266,21 +1244,21 @@ | | +-----------+-----------+ | V +-------------------+ | Media Transport | +-------------------+ 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 transport for redundant audio data together with primary data in the same RTP payload. The redundant data can be a time delayed version of the primary or another time delayed Encoded Stream using a different Media Encoder to encode the same Media Source as the primary, as depicted in Figure 10. +--------------------+ | Media Source | @@ -1310,21 +1288,21 @@ Figure 10: Concept for usage of Audio Redundancy with different Media Encoders The Redundancy format is thus providing the necessary meta information to correctly relate different parts of the same Encoded Stream, or in the case depicted above (Figure 10) relate the Received Source Stream fragments coming out of different Media Decoders to be 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 is protected by a retransmission (RTX) flow [RFC4588]. In this example the Source RTP Stream and the Redundancy RTP Stream share the same Media Transport. +--------------------+ | Media Source | +--------------------+ | @@ -1361,21 +1339,21 @@ Redundancy RTP Stream needs to be associated with its Source RTP Stream. This is done based on CNAME selectors and heuristics to match requested packets for a given Source RTP Stream with the original sequence number in the payload of any new Redundancy RTP Stream using the RTX payload format. In cases where the Redundancy RTP Stream is sent in a separate RTP Session from the Source RTP Stream, these sessions are related, which is signaled by using the SDP Media Grouping's [RFC5888] Flow Identification (FID identification-tag) semantics. -3.12. Forward Error Correction +3.11. Forward Error Correction Figure 12 shows an example where two Media Sources' Source RTP Streams are protected by Forward Error Correction (FEC). Source RTP Stream A has a RTP-based Redundancy transformation in FEC Encoder 1. This produces a Redundancy RTP Stream 1, that is only related to 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 protects them jointly, i.e. Redundancy RTP Stream 2 relates to two Source RTP Streams (a FEC group). FEC decoding, when needed due to packet loss or packet corruption at the receiver, requires knowledge @@ -1421,21 +1399,21 @@ Redundancy RTP Streams with its source information in Source RTP 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 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. This requires to either use a separate RTP Session or to use the Redundancy RTP Payload format [RFC2198]. The underlying relation requirement for this FEC format and a particular Redundancy RTP 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 Session level, or at the Multi-Media Session level. When the RTP Streams that have a relationship are all sent in the same RTP Session and are uniquely identified based on their SSRC 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 same Endpoint. SSRC-based approaches [RFC5576], when used, can explicitly relate various such RTP Streams. @@ -1458,21 +1436,21 @@ Streams across different RTP Sessions, as explained in the previous section. Such a relationship can be used to perform inter-media synchronization. RTP Streams that are related and need to be associated can be part of different Multimedia Sessions, rather than just different RTP Sessions within the same Multimedia Session context. This puts further demand on the scope of the mechanism(s) and its handling of 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 that allows several RTP Sessions to be carried over a single underlying Media Transport. The main reasons for doing this are related to the impact of using one or more Media Transports (using a common network path or potentially have different ones). The fewer Media Transports used, the less need for NAT/FW traversal resources and number of flow based Quality of Service (QoS). However, Multiple RTP Sessions over one Media Transport imply that a @@ -1595,49 +1573,79 @@ 4.6. Multipoint Control Unit (MCU) This term is commonly used to describe the central node in any type of star topology [I-D.ietf-avtcore-rtp-topologies-update] conference. It describes a device that includes one Participant (Section 2.2.3) (usually corresponding to a so-called conference focus) and one or more related Endpoints (Section 2.2.1) (sometimes one or more per 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 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 - (Section 2.1.4) sharing the same Synchronization Context - (Section 3.1). + A WebRTC RtcMediaStream is a set of Media Sources (Section 2.1.4) + sharing the same Synchronization Context (Section 3.1). -4.9. RtcMediaStreamTrack +4.10. RtcMediaStreamTrack 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 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 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 BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], for example, which 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 packets", which indicates that an SSRC is not only a unique 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 Packetizer (Section 2.1.9). 5. Security Considerations This document simply tries to clarify the confusion prevalent in RTP @@ -1648,28 +1656,28 @@ specifications of the various protocols making use of it. Hopefully having a well-defined common terminology and understanding of the complexities of the RTP architecture will help lead us to better standards, avoiding security problems. 6. Acknowledgement This document has many concepts borrowed from several documents such 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 like to thank all the authors of each of those documents. The authors would also like to acknowledge the insights, guidance and contributions of Magnus Westerlund, Roni Even, Paul Kyzivat, Colin Perkins, Keith Drage, Harald Alvestrand, Alex Eleftheriadis, Mo - Zanaty, and Stephan Wenger. + Zanaty, Stephan Wenger, and Bernard Aboba. 7. Contributors Magnus Westerlund has contributed the concept model for the media chain using transformations and streams model, including rewriting pre-existing concepts into this model and adding missing concepts. The first proposal for updating the relationships and the topologies based on this concept was also performed by Magnus. 8. IANA Considerations @@ -1679,33 +1687,38 @@ 9. Informative References [I-D.ietf-avtcore-rtp-multi-stream] Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session", draft-ietf-avtcore-rtp-multi-stream-06 (work in progress), October 2014. [I-D.ietf-avtcore-rtp-topologies-update] Westerlund, M. and S. Wenger, "RTP Topologies", draft- - ietf-avtcore-rtp-topologies-update-05 (work in progress), - November 2014. + ietf-avtcore-rtp-topologies-update-06 (work in progress), + March 2015. [I-D.ietf-clue-framework] Duckworth, M., Pepperell, A., and S. Wenger, "Framework 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] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session 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] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-13 (work in progress), November 2014. [I-D.westerlund-avtcore-transport-multiplexing] Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP Sessions onto a Single Lower-Layer Transport", draft- westerlund-avtcore-transport-multiplexing-07 (work in @@ -1768,25 +1781,49 @@ 7198, April 2014. [RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. Stokking, "RTP Clock Source Signalling", RFC 7273, June 2014. Appendix A. Changes From Earlier Versions 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 Redundancy" and "RTP-based Repair", since those terms are more specific and correct. o Changed "End Point" to "Endpoint" and removed Editor's Note on this. o Clarified that a Media Capture may impose constraints on clock handling. @@ -1808,49 +1845,49 @@ received by a Media Transport Receiver may still be corrupt. o Clarified that a corrupt packet in a Media Transport Receiver is typically either discarded or somehow marked and passed on in the Received RTP Stream. o Added Synchronization Context to Figure 6. 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 them with SRST, MRST, and MRMT. o Updated section 3.8 to align with terminology changes in section 3.5. o Added a new section 4.12, describing the term Multimedia Conference. o Changed reference from I-D to now published RFC 7273. o Editorial improvements and clarifications. -A.4. Modifications Between WG Version -01 and -02 +A.5. Modifications Between WG Version -01 and -02 o Major re-structure 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 sub-sections up one level, gathering some introductory text into the beginning of section 3 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 o Added a sub-section on clock source signaling + o Added a sub-section on RTP stream duplication o Elaborated a bit in section 2.2.1 on the relation between End Points, Participants and CNAMEs o Elaborated a bit in section 2.2.4 on Multimedia Session and synchronization contexts o Removed the section on CLUE scenes defining an implicit synchronization context, since it was incorrect @@ -1866,49 +1903,50 @@ section per term, mainly by moving text from sections 2 and 3 o Changed all occurrences of Packet Stream to RTP Stream o Moved all normative references to informative, since this is an informative document o Added references to RFC 7160, RFC 7197 and RFC 7198, and removed 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 Amended description of SVC SST and MST encodings with respect to concepts defined in this text o Removed UML as normative reference, since the text no longer uses any UML notation o Removed a number of level 4 sections and moved out text to the 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 reflect the major updates to Sections 1-3 o Section 8 removed (carryover from initial -00 draft) + 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 media chain. 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 Added new authors o Updated content organization and presentation Authors' Addresses Jonathan Lennox @@ -1941,12 +1979,11 @@ US Email: gsalguei@cisco.com Bo Burman Ericsson Kistavagen 25 SE-164 80 Stockholm Sweden - Phone: +46 10 714 13 11 Email: bo.burman@ericsson.com