draft-ietf-straw-b2bua-rtcp-17.txt   rfc8079.txt 
STRAW Working Group L. Miniero Internet Engineering Task Force (IETF) L. Miniero
Internet-Draft Meetecho Request for Comments: 8079 Meetecho
Intended status: Standards Track S. Garcia Murillo Category: Standards Track S. Garcia Murillo
Expires: June 25, 2017 Medooze ISSN: 2070-1721 Medooze
V. Pascual V. Pascual
Oracle Oracle
December 22, 2016 February 2017
Guidelines to support RTCP end-to-end in Back-to-Back User Agents Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in
(B2BUAs) Back-to-Back User Agents (B2BUAs)
draft-ietf-straw-b2bua-rtcp-17
Abstract Abstract
SIP Back-to-Back User Agents (B2BUAs) are often designed to also be SIP Back-to-Back User Agents (B2BUAs) are often designed to also be
on the media path, rather than just intercepting signalling. This on the media path, rather than just to intercept signalling. This
means that B2BUAs often implement an RTP/RTCP stack as well, thus means that B2BUAs often implement an RTP or RTP Control Protocol
leading to separate multimedia sessions that the B2BUA correlates and (RTCP) stack as well, thus leading to separate multimedia sessions
bridges together. If not disciplined, though, this behaviour can that the B2BUA correlates and bridges together. If not disciplined,
severely impact the communication experience, especially when this behaviour can severely impact the communication experience,
statistics and feedback information contained in RTCP messages get especially when statistics and feedback information contained in RTCP
lost because of mismatches in the reported data. messages get lost because of mismatches in the reported data.
This document defines the proper behaviour B2BUAs should follow when This document defines the proper behaviour B2BUAs should follow when
also acting on the signalling/media plane in order to preserve the acting on both the signalling plane and media plane in order to
end-to-end functionality of RTCP. preserve the end-to-end functionality of RTCP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on June 25, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8079.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Signalling/Media Plane B2BUAs . . . . . . . . . . . . . . . . 4 3. Signalling/Media Plane B2BUAs . . . . . . . . . . . . . . . . 4
3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Media-aware Relay . . . . . . . . . . . . . . . . . . . . 6 3.2. Media-Aware Relay . . . . . . . . . . . . . . . . . . . . 6
3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 11 3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Informative References . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Session Initiation Protocol [RFC3261] Back-to-Back User Agents Session Initiation Protocol (SIP) [RFC3261] Back-to-Back User Agents
(B2BUAs) are SIP entities that can act as a logical combination of (B2BUAs) are SIP entities that can act as a logical combination of
both a User Agent Server (UAS) and a User Agent Client (UAC). As both a User Agent Server (UAS) and a User Agent Client (UAC). As
such, their behaviour is not always completely adherent to the such, their behaviour is not always completely adherent to standards
standards, and can lead to unexpected situations. [RFC7092] presents and can lead to unexpected situations. [RFC7092] presents a taxonomy
a taxonomy of the most commonly deployed B2BUA implementations, of the most commonly deployed B2BUA implementations and describes how
describing how they differ in terms of the functionality and features they differ in terms of the functionality and features they provide.
they provide.
Such components often do not only act on the signalling plane, that Such components often do not only act on the signalling plane
is intercepting and possibly modifying SIP messages, but also on the (intercepting and possibly modifying SIP messages), but also on the
media plane. This means that, in order to receive and manage all RTP media plane. This means that, in order to receive and manage all RTP
and RTCP [RFC3550] packets in a session, these components also and RTCP [RFC3550] packets in a session, these components also
manipulate the session descriptions [RFC4566] in the related offer/ manipulate the session descriptions [RFC4566] in the related offer/
answer exchanges [RFC3264]. The reasons for such a behaviour can be answer exchanges [RFC3264]. The reasons for such behaviour can be
different. The B2BUA may want, for instance, to provide transcoding different. The B2BUA may want, for instance, to provide transcoding
functionality for participants with incompatible codecs, or it may functionality for participants with incompatible codecs, or it may
need the traffic to be directly handled for different reasons. This need the traffic to be directly handled for different reasons. This
can lead to several different topologies for RTP-based communication, can lead to several different topologies for RTP-based communication,
as documented in [RFC7667]. as documented in [RFC7667].
Whatever the reason, such a behaviour does not come without a cost. Whatever the reason, such behaviour does not come without a cost. In
In fact, whenever a media-aware component is placed on the path fact, whenever a media-aware component is placed on the path between
between two or more participants that want to communicate by means of two or more participants that want to communicate by means of RTP/
RTP/RTCP, the end-to-end nature of such protocols is broken. While RTCP, the end-to-end nature of such protocols is broken. While this
this may not be a problem for RTP packets, which can be quite easily may not be a problem for RTP packets, which can be quite easily
relayed, it definitely can cause serious issue for RTCP messages, relayed, it definitely can cause serious issue for RTCP messages,
which carry important information and feedback on the communication which carry important information and feedback on the communication
quality the participants are experiencing. Consider, for instance, quality the participants are experiencing. Consider, for instance,
the simple scenario only involving two participants and a single RTP the simple scenario only involving two participants and a single RTP
session depicted in Figure 1: session depicted in Figure 1:
+--------+ +---------+ +---------+ +--------+ +---------+ +---------+
| |=== SSRC1 ===>| |=== SSRC3 ===>| | | |=== SSRC1 ===>| |=== SSRC3 ===>| |
| Alice | | B2BUA | | Bob | | Alice | | B2BUA | | Bob |
| |<=== SSRC2 ===| |<=== SSRC4 ===| | | |<=== SSRC2 ===| |<=== SSRC4 ===| |
+--------+ +---------+ +---------+ +--------+ +---------+ +---------+
Figure 1: B2BUA modifying RTP headers Figure 1: B2BUA Modifying RTP Headers
In this common scenario, a participant (Alice) is communicating with In this common scenario, a participant (Alice) is communicating with
another participant (Bob) as a result of a signalling session managed another participant (Bob) as a result of a signalling session managed
by a B2BUA: this B2BUA is also on the media path between the two, and by a B2BUA: this B2BUA is also on the media path between the two and
is acting as a media relay. This means that two separate RTP is acting as a Media Relay. This means that two separate RTP
sessions are involved (one per side), each carrying two RTP streams sessions are involved (one per side), each carrying two RTP streams
(one per media direction). As part of this process, though, the (one per media direction). As part of this process, the B2BUA is
B2BUA is also rewriting some of the RTP header information on the also rewriting some of the RTP header information on the way. In
way. In this example, just the SSRC of the incoming RTP streams is this example, just the Synchronization Source (SSRC) of the incoming
changed, but more information may be modified as well (e.g., sequence RTP streams is changed, but more information may be modified as well
numbers, timestamps, etc.). In particular, whenever Alice sends an (e.g., sequence numbers, timestamps, etc.). In particular, whenever
RTP packet, she sets her SSRC (SSRC1) in the RTP header of her RTP Alice sends an RTP packet, she sets her SSRC (SSRC1) in the RTP
source stream. The B2BUA rewrites the SSRC (SSRC3) before relaying header of her RTP source stream. The B2BUA rewrites the SSRC (SSRC3)
the packet to Bob. At the same time, RTP packets sent by Bob (SSRC4) before relaying the packet to Bob. At the same time, RTP packets
get their SSRC rewritten as well (SSRC2) before being relayed to sent by Bob (SSRC4) get their SSRC rewritten as well (SSRC2) before
Alice. being relayed to Alice.
Assuming now that Alice needs to inform Bob she has lost several Assuming now that Alice needs to inform Bob that she has lost several
packets in the last few seconds, she will place the related received packets in the last few seconds, she will place the related received
RTP stream SSRC she is aware of (SSRC2), together with her own RTP stream SSRC she is aware of (SSRC2) together with her own (SSRC1)
(SSRC1), in RTCP Reports and/or NACKs. Since the B2BUA is making use in RTCP Reports and/or NACKs. Since the B2BUA is making use of
of different SSRCs for the RTP streams in the RTP session it different SSRCs for the RTP streams in the RTP session it established
established with each participant, blindly relaying Alice's incoming with each participant, blindly relaying Alice's incoming RTCP
RTCP messages to Bob would cause issues. These RTCP messages would messages to Bob would cause issues. These RTCP messages would
reference SSRCs Bob doesn't know about, which would result in reference SSRCs Bob doesn't know about, which would result in
precious feedback being dropped. In fact, Bob is only aware of SSRCs precious feedback being dropped. In fact, Bob is only aware of SSRC4
SSRC4 (the one his source RTP stream uses) and SSRC3 (the one he's (the one his source RTP stream uses) and SSRC3 (the one he's
receiving from the B2BUA in the received RTP stream), and knows receiving from the B2BUA in the received RTP stream) and knows
nothing about SSRCs SSRC1 and SSRC2 in the messages he received nothing about SSRC1 and SSRC2 in the messages he received instead.
instead. Considering the feedback being dropped because of this may Considering the feedback being dropped because of this may contain
contain precious information, e.g., related to packet loss, precious information (e.g., related to packet loss, congestion, and
congestion, and other network issues or considerations, the inability other network issues or considerations), the inability to take them
to take them into account may lead to severe issues. For instance, into account may lead to severe issues. For instance, Bob may flood
Bob may flood Alice with more media packets she can handle, and/or Alice with more media packets she can handle and/or not retransmit
not retransmit Alice the packets she missed and asked for. This may the packets she missed and asked for. This may easily lead to a very
easily lead to a very bad communication experience, if not eventually bad communication experience, if not eventually to an unwanted
to an unwanted termination of the communication itself. termination of the communication itself.
This is just a trivial example that, together with additional This is just a trivial example that, together with additional
scenarios, will be addressed in the following sections. scenarios, will be addressed in the following sections.
Nevertheless, it is a valid example of how such a simple mishandling Nevertheless, it is a valid example of how such a simple mishandling
of precious information may lead to serious consequences. This is of precious information may lead to serious consequences. This is
especially true if we picture more complex scenarios involving especially true if we picture more complex scenarios involving
several participants at the same time, multiple RTP sessions (e.g., a several participants at the same time, multiple RTP sessions (e.g., a
video stream along audio) rather than a single one, redundancy RTP video stream along audio) rather than a single one, redundancy RTP
streams, SSRC multiplexing and so on. Considering how common B2BUA streams, SSRC multiplexing, and so on. Considering how common B2BUA
deployments are, it is very important for them to properly address deployments are, it is very important for them to properly address
RTCP messages, in order to be sure that their activities on the media RTCP messages in order to be sure that their activities on the media
plane do not break or interfere with anything relevant to the plane do not break or interfere with anything relevant to the
session. session.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Besides, this document addresses, where relevant, the RTP-related In addition, this document uses, where relevant, the RTP-related
terminology as disciplined in [RFC7656]. terminology defined in [RFC7656].
3. Signalling/Media Plane B2BUAs 3. Signalling/Media Plane B2BUAs
As described in the introductory section, it's very common for B2BUA As described in the Introduction (Section 1), it's very common for
deployments to also act on the media plane, rather than just B2BUA deployments to act on the media plane rather than just on the
signalling alone. In particular, [RFC7092] describes three different signalling plane alone. In particular, [RFC7092] describes three
categories of such B2BUAs: a B2BUA, in fact, may act as a simple different categories of such B2BUAs: (1) a simple Media Relay that is
media relay (1), effectively unaware of anything that is transported; effectively unaware of anything that is transported; (2) a Media-
it may be a media-aware relay (2), also inspecting and/or modifying aware Relay that inspects and/or modifies RTP and RTCP messages as
RTP and RTCP messages as they flow by; or it may be a full-fledged they flow by; and (3) a full-fledged media termination entity that
media termination entity (3), terminating and generating RTP and RTCP terminates and generates RTP and RTCP messages as needed.
messages as needed.
[RFC3550] and [RFC7667] already mandate some specific behaviours in [RFC3550] and [RFC7667] already mandate some specific behaviours in
the presence of certain topologies. Anyway, due to their mixed the presence of certain topologies. However, due to their mixed
nature B2BUAs sometimes can't or won't implement all relevant nature, B2BUAs sometimes can't or won't implement all relevant
specifications. This means that it's not rare to encounter issues specifications. This means that it's not rare to encounter issues
that may be avoided with a more disciplined behaviour in that regard, that may be avoided with more disciplined behaviour in that regard,
that is if the B2BUAs followed at least a set of guidelines to ensure that is, if the B2BUAs followed at least a set of guidelines to
no known problems occur. For this reason, the following subsections ensure no known problems occur. For this reason, the following
will describe the proper behaviour B2BUAs, whatever above category subsections describe the proper behaviour that B2BUAs, whatever above
they fall in, should follow in order not to impact any end-to-end category they fall in, should follow in order not to impact any end-
RTCP effectiveness. to-end RTCP effectiveness.
3.1. Media Relay 3.1. Media Relay
A media relay, as identified in [RFC7092], simply forwards all RTP A Media Relay, as identified in [RFC7092], simply forwards all RTP
and RTCP messages it receives, without either inspecting or modifying and RTCP messages it receives without either inspecting or modifying
them. Using the RTP Topologies terminology, this can be seen as a them. Using the terminology in "RTP Topologies" [RFC7667], this can
RTP Transport Translator. As such, B2BUA acting as media relays are be seen as an RTP Transport Translator. As such, B2BUAs acting as
not aware of what traffic they're handling. This means that both Media Relays are not aware of what traffic they're handling. This
packet payloads and packet headers are opaque to them. Many Session means that both packet payloads and packet headers are opaque to
Border Controllers (SBC) implement this kind of behaviour, e.g., when them. Many Session Border Controllers (SBCs) implement this kind of
acting as a bridge between an inner and outer network. behaviour, e.g., when acting as a bridge between an inner and outer
network.
Considering all headers and identifiers in both RTP and RTCP are left Considering that all headers and identifiers in both RTP and RTCP are
untouched, issues like the SSRC mismatch described in the previous left untouched, issues like the SSRC mismatch described in the
section would not occur. Similar problems could still happen, previous section would not occur. However, similar problems could
though, for different reasons, as for instance if the session still happen for different reasons, for instance, if the session
description prepared by the B2BUA, whether it has been modified or description prepared by the B2BUA, whether it has been modified or
not, ends up providing incorrect information. This may happen, for not, ends up providing incorrect information. This may happen, for
example, if the SDP on either side contains 'ssrc' [RFC5576] example, if the Session Description Protocol (SDP) on either side
attributes that don't match the actual SSRC being advertized on the contains 'ssrc' [RFC5576] attributes that don't match the actual SSRC
media plane, or when the B2BUA advertized support for NACK because it being advertised on the media plane or if the B2BUA advertised
implements it, while the original INVITE didn't. Such issues might support for NACK because it implements it while the original INVITE
occur, for instance, when the B2BUA acting as a media relay is didn't. Such issues might occur, for instance, when the B2BUA acting
generating a new session description when bridging an incoming call, as a Media Relay is generating a new session description when
rather than using the original session description. This may cause bridging an incoming call rather than using the original session
participants to find a mismatch between the SSRCs advertized in the description. This may cause participants to find a mismatch between
SDP and the ones actually observed in RTP and RTCP messages, or to the SSRCs advertised in the SDP and the ones actually observed in RTP
have them either ignore or generate RTCP feedback packets that were and RTCP messages or to have them either ignore or generate RTCP
not explicitly advertized as supported. feedback packets that were not explicitly advertised as supported.
In order to prevent such an issue, a media-relay B2BUA SHOULD forward In order to prevent such an issue, a Media Relay B2BUA SHOULD forward
all the SSRC- and RTCP-related SDP attributes when handling a all the SSRC- and RTCP-related SDP attributes when handling a
multimedia session setup between participants: this includes multimedia session setup between participants: this includes
attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr- attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr-
attrib' [RFC3611] and others. However, certain SDP attributes may attrib' [RFC3611], and others. However, certain SDP attributes may
lead to call failures when forwarded by a media relay, as they have lead to call failures when forwarded by a Media Relay, as they have
an implied assumption that the attribute describes the immediate an implied assumption that the attribute describes the immediate
peer. A clear example of this is the 'rtcp' [RFC3605] attribute, peer. A clear example of this is the 'rtcp' [RFC3605] attribute,
which describes the expected RTCP peer port. Other attributes might which describes the expected RTCP peer port. Other attributes might
include the immediate peer's IP address, preferred transport, etc. include the immediate peer's IP address, preferred transport, etc.
In general, the guideline is to require rewriting of attributes that In general, the guideline is to require rewriting of attributes that
are implicitly describing the immediate peer. B2BUAs SHOULD forward are implicitly describing the immediate peer. B2BUAs SHOULD forward
all other SDP attributes in order to avoid breaking additional all other SDP attributes in order to avoid breaking additional
functionality endpoints may be relying on. If implementors have functionality that endpoints may be relying on. If implementors have
doubts about whether this guidance applies to a specific attribute, doubts about whether this guidance applies to a specific attribute,
they should test to determine if call failures occur. they should test to determine if call failures occur.
The cited 'rtcp' example is also relevant whenever RTP/RTCP The cited 'rtcp' example is also relevant whenever RTP/RTCP
multiplexing [RFC5761] support is being negotiated. If the B2BUA multiplexing [RFC5761] support is being negotiated. If the B2BUA
acting as a Media Relay is unaware of the specifics of the traffic it acting as a Media Relay is unaware of the specifics of the traffic it
is handling, and as such may not have RTP/RTCP parsing capabilities, is handling, and as such may not have RTP/RTCP parsing capabilities,
it SHOULD reject RTP/RTCP multiplexing by removing the 'rtcp-mux' SDP it SHOULD reject RTP/RTCP multiplexing by removing the 'rtcp-mux' SDP
attribute. If instead the Media Relay is able to parse RTP/RTCP, and attribute. If instead the Media Relay is able to parse RTP/RTCP, and
can verify that demultiplexing can be performed without any RTP can verify that demultiplexing can be performed without any RTP
Payload Type rewrites (i.e., no overlap between any RTP Payload Types Payload Type rewrites (i.e., no overlap between any RTP Payload Types
and the RTCP Payload Type space has been detected), then the B2BUA and the RTCP Payload Type space has been detected), then the B2BUA
SHOULD negotiate RTP/RTCP multiplexing support if advertized. SHOULD negotiate RTP/RTCP multiplexing support if advertised.
It is worth mentioning that, leaving RTCP messages untouched, a media It is worth mentioning that, by leaving RTCP messages untouched, a
relay may also leak information that, according to policies, may need Media Relay may also leak information that, according to policies,
to be hidden or masqueraded, e.g., domain names in CNAME items. may need to be hidden or masqueraded, e.g., domain names in CNAME
Besides, these CNAME items may actually contain IP addresses: this items. Besides, these CNAME items may actually contain IP addresses:
means that, should a NAT be involved in the communication, this may this means that, should a NAT be involved in the communication, this
actually result in CNAME collisions, which could indeed break the may actually result in CNAME collisions, which could indeed break the
end-to-end RTCP behaviour. While [RFC7022] can prevent this from end-to-end RTCP behaviour. While [RFC7022] can prevent this from
happening, there may be implementations that don't make use of it. happening, there may be implementations that don't make use of it.
As such, a B2BUA MAY rewrite CNAME items if any potential collision As such, a B2BUA MAY rewrite CNAME items if any potential collision
is detected, even in the Media Relay case. If a B2BUA does indeed is detected, even in the Media Relay case. If a B2BUA does indeed
decide to rewrite CNAME items, though, then it MUST generate new decide to rewrite CNAME items, then it MUST generate new CNAMEs
CNAMEs following [RFC7022]. The same SHOULD be done in case RTP following [RFC7022]. The same SHOULD be done if RTP extensions
extensions involving CNAMEs are involved (e.g., "urn:ietf:params:rtp- involving CNAMEs are involved (e.g., "urn:ietf:params:rtp-
hdrext:sdes:cname", [RFC7941]). If that is not possible, e.g., hdrext:sdes:cname" [RFC7941]). If that is not possible, e.g.,
because the Media Relay does not have RTP header editing capabilities because the Media Relay does not have RTP header editing capabilities
or does not support these extensions, then the B2BUA MUST reject the or does not support these extensions, then the B2BUA MUST reject the
negotiation of such extensions when negotiating the session. negotiation of such extensions when negotiating the session.
3.2. Media-aware Relay 3.2. Media-Aware Relay
A Media-aware relay, unlike the the Media Relay addressed in the A Media-aware Relay, unlike the Media Relay addressed in the previous
previous section, is aware of the media traffic it is handling. This section, is aware of the media traffic it is handling. This means it
means it inspects RTP and RTCP messages flowing by, and may even inspects RTP and RTCP messages flowing by and may even modify their
modify their headers. Using the RFC3550 terminology, this can be headers. Using the terminology in [RFC3550], this can be seen as an
seen as a RTP Translator. A B2BUA implementing this role, though, RTP Translator. A B2BUA implementing this role typically does not
typically does not inspect the RTP payloads, which would be opaque to inspect the RTP payloads, which would be opaque to them: this means
them: this means that the actual media would not be manipulated (e.g, that the actual media would not be manipulated (e.g., transcoded).
transcoded).
This makes them quite different from the Media Relay previously This makes them quite different from the Media Relays previously
discussed, especially in terms of the potential issues that may occur discussed, especially in terms of the potential issues that may occur
at the RTCP level. In fact, being able to modify the RTP and RTCP at the RTCP level. In fact, being able to modify the RTP and RTCP
headers, such B2BUAs may end up modifying RTP related information headers, such B2BUAs may end up modifying RTP-related information
like SSRC/CSRC, sequence numbers, timestamps and others in an RTP like SSRC / Contributing Source (CSRC), sequence numbers, timestamps,
stream, before forwarding the modified packets to the other and others in an RTP stream before forwarding the modified packets to
interested participants. This means that, if not properly the other interested participants. This means that, if not properly
disciplined, such a behaviour may easily lead to issues like the one disciplined, such behaviour may easily lead to issues like the one
described in the introductory section. For this reason, it is very described in the introductory section. For this reason, it is very
important for a B2BUA modifying RTP-related information across two important for a B2BUA modifying RTP-related information across two
related RTP streams to also modify, in a coherent way, the same related RTP streams to also modify, in a coherent way, the same
information in RTCP messages. information in RTCP messages.
It is worthwile to point out that such a B2BUA may not necessarily It is worthwhile to point out that such a B2BUA may not necessarily
forward all the packets it receives, though. Selective Forwarding forward all the packets it receives. Selective Forwarding Units
Units (SFU) [RFC7667], for instance, may be implemented to aggregate (SFUs) [RFC7667], for instance, may be implemented to aggregate or
or drop incoming RTCP messages, while at the same time originating drop incoming RTCP messages while at the same time originating new
new ones on their own. It is important to clarify that a B2BUA ones on their own. It is important to clarify that a B2BUA SHOULD
SHOULD NOT randomly drop or forward RTCP feedback of the same type NOT randomly drop or forward RTCP feedback of the same type (e.g., a
(e.g., a specific XR block type, or specific Feedback messages) specific XR block type or specific Feedback messages) within the
within the context of the same session, as that may lead to context of the same session as that may lead to confusing, if not
confusing, if not broken, feedback to the recipients of the message broken, feedback to the recipients of the message due to gaps in the
due to gaps in the communication. As to the messages that are communication. As to the messages that are forwarded and/or
forwarded and/or aggregated, though, it's important to make sure the aggregated, it's important to make sure the information is coherent.
information is coherent.
Besides the behaviour already mandated for RTCP translators in Besides the behaviour already mandated for RTCP translators in
Section 7.2 of [RFC3550], a media-aware B2BUA MUST handle incoming Section 7.2 of [RFC3550], a media-aware B2BUA MUST handle incoming
RTCP messages to forward following this guideline: RTCP messages to forward following these guidelines:
SR: [RFC3550] Sender Report (SR) [RFC3550]:
If the B2BUA has changed the SSRC of the sender RTP stream a If the B2BUA has changed the SSRC of the sender RTP stream a
Sender Report refers to, it MUST update the SSRC in the SR packet Sender Report refers to, it MUST update the SSRC in the SR packet
header as well. If the B2BUA has changed the SSRCs of other RTP header as well. If the B2BUA has changed the SSRCs of other RTP
streams too, and any of these streams are addressed in any of the streams too, and any of these streams are addressed in any of the
SR report blocks, it MUST update the related values in the SR SR Report Blocks, it MUST update the related values in the SR
report blocks as well. If the B2BUA has also changed the base RTP Report Blocks as well. If the B2BUA has also changed the base RTP
sequence number when forwarding RTP packets, then this change MUST sequence number when forwarding RTP packets, then this change MUST
be reflected in the 'extended highest sequence number received' be reflected in the 'extended highest sequence number received'
field in the Report Blocks. In case the B2BUA is acting as a field in the Report Blocks. In case the B2BUA is acting as a
Selective Forwarding Units (SFU) [RFC7667], it needs to track in Selective Forwarding Unit (SFU) [RFC7667], it needs to track in
the outgoing SR the relevant number of packets sent and total the outgoing SR, the relevant number of packets sent, and the
amount of bytes sent to the receiver. total amount of bytes sent to the receiver.
RR: [RFC3550] Receiver Report (RR) [RFC3550]:
The same guidelines given for SR apply for RR as well. The guidelines for SR apply to RR as well.
SDES: [RFC3550] Source Description (SDES) [RFC3550]:
If the B2BUA has changed the SSRC of any RTP stream addressed in If the B2BUA has changed the SSRC of any RTP stream addressed in
any of the chunks of an incoming SDES message, it MUST update the any of the chunks of an incoming SDES message, it MUST update the
related SSRCs in all the chunks. The same considerations made related SSRCs in all the chunks. The same considerations made
with respect to CNAME collisions at the end of Section 3.1 apply with respect to CNAME collisions at the end of Section 3.1 apply
here as well. here as well.
BYE: [RFC3550] BYE [RFC3550]:
If the B2BUA has changed the SSRC of any RTP stream addressed in If the B2BUA has changed the SSRC of any RTP stream addressed in
the SSRC/CSRC identifiers included in a BYE packet, it MUST update the SSRC/CSRC identifiers included in a BYE packet, it MUST update
them in the message. them in the message.
APP: [RFC3550] APP [RFC3550]:
If the B2BUA has changed the SSRC of any RTP stream addressed in If the B2BUA has changed the SSRC of any RTP stream addressed in
the header of an APP packet, it MUST update the identifier in the the header of an APP packet, it MUST update the identifier in the
message. Should the B2BUA be aware of any specific APP message message. Should the B2BUA be aware of any specific APP message
format that contains additional information related to SSRCs, it format that contains additional information related to SSRCs, it
SHOULD update them as well accordingly. SHOULD update them accordingly as well.
Extended Reports (XR): [RFC3611] Extended Reports (XRs) [RFC3611]:
If the B2BUA has changed the SSRC of the RTP stream associated If the B2BUA has changed the SSRC of the RTP stream associated
with the originator of an XR packet, it MUST update the SSRC in with the originator of an XR packet, it MUST update the SSRC in
the XR message header. The same guidelines given for SR/RR, with the XR message header. The same guidelines given for SR/RR, with
respect to SSRC identifiers in report blocks, apply for all the respect to SSRC identifiers in Report Blocks, apply to all the
Report Block types in the XR message as well. If the B2BUA has Report Block types in the XR message as well. If the B2BUA has
also changed the base RTP sequence number when forwarding RTP also changed the base RTP sequence number when forwarding RTP
packets, then this change MUST be reflected in the 'begin_seq' and packets, then this change MUST be reflected in the 'begin_seq' and
'end_seq' fields that are available in most of the Report Block 'end_seq' fields that are available in most of the Report Block
types that are part of the XR specification. types that are part of the XR specification.
Receiver Summary Information (RSI): [RFC5760] Receiver Summary Information (RSI) [RFC5760]:
If the B2BUA has changed any SSRC of RTP streams addressed in a If the B2BUA has changed any SSRC of RTP streams addressed in an
RSI packet, it MUST update the SSRC identifiers in the message. RSI packet, it MUST update the SSRC identifiers in the message.
This includes the distribution source SSRC, which MUST be This includes the distribution source SSRC, which MUST be
rewritten with the one the B2BUA uses to send RTP packets to each rewritten with the one the B2BUA uses to send RTP packets to each
sender participant, the summarized SSRC and, when a Collision Sub- sender participant, the summarized SSRC, and when a Collision Sub-
Report Block is available, the SSRCs in the related list. Report Block is available, the SSRCs in the related list.
Port Mapping (TOKEN): [RFC6284] Port Mapping (TOKEN) [RFC6284]:
If the B2BUA has changed any SSRC of RTP streams addressed in a If the B2BUA has changed any SSRC of RTP streams addressed in a
TOKEN packet, it MUST update the SSRC identifiers in the message. TOKEN packet, it MUST update the SSRC identifiers in the message.
This includes the Packet Sender SSRC, which MUST be rewritten with This includes the Packet Sender SSRC, which MUST be rewritten with
the one the B2BUA uses to send RTP packets to each sender the one the B2BUA uses to send RTP packets to each sender
participant, and the Requesting Client SSRC when the message is a participant, and the Requesting Client SSRC when the message is a
response, which MUST be rewritten using the related sender response, which MUST be rewritten using the related sender
participant(s) SSRC. participant(s) SSRC.
Feedback messages: [RFC4585] Feedback Messages [RFC4585]:
All Feedback messages have a common packet format, which includes All Feedback messages have a common packet format, which includes
the SSRC identifier of the packet sender and the SSRC identifier the SSRC identifier of the Packet Sender and the SSRC identifier
of the media source the feedack is related to. Just as described of the media source the feedback is related to. Just as described
for the previous messages, these SSRC identifiers MUST be updated for the previous messages, these SSRC identifiers MUST be updated
in the message if the B2BUA has changed the SSRC of the RTP in the message if the B2BUA has changed the SSRC of the RTP
streams addressed there. It MUST NOT, though, change a media streams addressed there. It MUST NOT, however, change a media
source SSRC that was originally set to zero, unless zero is source SSRC that was originally set to zero, unless zero is
actually the SSRC that was chosen by one of the involved actually the SSRC that was chosen by one of the involved
endpoints, in which case the above mentioned rules as to SSRC endpoints, in which case the above-mentioned rules as to SSRC
rewriting apply. Considering that many feedback messages also rewriting apply. Considering that many Feedback messages also
include additional data as part of their specific Feedback Control include additional data as part of their specific Feedback Control
Information (FCI), a media-aware B2BUA MUST take care of them Information (FCI), a media-aware B2BUA MUST take care of them
accordingly, if it can parse and regenerate them, according to the accordingly, if it can parse and regenerate them, according to the
following guidelines: following guidelines:
NACK: [RFC4585] NACK [RFC4585]:
A media-aware B2BUA MUST properly rewrite the Packet ID (PID) A media-aware B2BUA MUST properly rewrite the Packet ID (PID)
of all addressed lost packets in the NACK FCI if it changed the of all addressed lost packets in the NACK FCI if it changed the
RTP sequence numbers. RTP sequence numbers.
TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM: [RFC5104] TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM [RFC5104]:
A media-aware B2BUA MUST properly rewrite the additional SSRC A media-aware B2BUA MUST properly rewrite the additional SSRC
identifier in the specific FCI, if it changed the related RTP identifier in the specific FCI if it changed the related RTP
SSRC of the media sender. SSRC of the media sender.
REMB: [I-D.alvestrand-rmcat-remb] Receiver Estimated Max Bitrate (REMB) [RTCP-REMB]:
This draft describes an RTCP Payload-Specific feedback message [RTCP-REMB] describes an RTCP payload-specific Feedback message
that reports the receiver's available bandwidth to the the that reports the receiver's available bandwidth to the sender.
sender. As of the time of this writing, REMB has been widely As of the time of this writing, REMB has been widely deployed
deployed, but has not been standardized. The REMB mechanism but has not been standardized. The REMB mechanism will not
will not function correctly across a media-aware B2BUA that function correctly across a media-aware B2BUA that changes the
changes the SSRC of the media sender unless it also changes the SSRC of the media sender unless it also changes the SSRC values
SSRC values in the REMB packet. in the REMB packet.
Explicit Congestion Notification (ECN): [RFC6679] Explicit Congestion Notification (ECN) [RFC6679]:
The same guidelines given for SR/RR management apply, The same guidelines given for SR/RR management apply,
considering the presence of sequence numbers in the ECN considering the presence of sequence numbers in the ECN
Feedback Report format. For what concerns the management of Feedback Report format. For the management of RTCP XR ECN
RTCP XR ECN Summary Report messages, the same guidelines given Summary Report messages, the same guidelines given for generic
for generic XR messages apply. XR messages apply.
Apart from the generic guidelines related to Feedback messages, no Apart from the generic guidelines related to Feedback messages, no
additional modifications are needed for PLI, SLI and RPSI feedback additional modifications are needed for Picture Loss Indication
messages. (PLI), Slice Lost Indication (SLI), and Reference Picture Selection
Indication (RPSI) Feedback messages.
Of course, the same considerations about the need for SDP and RTP/ Of course, the same considerations about the need for SDP and RTP/
RTCP information to be coherent applies to media-aware B2BUAs. This RTCP information to be coherent applies to media-aware B2BUAs. This
means that, if a B2BUA changes any SSRC, it MUST update the related means that, if a B2BUA changes any SSRC, it MUST update the related
'ssrc' attributes, if present, before sending it to the recipient. 'ssrc' attributes, if present, before sending it to the recipient.
Besides, it MUST rewrite the 'rtcp' attribute if provided. At the Besides, it MUST rewrite the 'rtcp' attribute if provided. At the
same time, while a media-aware B2BUA is typically able to inspect/ same time, while a media-aware B2BUA is typically able to inspect/
modify RTCP messages, it may not support all RTCP messages. This modify RTCP messages, it may not support all RTCP messages. This
means that a B2BUA may choose to drop RTCP messages it can't parse. means that a B2BUA may choose to drop RTCP messages it can't parse.
In that case, a media-aware B2BUA MUST advertize its RTCP level of In that case, a media-aware B2BUA MUST advertise its RTCP level of
support in the SDP in a coherent way, in order to prevent, for support in the SDP in a coherent way in order to prevent, for
instance, a UAC to from sending NACK messages that would never reach instance, a UAC from sending NACK messages that would never reach the
the intended recipients. It's important to point out that, in case a intended recipients. It's important to point out that, in case a
compound RTCP packet was received and any RTCP message in it needs to compound RTCP packet was received and any RTCP message in it needs to
be dropped, then the B2BUA SHOULD NOT drop the whole compound RTCP be dropped, then the B2BUA SHOULD NOT drop the whole compound RTCP
packet, but only the selected messages. packet, but only the selected messages.
The same considerations on CNAMEs made when talking of Media Relays The same considerations on CNAMEs made in regard to Media Relays
apply for Media-aware Relays as well. Specifically, if RTP apply to Media-aware Relays as well. Specifically, if RTP extensions
extensions involving CNAMEs are involved (e.g., "urn:ietf:params:rtp- involving CNAMEs are involved (e.g., "urn:ietf:params:rtp-
hdrext:sdes:cname", [RFC7941]) and negotiated because the B2BUA hdrext:sdes:cname" [RFC7941]) and negotiated because the B2BUA
supports them, then the B2BUA MUST update the CNAME value in there as supports them, then the B2BUA MUST update the CNAME value in there as
well, if it was changed. It is worth pointing out that, if the new well, if it was changed. It is worth pointing out that, if the new
CNAME is larger than the old one, this would result in a larger RTP CNAME is larger than the old one, this would result in a larger RTP
packet than originally received. If the length of the updated packet packet than originally received. If the length of the updated packet
exceeds the MTU of any of the networks the packet will traverse, this exceeds the MTU of any of the networks the packet will traverse, this
can result in the packet being dropped and lost by the recipient. can result in the packet being dropped and lost by the recipient.
A different set of considerations is worthwhile for what concerns A different set of considerations is worthwhile for RTP/RTCP
RTP/RTCP multiplexing [RFC5761] and Reduced-Size RTCP [RFC5506]. multiplexing [RFC5761] and Reduced-Size RTCP [RFC5506]. While the
While the former allows for a better management of network resources former allows for a better management of network resources by
by multiplexing RTP packets and RTCP messages over the same multiplexing RTP packets and RTCP messages over the same transport,
transport, the latter allows for a compression of RTCP messages, thus the latter allows for a compression of RTCP messages, thus leading to
leading to less network traffic. For what concerns RTP/RTCP less network traffic. For RTP/RTCP multiplexing, a B2BUA acting as a
multiplexing, a B2BUA acting as a Media Relay may use it on either Media Relay may use it on either RTP session independently. This
RTP session independently. This means that, for instance, a Media means that, for instance, a Media Relay B2BUA may use RTP/RTCP
Relay B2BUA may use RTP/RTCP multiplexing on one side of the multiplexing on one side of the communication and not use it on the
communication, and not use it on the other side, if the endpoint does other side, if the endpoint does not support it. This allows for a
not support it. This allows for a better management of network better management of network resources on the side that does support
resources on the side that does support it. In case any of the it. In case any of the parties in the communications supports it and
parties in the communications supports it and the B2BUA does too, the the B2BUA does too, the related 'rtcp-mux' SDP attribute MUST be
related 'rtcp-mux' SDP attribute MUST be forwarded on the other forwarded on the other side(s). If the B2BUA detects that any of the
side(s). If the B2BUA detects that any of the parties in the parties in the communication do not support the feature, it may
communication do not support the feature, it may decide to either decide to either disable it entirely or still advertise it for the
disable it entirely or still advertize it for the RTP sessions with RTP sessions with parties that do support it. In case the B2BUA
parties that do support it. In case the B2BUA decides to involve decides to involve RTP/RTCP multiplexing, it MUST ensure that there
RTP/RTCP multiplexing, it MUST ensure that there are no conflicting are no conflicting RTP Payload Type numbers on either side. When
RTP payload type numbers on either side. When there are, it MUST there are, it MUST rewrite RTP Payload Type numbers to prevent
rewrite RTP payload type numbers to prevent conflicts in the session conflicts in the session where the RTP/RTCP multiplexing is applied.
where the RTP/RTCP multiplexing is applied. Should RTP payload types Should RTP Payload Types be rewritten, the related information in the
be rewritten, the related information in the SDP MUST be updated SDP MUST be updated accordingly.
accordingly.
For what concerns Reduced-Size RTCP, instead, the considerations are For Reduced-Size RTCP, the considerations are a bit different. In
a bit different. In fact, while a Media Relay B2BUA may choose to fact, while a Media Relay B2BUA may choose to use it on the side that
use it on the side that supports it and not on the side that doesn't, supports it and not on the side that doesn't, there are several
there are several reasons for discouraging such a behaviour. While reasons for discouraging such behaviour. While Reduced-Size allows
Reduced-Size allows indeed for less network traffic related to RTCP for less network traffic related to RTCP messaging in general, this
messaging in general, this gain may lead a Reduced-Size RTCP gain may lead a Reduced-Size RTCP implementation to also issue a
implementation to also issue a higher rate of RTCP feedback messages. higher rate of RTCP Feedback messages. This would result in
This would result in an increased RTCP traffic on the side that does increased RTCP traffic on the side that does not support Reduced-Size
not support Reduced-Size, and could as a consequence be actually and could, as a consequence, actually be counterproductive if the
counterproductive if the available bandwidth is different on the two available bandwidth is different on the two sides. Negotiating a
sides. Negotiating a session with both sides would allow the B2BUA session with both sides would allow the B2BUA to discover which one
to discover which one supports Reduced-Size and which doesn't, and in supports Reduced-Size and which doesn't and decide whether or not to
case decide whether to allow the sides to independently use Reduced- allow the sides to independently use Reduced-Size. Should the B2BUA
Size or not. Should the B2BUA decide to disable the feature on all decide to disable the feature on all sides, which is suggested in
sides, which is suggested in case Reduced-Size is not supported by case Reduced-Size is not supported by all parties involved, it MUST
all parties involved, it MUST NOT advertize support for the Reduced- NOT advertise support for the Reduced-Size RTCP functionality on
Size RTCP functionality on either side, by removing the 'rtcp-rsize' either side, by removing the 'rtcp-rsize' attribute from the SDP.
attribute from the SDP.
3.3. Media Terminator 3.3. Media Terminator
A Media Terminator B2BUA, unlike simple relays and media-aware ones, A Media Terminator B2BUA, unlike simple Media Relays and media-aware
is also able to terminate media itself. As such, it can inspect and/ ones, is able to terminate media itself. As such, it can inspect
or modify RTP payloads as well. This means that such components, for and/or modify RTP payloads as well. This means that such components,
instance, can act as media transcoders and/or originate specific RTP for instance, can act as media transcoders and/or originate specific
media. Using the RTP Topologies terminology, this can be seen as a RTP media. Using the terminology in "RTP Topologies" [RFC7667], this
RTP Media Translator. Such a topology can also be seen as a Back-to- can be seen as an RTP Media Translator. Such a topology can also be
back RTP sessions through a Middlebox, as described in Section 3.2.2 seen as a back-to-back RTP session through a middlebox, as described
of [RFC7667]. Such a capability makes them quite different from the in Section 3.2.2 of [RFC7667]. Such a capability makes them quite
previously introduced B2BUA typologies. Since such a B2BUA would different from the previously introduced B2BUA typologies. Since
terminate RTP itself, it can take care of the related statistics and such a B2BUA would terminate RTP itself, it can take care of the
feedback functionality directly, with no need to simply relay any related statistics and feedback functionality directly, with no need
message between the participants in the multimedia session. to simply relay any message between the participants in the
multimedia session.
For this reason, no specific guideline is needed to ensure a proper For this reason, no specific guideline is needed to ensure a proper
end-to-end RTCP behaviour in such scenarios, mostly because most of end-to-end RTCP behaviour in such scenarios, because most of the
the times there would be no end-to-end RTCP interaction among the time, there would be no end-to-end RTCP interaction among the
involved participants in the first place. Nevertheless, should any involved participants in the first place. Nevertheless, should any
RTCP message actually need to be forwarded to another participant in RTCP message actually need to be forwarded to another participant in
the multimedia session, the same guidelines provided for the media- the multimedia session, the same guidelines provided for the media-
aware B2BUA case apply. aware B2BUA case apply.
For what concerns RTP/RTCP multiplexing support, the same For RTP/RTCP multiplexing support, the same considerations already
considerations already given for the Media Relay management also given for the Media Relay management also apply to Media Terminators.
apply for a Media Terminator. Some different considerations might be
given as to the Reduced-Size RTCP functionality, instead. In fact, Some different considerations might be given as to the Reduced-Size
in the Media Terminator case it is safe to use the feature RTCP functionality instead. In fact, in the Media Terminator case,
independently on each side, as the B2BUA would terminate RTCP. In it is safe to use the feature independently on each side, as the
that case, the B2BUA SHOULD advertize and negotiate support for B2BUA would terminate RTCP. In that case, the B2BUA SHOULD advertise
Reduced-Size if available, and MUST NOT otherwise. and negotiate support for Reduced-Size if available and MUST NOT
otherwise.
4. IANA Considerations 4. IANA Considerations
This document makes no request of IANA. This document does not require any IANA actions.
5. Security Considerations 5. Security Considerations
The discussion made in the previous sections on the management of The discussion in the previous sections on the management of RTCP
RTCP messages by a B2BUA worked under the assumption that the B2BUA messages by a B2BUA worked under the assumption that the B2BUA has
has actually access to the RTP/RTCP information itself. This is actual access to the RTP/RTCP information itself. This is indeed
indeed true if we assume that plain RTP and RTCP is being handled, true if we assume that plain RTP and RTCP are being handled, but they
but may not be once any security is enforced on RTP packets and RTCP may not be once any security is enforced on RTP packets and RTCP
messages by means of SRTP [RFC3711]. messages by means of Secure RTP (SRTP) [RFC3711].
While typically not an issue in the Media Relay case, where RTP and While typically not an issue in the Media Relay case, where RTP and
RTCP packets are forwarded without any modification no matter whether RTCP packets are forwarded without any modification regardless of
security is involved or not, this could definitely have an impact on whether or not security is involved, this could definitely have an
Media-aware Relays and Media Terminator B2BUAs. To make a simple impact on Media-aware Relays and Media Terminator B2BUAs. As simple
example, if we envisage a SRTP/SRTCP session across a B2BUA, where example, if we envisage an SRTP / Secure RTCP (SRTCP) session across
the B2BUA itself has no access to the keys used to secure the a B2BUA where the B2BUA itself has no access to the keys used to
session, there would be no way to manipulate SRTP headers without secure the session, there would be no way to manipulate SRTP headers
violating the hashing on the packet. At the same time, there would without violating the hashing on the packet. At the same time, there
be no way to rewrite the RTCP information accordingly either. would be no way to rewrite the RTCP information accordingly either.
For this reason, it is important to point out that the operations For this reason, it is important to point out that the operations
described in the previous sections are only possible if the B2BUA has described in the previous sections are only possible if the B2BUA has
a way to effectively manipulate the packets and messages flowing by. a way to effectively manipulate the packets and messages flowing by.
This means that, when media security is involved, only the Media- This means that, when media security is involved, only the Media
unaware Relay scenario can be properly addressed. Attempting to Relay scenario can be properly addressed. Attempting to cover Media-
cover Media-aware Relay and Media Termination scenarios when aware Relay and Media Termination scenarios when involving secure
involving secure sessions will inevitably lead to the B2BUA acting as sessions will inevitably lead to the B2BUA acting as a man in the
a man-in-the-middle, and consequently its behaviour is unspecified middle; consequently, its behaviour is unspecified and discouraged.
and discouraged. More considerations on this are provided in More considerations on this are provided in [RFC7879].
[RFC7879].
It is also worth pointing out that there are scenarios where an It is also worth pointing out that there are scenarios where an
improper management of RTCP messaging across a B2BUA may lead, improper management of RTCP messaging across a B2BUA may lead,
willingly or not, to situations not unlike an attack. To make a willingly or not, to situations not unlike an attack. As a simple
simple example, an improper management of a REMB feedback message example, improper management of an REMB Feedback message containing,
containing, e.g., information on the limited bandwidth availability e.g., information on the limited bandwidth availability for a user,
for a user, may lead to missing or misleading information to its may lead to missing or misleading information to its peer. This may
peer. This may cause the peer to increase the encoder bitrate, maybe cause the peer to increase the encoder bitrate, maybe up to a point
up to a point where a user with poor connectivity will inevitably be where a user with poor connectivity will inevitably be choked by an
choked by an amount of data it cannot process. This scenario may amount of data it cannot process. This scenario may thus result in
thus result in what looks like a Denial of Service (DOS) attack what looks like a Denial-of-Service (DoS) attack towards the user.
towards the user.
6. IANA Considerations
This document has no IANA actions.
7. Change Summary
Note to RFC Editor: Please remove this whole section.
The following are the major changes between the 16 and the 17
versions of the draft:
o Clarified the meaning of a sentence.
The following are the major changes between the 14 and the 15
versions of the draft:
o Several changes addressing the IESG review (list follows).
o Addressed 'rtcp-mux' in 3.1 as well, and not only 3.2.
o Clarified that, if CNAMEs are rewritten, RTP extensions
referencing them (e.g., [RFC7941]) should be updated too.
Clarified that MTU issues can occur if the rewriting results in a
larger RTP packet.
o Clarified that when handling SR packets, the an SFU B2BUA must
track packets/bytes sent.
o Removed references to billing, lawful interception, etc. from the
intro.
o Moved some references (especially those affected by MUSTs in 3.2)
to Normative.
o Rewritten the "Such attributes SHOULD NOT be forwarded" section to
clarify the context of the attributes that may lead to a failure
if not taken care of.
o Clarified that randomly dropping RTCP packets can lead to
confusion on the recipient.
o Updated text related to REMB.
o Smaller fixes here and there.
The following are the major changes between the 13 and the 14
versions of the draft:
o Removed first paragraph of Security Considerations which was
unclear.
o Added an IANA Considerations section to clarify there are no
actions.
The following are the major changes between the 12 and the 13
versions of the draft:
o Updated authors' affiliations and mail addresses.
The following are the major changes between the 11 and the 12
versions of the draft:
o Addressed remaining points in Ben's second review.
o Updated reference of STRAW's DTLS-SRTP draft to new [RFC7879].
The following are the major changes between the 10 and the 11
versions of the draft:
o Addressed Ben's second review.
The following are the major changes between the 09 and the 10
versions of the draft:
o Replaced references to obsoleted RFC 5117 with [RFC7667].
o Made reference to [RFC7656] normative.
o Clarified text across the whole document to address Ben's review.
The following are the major changes between the 08 and the 09
versions of the draft:
o Updated references to documents which have become RFC in the
meanwhile, [RFC7667] and [RFC7656].
The following are the major changes between the 06 and the 07
versions of the draft:
o Clarified the suggested changed by Colin Perkins on the management
of CNAME items in SDES, and added reference to [RFC7022].
o Addressed comment by Simon Perreault on CNAME collisions
management.
The following are the major changes between the 05 and the 06
versions of the draft:
o Addressed comment by Colin Perkins on the management of CNAME
items in SDES.
The following are the major changes between the 04 and the 05
versions of the draft:
o Clarified behaviour when SSRC is zero.
o Fixed a couple of nits found by the Idnits tool.
The following are the major changes between the 03 and the 04
versions of the draft:
o Addressed review by Magnus Westerlund.
o Added guidelines for ECN RTCP messages.
o Clarified that if an RTCP message is dropped because unsupported,
only the unsupported packet is dropped and not the compound packet
that contains it.
o Added reference to Section 3.2.2 of [RFC7667] to Section 3.3.
o Added considerations on RTP/RTCP multiplexing and Reduced-Size
RTCP.
The following are the major changes between the 02 and the 03
versions of the draft:
o Rephrased the Media Path Security section to take into account the
MITM-related discussion in Honolulu.
o Added some Security Considerations.
The following are the major changes between the 01 and the 02
versions of the draft:
o Updated terminology to better adhere to [RFC7656].
o Rephrased the Media Path Security section to take into account the
MITM-related discussion in Toronto.
o Clarified that NACK management might be trickier when SRTP is
involved.
The following are the major changes between the 00 and the 01
versions of the draft:
o Updated references and mapping per taxonomy RFC (7092).
o Added a reference to RTP topologies, and tried a mapping as per-
discussion in London.
o Added more RTCP message types to the Media-Aware section.
o Clarified that fixing the 'rtcp' SDP attribute is important.
o Added a new section on the impact of media security.
8. Acknowledgements
The authors would like to thank Flavio Battimo and Pierluigi Palma
for their invaluable feedback in the early stages of the document.
The authors would also like to thank Colin Perkins, Bernard Aboba,
Albrecht Schwarz, Hadriel Kaplan, Keith Drage, Jonathan Lennox,
Stephen Farrell, Magnus Westerlund, Simon Perreault and Ben Campbell
for their constructive comments, suggestions, and reviews that were
critical to the formulation and refinement of this document.
9. References 6. References
9.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>. <http://www.rfc-editor.org/info/rfc3264>.
[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, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms "RTP Control Protocol Extended Reports (RTCP XR)",
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, RFC 3611, DOI 10.17487/RFC3611, November 2003,
DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc3611>.
<http://www.rfc-editor.org/info/rfc7656>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>. <http://www.rfc-editor.org/info/rfc4585>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"RTP Control Protocol Extended Reports (RTCP XR)", "Codec Control Messages in the RTP Audio-Visual Profile
RFC 3611, DOI 10.17487/RFC3611, November 2003, with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
<http://www.rfc-editor.org/info/rfc3611>. February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <http://www.rfc-editor.org/info/rfc5506>.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, Sessions with Unicast Feedback", RFC 5760,
DOI 10.17487/RFC5760, February 2010, DOI 10.17487/RFC5760, February 2010,
<http://www.rfc-editor.org/info/rfc5760>. <http://www.rfc-editor.org/info/rfc5760>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>.
[RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping [RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping
between Unicast and Multicast RTP Sessions", RFC 6284, between Unicast and Multicast RTP Sessions", RFC 6284,
DOI 10.17487/RFC6284, June 2011, DOI 10.17487/RFC6284, June 2011,
<http://www.rfc-editor.org/info/rfc6284>. <http://www.rfc-editor.org/info/rfc6284>.
[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>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <http://www.rfc-editor.org/info/rfc6679>. 2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <http://www.rfc-editor.org/info/rfc5506>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <http://www.rfc-editor.org/info/rfc7022>. September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>.
[RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP
Header Extension for the RTP Control Protocol (RTCP) Header Extension for the RTP Control Protocol (RTCP)
Source Description Items", RFC 7941, DOI 10.17487/RFC7941, Source Description Items", RFC 7941, DOI 10.17487/RFC7941,
August 2016, <http://www.rfc-editor.org/info/rfc7941>. August 2016, <http://www.rfc-editor.org/info/rfc7941>.
9.2. Informative References 6.2. Informative References
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013,
<http://www.rfc-editor.org/info/rfc7092>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015,
<http://www.rfc-editor.org/info/rfc7667>.
[I-D.alvestrand-rmcat-remb]
Alvestrand, H., "RTCP message for Receiver Estimated
Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in
progress), October 2013.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC3605, October 2003, DOI 10.17487/RFC3605, October 2003,
<http://www.rfc-editor.org/info/rfc3605>. <http://www.rfc-editor.org/info/rfc3605>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>. <http://www.rfc-editor.org/info/rfc3711>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013,
<http://www.rfc-editor.org/info/rfc7092>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015,
<http://www.rfc-editor.org/info/rfc7667>.
[RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., [RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V.,
and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back
User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016,
<http://www.rfc-editor.org/info/rfc7879>. <http://www.rfc-editor.org/info/rfc7879>.
[RTCP-REMB]
Alvestrand, H., Ed., "RTCP message for Receiver Estimated
Maximum Bitrate", Work in Progress, draft-alvestrand-
rmcat-remb-03, October 2013.
Acknowledgements
The authors would like to thank Flavio Battimo and Pierluigi Palma
for their invaluable feedback in the early stages of this document.
The authors would also like to thank Colin Perkins, Bernard Aboba,
Albrecht Schwarz, Hadriel Kaplan, Keith Drage, Jonathan Lennox,
Stephen Farrell, Magnus Westerlund, Simon Perreault, and Ben Campbell
for their constructive comments, suggestions, and reviews that were
critical to the formulation and refinement of this document.
Authors' Addresses Authors' Addresses
Lorenzo Miniero Lorenzo Miniero
Meetecho Meetecho
Email: lorenzo@meetecho.com Email: lorenzo@meetecho.com
Sergio Garcia Murillo Sergio Garcia Murillo
Medooze Medooze
 End of changes. 91 change blocks. 
531 lines changed or deleted 364 lines changed or added

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