draft-ietf-avtcore-rtp-topologies-update-07.txt   draft-ietf-avtcore-rtp-topologies-update-08.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: October 12, 2015 April 10, 2015 Expires: December 19, 2015 June 17, 2015
RTP Topologies RTP Topologies
draft-ietf-avtcore-rtp-topologies-update-07 draft-ietf-avtcore-rtp-topologies-update-08
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 replaces RFC This document is updated with additional topologies and replaces RFC
5117. 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 October 12, 2015. This Internet-Draft will expire on December 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 9 skipping to change at page 3, line 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Normative References . . . . . . . . . . . . . . . . . . 44 9.1. Normative References . . . . . . . . . . . . . . . . . . 44
9.2. Informative References . . . . . . . . . . . . . . . . . 45 9.2. Informative References . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
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 for 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 communication industry, such as the
such as the Multipoint Control Unit or MCU. Multipoint Control Unit or MCU.
When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was
developed the main emphasis lay in the efficient support of point to developed the main emphasis lay in the efficient support of point to
point and small multipoint scenarios without centralized multipoint point and small multipoint scenarios without centralized multipoint
control. In practice, however, most multipoint conferences operate control. In practice, however, most multipoint conferences operate
utilizing centralized units referred to as MCUs. MCUs may implement utilizing centralized units referred to as MCUs. MCUs may implement
Mixer or Translator functionality (in RTP [RFC3550] terminology), and Mixer or Translator functionality (in RTP [RFC3550] terminology), and
signalling support. They may also contain additional application signalling support. They may also contain additional application
layer functionality. This document focuses on the media transport layer functionality. This document focuses on the media transport
aspects of the MCU that can be realized using RTP, as discussed aspects of the MCU that can be realized using RTP, as discussed
skipping to change at page 7, line 24 skipping to change at page 7, line 24
implementers. implementers.
In general, a Translator implementation should consider which RTCP In general, a Translator implementation should consider which RTCP
feedback messages or codec-control messages it needs to understand in feedback messages or codec-control messages it needs to understand in
relation to the functionality of the Translator itself. This is relation to the functionality of the Translator itself. This is
completely in line with the requirement to also translate RTCP completely in line with the requirement to also translate RTCP
messages between the domains. messages between the domains.
3.2.1.1. Transport Relay/Anchoring 3.2.1.1. Transport Relay/Anchoring
Shortcut name: Topo-PtP-Relay
There exist a number of different types of middleboxes that might be There exist a number of different types of middleboxes that might be
inserted between two endpoints on the transport level, e.g., to inserted between two endpoints on the transport level, e.g., to
perform changes on the IP/UDP headers, and are, therefore, basic perform changes on the IP/UDP headers, and are, therefore, basic
transport translators. These middleboxes come in many variations transport translators. These middleboxes come in many variations
including NAT [RFC3022] traversal by pinning the media path to a including NAT [RFC3022] traversal by pinning the media path to a
public address domain relay, network topologies where the RTP stream public address domain relay, network topologies where the RTP stream
is required to pass a particular point for audit by employing is required to pass a particular point for audit by employing
relaying, or preserving privacy by hiding each peer's transport relaying, or preserving privacy by hiding each peer's transport
addresses to the other party. Other protocols or functionalities addresses to the other party. Other protocols or functionalities
that provide this behavior are TURN [RFC5766] servers, Session Border that provide this behavior are TURN [RFC5766] servers, Session Border
skipping to change at page 8, line 19 skipping to change at page 8, line 21
The transport relay implementations also have to take into account The transport relay implementations also have to take into account
security considerations. In particular, source address filtering of security considerations. In particular, source address filtering of
incoming packets is usually important in relays, to prevent attackers incoming packets is usually important in relays, to prevent attackers
to inject traffic into a session, which one peer may, in the absence to inject traffic into a session, which one peer may, in the absence
fo adequate security in the relay, think it comes from the other fo adequate security in the relay, think it comes from the other
peer. peer.
3.2.1.2. Transport Translator 3.2.1.2. Transport Translator
Shortcut name: Topo-Trn-Translator
Transport Translators (Topo-Trn-Translator) do not modify the RTP Transport Translators (Topo-Trn-Translator) do not modify the RTP
stream itself, but are concerned with transport parameters. stream itself, but are concerned with transport parameters.
Transport parameters, in the sense of this section, comprise the Transport parameters, in the sense of this section, comprise the
transport addresses (to bridge different domains such unicast to transport addresses (to bridge different domains such unicast to
multicast) and the media packetization to allow other transport multicast) and the media packetization to allow other transport
protocols to be interconnected to a session (in gateways). protocols to be interconnected to a session (in gateways).
Translators that bridge between different protocol worlds need to be Translators that bridge between different protocol worlds need to be
concerned about the mapping of the SSRC/CSRC (Contributing Source) concerned about the mapping of the SSRC/CSRC (Contributing Source)
concept to the non-RTP protocol. When designing a Translator to a concept to the non-RTP protocol. When designing a Translator to a
skipping to change at page 8, line 41 skipping to change at page 8, line 45
not discussed henceforth. not discussed henceforth.
Of the transport Translators, this memo is primarily interested in Of the transport Translators, this memo is primarily interested in
those that use RTP on both sides, and this is assumed henceforth. those that use RTP on both sides, and this is assumed henceforth.
The most basic transport translators that operate below the RTP level The most basic transport translators that operate below the RTP level
were already discussed in Section 3.2.1.1. were already discussed in Section 3.2.1.1.
3.2.1.3. Media Translator 3.2.1.3. Media Translator
Shortcut name: Topo-Media-Translator
Media Translators (Topo-Media-Translator) modify the media inside the Media Translators (Topo-Media-Translator) modify the media inside the
RTP stream. This process is commonly known as transcoding. The RTP stream. This process is commonly known as transcoding. The
modification of the media can be as small as removing parts of the modification of the media can be as small as removing parts of the
stream, and it can go all the way to a full decoding and re-encoding stream, and it can go all the way to a full decoding and re-encoding
(down to the sample level or equivalent) utilizing a different media (down to the sample level or equivalent) utilizing a different media
codec. Media Translators are commonly used to connect endpoints codec. Media Translators are commonly used to connect endpoints
without a common interoperability point in the media encoding. without a common interoperability point in the media encoding.
Stand-alone Media Translators are rare. Most commonly, a combination Stand-alone Media Translators are rare. Most commonly, a combination
of Transport and Media Translator is used to translate both the media of Transport and Media Translator is used to translate both the media
skipping to change at page 10, line 18 skipping to change at page 10, line 29
Similarly, a Media Translator can sometimes remove information from Similarly, a Media Translator can sometimes remove information from
the RTP stream, while otherwise leaving the remaining RTP packets the RTP stream, while otherwise leaving the remaining RTP packets
unchanged (again with the exception of certain RTP header fields). unchanged (again with the exception of certain RTP header fields).
Either type of functionality where T manipulates the RTP stream, or Either type of functionality where T manipulates the RTP stream, or
adds an accompanying RTP stream, on behalf of A is also covered under adds an accompanying RTP stream, on behalf of A is also covered under
the media translator definition. the media translator definition.
3.2.2. Back to Back RTP sessions 3.2.2. Back to Back RTP sessions
Shortcut name: Topo-Back-To-Back
There exist middleboxes that interconnect two endpoints A and B There exist middleboxes that interconnect two endpoints A and B
through themselves (MB), but not by being part of a common RTP through themselves (MB), but not by being part of a common RTP
session. They establish instead two different RTP sessions, one session. They establish instead two different RTP sessions, one
between A and the middlebox and another between the middlebox and B. between A and the middlebox and another between the middlebox and B.
This topology is called Topo-Back-To-Back This topology is called Topo-Back-To-Back
|<--Session A-->| |<--Session B-->| |<--Session A-->| |<--Session B-->|
+------+ +------+ +------+ +------+ +------+ +------+
| A |------->| MB |-------->| B | | A |------->| MB |-------->| B |
+------+ +------+ +------+ +------+ +------+ +------+
skipping to change at page 11, line 17 skipping to change at page 11, line 30
conceptually easier to handle when considering the two RTP streams as conceptually easier to handle when considering the two RTP streams as
belonging to a single RTP session. belonging to a single RTP session.
3.3. Point to Multipoint Using Multicast 3.3. Point to Multipoint Using Multicast
Multicast is an IP layer functionality that is available in some Multicast is an IP layer functionality that is available in some
networks. Two main flavors can be distinguished: Any Source networks. Two main flavors can be distinguished: Any Source
Multicast (ASM) [RFC1112] where any multicast group participant can Multicast (ASM) [RFC1112] where any multicast group participant can
send to the group address and expect the packet to reach all group send to the group address and expect the packet to reach all group
participants; and Source Specific Multicast (SSM) [RFC3569], where participants; and Source Specific Multicast (SSM) [RFC3569], where
only a particular IP host sends to the multicast group. Both these only a particular IP host sends to the multicast group. Each of
models are discussed below in their respective sections. these models are discussed below in their respective sections.
3.3.1. Any Source Multicast (ASM) 3.3.1. Any Source Multicast (ASM)
Shortcut name: Topo-ASM (was Topo-Multicast) Shortcut name: Topo-ASM (was Topo-Multicast)
+-----+ +-----+
+---+ / \ +---+ +---+ / \ +---+
| A |----/ \---| B | | A |----/ \---| B |
+---+ / Multi- \ +---+ +---+ / Multi- \ +---+
+ Cast + + Cast +
skipping to change at page 12, line 32 skipping to change at page 12, line 44
subscription). Therefore, the feedback suppression mechanism subscription). Therefore, the feedback suppression mechanism
discussed in [RFC4585] is typically required. Each individual discussed in [RFC4585] is typically required. Each individual
endpoint that is a multicast group participant needs to process every endpoint that is a multicast group participant needs to process every
feedback message it receives, not only to determine if it is affected feedback message it receives, not only to determine if it is affected
or if the feedback message applies only to some other endpoint, but or if the feedback message applies only to some other endpoint, but
also to derive timing restrictions for the sending of its own also to derive timing restrictions for the sending of its own
feedback messages, if any. feedback messages, if any.
3.3.2. Source Specific Multicast (SSM) 3.3.2. Source Specific Multicast (SSM)
Shortcut name: Topo-SSM
In Any Source Multicast, any of the multicast group participants can In Any Source Multicast, any of the multicast group participants can
send to all the other multicast group participants, by sending a send to all the other multicast group participants, by sending a
packet to the multicast group. In contrast, Source Specific packet to the multicast group. In contrast, Source Specific
Multicast [RFC3569][RFC4607] refers to scenarios where only a single Multicast [RFC3569][RFC4607] refers to scenarios where only a single
source (Distribution Source) can send to the multicast group, source (Distribution Source) can send to the multicast group,
creating a topology that looks like the one below: creating a topology that looks like the one below:
+--------+ +-----+ +--------+ +-----+
|Media | | | Source-specific |Media | | | Source-specific
|Sender 1|<----->| D S | Multicast |Sender 1|<----->| D S | Multicast
skipping to change at page 14, line 38 skipping to change at page 14, line 38
not visually pleasing results. not visually pleasing results.
Security solutions for this type of group communications are also Security solutions for this type of group communications are also
challenging. First, the key-management and the security protocol challenging. First, the key-management and the security protocol
must support group communication. Source authentication becomes more must support group communication. Source authentication becomes more
difficult and requires specialized solutions. For more discussion on difficult and requires specialized solutions. For more discussion on
this please review Options for Securing RTP Sessions [RFC7201]. this please review Options for Securing RTP Sessions [RFC7201].
3.3.3. SSM with Local Unicast Resources 3.3.3. SSM with Local Unicast Resources
Shortcut name: Topo-SSM-RAMS
"Unicast-Based Rapid Acquisition of Multicast RTP Sessions" [RFC6285] "Unicast-Based Rapid Acquisition of Multicast RTP Sessions" [RFC6285]
results in additional extensions to SSM Topology. results in additional extensions to SSM Topology.
----------- -------------- ----------- --------------
| |------------------------------------>| | | |------------------------------------>| |
| |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| | | |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| |
| | | | | | | |
| Multicast | ---------------- | | | Multicast | ---------------- | |
| Source | | Retransmission | | | | Source | | Retransmission | | |
| |-------->| Server (RS) | | | | |-------->| Server (RS) | | |
skipping to change at page 17, line 31 skipping to change at page 17, line 31
| | | | +-Video-| |-Video-+ | | | | | | | +-Video-| |-Video-+ | | |
| +-------+-+-+--->AV1|---------------->| | | | | | +-------+-+-+--->AV1|---------------->| | | | |
| | | | |<----------------|CV1 | | | | | | | | |<----------------|CV1 | | | |
| | | +-------| |-------+ | | | | | | +-------| |-------+ | | |
| | +---------| |---------+ | | | | +---------| |---------+ | |
| +-----------| |-----------+ | | +-----------| |-----------+ |
+----------------------+ +-------------+ +----------------------+ +-------------+
Figure 9: An Multi-unicast Mesh with a joint RTP session Figure 9: An Multi-unicast Mesh with a joint RTP session
A joint RTP session from endpoint A's perspective for the Mesh Figure 9 depicts endpoints A's view of using a common RTP session
depicted in Figure 8 with a joint RTP session have multiple transport when establishing the mesh as shown in Figure 8. There is only one
flows, here enumerated as UDP1 and UDP2. However, there is only one RTP session (RTP1) but two transport flows (UDP1 and UDP2). The
RTP session (RTP1). The Media Source (CAM) is encoded and Media Source (CAM) is encoded and transmitted over the SSRC (AV1)
transmitted over the SSRC (AV1) across both transport layers. across both transport layers. However, as this is a joint RTP
However, as this is a joint RTP session, the two streams must be the session, the two streams must be the same. Thus, an congestion
same. Thus, an congestion control adaptation needed for the paths A control adaptation needed for the paths A to B and A to C needs to
to B and A to C needs to use the most restricting path's properties. use the most restricting path's properties.
An alternative structure for establishing the above topology is to An alternative structure for establishing the above topology is to
use independent RTP sessions between each pair of peers, i.e., three use independent RTP sessions between each pair of peers, i.e., three
different RTP sessions. In some scenarios, the same RTP stream may different RTP sessions. In some scenarios, the same RTP stream may
be sent from the transmitting endpoint, however it also supports be sent from the transmitting endpoint, however it also supports
local adaptation taking place in one or more of the RTP streams, local adaptation taking place in one or more of the RTP streams,
rendering them non-identical. rendering them non-identical.
+-A----------------------+ +-B-----------+ +-A----------------------+ +-B-----------+
|+---+ | | | |+---+ | | |
skipping to change at page 18, line 36 skipping to change at page 18, line 36
| | +---------| |---------+ | | | | +---------| |---------+ | |
| +-----------| |-----------+ | | +-----------| |-----------+ |
+------------------------+ +-------------+ +------------------------+ +-------------+
Figure 10: An Multi-unicast Mesh with independent RTP session Figure 10: An Multi-unicast Mesh with independent RTP session
Lets review the topology when independent RTP sessions are used, from Lets review the topology when independent RTP sessions are used, from
A's perspective in Figure 10 by considering both how the media is A's perspective in Figure 10 by considering both how the media is
handled and the RTP sessions that are set-up in Figure 10. A's handled and the RTP sessions that are set-up in Figure 10. A's
microphone is captured and the audio is fed into two different microphone is captured and the audio is fed into two different
encoder instances, each being associated with two independent RTP encoder instances, each with a different independent RTP session,
sessions (RTP1 and RTP2). The SSRCs (AA1 and AA2) in each RTP i.e. RTP1 and RTP2 respectively. The SSRCs (AA1 and AA2) in each RTP
session are completely independent and the media bit-rate produced by session are completely independent and the media bit-rate produced by
the encoders can also be tuned differently to address any congestion the encoders can also be tuned differently to address any congestion
control requirements differing for the paths A to B compared to A to control requirements differing for the paths A to B compared to A to
C. C.
From a topologies viewpoint, an important difference exists in the From a topologies viewpoint, an important difference exists in the
behavior around RTCP. First, when a single RTP session spans all behavior around RTCP. First, when a single RTP session spans all
three endpoints A, B, and C, and their connecting RTP streams, a three endpoints A, B, and C, and their connecting RTP streams, a
common RTCP bandwidth is calculated and used for this single joint common RTCP bandwidth is calculated and used for this single joint
session. In contrast, when there are multiple independent RTP session. In contrast, when there are multiple independent RTP
skipping to change at page 30, line 9 skipping to change at page 30, line 9
endpoints, then only two out of these five SSRCs need concurrently endpoints, then only two out of these five SSRCs need concurrently
transmit media to A. As the middlebox selects the source in the transmit media to A. As the middlebox selects the source in the
different RTP sessions that transmit media to the endpoints, each RTP different RTP sessions that transmit media to the endpoints, each RTP
stream requires rewriting of certain RTP header fields when being stream requires rewriting of certain RTP header fields when being
projected from one session into another. In particular, the sequence projected from one session into another. In particular, the sequence
number needs to be consecutively incremented based on the packet number needs to be consecutively incremented based on the packet
actually being transmitted in each RTP session. Therefore, the RTP actually being transmitted in each RTP session. Therefore, the RTP
sequence number offset will change each time a source is turned on in sequence number offset will change each time a source is turned on in
a RTP session. The timestamp (possibly offset) stays the same. a RTP session. The timestamp (possibly offset) stays the same.
The RTP sessions can be considered independent, the SSRC numbers used The RTP sessions can be considered independent, resulting in that the
can also be handled independently, thereby bypassing the requirement SSRC numbers used can also be handled independently. This simplifies
for SSRC collision detection and avoidance. This will require tools the SSRC collision detection and avoidance, but require tools such as
such as remapping tables between the RTP sessions.However, using remapping tables between the RTP sessions. Using independent RTP
independent RTP sessions are not required, the switching behavior is sessions are not required, as the switching behavior is possible to
possible to perform also with a common SSRC space. However, in this perform also with a common SSRC space. However, in this case
case collision detection and handling becomes a different problem. collision detection and handling becomes a different problem. It is
Therefore, it is up to the implementation to use a single common SSRC up to the implementation to use a single common SSRC space or
space or separate ones. separate ones.
Using separate SSRC spaces have some implications. For example, the Using separate SSRC spaces has some implications. For example, the
RTP stream that is being sent by endpoint B to the middlebox (BV1) RTP stream that is being sent by endpoint B to the middlebox (BV1)
may use an SSRC value of 12345678. When that RTP stream is sent to may use an SSRC value of 12345678. When that RTP stream is sent to
endpoint F by the middlebox, it can use any SSRC value, e.g. endpoint F by the middlebox, it can use any SSRC value, e.g.
87654321. As a result, each endpoint may have a different view of 87654321. As a result, each endpoint may have a different view of
the application usage of a particular SSRC. Any RTP level identity the application usage of a particular SSRC. Any RTP level identity
information, such as SDES items also needs to update the SSRC information, such as SDES items also needs to update the SSRC
referenced, if the included SDES items are intended to be global. referenced, if the included SDES items are intended to be global.
Thus the application must not use SSRC as references to RTP streams Thus the application must not use SSRC as references to RTP streams
when communicating with other peers directly. This also affects loop when communicating with other peers directly. This also affects loop
detection which will fail to work, as there is no common namespace detection which will fail to work, as there is no common namespace
and identities across the different legs in the communication session and identities across the different legs in the communication session
on RTP level. Instead this responsibility falls onto higher layers. on RTP level. Instead this responsibility falls onto higher layers.
The middlebox is also responsible to receive any RTCP codec control The middlebox is also responsible for receiving any RTCP codec
requests coming from an endpoint, and decide if it can act on the control requests coming from an endpoint, and decide if it can act on
request locally or needs to translate the request into the RTP the request locally or needs to translate the request into the RTP
session/transport leg that contains the media source. Both endpoints session/transport leg that contains the media source. Both endpoints
and the middlebox need to implement conference related codec control and the middlebox need to implement conference related codec control
functionalities to provide a good experience. Commonly used are Full functionalities to provide a good experience. Commonly used are Full
Intra Request to request from the media source to provide switching Intra Request to request from the media source to provide switching
points between the sources, and Temporary Maximum Media Bit-rate points between the sources, and Temporary Maximum Media Bit-rate
Request (TMMBR) to enable the middlebox to aggregate congestion Request (TMMBR) to enable the middlebox to aggregate congestion
control responses towards the media source so to enable it to adjust control responses towards the media source so to enable it to adjust
its bit-rate (obviously only in case the limitation is not in the its bit-rate (obviously only in case the limitation is not in the
source to middlebox link). source to middlebox link).
skipping to change at page 35, line 9 skipping to change at page 35, line 9
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 physical video by another. Each of these subunits uses its own physical
network interface (for example: Ethernet jack) and network address. network interface (for example: Ethernet jack) and network address.
The various (media processing) subunits need (logically and 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. Historically, the earliest referred to as split component terminals. Historically, the earliest
split component terminals were perhaps the (independent) audio and split component terminals were perhaps the independent audio and
video conference software tools used over the MBONE in the late video conference software tools used over the MBONE in the late
1990s. 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 terminates RTP, and acts From an RTP viewpoint, each of the subunits terminates RTP, and acts
skipping to change at page 38, line 34 skipping to change at page 38, line 34
(ASM), provides the functionality that everyone may send to, or (ASM), provides the functionality that everyone may send to, or
receive from, everyone else within the session. Source-specific receive from, everyone else within the session. Source-specific
Multicast (SSM) can provide a similar functionality by having anyone Multicast (SSM) can provide a similar functionality by having anyone
intending to participate as sender to send its media to the SSM intending to participate as sender to send its media to the SSM
distribution source. The SSM distribution source forwards the media distribution source. The SSM distribution source forwards the media
to all receivers subscribed to the multicast group. Mesh, MCUs, to all receivers subscribed to the multicast group. Mesh, MCUs,
Mixers, SFMs and Translators may all provide that functionality at Mixers, SFMs and Translators may all provide that functionality at
least on some basic level. However, there are some differences in least on some basic level. However, there are some differences in
which type of reachability they provide. which type of reachability they provide.
Closest to true IP-multicast-based, all-to-all transmission comes The topologies that comes closest to emulating Any Source IP
perhaps the transport Translator function called "relay" in Multicast, with all-to-all transmission capabilities, are the
Section 3.5, as well as the Mesh with joint RTP sessions. Media transport Translator function called "relay" in Section 3.5, as well
as the Mesh with joint RTP sessions (Section 3.4). Media
Translators, Mesh with independent RTP Sessions, Mixers, SFUs and the Translators, Mesh with independent RTP Sessions, Mixers, SFUs and the
MCU variants do not provide a fully meshed forwarding on the MCU variants do not provide a fully meshed forwarding on the
transport level; instead, they only allow limited forwarding of transport level; instead, they only allow limited forwarding of
content from the other session participants. content from the other session participants.
The "all to all media transmission" requires that any media The "all to all media transmission" requires that any media
transmitting endpoint considers the path to the least capable transmitting endpoint considers the path to the least capable
receiving endpoint. Otherwise, the media transmissions may overload receiving endpoint. Otherwise, the media transmissions may overload
that path. Therefore, a sending endpoint needs to monitor the path that path. Therefore, a sending endpoint needs to monitor the path
from itself to any of the receiving endpoints, to detect the from itself to any of the receiving endpoints, to detect the
skipping to change at page 45, line 18 skipping to change at page 45, line 18
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:
Grouping RTCP Reception Statistics and Other Feedback", Grouping RTCP Reception Statistics and Other Feedback",
draft-ietf-avtcore-rtp-multi-stream-optimisation-05 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-05 (work
in progress), February 2015. in progress), February 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-19 (work in progress), March 2015. negotiation-22 (work in progress), June 2015.
[I-D.westerlund-avtext-sdes-hdr-ext] [I-D.westerlund-avtext-sdes-hdr-ext]
Westerlund, M., Even, R., and M. Zanaty, "RTP Header Westerlund, M., Even, R., and M. Zanaty, "RTP Header
Extension for RTCP Source Description Items", draft- Extension for RTCP Source Description Items", draft-
westerlund-avtext-sdes-hdr-ext-03 (work in progress), westerlund-avtext-sdes-hdr-ext-03 (work in progress),
November 2014. November 2014.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
 End of changes. 20 change blocks. 
36 lines changed or deleted 49 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/