< draft-ietf-avtcore-rtp-topologies-update-06.txt   draft-ietf-avtcore-rtp-topologies-update-07.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: September 3, 2015 March 2, 2015 Expires: October 1, 2015 March 30, 2015
RTP Topologies RTP Topologies
draft-ietf-avtcore-rtp-topologies-update-06 draft-ietf-avtcore-rtp-topologies-update-07
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 September 3, 2015. This Internet-Draft will expire on October 1, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
3.3.2. Source Specific Multicast (SSM) . . . . . . . . . . . 12 3.3.2. Source Specific Multicast (SSM) . . . . . . . . . . . 12
3.3.3. SSM with Local Unicast Resources . . . . . . . . . . 14 3.3.3. SSM with Local Unicast Resources . . . . . . . . . . 14
3.4. Point to Multipoint Using Mesh . . . . . . . . . . . . . 16 3.4. Point to Multipoint Using Mesh . . . . . . . . . . . . . 16
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 . . . . . 32
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 . . . . . . . . . . . . . 37 3.11. Non-Symmetric Mixer/Translators . . . . . . . . . . . . . 37
3.12. Combining Topologies . . . . . . . . . . . . . . . . . . 37 3.12. Combining Topologies . . . . . . . . . . . . . . . . . . 37
4. Topology Properties . . . . . . . . . . . . . . . . . . . . . 38 4. Topology Properties . . . . . . . . . . . . . . . . . . . . . 38
4.1. All to All Media Transmission . . . . . . . . . . . . . . 38 4.1. All to All Media Transmission . . . . . . . . . . . . . . 38
4.2. Transport or Media Interoperability . . . . . . . . . . . 39 4.2. Transport or Media Interoperability . . . . . . . . . . . 39
4.3. Per Domain Bit-Rate Adaptation . . . . . . . . . . . . . 39 4.3. Per Domain Bit-Rate Adaptation . . . . . . . . . . . . . 39
4.4. Aggregation of Media . . . . . . . . . . . . . . . . . . 40 4.4. Aggregation of Media . . . . . . . . . . . . . . . . . . 40
4.5. View of All Session Participants . . . . . . . . . . . . 40 4.5. View of All Session Participants . . . . . . . . . . . . 40
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.
As the RTP sessions are independent, the SSRC numbers used can also The RTP sessions can be considered independent, the SSRC numbers used
be handled independently, thereby bypassing the requirement for SSRC can also be handled independently, thereby bypassing the requirement
collision detection and avoidance. On the other hand, tools such as for SSRC collision detection and avoidance. This will require tools
remapping tables between the RTP sessions are required. For example, such as remapping tables between the RTP sessions.However, using
the RTP stream that is being sent by endpoint B to the middlebox independent RTP sessions are not required, the switching behavior is
(BV1) may use an SSRC value of 12345678. When that RTP stream is possible to perform also with a common SSRC space. However, in this
sent to endpoint F by the middlebox, it can use any SSRC value, e.g. case collision detection and handling becomes a different problem.
Therefore, it is up to the implementation to use a single common SSRC
space or separate ones.
Using separate SSRC spaces have some implications. For example, the
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
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 to receive any RTCP codec control
requests coming from an endpoint, and decide if it can act on the requests coming from an endpoint, and decide if it can act on the
request locally or needs to translate the request into the RTP request locally or needs to translate the request into the RTP
session that contains the media source. Both endpoints and the session/transport leg that contains the media source. Both endpoints
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).
The selective forwarding middlebox has been introduced in recently The selective forwarding middlebox has been introduced in recently
developed videoconferencing systems in conjunction with, and to developed videoconferencing systems in conjunction with, and to
skipping to change at page 31, line 23 skipping to change at page 31, line 30
streams providing media. As each projected SSRC can, at any time, streams providing media. As each projected SSRC can, at any time,
provide media, the endpoint either needs to be able to handle as many provide media, the endpoint either needs to be able to handle as many
decoder instances as the middlebox received, or have efficient decoder instances as the middlebox received, or have efficient
switching of decoder contexts in a more limited set of actual decoder switching of decoder contexts in a more limited set of actual decoder
instances to cope with the switches. The application also gets more instances to cope with the switches. The application also gets more
responsibility to update how the media provided is to be presented to responsibility to update how the media provided is to be presented to
the user. the user.
Note that this topology could potentially be seen as a media Note that this topology could potentially be seen as a media
translator which include an on/off logic as part of its media translator which include an on/off logic as part of its media
translation. The main difference would be a common global SSRC space translation. The topology has the property that all SSRCs present in
in the case of the Media Translator and the mapped one used in the the session is visible to an endpoint. It also has mixer aspects, as
above. It also has mixer aspects, as the streams it provides are not the streams it provides are not basically translated version, but
basically translated version, but instead they have conceptual instead they have conceptual property assigned to them and can be
property assigned to them. Thus this topology appears to be some both turned on/off as well as being fully or partially delivered.
hybrid between the translator and mixer model. Thus this topology appears to be some hybrid between the translator
and mixer model.
The differences between selective forwarding middlebox and a The differences between selective forwarding middlebox and a
switching mixer (Section 3.6.2) are minor, and they share most switching mixer (Section 3.6.2) are minor, and they share most
properties. The above requirement on having a large number of properties. The above requirement on having a large number of
decoding instances or requiring efficient switching of decoder decoding instances or requiring efficient switching of decoder
contexts, are one point of difference. The other is how the contexts, are one point of difference. The other is how the
identification is performed, where the Mixer uses CSRC to provide identification is performed, where the Mixer uses CSRC to provide
information on what is included in a particular RTP stream that information on what is included in a particular RTP stream that
represent a particular concept. Selective forwarding gets the source represent a particular concept. Selective forwarding gets the source
information through the SSRC, and instead have to use other mechanism information through the SSRC, and instead have to use other mechanism
skipping to change at page 41, line 24 skipping to change at page 41, line 24
endpoints. However, the Back-to-Back RTP sessions, Mesh with endpoints. However, the Back-to-Back RTP sessions, Mesh with
independent RTP sessions, SFM, will definitely break the loop independent RTP sessions, SFM, will definitely break the loop
detection mechanism. detection mechanism.
4.7. Consistency between header extensions and RTCP 4.7. Consistency between header extensions and RTCP
Some RTP header extensions have relevance not only end-to-end, but Some RTP header extensions have relevance not only end-to-end, but
also hop-to-hop, meaning at least some of the middleboxes in the path also hop-to-hop, meaning at least some of the middleboxes in the path
are aware of their potential presence through signaling, intercept are aware of their potential presence through signaling, intercept
and interpret such header extensions and potentially also rewrite or and interpret such header extensions and potentially also rewrite or
generate them. Modern header extensions generally follow RFC 5285 generate them. Modern header extensions generally follow "A General
[RFC5285], which allows for all of the above. Examples for such Mechanism for RTP Header Extensions" [RFC5285], which allows for all
header extensions include the mid (media ID) in [draft-ietf-mmusic- of the above. Examples for such header extensions include the mid
sdp-bundle-negotiation-12] [I-D.ietf-mmusic-sdp-bundle-negotiation]. (media ID) in [I-D.ietf-mmusic-sdp-bundle-negotiation]. At the time
At the time of writing there was also a proposal for how to include of writing there was also a proposal for how to include any SDES into
any SDES into an RTP header extension [draft-westerlund-avtext-dses- an RTP header extension [I-D.westerlund-avtext-sdes-hdr-ext].
hdr-ext] [I-D.westerlund-avtext-sdes-hdr-ext].
When such header extensions are in use, any middlebox that When such header extensions are in use, any middlebox that
understands it must ensure consistency between the extensions it sees understands it must ensure consistency between the extensions it sees
and/or generates, and the RTCP it receives and generates. For and/or generates, and the RTCP it receives and generates. For
example, the mid of bundle is sent in an RTP header extension and example, the mid of bundle is sent in an RTP header extension and
also in an RTCP SDES message. This apparent redundancy was also in an RTCP SDES message. This apparent redundancy was
introduced as unaware middleboxes may choose to discard RTP header introduced as unaware middleboxes may choose to discard RTP header
extensions. Obviously, inconsistency between the media ID sent in extensions. Obviously, inconsistency between the media ID sent in
the RTP header extension and in the RTCP SDES message could lead to the RTP header extension and in the RTCP SDES message could lead to
undesirable results, and, therefore, consistency is needed. undesirable results, and, therefore, consistency is needed.
Middleboxes unaware of the nature of a header extension, as specified Middleboxes unaware of the nature of a header extension, as specified
in RFC 5285 [RFC5285], are free to forward or discard header in [RFC5285], are free to forward or discard header extensions.
extensions.
5. Comparison of Topologies 5. Comparison of Topologies
The table below attempts to summarize the properties of the different The table below attempts to summarize the properties of the different
topologies. The legend to the topology abbreviations are: Topo- topologies. The legend to the topology abbreviations are: Topo-
Point-to-Point (PtP), Topo-ASM (ASM), Topo-SSM (SSM), Topo-Trns- Point-to-Point (PtP), Topo-ASM (ASM), Topo-SSM (SSM), Topo-Trns-
Translator (TT), Topo-Media-Translator (including Transport Translator (TT), Topo-Media-Translator (including Transport
Translator) (MT), Topo-Mesh with joint session (MJS), Topo-Mesh with Translator) (MT), Topo-Mesh with joint session (MJS), Topo-Mesh with
individual sessions (MIS), Topo-Mixer (Mix), Topo-Asymmetric (ASY), individual sessions (MIS), Topo-Mixer (Mix), Topo-Asymmetric (ASY),
Topo-Video-switch-MCU (VSM), and Topo-RTCP-terminating-MCU (RTM), Topo-Video-switch-MCU (VSM), and Topo-RTCP-terminating-MCU (RTM),
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-16 (work in progress), January 2015. negotiation-19 (work in progress), March 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. 10 change blocks. 
29 lines changed or deleted 35 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/
X-Generator: pyht 0.35