Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7667

RTP Topologies

Pages: 48
Informational
Errata
Obsoletes:  5117
Part 3 of 3 – Pages 39 to 48
First   Prev   None

Top   ToC   RFC7667 - Page 39   prevText

4. Topology Properties

The topologies discussed in Section 3 have different properties. This section describes these properties. Note that, even if a certain property is supported within a particular topology concept, the necessary functionality may be optional to implement.

4.1. All-to-All Media Transmission

To recapitulate, multicast, and in particular ASM, provides the functionality that everyone may send to, or receive from, everyone else within the session. SSM can provide a similar functionality by having anyone intending to participate as a sender to send its media to the SSM Distribution Source. The SSM Distribution Source forwards the media to all receivers subscribed to the multicast group. Mesh, MCUs, mixers, Selective Forwarding Middleboxes (SFMs), and translators may all provide that functionality at least on some basic level. However, there are some differences in which type of reachability they provide. The topologies that come closest to emulating Any-Source IP Multicast, with all-to-all transmission capabilities, are the 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 MCU variants do not provide a fully meshed forwarding on the transport level; instead, they only allow limited forwarding of content from the other session participants. The "all-to-all media transmission" requires that any media transmitting endpoint considers the path to the least-capable receiving endpoint. Otherwise, the media transmissions may overload that path. Therefore, a sending endpoint needs to monitor the path from itself to any of the receiving endpoints, to detect the currently least-capable receiver and adapt its sending rate accordingly. As multiple endpoints may send simultaneously, the available resources may vary. RTCP's receiver reports help perform this monitoring, at least on a medium time scale.
Top   ToC   RFC7667 - Page 40
   The resource consumption for performing all-to-all transmission
   varies depending on the topology.  Both ASM and SSM have the benefit
   that only one copy of each packet traverses a particular link.  Using
   a relay causes the transmission of one copy of a packet per
   endpoint-to-relay path and packet transmitted.  However, in most
   cases, the links carrying the multiple copies will be the ones close
   to the relay (which can be assumed to be part of the network
   infrastructure with good connectivity to the backbone) rather than
   the endpoints (which may be behind slower access links).  The Mesh
   topologies causes N-1 streams of transmitted packets to traverse the
   first-hop link from the endpoint, in a mesh with N endpoints.  How
   long the different paths are common is highly situation dependent.

   The transmission of RTCP by design adapts to any changes in the
   number of participants due to the transmission algorithm, defined in
   the RTP specification [RFC3550], and the extensions in AVPF [RFC4585]
   (when applicable).  That way, the resources utilized for RTCP stay
   within the bounds configured for the session.

4.2. Transport or Media Interoperability

All translators, mixers, RTCP-terminating MCUs, and Mesh with individual RTP sessions allow changing the media encoding or the transport to other properties of the other domain, thereby providing extended interoperability in cases where the endpoints lack a common set of media codecs and/or transport protocols. Selective Forwarding Middleboxes can adopt the transport and (at least) selectively forward the encoded streams that match a receiving endpoint's capability. It requires an additional translator to change the media encoding if the encoded streams do not match the receiving endpoint's capabilities.

4.3. Per-Domain Bitrate Adaptation

Endpoints are often connected to each other with a heterogeneous set of paths. This makes congestion control in a Point-to-Multipoint set problematic. In the ASM, SSM, Mesh with common RTP session, and Transport Relay scenarios, each individual sending endpoint has to adapt to the receiving endpoint behind the least-capable path, yielding suboptimal quality for the endpoints behind the more capable paths. This is no longer an issue when Media Translators, mixers, SFMs, or MCUs are involved, as each endpoint only needs to adapt to the slowest path within its own domain. The translator, mixer, SFM, or MCU topologies all require their respective outgoing RTP streams to adjust the bitrate, packet rate, etc., to adapt to the least- capable path in each of the other domains. That way one can avoid lowering the quality to the least-capable endpoint in all the domains at the cost (complexity, delay, equipment) of the mixer, SFM, or
Top   ToC   RFC7667 - Page 41
   translator, and potentially the media sender (multicast/layered
   encoding and sending the different representations).

4.4. Aggregation of Media

