draft-ietf-straw-b2bua-rtcp-09.txt   draft-ietf-straw-b2bua-rtcp-10.txt 
STRAW Working Group L. Miniero STRAW Working Group L. Miniero
Internet-Draft Meetecho Internet-Draft Meetecho
Intended status: Standards Track S. Garcia Murillo Intended status: Standards Track S. Garcia Murillo
Expires: October 13, 2016 Medooze Expires: October 21, 2016 Medooze
V. Pascual V. Pascual
Quobis Quobis
April 11, 2016 April 19, 2016
Guidelines to support RTCP end-to-end in Back-to-Back User Agents Guidelines to support RTCP end-to-end in Back-to-Back User Agents
(B2BUAs) (B2BUAs)
draft-ietf-straw-b2bua-rtcp-09 draft-ietf-straw-b2bua-rtcp-10
Abstract Abstract
SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be
on the media path, rather than just intercepting signalling. This on the media path, rather than just intercepting signalling. This
means that B2BUAs often implement an RTP/RTCP stack as well, whether means that B2BUAs often implement an RTP/RTCP stack as well, whether
to act as media transcoders or to just passthrough the media to act as media transcoders or to just passthrough the media
themselves, thus leading to separate multimedia sessions that the themselves, thus leading to separate multimedia sessions that the
B2BUA correlates and bridges together. If not disciplined, though, B2BUA correlates and bridges together. If not disciplined, though,
this behaviour can severely impact the communication experience, this behaviour can severely impact the communication experience,
especially when statistics and feedback information contained in RTCP especially when statistics and feedback information contained in RTCP
packets get 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 also acting on the signalling/media plane in order to preserve the
end-to-end functionality of RTCP. 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 13, 2016. This Internet-Draft will expire on October 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . 10
4. Media Path Security . . . . . . . . . . . . . . . . . . . . . 11 4. Media Path Security . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 12 7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 4 skipping to change at page 3, line 4
such, their behaviour is not always completelely adherent to the such, their behaviour is not always completelely adherent to the
standards, and can lead to unexpected situations the IETF is trying standards, and can lead to unexpected situations the IETF is trying
to address. [RFC7092] presents a taxonomy of the most deployed B2BUA to address. [RFC7092] presents a taxonomy of the most deployed B2BUA
implementations, describing how they differ in terms of the implementations, describing how they differ in terms of the
functionality and features they provide. functionality and features 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, that
is intercepting and possibly modifying SIP messages, but also on the is intercepting and possibly modifying SIP messages, but also on the
media plane. This means that, when on the signalling path between media plane. This means that, when on the signalling path between
two or more participants willing to communicate, such components also two or more participants willing to communicate, such components also
manipulate the session description [RFC4566] in order to have all RTP manipulate the session description [RFC4566], in order to have all
and RTCP [RFC3550] pass through it as well within the context of an RTP and RTCP [RFC3550] pass through it as well within the context of
SDP offer/answer [RFC3264]. The reasons for such a behaviour can be an SDP offer/answer [RFC3264]. The reasons for such a behaviour can
different: the B2BUA may want, for instance, to provide transcoding be different: the B2BUA may want, for instance, to provide
functionality for participants with incompatible codecs, or it may transcoding functionality for participants with incompatible codecs,
need the traffic to be directly handled for different reasons like or it may need the traffic to be directly handled for different
billing, lawful interception, session recording and so on. This can reasons like billing, lawful interception, session recording and so
lead to several different topologies for RTP-based communication, as on. This can lead to several different topologies for RTP-based
documented in [RFC5117]. These topologies are currently being communication, as documented in [RFC7667]. These topologies are
updated to address new commonly encountered scenarios as well currently being updated to address new commonly encountered scenarios
[RFC7667]. as well [RFC7667].
Whatever the reason, such a behaviour does not come without a cost. Whatever the reason, such a behaviour does not come without a cost.
In fact, whenever a media-aware component is placed on the path In fact, whenever a media-aware component is placed on the path
between two or more participants that want to communicate by means of between two or more participants that want to communicate by means of
RTP/RTCP, the end-to-end nature of such protocols is broken, and RTP/RTCP, the end-to-end nature of such protocols is broken, and
their effectiveness may be affected as a consequence. While this may their effectiveness may be affected as a consequence. While this may
not be a problem for RTP packets, which from a protocol point of view not be a problem for RTP packets, which can be quite easily relayed,
just contain opaque media packets and as such can be quite easily it definitely can cause serious issue for RTCP messages, which carry
relayed, it definitely can cause serious issue for RTCP packets, important information and feedback on the communication quality the
which carry important information and feedback on the communication participants are experiencing. Consider, for instance, the simple
quality the participants are experiencing. In fact, RTCP packets scenario only involving two participants and a single RTP session
make use of specific ways to address the media they are referring to. depicted in Figure 1:
Consider, for instance, the simple scenario only involving two
participants and a single RTP 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, it is (one per media direction). As part of this process, though, it is
also rewriting some of the RTP header information on the way, for also rewriting some of the RTP header information on the way, for
instance because that's how its RTP relaying stack works: in this instance because that's how its RTP relaying stack works: in this
example, just the SSRC of the incoming RTP audio streams is changed, example, just the SSRC of the incoming RTP audio streams is changed,
but more information may be changed as well (e.g., sequence numbers, but more information may be changed as well (e.g., sequence numbers,
timestamps, etc.). In particular, whenever Alice sends an audio RTP timestamps, etc.). In particular, whenever Alice sends an audio RTP
packet, she sets her SSRC (SSRC1) to the RTP header of her RTP source packet, she sets her SSRC (SSRC1) in the RTP header of her RTP source
stream; the B2BUA rewrites the SSRC (SSRC3) before relaying the stream. The B2BUA rewrites the SSRC (SSRC3) before relaying the
packet to Bob. At the same time, RTP packets sent by Bob (SSRC4) get packet to Bob. At the same time, RTP packets sent by Bob (SSRC4) get
their SSRC rewritten as well (SSRC2) before being relayed to Alice. their SSRC rewritten as well (SSRC2) before being relayed to Alice.
Assuming now that Alice needs to inform Bob she has lost several Assuming now that Alice needs to inform Bob she has lost several
audio packets in the last few seconds, maybe because of a network audio packets in the last few seconds, she will place the related
congestion, she would of course place the related received RTP stream received RTP stream SSRC she is aware of (SSRC2), together with her
SSRC she is aware of (SSRC2), together with her own (SSRC1), in RTCP own (SSRC1), in RTCP Reports and/or NACKs. Since the B2BUA is making
Reports and/or NACKS to do so, hoping for a retransmission [RFC4588] use of different SSRCs for the RTP streams in the RTP session it
or for Bob to slow down. Since the B2BUA is making use of different established with each participant, a blind relaying of these RTCP
SSRCs for the RTP streams in the RTP session it established with each messages to Bob would in this case result, from Bob's perspective, in
participant, a blind relaying of the RTCP packets to Bob would in unknown SSRCs being addressed, thus resulting in the precious
this case result, from Bob's perspective, in unknown SSRCs being information being dropped. In fact, Bob is only aware of SSRCs SSRC4
addressed, thus resulting in the precious information being dropped. (the one his source RTP stream uses) and SSRC3 (the one he's
In fact, Bob is only aware of SSRCs SSRC4 (the one his source RTP receiving from the B2BUA in the received RTP stream), and knows
stream uses) and SSRC3 (the one he's receiving from the B2BUA in the nothing about SSRCs SSRC1 and SSRC2 in the messages he received
received RTP stream), and knows nothing about SSRCs SSRC1 and SSRC2 instead. As a consequence of the feedback being dropped, unaware of
in the RTCP packets he would receive instead. As a consequence of the issue Bob may continue to flood Alice with even more media
the feedback being dropped, unaware of the issue Bob may continue to packets and/or not retransmit Alice the packets she missed. This may
flood Alice with even more media packets and/or not retransmit Alice easily lead to a very bad communication experience, if not eventually
the packets she missed, which may easily lead to a very bad to an unwanted termination of the communication itself.
communication experience, if not eventually to an unwanted
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 trivial mishandling Nevertheless, it is a valid example of how such a simple mishandling
of precious information may lead to serious consequences, especially of precious information may lead to serious consequences. This is
considering that more complex scenarios may involve several especially true if we picture more complex scenarios involving
participants at the same time, multiple RTP sessions (e.g., a video several participants at the same time, multiple RTP sessions (e.g., a
stream along audio) rather than a single one, redundancy RTP streams, video stream along audio) rather than a single one, redundancy RTP
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
such feedback, in order to be sure that their activities on the media such feedback, in order to be sure that their activities on the media
plane do not break anything they're not supposed to. plane do not break anything they're not supposed to.
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 Besides, this document addresses, where relevant, the RTP-related
terminology as disciplined in [RFC7656]. terminology as disciplined in [RFC7656].
3. Signalling/Media Plane B2BUAs 3. Signalling/Media Plane B2BUAs
As anticipated in the introductory section, it's very common for As anticipated in the introductory section, it's very common for
B2BUA deployments to also act on the media plane, rather than just B2BUA deployments to also act on the media plane, rather than just
signalling alone. In particular, [RFC7092] describes three different signalling alone. In particular, [RFC7092] describes three different
categories of such B2BUAs, according to the level of activities categories of such B2BUAs: a B2BUA, in fact, may act as a simple
performed on the media plane: a B2BUA, in fact, may act as a simple
media relay (1), effectively unaware of anything that is transported; media relay (1), effectively unaware of anything that is transported;
it may be a media-aware relay (2), also inspecting and/or modifying it may be a media-aware relay (2), also inspecting and/or modifying
RTP and RTCP packets as they flow by; or it may be a full-fledged RTP and RTCP messages as they flow by; or it may be a full-fledged
media termination entity, terminating and generating RTP and RTCP media termination entity, terminating and generating RTP and RTCP
packets as needed. messages as needed.
While [RFC3550] and [RFC5117] already mandate some specific While [RFC3550] and [RFC7667] already mandate some specific
behaviours when specific topologies are deployed, not all deployments behaviours in the presence of certain topologies, not all deployments
strictly adhere to the specifications and as such it's not rare to strictly adhere to the specifications. As such, it's not rare to
encounter issues that may be avoided with a more disciplined encounter issues that may be avoided with a more disciplined
behaviour in that regard. For this reason, the following subsections behaviour in that regard. For this reason, the following subsections
will describe the proper behaviour B2BUAs, whatever above category will describe the proper behaviour B2BUAs, whatever above category
they fall in, should follow in order to avoid, or at least minimize, they fall in, should follow in order not to impact any end-to-end
any impact on end-to-end RTCP effectiveness. RTCP effectiveness.
3.1. Media Relay 3.1. Media Relay
A media relay as identified in [RFC7092] basically just forwards, A media relay, as identified in [RFC7092], basically just forwards
from an application level point of view, all RTP and RTP packets it all RTP and RTCP messages it receives, without either inspecting or
receives, without either inspecting or modifying them. Using the RTP modifying them. Using the RTP Topologies terminology, this can be
Topologies terminology, this can be seen as a RTP Transport seen as a RTP Transport Translator. As such, B2BUA acting as media
Translator. As such, B2BUA acting as media relays are not aware of relays are not aware of what traffic they're handling. This means
what traffic they're handling, meaning that not only the packet that both packet payloads and packet headers are opaque to them.
payloads are opaque to them, but headers as well. Many Session Many Session Border Controllers (SBC) implement this kind of
Border Controllers (SBC) implement this kind of behaviour, e.g., when behaviour, e.g., when acting as a bridge between an inner and outer
acting as a bridge between an inner and outer network. network.
Considering all headers and identifiers in both RTP and RTCP are left Considering all headers and identifiers in both RTP and RTCP are left
untouched, issues like the SSRC mismatch described in the previous untouched, issues like the SSRC mismatch described in the previous
section would not occur. Similar problems could occur, though, section would not occur. Similar problems could still happen,
should the session description end up providing incorrect information though, for different reasons, as for instance if the session
about the media flowing (e.g., if the SDP on either side contain description ends up providing incorrect information. This may
'ssrc' [RFC5576] attributes that don't match the actual SSRC being happen, for example, if the SDP on either side contains 'ssrc'
advertized on the media plane) or about the supported RTCP mechanisms [RFC5576] attributes that don't match the actual SSRC being
(e.g., in case the B2BUA advertized support for NACK because it advertized on the media plane, or in case the B2BUA advertized
implements it, but the original INVITE didn't). Such an issue might support for NACK because it implements it, while the original INVITE
occur, for instance, in case the B2BUA acting as a media relay is didn't. Such issues might occur, for instance, in case the B2BUA
generating a new session description when bridging an incoming call, acting as a media relay is generating a new session description when
rather than taking into account the original session description in bridging an incoming call, rather than taking into account the
the first place. This may cause the participants to find a mismatch original session description. This may cause participants to find a
between the SSRCs advertized in SDP and the ones actually observed in mismatch between the SSRCs advertized in SDP and the ones actually
RTP and RTCP packets (which may indeed change during a multimedia observed in RTP and RTCP messages (which may indeed change during a
session anyway, but having them synced during setup would help multimedia session anyway, but having them synced during setup would
nonetheless), or having them either ignore or generate RTCP feedback help nonetheless), or to have them either ignore or generate RTCP
packets that were not explicitly advertized as supported. feedback packets that were not explicitly advertized 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 interested participants: this multimedia session setup between interested participants: this
includes attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], includes attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585],
'rtcp-xr-attrib' [RFC3611] and others. It SHOULD NOT, though, 'rtcp-xr-attrib' [RFC3611] and others. It SHOULD NOT, though,
blindly forward all SDP attributes, as some of them (e.g., blindly forward all SDP attributes, as some of them (e.g.,
candidates, fingerprints, crypto, etc.) may lead to call failures for candidates, fingerprints, crypto, etc.) may lead to call failures for
different reasons out of scope to this document. One notable example different reasons out of scope to this document. One notable example
is the 'rtcp' [RFC3605] attribute that UAC may make use of to is the 'rtcp' [RFC3605] attribute, that UAC may make use of to
explicitly state the port they're willing to use for RTCP: explicitly state the port they're willing to use for RTCP.
considering the B2BUA would relay RTCP packets, the port as seen by Considering the B2BUA would relay RTCP messages, the port as seen by
the other UAC involved in the communication would differ from the one the other UAC involved in the communication would differ from the one
negotiated originally, and as such it MUST be rewritten accordingly. negotiated originally, and as such it MUST be rewritten accordingly.
It is worth mentioning that, leaving RTCP packets untouched, a media It is worth mentioning that, leaving RTCP messages untouched, a media
relay may also let through information that, according to policies, relay may also let through information that, according to policies,
may be best left hidden or masqueraded, e.g., domain names in CNAME may be best left hidden or masqueraded, e.g., domain names in CNAME
items. Besides, these CNAME items may actually contain IP addresses items. Besides, these CNAME items may actually contain IP addresses
instead: this means that, should a NAT be involved in the instead: this means that, should a NAT be involved in the
communication, this may actually result in CNAME collisions, which communication, this may actually result in CNAME collisions, which
could indeed break the end-to-end RTCP behaviour. While [RFC7022] could indeed break the end-to-end RTCP behaviour. While [RFC7022]
can prevent this from happening, there may be implementations that can prevent this from happening, there may be implementations that
don't make use of it. As such, a B2BUA MAY rewrite CNAME items if don't make use of it. As such, a B2BUA MAY rewrite CNAME items if
any potential collision is detected, even in the Media Relay case. any potential collision is detected, even in the Media Relay case.
If a B2BUA does indeed decide to rewrite CNAME items, though, then it If a B2BUA does indeed decide to rewrite CNAME items, though, then it
MUST generate new CNAMEs following [RFC7022]. MUST generate new CNAMEs following [RFC7022].
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 the Media Relay addressed in the
previous section, is actually aware of the media traffic it is previous section, is actually aware of the media traffic it is
handling. As such, it is able to inspect RTP and RTCP packets handling. As such, it is able to inspect RTP and RTCP messages
flowing by, and may even be able to modify the headers in any of them flowing by, and may even be able to modify their headers. Using the
before forwarding them. Using the RFC3550 terminology, this can be RFC3550 terminology, this can be seen as a RTP Translator. A B2BUA
seen as a RTP Translator. A B2BUA implementing this role would implementing this role, though, typically does not inspect the RTP
typically not, though, inspect the RTP payloads as well, which would payloads as well, which would be opaque to them: this means that the
be opaque to them: this means that the actual media would not be actual media would not be manipulated (e.g, transcoded).
manipulated (e.g, transcoded).
This makes them quite different from the Media Relay previously This makes them quite different from the Media Relay 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 (and hence CSRC lists, that must of course be updated like SSRC/CSRC, sequence numbers, timestamps and others in an RTP
accordingly), sequence numbers, timestamps and the like in an RTP
stream, before forwarding the modified packets to the other stream, before forwarding the modified packets to the other
interested participants in the multimedia sessions on the RTP streams interested participants. This means that, if not properly
they're using to receive the media. This means that, if not properly
disciplined, such a behaviour may easily lead to issues like the one disciplined, such a behaviour may easily lead to issues like the one
described in the introductory section. As such, it is very important described in the introductory section. As such, it is very important
for a B2BUA modifying RTP-related information across two related RTP for a B2BUA modifying RTP-related information across two related RTP
streams to also modify the same information in RTCP packets as well, streams to also modify, in a coherent way, the same information in
and in a coherent way, so that not to confuse any of the participants RTCP messages as well.
involved in a communication.
It is worthwile to point out that such a B2BUA would not necessarily It is worthwile to point out that such a B2BUA may not necessarily
forward all the packets it is receiving, though: Selective Forwarding forward all the packets it is receiving, though. Selective
Units (SFU) [RFC7667], for instance, could aggregate or drop incoming Forwarding Units (SFU) [RFC7667], for instance, may aggregate or drop
RTCP messages, while at the same time originating new ones on their incoming RTCP messages, while at the same time originating new ones
own. For the messages that are forwarded and/or aggregated, though, on their own. For the messages that are forwarded and/or aggregated,
it's important to make sure the information is coherent. though, it's important to make sure the 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 also handle Section 7.2 of [RFC3550], a media-aware B2BUA MUST also handle
incoming RTCP messages to forward following this guideline: incoming RTCP messages to forward following this guideline:
SR: [RFC3550] SR: [RFC3550]
If the B2BUA has changed any SSRC in any RTP streams relation, it If the B2BUA has changed the SSRC of the sender RTP stream a
MUST update the SSRC-related information in the incoming SR packet Sender Report refers to, it MUST update the SSRC in the SR packet
before forwarding it. This includes the sender SSRC, which MUST header as well. If the B2BUA has changed the SSRCs of other RTP
be rewritten with the one the B2BUA uses in the RTP stream used to streams too, and any of these streams are addressed in any of the
receive RTP packets from each participant, and the SSRC SR report blocks, it MUST update the related values in the SR
information in all the blocks, which MUST be rewritten using the report blocks as well. If the B2BUA has also changed the base RTP
related sender participant(s) SSRC. If the B2BUA has also changed sequence number when forwarding RTP packets, then this change
the base RTP sequence number when forwarding RTP packets, then needs to be properly addressed in the 'extended highest sequence
this change needs to be properly addressed in the 'extended number received' field in the Report Blocks.
highest sequence number received' field in the Report Blocks.
RR: [RFC3550] RR: [RFC3550]
The same guidelines given for SR apply for RR as well. The same guidelines given for SR apply for RR as well.
SDES: [RFC3550] SDES: [RFC3550]
If the B2BUA has changed any SSRC in any direction, it MUST update If the B2BUA has changed the SSRC of any RTP stream addressed in
the SSRC-related information in all the chunks in the incoming any of the chunks of an incoming SDES message, it MUST update the
SDES packet before forwarding it. 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 any SSRC in any direction, it MUST update If the B2BUA has changed the SSRC of any RTP stream addressed in
the SSRC in the BYE message. the SSRC/CSRC identifiers included in a BYE packet, it MUST update
them in the message.
APP: [RFC3550] APP: [RFC3550]
If the B2BUA has changed any SSRC in any direction, it MUST update If the B2BUA has changed the SSRC of any RTP stream addressed in
the SSRC in the APP message. Should the B2BUA be aware of any the header of an APP packet, it MUST update the identifier in the
specific APP message format that contains additional information message. Should the B2BUA be aware of any specific APP message
related to SSRCs, it SHOULD update them as well. format that contains additional information related to SSRCs, it
SHOULD update them as well accordingly.
Extended Reports (XR): [RFC3611] Extended Reports (XR): [RFC3611]
If the B2BUA has changed any SSRC in any direction, it MUST update If the B2BUA has changed the SSRC of the RTP stream associated
the SSRC-related information in the incoming XR message header with the originator of an XR packet, it MUST update the SSRC in
before forwarding it. This includes the source SSRC, which MUST the XR message header. The same guidelines given for SR/RR, with
be rewritten with the one the B2BUA uses to send RTP packets to respect to SSRC identifiers in report blocks, apply for all the
each sender participant, and the SSRC information in all the block Report Block types in the XR message as well. If the B2BUA has
types that include it, which MUST be rewritten using the related also changed the base RTP sequence number when forwarding RTP
sender participant(s) SSRC. If the B2BUA has also changed the packets, then this change needs to be properly addressed in the
base RTP sequence number when forwarding RTP packets, then this 'begin_seq' and 'end_seq' fields that are available in most of the
change needs to be properly addressed in the 'begin_seq' and Report Block types that are part of the XR specification.
'end_seq' fields that are available in most of the Report Block
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 in any direction, it MUST update If the B2BUA has changed any SSRC of RTP streams addressed in a
the SSRC-related information in the incoming RSI message header RSI packet, it MUST update the SSRC identifiers in the message.
before forwarding it. This includes the distribution source SSRC, This includes the distribution source SSRC, which MUST be
which MUST be rewritten with the one the B2BUA uses to send RTP rewritten with the one the B2BUA uses to send RTP packets to each
packets to each sender participant, the summarized SSRC and, in sender participant, the summarized SSRC and, in case a Collision
case a Collision Sub-Report Block is available, the SSRCs in the Sub-Report Block is available, the SSRCs in the related list.
related list.
Port Mapping (TOKEN): [RFC6284] Port Mapping (TOKEN): [RFC6284]
If the B2BUA has changed any SSRC in any direction, it MUST update If the B2BUA has changed any SSRC of RTP streams addressed in a
the SSRC-related information in the incoming TOKEN message before TOKEN packet, it MUST update the SSRC identifiers in the message.
forwarding it. This includes the Packet Sender SSRC, which MUST This includes the Packet Sender SSRC, which MUST be rewritten with
be rewritten with the one the B2BUA uses to send RTP packets to the one the B2BUA uses to send RTP packets to each sender
each sender participant, and the Requesting Client SSRC in case participant, and the Requesting Client SSRC in case the message is
the message is a response, which MUST be rewritten using the a response, which MUST be rewritten using the related sender
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 of the packet sender and the one of the media source the the SSRC identifier of the packet sender and the SSRC identifier
feedack is related to. Just as described for the previous of the media source the feedack is related to. Just as described
messages, these SSRC identifiers MUST be updated if the B2BUA has for the previous messages, these SSRC identifiers MUST be updated
changed any SSRC in any direction. It MUST NOT, though, change a in the message if the B2BUA has changed the SSRC of the RTP
media source SSRC that was originally set to zero, unless zero is streams addressed there. It MUST NOT, though, change a media
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. Besides, considering that many feedback messages rewriting apply. Besides, considering that many feedback messages
also include additional data as part of their specific Feedback also include additional data as part of their specific Feedback
Control Information (FCI), a media-aware B2BUA MUST take care of Control Information (FCI), a media-aware B2BUA MUST take care of
them accordingly, if it can parse and regenerate them, according them accordingly, if it can parse and regenerate them, according
to the following guidelines. to the following guidelines.
NACK: [RFC4585] NACK: [RFC4585]
Besides the common packet format management for feedback messages, Besides the common packet format management for feedback messages,
a media-aware B2BUA MUST also properly rewrite the Packet ID (PID) a media-aware B2BUA MUST also 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 before forwarding a packet. RTP sequence numbers.
TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM: [RFC5104] TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM: [RFC5104]
Besides the common packet format management for feedback messages, Besides the common packet format management for feedback messages,
a media-aware B2BUA MUST also properly rewrite the additional SSRC a media-aware B2BUA MUST also properly rewrite the additional SSRC
identifier all those messages envisage as part of their specific identifier in the specific FCI, if it changed the related RTP SSRC
FCI if it changed the related RTP SSRC of the media sender. of the media sender.
REMB: [I-D.alvestrand-rmcat-remb] REMB: [I-D.alvestrand-rmcat-remb]
Besides the common packet format management for feedback messages, Besides the common packet format management for feedback messages,
a media-aware B2BUA MUST also properly rewrite the additional SSRC a media-aware B2BUA MUST also properly rewrite the additional SSRC
identifier(s) REMB packets envisage as part of their specific FCI identifier(s) in REMB packets, if it changed the related RTP SSRC
if it changed the related RTP SSRC of the media sender. of the media sender.
Explicit Congestion Notification (ECN): [RFC6679] Explicit Congestion Notification (ECN): [RFC6679]
Besides the common packet format management for feedback messages, Besides the common packet format management for feedback messages,
the same guidelines given for SR/RR management apply as well, the same guidelines given for SR/RR management apply as well,
considering the presence of sequence numbers in the ECN Feedback considering the presence of sequence numbers in the ECN Feedback
Report format. For what concerns the management of RTCP XR ECN Report format. For what concerns the management of RTCP XR ECN
Summary Report messages, the same guidelines given for generic XR Summary Report messages, the same guidelines given for generic XR
messages apply. 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 PLI, SLI and RPSI feedback
messages instead. messages instead.
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 also applies to media-aware B2BUAs. RTCP information to be coherent also applies to media-aware B2BUAs.
This means that, if a B2BUA is going to change any SSRC, it SHOULD This means that, if a B2BUA is going to change any SSRC, it SHOULD
update the related 'ssrc' attributes if they were present in the update the related 'ssrc' attributes, if present, before sending it
original description before sending it to the recipient, just as it to the recipient. Besides, it MUST rewrite the 'rtcp' attribute if
MUST rewrite the 'rtcp' attribute if provided. At the same time, the provided. At the same time, while a media-aware B2BUA is typically
ability for a media-aware B2BUA to inspect/modify RTCP packets may able to inspect/modify RTCP messages, it may not support all RTCP
also mean such a B2BUA may choose to drop RTCP packets it can't messages. This means that a B2BUA may choose to drop RTCP messages
parse: in that case, a media-aware B2BUA MUST also advertize its RTCP it can't parse. In that case, a media-aware B2BUA MUST also
level of support in the SDP in a coherent way, in order to prevent, advertize its RTCP level of support in the SDP in a coherent way, in
for instance, a UAC to make use of NACK messages that would never order to prevent, for instance, a UAC to make use of NACK messages
reach the intended recipients. It's important to point out that, in that would never reach the intended recipients. It's important to
case any RTCP packet needs to be dropped, then only the offending point out that, in case any RTCP message needs to be dropped, then
RTCP packet needs to be dropped, and not the whole compound RTCP the B2BUA SHOULD NOT drop the whole compound RTCP message it may
packet it may belong to. belong to, but only the RTCP message itself.
A different set of considerations, instead, is worthwhile for what A different set of considerations, instead, is worthwhile for what
concerns RTP/RTCP multiplexing [RFC5761] and Reduced-Size RTCP concerns RTP/RTCP multiplexing [RFC5761] and Reduced-Size RTCP
[RFC5506]. While the former allows for a better management of [RFC5506]. While the former allows for a better management of
network resources by multiplexing RTP packets and RTCP messages over network resources by multiplexing RTP packets and RTCP messages over
the same transport, the latter allows for a compression of RTCP the same transport, the latter allows for a compression of RTCP
messages, thus leading to less network traffic. For what concerns messages, thus leading to less network traffic. For what concerns
RTP/RTCP multiplexing, a B2BUA acting as a Media Relay can use it on RTP/RTCP multiplexing, a B2BUA acting as a Media Relay may use it on
either RTP session independently: this means that, for instance, a either RTP session independently. This means that, for instance, a
Media Relay B2BUA may use RTP/RTCP multiplexing on one side of the Media Relay B2BUA may use RTP/RTCP multiplexing on one side of the
communication, and not use it on the other side, if it's not communication, and not use it on the other side, if it's not
supported. This allows for a better management of network resources supported. This allows for a better management of network resources
on the side that does support it. In case any of the parties in the on the side that does support it. In case any of the parties in the
communications supports it and the B2BUA does too, the related 'rtcp- communications supports it and the B2BUA does too, the related 'rtcp-
mux' SDP attribute MUST be forwarded on the other side(s); if the mux' SDP attribute MUST be forwarded on the other side(s). If the
B2BUA detects that any of the parties in the communication does not B2BUA detects that any of the parties in the communication does not
support the feature, it may decide to either disable it entirely or support the feature, it may decide to either disable it entirely or
still advertize it for the RTP sessions with parties that do support still advertize it for the RTP sessions with parties that do support
it. In case the B2BUA decides to involve RTP/RTCP multiplexing, it it. In case the B2BUA decides to involve RTP/RTCP multiplexing, it
MUST ensure that there are no conflicting RTP payload type numbers on MUST ensure that there are no conflicting RTP payload type numbers on
both sides, and in case there are, it MUST rewrite RTP payload type both sides. In case there are, it MUST rewrite RTP payload type
numbers to ensure no conflict in the domain where the RTP/RTCP numbers to ensure no conflict in the domain where the RTP/RTCP
multiplexing is applied. Should RTP payload types be rewritten, the multiplexing is applied. Should RTP payload types be rewritten, the
related information in the SDP MUST be updated accordingly. related information in the SDP MUST be updated accordingly.
For what concerns Reduced-Size RTCP, instead, the considerations are For what concerns Reduced-Size RTCP, instead, the considerations are
a bit different. In fact, while a Media Relay B2BUA may choose to a bit different. In fact, while a Media Relay B2BUA may choose to
use it on the side that supports it and not on the side that doesn't, use it on the side that supports it and not on the side that doesn't,
there are other aspects to take into account before doing so. While there are other aspects to take into account before doing so. While
Reduced-Size allows indeed for less network traffic related to RTCP Reduced-Size allows indeed for less network traffic related to RTCP
messaging in general, this gain may lead a Reduced-Size RTCP messaging in general, this gain may lead a Reduced-Size RTCP
implementation to also issue a higher rate of RTCP feedback messages. implementation to also issue a higher rate of RTCP feedback messages.
This would result in an increased RTCP traffic on the side that does This would result in an increased RTCP traffic on the side that does
not support Reduced-Size, and could as a consequence be actually not support Reduced-Size, and could as a consequence be actually
counterproductive if the bandwidth is different on each side. That counterproductive if the available bandwidth is different on the two
said, the B2BUA can choose whether or not to advertize support for sides. That said, the B2BUA can choose whether or not to advertize
Reduced-Size RTCP on either side by means of the 'rtcp-rsize' SDP support for Reduced-Size RTCP on either side by means of the 'rtcp-
attribute. Should a B2BUA decide to allow the sides to independently rsize' SDP attribute. Should a B2BUA decide to allow the sides to
use or not Reduced-Size, then the B2BUA MUST advertize support for independently use Reduced-Size or not, then the B2BUA MUST advertize
the feature on the sides that support it, and MUST NOT advertize it support for the feature on the sides that support it, and MUST NOT
on the sides that don't, by removing the related attribute from the advertize it on the sides that don't, by removing the related
SDP before forwarding it. Should the B2BUA decide to disable the attribute from the SDP before forwarding it. Should the B2BUA decide
feature on all sides, instead, it MUST NOT advertize support for the to disable the feature on all sides, instead, it MUST NOT advertize
Reduced-Size RTCP functionality on any side, by removing the 'rtcp- support for the Reduced-Size RTCP functionality on either side, by
rsize' attribute from the SDP. removing the 'rtcp-rsize' 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 relays and media-aware ones,
is also able to terminate media itself, that is taking care of RTP is also able to terminate media itself. As such, it can inspect and/
payloads as well and not only headers. This means that such or modify RTP payloads as well. This means that such components, for
components, for instance, can act as media transcoders and/or instance, can act as media transcoders and/or originate specific RTP
originate specific RTP media. Using the RTP Topologies terminology, media. Using the RTP Topologies terminology, this can be seen as a
this can be seen as a RTP Media Translator. Such a topology can also RTP Media Translator. Such a topology can also be seen as a Back-to-
be seen as a Back-to-back RTP sessions through a Middlebox, as back RTP sessions through a Middlebox, as described in Section 3.2.2
described in Section 3.2.2 of [RFC7667]. Such a capability makes of [RFC7667]. Such a capability makes them quite different from the
them quite different from the previously introduced B2BUA typologies, previously introduced B2BUA typologies. Since such a B2BUA would
as this means they are going to terminate RTCP as well: in fact, terminate RTP itself, it can take care of the related statistics and
since the media is terminated by themselves, the related statistics feedback functionality directly, with no need to simply relay any
and feedback functionality can be taken care directly by the B2BUA, message between the participants in the multimedia session.
and does not need to be relayed to the other 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, mostly because most of
the times there would be no end-to-end RTCP interaction among the the times there would be no end-to-end RTCP interaction among the
involved participants at all, as the B2BUA would terminate them all involved participants in the first place. Nevertheless, should any
and take care of them accordingly. Nevertheless, should any RTCP RTCP message actually need to be forwarded to another participant in
packet actually need to be forwarded to another participant in the the multimedia session, the same guidelines provided for the media-
multimedia session, the same guidelines provided for the media-aware aware B2BUA case apply.
B2BUA case apply.
For what concerns RTP/RTCP multiplexing support, the same For what concerns RTP/RTCP multiplexing support, the same
considerations already given for the Media Relay management basically considerations already given for the Media Relay management basically
apply for a Media Terminator as well. Some different considerations apply for a Media Terminator as well. Some different considerations
might be given as to the Reduced-Size RTCP functionality, instead: in might be given as to the Reduced-Size RTCP functionality, instead: in
fact, in the Media Terminator case it is safe to use the feature fact, in the Media Terminator case it is safe to use the feature
independently on each leg. In that case, the same considerations independently on each side. In that case, the same considerations
about advertizing the support, or lack of support, of the feature on about advertizing the support, or lack of, of the feature on either
either side as described for the Media Relay case apply here as well. side as described for the Media Relay case apply here as well.
4. Media Path Security 4. Media Path Security
The discussion made in the previous sections on the management of The discussion made in the previous sections on the management of
RTCP messages by a B2BUA has so far mostly worked under the RTCP messages by a B2BUA has so far mostly worked under the
assumption that the B2BUA has actually access to the RTP/RTCP assumption that the B2BUA has actually access to the RTP/RTCP
information itself. This is indeed true if we assume that plain RTP information itself. This is indeed true if we assume that plain RTP
and RTCP is being handled, but this may not be true once any security and RTCP is being handled, but may not be once any security is
is enforced on RTP packets and RTCP messages by means of SRTP enforced on RTP packets and RTCP messages by means of SRTP [RFC3711].
[RFC3711], whether the keying is done using Secure Descriptions
[RFC4568] or DTLS-SRTP [RFC5764].
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 no matter whether
security is involved or not, this could definitely have an impact on security is involved or not, this could definitely have an impact on
Media-aware Relays and Media Terminator B2BUAs. To make a simple Media-aware Relays and Media Terminator B2BUAs. To make a simple
example, if we think of a SRTP/SRTCP session across a B2BUA where the example, if we envisage a SRTP/SRTCP session across a B2BUA, where
B2BUA itself has no access to the keys used to secure the session, the B2BUA itself has no access to the keys used to secure the
there would be no way to manipulate SRTP headers without violating session, there would be no way to manipulate SRTP headers without
the hashing on the packet; at the same time, there would be no way to violating the hashing on the packet. At the same time, there would
rewrite the RTCP information accordingly either, as most of the be no way to rewrite the RTCP information accordingly either.
packet (especially when RTCP compound packets are involved) would be
encrypted.
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, in case media security is involved, only the Media- This means that, in case media security is involved, only the Media-
unaware Relay scenario can be properly addressed. Attempting to unaware Relay scenario can be properly addressed. Attempting to
cover Media-aware Relay and Media Terminarion scenarios when cover Media-aware Relay and Media Terminarion scenarios when
involving secure sessions will inevitably lead to the B2BUA acting as involving secure sessions will inevitably lead to the B2BUA acting as
a man-in-the-middle, and as such its behaviour is unspecified and a man-in-the-middle, and as such its behaviour is unspecified and
discouraged. discouraged. More considerations on this are provided in
[I-D.ietf-straw-b2bua-dtls-srtp].
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
6. Security Considerations 6. Security Considerations
This document, being a summary and vest common practice overview that This document, being a summary and a best common practice overview
covers different standards, does not introduce any additional that covers different standards, does not introduce any additional
consideration to those described by the aforementioned standard consideration to those described by the aforementioned standard
documents themselves. documents.
It is worth pointing out, though, that there are scenarios where an It is worth pointing out, though, 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. To make a
simple example, an improper management of a REMB feedback message simple example, an improper management of a REMB feedback message
containing, e.g., information on the limited bandwidth availability containing, e.g., information on the limited bandwidth availability
for a user, may lead to missing information to its peer, who may end for a user, may lead to missing or misleading information to its
up increasing the encoder bitrate up to a point where the user with peer. This may cause the peer to increase the encoder bitrate, maybe
poor connectivity will inevitably be choked by an amount of data it up to a point where a user with poor connectivity will inevitably be
cannot process. This scenario may as such result in what looks like choked by an amount of data it cannot process. This scenario may as
a Denial of Service (DOS) attack towards the user. such result in what looks like a Denial of Service (DOS) attack
towards the user.
7. Change Summary 7. Change Summary
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
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 The following are the major changes between the 08 and the 09
versions of the draft: versions of the draft:
o Updated references to documents which have become RFC in the o Updated references to documents which have become RFC in the
meanwhile, [RFC7667] and [RFC7656]. meanwhile, [RFC7667] and [RFC7656].
The following are the major changes between the 06 and the 07 The following are the major changes between the 06 and the 07
versions of the draft: versions of the draft:
o Clarified the suggested changed by Colin Perkins on the management o Clarified the suggested changed by Colin Perkins on the management
skipping to change at page 13, line 37 skipping to change at page 13, line 31
o Fixed a couple of nits found by the Idnits tool. o Fixed a couple of nits found by the Idnits tool.
The following are the major changes between the 03 and the 04 The following are the major changes between the 03 and the 04
versions of the draft: versions of the draft:
o Addressed review by Magnus Westerlund. o Addressed review by Magnus Westerlund.
o Added guidelines for ECN RTCP messages. o Added guidelines for ECN RTCP messages.
o Clarified that if an RTCP packet is dropped because unsupported, o Clarified that if an RTCP message is dropped because unsupported,
only the unsupported packet is dropped and not the compound packet only the unsupported packet is dropped and not the compound packet
that contains it. that contains it.
o Added reference to Section 3.2.2 of [RFC7667] to Section 3.3. o Added reference to Section 3.2.2 of [RFC7667] to Section 3.3.
o Added considerations on RTP/RTCP multiplexing and Reduced-Size o Added considerations on RTP/RTCP multiplexing and Reduced-Size
RTCP. RTCP.
The following are the major changes between the 02 and the 03 The following are the major changes between the 02 and the 03
versions of the draft: versions of the draft:
skipping to change at page 14, line 24 skipping to change at page 14, line 19
involved. involved.
The following are the major changes between the 00 and the 01 The following are the major changes between the 00 and the 01
versions of the draft: versions of the draft:
o Updated references and mapping per taxonomy RFC (7092). o Updated references and mapping per taxonomy RFC (7092).
o Added a reference to RTP topologies, and tried a mapping as per- o Added a reference to RTP topologies, and tried a mapping as per-
discussion in London. discussion in London.
o Added more RTCP packet types to the Media-Aware section. o Added more RTCP message types to the Media-Aware section.
o Clarified that fixing the 'rtcp' SDP attribute is important. o Clarified that fixing the 'rtcp' SDP attribute is important.
o Added a new section on the impact of media security. o Added a new section on the impact of media security.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Flavio Battimo and Pierluigi Palma The authors would like to thank Flavio Battimo and Pierluigi Palma
for their invaluable feedback in the early stages of the document. for their invaluable feedback in the early stages of the document.
The authors would also like to thank Colin Perkins, Bernard Aboba, The authors would also like to thank Colin Perkins, Bernard Aboba,
skipping to change at page 15, line 25 skipping to change at page 15, line 15
[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
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>.
9.2. Informative References 9.2. Informative References
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents", Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013, RFC 7092, DOI 10.17487/RFC7092, December 2013,
<http://www.rfc-editor.org/info/rfc7092>. <http://www.rfc-editor.org/info/rfc7092>.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
DOI 10.17487/RFC5117, January 2008,
<http://www.rfc-editor.org/info/rfc5117>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015, DOI 10.17487/RFC7667, November 2015,
<http://www.rfc-editor.org/info/rfc7667>. <http://www.rfc-editor.org/info/rfc7667>.
[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>.
[I-D.alvestrand-rmcat-remb] [I-D.alvestrand-rmcat-remb]
Alvestrand, H., "RTCP message for Receiver Estimated Alvestrand, H., "RTCP message for Receiver Estimated
Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in
progress), October 2013. progress), October 2013.
[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>.
skipping to change at page 17, line 36 skipping to change at page 17, line 21
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
DOI 10.17487/RFC4588, July 2006, DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>. <http://www.rfc-editor.org/info/rfc4588>.
[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>.
[I-D.ietf-straw-b2bua-dtls-srtp]
R, R., Reddy, T., Salgueiro, G., Pascual, V., and P.
Ravindran, "DTLS-SRTP Handling in Session Initiation
Protocol (SIP) Back-to-Back User Agents (B2BUAs)", draft-
ietf-straw-b2bua-dtls-srtp-12 (work in progress), April
2016.
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. 58 change blocks. 
244 lines changed or deleted 241 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/