draft-ietf-avtcore-rtp-topologies-update-03.txt   draft-ietf-avtcore-rtp-topologies-update-04.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: 5117 (if approved) S. Wenger Obsoletes: 5117 (if approved) S. Wenger
Intended status: Informational Vidyo Intended status: Informational Vidyo
Expires: February 8, 2015 August 7, 2014 Expires: February 19, 2015 August 18, 2014
RTP Topologies RTP Topologies
draft-ietf-avtcore-rtp-topologies-update-03 draft-ietf-avtcore-rtp-topologies-update-04
Abstract Abstract
This document discusses point to point and multi-endpoint topologies This document discusses point to point and multi-endpoint topologies
used in Real-time Transport Protocol (RTP)-based environments. In used in Real-time Transport Protocol (RTP)-based environments. In
particular, centralized topologies commonly employed in the video particular, centralized topologies commonly employed in the video
conferencing industry are mapped to the RTP terminology. conferencing industry are mapped to the RTP terminology.
This document is updated with additional topologies and is intended This document is updated with additional topologies and is intended
to replace RFC 5117. to replace RFC 5117.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 February 8, 2015. This Internet-Draft will expire on February 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3.5. Point to Multipoint Using the RFC 3550 Translator . . . . 19 3.5. Point to Multipoint Using the RFC 3550 Translator . . . . 19
3.5.1. Relay - Transport Translator . . . . . . . . . . . . 19 3.5.1. Relay - Transport Translator . . . . . . . . . . . . 19
3.5.2. Media Translator . . . . . . . . . . . . . . . . . . 20 3.5.2. Media Translator . . . . . . . . . . . . . . . . . . 20
3.6. Point to Multipoint Using the RFC 3550 Mixer Model . . . 21 3.6. Point to Multipoint Using the RFC 3550 Mixer Model . . . 21
3.6.1. Media Mixing Mixer . . . . . . . . . . . . . . . . . 23 3.6.1. Media Mixing Mixer . . . . . . . . . . . . . . . . . 23
3.6.2. Media Switching . . . . . . . . . . . . . . . . . . . 26 3.6.2. Media Switching . . . . . . . . . . . . . . . . . . . 26
3.7. Selective Forwarding Middlebox . . . . . . . . . . . . . 28 3.7. Selective Forwarding Middlebox . . . . . . . . . . . . . 28
3.8. Point to Multipoint Using Video Switching MCUs . . . . . 31 3.8. Point to Multipoint Using Video Switching MCUs . . . . . 31
3.9. Point to Multipoint Using RTCP-Terminating MCU . . . . . 33 3.9. Point to Multipoint Using RTCP-Terminating MCU . . . . . 33
3.10. Split Component Terminal . . . . . . . . . . . . . . . . 34 3.10. Split Component Terminal . . . . . . . . . . . . . . . . 34
3.11. Non-Symmetric Mixer/Translators . . . . . . . . . . . . . 36 3.11. Non-Symmetric Mixer/Translators . . . . . . . . . . . . . 37
3.12. Combining Topologies . . . . . . . . . . . . . . . . . . 36 3.12. Combining Topologies . . . . . . . . . . . . . . . . . . 37
4. Comparing Topologies . . . . . . . . . . . . . . . . . . . . 37 4. Comparing Topologies . . . . . . . . . . . . . . . . . . . . 38
4.1. Topology Properties . . . . . . . . . . . . . . . . . . . 37 4.1. Topology Properties . . . . . . . . . . . . . . . . . . . 38
4.1.1. All to All Media Transmission . . . . . . . . . . . . 37 4.1.1. All to All Media Transmission . . . . . . . . . . . . 38
4.1.2. Transport or Media Interoperability . . . . . . . . . 38 4.1.2. Transport or Media Interoperability . . . . . . . . . 39
4.1.3. Per Domain Bit-Rate Adaptation . . . . . . . . . . . 38 4.1.3. Per Domain Bit-Rate Adaptation . . . . . . . . . . . 39
4.1.4. Aggregation of Media . . . . . . . . . . . . . . . . 39 4.1.4. Aggregation of Media . . . . . . . . . . . . . . . . 40
4.1.5. View of All Session Participants . . . . . . . . . . 39 4.1.5. View of All Session Participants . . . . . . . . . . 40
4.1.6. Loop Detection . . . . . . . . . . . . . . . . . . . 39 4.1.6. Loop Detection . . . . . . . . . . . . . . . . . . . 41
4.2. Comparison of Topologies . . . . . . . . . . . . . . . . 40 4.2. Comparison of Topologies . . . . . . . . . . . . . . . . 41
5. Security Considerations . . . . . . . . . . . . . . . . . . . 40 5. Security Considerations . . . . . . . . . . . . . . . . . . . 41
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.1. Normative References . . . . . . . . . . . . . . . . . . 43 8.1. Normative References . . . . . . . . . . . . . . . . . . 44
8.2. Informative References . . . . . . . . . . . . . . . . . 43 8.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
Real-time Transport Protocol (RTP) [RFC3550] topologies describe Real-time Transport Protocol (RTP) [RFC3550] topologies describe
methods for interconnecting RTP entities and their processing methods for interconnecting RTP entities and their processing
behavior of RTP and RTCP. This document tries to address past and behavior of RTP and RTCP. This document tries to address past and
existing confusion, especially with respect to terms not defined in existing confusion, especially with respect to terms not defined in
RTP but in common use in the conversational communication industry, RTP but in common use in the conversational communication industry,
such as the Multipoint Control Unit or MCU. such as the Multipoint Control Unit or MCU.
skipping to change at page 34, line 46 skipping to change at page 34, line 46
Shortcut name: Topo-Split-Terminal Shortcut name: Topo-Split-Terminal
In some applications, for example in some telepresence systems, In some applications, for example in some telepresence systems,
terminals may be not integrated into a single functional unit, but terminals may be not integrated into a single functional unit, but
composed of more than one subunits. For example, a telepresence room composed of more than one subunits. For example, a telepresence room
terminal employing multiple cameras and monitors may consist of terminal employing multiple cameras and monitors may consist of
multiple video conferencing subunits, each capable of handling a multiple video conferencing subunits, each capable of handling a
single camera and monitor. Another example would be a video single camera and monitor. Another example would be a video
conferencing terminal in which audio is handled by one subunit, and conferencing terminal in which audio is handled by one subunit, and
video by another. Each of these subunits uses its own network video by another. Each of these subunits uses its own physical
address. The various (media processing) subunits need (logically and network interface (for example: Ethernet jack) and network address.
The various (media processing) subunits need (logically and
physically) to be interconnected by control functionality, but their physically) to be interconnected by control functionality, but their
media plane functionality may be split. This type of terminals is media plane functionality may be split. This type of terminals is
referred to as split component terminals. referred to as split component terminals. Historically, the earliest
split component terminals were perhaps the (independent) audio and
video conference software tools used over the MBONE in the late
1990s.
An example for such a split component terminal is depicted in An example for such a split component terminal is depicted in
Figure 20. Within split component terminal A, at least audio and Figure 20. Within split component terminal A, at least audio and
video subunits are addressed by their own network addresses. In some video subunits are addressed by their own network addresses. In some
of these systems, the control stack subunit may also have its own of these systems, the control stack subunit may also have its own
network address. network address.
From an RTP viewpoint, each of the subunits terminate RTP, and act as From an RTP viewpoint, each of the subunits terminates RTP, and acts
an End Point in the sense that each subunit includes its own, as an End Point in the sense that each subunit includes its own,
independent RTP stack. However, as the subunits are semantically independent RTP stack. However, as the subunits are semantically
part of the same terminal, it is appropriate that this semantic part of the same terminal, it is appropriate that this semantic
relationship is expressed in RTCP protocol elements, namely in the relationship is expressed in RTCP protocol elements, namely in the
CNAME. CNAME.
+---------------------+ +---------------------+
| Endpoint A | | Endpoint A |
| Local Area Network | | Local Area Network |
| +------------+ | | +------------+ |
| +->| Audio |<+-RTP---\ | +->| Audio |<+-RTP---\
skipping to change at page 35, line 34 skipping to change at page 35, line 38
| | +------------+ | +-->| | | | +------------+ | +-->| |
| +->| Video |<+-RTP-------->| B | | +->| Video |<+-RTP-------->| B |
| | +------------+ | +-->| | | | +------------+ | +-->| |
| | +------------+ | / +------+ | | +------------+ | / +------+
| +->| Control |<+-SIP---/ | +->| Control |<+-SIP---/
| +------------+ | | +------------+ |
+---------------------+ +---------------------+
Figure 20: Split Component Terminal Figure 20: Split Component Terminal
In a compliant RTP implementation, it is not feasible for more than It is further sensible that the subunits share a common clock from
one subunit to be part of a given RTP session. When attempting to do which RTP and RTCP clocks are derived, to facilitate synchronization
so, a third party monitor would report the two subunits as two and avoid clock drift.
separate End Points with a CNAME collision. As a result, a fully RTP
conformant split component terminal is one where the subunits use
separate RTP sessions to send and/or receive RTP streams intended for
them.
In addition to the use of a common CNAME and the use of independent To indicate that audio and video Source Streams generated by
RTP sessions for the RTP streams generated or consumed by the various different sub-units share a common clock, and can be synchronized,
subunits, it is sensible that the subunits share a common clock, to the RTP streams generated from those Source Streams need to include
ensure that synchronization and clock drift handling works, despite the same CNAME in their RTCP SDES packets. The use of a common CNAME
the fact that the components are separated. RTCP handling works for RTP flows carried in different transport-layer flows is entirely
correctly as long as each subunit participates in its own RTP normal for RTP and RTCP senders, and fully compliant RTP End Points,
session. middle-boxes, and other tools should have no problem with this.
However, outside of the split component terminal scenario (and
perhaps a multi-homed End Point scenario, which is not further
discussed herein), the use of a common CNAME in RTP streams sent from
separate endpoints (as opposed to a common CNAME for RTP streams sent
on different transport layer flows between two endpoints) is rare.
It has been reported that at least some third party tools like some
network monitors do not handle endpoints that use of a common CNAME
across multiple transport layer flows gracefully: they report an
error condition that two separate End Points are using the same
CNAME. Depending on the sophistication of the support staff, such
erroneous reports can lead to support issues.
Aforementioned support issue can sometimes be avoided if each of the
subunits of a split component terminal is configured to use a
different CNAME, with the synchronization between the RTP streams
being indicated by some non-RTP signaling channel rather than using a
common CNAME sent in RTCP. This complicates the signaling,
especially in cases where there are multiple SSRCs in use with
complex synchronization requirements, as is the same in many current
telepresence systems. Unless one uses RTCP terminating topologies
such as Topo-RTCP-terminating-MCU, sessions involving more than one
video subunit with a common CNAME are close to unavoidable.
The different RTP streams comprising a split terminal system can form
a single RTP session or they can form multiple RTP sessions,
depending on the visibility of their SSRC values in RTCP reports. If
the receiver of the RTP streams sent by the split terminal sends
reports relating to all of the RTP flows (i.e., to each SSRC) in each
RTCP report then a single RTP session is formed. Alternatively, if
the receiver of the RTP streams sent by the split terminal does not
send cross-reports in RTCP, then the audio and video form separate
RTP sessions.
For example, in the Figure 20, B will send RTCP reports to each of
the sub-units of A. If the RTCP packets that B sends to the audio
sub-unit of A include reports on the reception quality of the video
as well as the audio, and similarly if the RTCP packets that B sends
to the video sub-unit of A include reports on the reception quality
of the audio as well as video, then a single RTP session is formed.
However, if the RTCP packets B sends to the audio sub-unit of A only
report on the received audio, and the RTCP packet B sends to the
video sub-unit of A only report on the received video, then there are
two separate RTP sessions.
Forming a single RTP session across the RTP streams sent by the
different sub-units of a split terminal gives each sub-unit
visibility into reception quality of RTP streams sent by the other
sub-units. This information can help diagnose reception quality
problems, but at the cost of increased RTCP bandwidth use.
RTP streams sent by the sub-units of a split terminal need to use the
same CNAME in their RTCP packets if they are to be synchronized,
irrespective of whether a single RTP session is formed or not.
3.11. Non-Symmetric Mixer/Translators 3.11. Non-Symmetric Mixer/Translators
Shortcut name: Topo-Asymmetric Shortcut name: Topo-Asymmetric
It is theoretically possible to construct an MCU that is a Mixer in It is theoretically possible to construct an MCU that is a Mixer in
one direction and a Translator in another. The main reason to one direction and a Translator in another. The main reason to
consider this would be to allow topologies similar to Figure 13, consider this would be to allow topologies similar to Figure 13,
where the Mixer does not need to mix in the direction from B or D where the Mixer does not need to mix in the direction from B or D
towards the multicast domains with A and C. Instead, the RTP streams towards the multicast domains with A and C. Instead, the RTP streams
skipping to change at page 43, line 7 skipping to change at page 44, line 10
6. IANA Considerations 6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Bo Burman, Umesh Chandra, Roni Even, The authors would like to thank Mark Baugher, Bo Burman, Umesh
Keith Lantz, Ladan Gharai, Geoff Hunt, Mark Baugher, and Alex Chandra, Alex Eleftheriadis, Roni Even, Ladan Gharai, Geoff Hunt,
Eleftheriadis for their help in reviewing this document. Keith Lantz, and Colin Perkins for their help in reviewing and
improving this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
 End of changes. 10 change blocks. 
43 lines changed or deleted 99 lines changed or added

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