In the all-to-all media property mentioned above and provided by ASM, SSM, Mesh with common RTP session, and relay, all simultaneous media transmissions share the available bitrate. For endpoints with limited reception capabilities, this may result in a situation where even a minimal, acceptable media quality cannot be accomplished, because multiple RTP streams need to share the same resources. One solution to this problem is to use a mixer, or MCU, to aggregate the multiple RTP streams into a single one, where the single RTP stream takes up less resources in terms of bitrate. This aggregation can be performed according to different methods. Mixing or selection are two common methods. Selection is almost always possible and easy to implement. Mixing requires resources in the mixer and may be relatively easy and not impair the quality too badly (audio) or quite difficult (video tiling, which is not only computationally complex but also reduces the pixel count per stream, with corresponding loss in perceptual quality).

4.5. View of All Session Participants

The RTP protocol includes functionality to identify the session participants through the use of the SSRC and CSRC fields. In addition, it is capable of carrying some further identity information about these participants using the RTCP SDES. In topologies that provide a full all-to-all functionality, i.e., ASM, Mesh with common RTP session, and relay, a compliant RTP implementation offers the functionality directly as specified in RTP. In topologies that do not offer all-to-all communication, it is necessary that RTCP is handled correctly in domain bridging functions. RTP includes explicit specification text for translators and mixers, and for SFMs the required functionality can be derived from that text. However, the MCU described in Section 3.8 cannot offer the full functionality for session participant identification through RTP means. The topologies that create independent RTP sessions per endpoint or pair of endpoints, like a Back-to-Back RTP session, MESH with independent RTP sessions, and the RTCP terminating MCU (Section 3.9), with an exception of SFM, do not support RTP-based identification of session participants. In all those cases, other non-RTP-based mechanisms need to be implemented if such knowledge is required or desirable. When it comes to SFM, the SSRC namespace is not necessarily joint. Instead, identification will require knowledge of SSRC/CSRC mappings that the SFM performed; see Section 3.7.
Top   ToC   RFC7667 - Page 42

4.6. Loop Detection

In complex topologies with multiple interconnected domains, it is possible to unintentionally form media loops. RTP and RTCP support detecting such loops, as long as the SSRC and CSRC identities are maintained and correctly set in forwarded packets. Loop detection will work in ASM, SSM, Mesh with joint RTP session, and relay. It is likely that loop detection works for the video-switching MCU, Section 3.8, at least as long as it forwards the RTCP between the endpoints. However, the Back-to-Back RTP sessions, Mesh with independent RTP sessions, and SFMs will definitely break the loop detection mechanism.

4.7. Consistency between Header Extensions and RTCP

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 are aware of their potential presence through signaling, intercept and interpret such header extensions, and potentially also rewrite or generate them. Modern header extensions generally follow "A General Mechanism for RTP Header Extensions" [RFC5285], which allows for all of the above. Examples for such header extensions include the Media ID (MID) in [SDP-BUNDLE]. At the time of writing, there was also a proposal for how to include some SDES into an RTP header extension [RTCP-SDES]. When such header extensions are in use, any middlebox that understands it must ensure consistency between the extensions it sees and/or generates and the RTCP it receives and generates. For example, the MID of the bundle is sent in an RTP header extension and also in an RTCP SDES message. This apparent redundancy was introduced as unaware middleboxes may choose to discard RTP header extensions. Obviously, inconsistency between the MID sent in the RTP header extension and in the RTCP SDES message could lead to undesirable results, and, therefore, consistency is needed. Middleboxes unaware of the nature of a header extension, as specified in [RFC5285], are free to forward or discard header extensions.

5. Comparison of Topologies

The table below attempts to summarize the properties of the different topologies. The legend to the topology abbreviations are: Topo-Point-to-Point (PtP), Topo-ASM (ASM), Topo-SSM (SSM), Topo-Trn- Translator (TT), Topo-Media-Translator (including Transport Translator) (MT), Topo-Mesh with joint session (MJS), Topo-Mesh with individual sessions (MIS), Topo-Mixer (Mix), Topo-Asymmetric (ASY), Topo-Video-switch-MCU (VSM), Topo-RTCP-terminating-MCU (RTM), and Selective Forwarding Middlebox (SFM). In the table below, Y
Top   ToC   RFC7667 - Page 43
   indicates Yes or full support, N indicates No support, (Y) indicates
   partial support, and N/A indicates not applicable.

   Property             PtP  ASM SSM  TT MT MJS MIS Mix ASY VSM RTM SFM
   ---------------------------------------------------------------------
   All-to-All Media      N    Y  (Y)  Y  Y   Y  (Y) (Y) (Y) (Y) (Y) (Y)
   Interoperability      N/A  N   N   Y  Y   Y   Y   Y   Y   N   Y   Y
   Per-Domain Adaptation N/A  N   N   N  Y   N   Y   Y   Y   N   Y   Y
   Aggregation of Media  N    N   N   N  N   N   N   Y  (Y)  Y   Y   N
   Full Session View     Y    Y   Y   Y  Y   Y   N   Y   Y  (Y)  N   Y
   Loop Detection        Y    Y   Y   Y  Y   Y   N   Y   Y  (Y)  N   N

   Please note that the Media Translator also includes the Transport
   Translator functionality.

6. Security Considerations

The use of mixers, SFMs, and translators has impact on security and the security functions used. The primary issue is that mixers, SFMs, and translators modify packets, thus preventing the use of integrity and source authentication, unless they are trusted devices that take part in the security context, e.g., the device can send Secure Real- time Transport Protocol (SRTP) and Secure Real-time Transport Control Protocol (SRTCP) [RFC3711] packets to endpoints in the Communication Session. If encryption is employed, the Media Translator, SFM, and mixer need to be able to decrypt the media to perform its function. A Transport Translator may be used without access to the encrypted payload in cases where it translates parts that are not included in the encryption and integrity protection, for example, IP address and UDP port numbers in a media stream using SRTP [RFC3711]. However, in general, the translator, SFM, or mixer needs to be part of the signaling context and get the necessary security associations (e.g., SRTP crypto contexts) established with its RTP session participants. Including the mixer, SFM, and translator in the security context allows the entity, if subverted or misbehaving, to perform a number of very serious attacks as it has full access. It can perform all the attacks possible (see RFC 3550 and any applicable profiles) as if the media session were not protected at all, while giving the impression to the human session participants that they are protected. Transport Translators have no interactions with cryptography that work above the transport layer, such as SRTP, since that sort of translator leaves the RTP header and payload unaltered. Media Translators, on the other hand, have strong interactions with cryptography, since they alter the RTP payload. A Media Translator in a session that uses cryptographic protection needs to perform cryptographic processing to both inbound and outbound packets.
Top   ToC   RFC7667 - Page 44
   A Media Translator may need to use different cryptographic keys for
   the inbound and outbound processing.  For SRTP, different keys are
   required, because an RFC 3550 Media Translator leaves the SSRC
   unchanged during its packet processing, and SRTP key sharing is only
   allowed when distinct SSRCs can be used to protect distinct packet
   streams.

   When the Media Translator uses different keys to process inbound and
   outbound packets, each session participant needs to be provided with
   the appropriate key, depending on whether they are listening to the
   translator or the original source.  (Note that there is an
   architectural difference between RTP media translation, in which
   participants can rely on the RTP payload type field of a packet to
   determine appropriate processing, and cryptographically protected
   media translation, in which participants must use information that is
   not carried in the packet.)

   When using security mechanisms with translators, SFMs, and mixers, it
   is possible that the translator, SFM, or mixer could create different
   security associations for the different domains they are working in.
   Doing so has some implications:

   First, it might weaken security if the mixer/translator accepts a
   weaker algorithm or key in one domain rather than in another.
   Therefore, care should be taken that appropriately strong security
   parameters are negotiated in all domains.  In many cases,
   "appropriate" translates to "similar" strength.  If a key-management
   system does allow the negotiation of security parameters resulting in
   a different strength of the security, then this system should notify
   the participants in the other domains about this.

   Second, the number of crypto contexts (keys and security-related
   state) needed (for example, in SRTP [RFC3711]) may vary between
   mixers, SFMs, and translators.  A mixer normally needs to represent
   only a single SSRC per domain and therefore needs to create only one
   security association (SRTP crypto context) per domain.  In contrast,
   a translator needs one security association per participant it
   translates towards, in the opposite domain.  Considering Figure 11,
   the translator needs two security associations towards the multicast
   domain: one for B and one for D.  It may be forced to maintain a set
   of totally independent security associations between itself and B and
   D, respectively, so as to avoid two-time pad occurrences.  These
   contexts must also be capable of handling all the sources present in
   the other domains.  Hence, using completely independent security
   associations (for certain keying mechanisms) may force a translator
   to handle N*DM keys and related state, where N is the total number of
   SSRCs used over all domains and DM is the total number of domains.
Top   ToC   RFC7667 - Page 45
   The ASM, SSM, Relay, and Mesh (with common RTP session) topologies
   each have multiple endpoints that require shared knowledge about the
   different crypto contexts for the endpoints.  These multiparty
   topologies have special requirements on the key management as well as
   the security functions.  Specifically, source authentication in these
   environments has special requirements.

   There exist a number of different mechanisms to provide keys to the
   different participants.  One example is the choice between group keys
   and unique keys per SSRC.  The appropriate keying model is impacted
   by the topologies one intends to use.  The final security properties
   are dependent on both the topologies in use and the keying
   mechanisms' properties and need to be considered by the application.
   Exactly which mechanisms are used is outside of the scope of this
   document.  Please review RTP Security Options [RFC7201] to get a
   better understanding of most of the available options.

7. References

7.1. Normative References

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>. [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.

7.2. Informative References

[MULTI-STREAM-OPT] Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback", Work in Progress, draft-ietf-avtcore-rtp-multi-stream- optimisation-08, October 2015.
Top   ToC   RFC7667 - Page 46
   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, DOI 10.17487/RFC1112, August 1989,
              <http://www.rfc-editor.org/info/rfc1112>.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              DOI 10.17487/RFC3022, January 2001,
              <http://www.rfc-editor.org/info/rfc3022>.

   [RFC3569]  Bhattacharyya, S., Ed., "An Overview of Source-Specific
              Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July
              2003, <http://www.rfc-editor.org/info/rfc3569>.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, DOI 10.17487/RFC3711, March 2004,
              <http://www.rfc-editor.org/info/rfc3711>.

   [RFC4575]  Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A
              Session Initiation Protocol (SIP) Event Package for
              Conference State", RFC 4575, DOI 10.17487/RFC4575, August
              2006, <http://www.rfc-editor.org/info/rfc4575>.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
              <http://www.rfc-editor.org/info/rfc4607>.

   [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
              "Codec Control Messages in the RTP Audio-Visual Profile
              with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
              February 2008, <http://www.rfc-editor.org/info/rfc5104>.

   [RFC5117]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
              DOI 10.17487/RFC5117, January 2008,
              <http://www.rfc-editor.org/info/rfc5117>.

   [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
              Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
              2008, <http://www.rfc-editor.org/info/rfc5285>.

   [RFC5760]  Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
              Protocol (RTCP) Extensions for Single-Source Multicast
              Sessions with Unicast Feedback", RFC 5760,
              DOI 10.17487/RFC5760, February 2010,
              <http://www.rfc-editor.org/info/rfc5760>.
Top   ToC   RFC7667 - Page 47
   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766,
              DOI 10.17487/RFC5766, April 2010,
              <http://www.rfc-editor.org/info/rfc5766>.

   [RFC6285]  Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,
              "Unicast-Based Rapid Acquisition of Multicast RTP
              Sessions", RFC 6285, DOI 10.17487/RFC6285, June 2011,
              <http://www.rfc-editor.org/info/rfc6285>.

   [RFC6465]  Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-
              time Transport Protocol (RTP) Header Extension for Mixer-
              to-Client Audio Level Indication", RFC 6465,
              DOI 10.17487/RFC6465, December 2011,
              <http://www.rfc-editor.org/info/rfc6465>.

   [RFC7201]  Westerlund, M. and C. Perkins, "Options for Securing RTP
              Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
              <http://www.rfc-editor.org/info/rfc7201>.

   [RTCP-SDES]
              Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP
              Header Extension for RTCP Source Description Items", Work
              in Progress, draft-ietf-avtext-sdes-hdr-ext-02, July 2015.

   [SDP-BUNDLE]
              Holmberg, C., Alvestrand, H., and C. Jennings,
              "Negotiating Media Multiplexing Using the Session
              Description Protocol (SDP)", Work in Progress,
              draft-ietf-mmusic-sdp-bundle-negotiation-23, July 2015.
Top   ToC   RFC7667 - Page 48

Acknowledgements

The authors would like to thank Mark Baugher, Bo Burman, Ben Campbell, Umesh Chandra, Alex Eleftheriadis, Roni Even, Ladan Gharai, Geoff Hunt, Suresh Krishnan, Keith Lantz, Jonathan Lennox, Scarlet Liuyan, Suhas Nandakumar, Colin Perkins, and Dan Wing for their help in reviewing and improving this document.

Authors' Addresses

Magnus Westerlund Ericsson Farogatan 2 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Stephan Wenger Vidyo 433 Hackensack Ave Hackensack, NJ 07601 United States Email: stewe@stewe.org