draft-ietf-straw-b2bua-rtcp-10.txt   draft-ietf-straw-b2bua-rtcp-11.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 21, 2016 Medooze Expires: December 2, 2016 Medooze
V. Pascual V. Pascual
Quobis Quobis
April 19, 2016 May 31, 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-10 draft-ietf-straw-b2bua-rtcp-11
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, thus
to act as media transcoders or to just passthrough the media leading to separate multimedia sessions that the B2BUA correlates and
themselves, thus leading to separate multimedia sessions that the bridges together. If not disciplined, though, this behaviour can
B2BUA correlates and bridges together. If not disciplined, though, 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 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 21, 2016. This Internet-Draft will expire on December 2, 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . . . 10 3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 10
4. Media Path Security . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 12
7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Session Initiation Protocol [RFC3261] Back-to-Back User Agents Session Initiation Protocol [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 completelely adherent to the such, their behaviour is not always completely adherent to the
standards, and can lead to unexpected situations the IETF is trying standards, and can lead to unexpected situations. [RFC7092] presents
to address. [RFC7092] presents a taxonomy of the most deployed B2BUA a taxonomy of the most commonly deployed B2BUA implementations,
implementations, describing how they differ in terms of the describing how they differ in terms of the functionality and features
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, 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, in order to receive and manage all RTP
two or more participants willing to communicate, such components also and RTCP [RFC3550] packets in a session, these components also
manipulate the session description [RFC4566], in order to have all manipulate the session descriptions [RFC4566] in the related offer/
RTP and RTCP [RFC3550] pass through it as well within the context of answer exchanges [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 [RFC7667].
communication, as documented in [RFC7667]. These topologies are
currently being updated to address new commonly encountered scenarios
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. While
their effectiveness may be affected as a consequence. While this may this may not be a problem for RTP packets, which can be quite easily
not be a problem for RTP packets, which can be quite easily relayed, relayed, it definitely can cause serious issue for RTCP messages,
it definitely can cause serious issue for RTCP messages, which carry which carry important information and feedback on the communication
important information and feedback on the communication quality the quality the participants are experiencing. Consider, for instance,
participants are experiencing. Consider, for instance, the simple the simple scenario only involving two participants and a single RTP
scenario only involving two participants and a single RTP session session depicted in Figure 1:
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, the
also rewriting some of the RTP header information on the way, for B2BUA is also rewriting some of the RTP header information on the
instance because that's how its RTP relaying stack works: in this way. In this example, just the SSRC of the incoming RTP streams is
example, just the SSRC of the incoming RTP audio streams is changed, changed, but more information may be modified as well (e.g., sequence
but more information may be changed as well (e.g., sequence numbers, numbers, timestamps, etc.). In particular, whenever Alice sends an
timestamps, etc.). In particular, whenever Alice sends an audio RTP RTP packet, she sets her SSRC (SSRC1) in the RTP header of her RTP
packet, she sets her SSRC (SSRC1) in the RTP header of her RTP source source stream. The B2BUA rewrites the SSRC (SSRC3) before relaying
stream. The B2BUA rewrites the SSRC (SSRC3) before relaying the the packet to Bob. At the same time, RTP packets sent by Bob (SSRC4)
packet to Bob. At the same time, RTP packets sent by Bob (SSRC4) get get their SSRC rewritten as well (SSRC2) before being relayed to
their SSRC rewritten as well (SSRC2) before being relayed to Alice. 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, she will place the related packets in the last few seconds, she will place the related received
received RTP stream SSRC she is aware of (SSRC2), together with her RTP stream SSRC she is aware of (SSRC2), together with her own
own (SSRC1), in RTCP Reports and/or NACKs. Since the B2BUA is making (SSRC1), in RTCP Reports and/or NACKs. Since the B2BUA is making use
use of different SSRCs for the RTP streams in the RTP session it of different SSRCs for the RTP streams in the RTP session it
established with each participant, a blind relaying of these RTCP established with each participant, blindly relaying Alice's incoming
messages to Bob would in this case result, from Bob's perspective, in RTCP messages to Bob would cause issues. These RTCP messages would
unknown SSRCs being addressed, thus resulting in the precious reference SSRCs Bob doesn't know about, which would result in
information being dropped. In fact, Bob is only aware of SSRCs SSRC4 precious feedback being dropped. In fact, Bob is only aware of SSRCs
(the one his source RTP stream uses) and SSRC3 (the one he's SSRC4 (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 SSRCs SSRC1 and SSRC2 in the messages he received
instead. As a consequence of the feedback being dropped, unaware of instead. Considering the feedback being dropped because of this may
the issue Bob may continue to flood Alice with even more media contain precious information, e.g., related to packet loss,
packets and/or not retransmit Alice the packets she missed. This may congestion, and other network issues or considerations, the inability
to take them into account may lead to severe issues. For instance,
Bob may flood Alice with more media packets she can handle, and/or
not retransmit Alice the packets she missed and asked for. This may
easily lead to a very bad communication experience, if not eventually easily lead to a very bad communication experience, if not eventually
to an unwanted termination of the communication itself. 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 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
such feedback, 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 anything they're not supposed to. plane do not break or interfere with anything relevant to the
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 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 described in the introductory section, it's very common for B2BUA
B2BUA deployments to also act on the media plane, rather than just 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: a B2BUA, in fact, may act as a simple categories of such B2BUAs: 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 messages 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 (3), terminating and generating RTP and RTCP
messages as needed. messages as needed.
While [RFC3550] and [RFC7667] already mandate some specific While [RFC3550] and [RFC7667] already mandate some specific
behaviours in the presence of certain topologies, not all deployments behaviours in the presence of certain topologies, not all deployments
strictly adhere to the specifications. As such, it's not rare to strictly adhere to the specifications. This means that it's not rare
encounter issues that may be avoided with a more disciplined to 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 not to impact any end-to-end they fall in, should follow in order not to impact any 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], simply forwards all RTP
all RTP and RTCP messages it receives, without either inspecting or and RTCP messages it receives, without either inspecting or modifying
modifying them. Using the RTP Topologies terminology, this can be them. Using the RTP Topologies terminology, this can be seen as a
seen as a RTP Transport Translator. As such, B2BUA acting as media RTP Transport Translator. As such, B2BUA acting as media relays are
relays are not aware of what traffic they're handling. This means not aware of what traffic they're handling. This means that both
that both packet payloads and packet headers are opaque to them. packet payloads and packet headers are opaque to them. 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 still happen, section would not occur. Similar problems could still happen,
though, for different reasons, as for instance if the session though, for different reasons, as for instance if the session
description ends up providing incorrect information. This may description prepared by the B2BUA, whether it has been modified or
happen, for example, if the SDP on either side contains 'ssrc' not, ends up providing incorrect information. This may happen, for
[RFC5576] attributes that don't match the actual SSRC being example, if the SDP on either side contains 'ssrc' [RFC5576]
advertized on the media plane, or in case the B2BUA advertized attributes that don't match the actual SSRC being advertized on the
support for NACK because it implements it, while the original INVITE media plane, or when the B2BUA advertized support for NACK because it
didn't. Such issues might occur, for instance, in case the B2BUA implements it, while the original INVITE didn't. Such issues might
acting as a media relay is generating a new session description when occur, for instance, when the B2BUA acting as a media relay is
bridging an incoming call, rather than taking into account the generating a new session description when bridging an incoming call,
original session description. This may cause participants to find a rather than using the original session description. This may cause
mismatch between the SSRCs advertized in SDP and the ones actually participants to find a mismatch between the SSRCs advertized in the
observed in RTP and RTCP messages (which may indeed change during a SDP and the ones actually observed in RTP and RTCP messages, or to
multimedia session anyway, but having them synced during setup would have them either ignore or generate RTCP feedback packets that were
help nonetheless), or to have them either ignore or generate RTCP 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 participants: this includes
includes attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr-
'rtcp-xr-attrib' [RFC3611] and others. It SHOULD NOT, though, attrib' [RFC3611] and others. It SHOULD NOT, though, blindly forward
blindly forward all SDP attributes, as some of them (e.g., all SDP attributes, as some of them (e.g., candidates, fingerprints,
candidates, fingerprints, crypto, etc.) may lead to call failures for crypto, etc.) may lead to call failures for different reasons out of
different reasons out of scope to this document. One notable example scope to this document. One notable example is the 'rtcp' [RFC3605]
is the 'rtcp' [RFC3605] attribute, that UAC may make use of to attribute, that UAC may make use of to explicitly state the port
explicitly state the port they're willing to use for RTCP. they're willing to use for RTCP. Considering the B2BUA would relay
Considering the B2BUA would relay RTCP messages, the port as seen by RTCP messages, the port as seen by the other UAC involved in the
the other UAC involved in the communication would differ from the one communication would differ from the one negotiated originally, and it
negotiated originally, and as such it MUST be rewritten accordingly. MUST be rewritten accordingly.
It is worth mentioning that, leaving RTCP messages 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 leak information that, according to policies, may need
may be best left hidden or masqueraded, e.g., domain names in CNAME to be hidden or masqueraded, e.g., domain names in CNAME items.
items. Besides, these CNAME items may actually contain IP addresses Besides, these CNAME items may actually contain IP addresses: this
instead: this means that, should a NAT be involved in the means that, should a NAT be involved in the communication, this may
communication, this may actually result in CNAME collisions, which actually result in CNAME collisions, which could indeed break the
could indeed break the end-to-end RTCP behaviour. While [RFC7022] end-to-end RTCP behaviour. While [RFC7022] can prevent this from
can prevent this from happening, there may be implementations that happening, there may be implementations that don't make use of it.
don't make use of it. As such, a B2BUA MAY rewrite CNAME items if As such, a B2BUA MAY rewrite CNAME items if any potential collision
any potential collision is detected, even in the Media Relay case. is detected, even in the Media Relay case. If a B2BUA does indeed
If a B2BUA does indeed decide to rewrite CNAME items, though, then it decide to rewrite CNAME items, though, then it MUST generate new
MUST generate new CNAMEs following [RFC7022]. 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 aware of the media traffic it is handling. This
handling. As such, it is able to inspect RTP and RTCP messages means it inspects RTP and RTCP messages flowing by, and may even
flowing by, and may even be able to modify their headers. Using the modify their headers. 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, though,
implementing this role, though, typically does not inspect the RTP typically does not inspect the RTP payloads, which would be opaque to
payloads as well, which would be opaque to them: this means that the them: this means that the actual media would not be manipulated (e.g,
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 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/CSRC, sequence numbers, timestamps and others in an RTP like SSRC/CSRC, sequence numbers, timestamps and others in an RTP
stream, before forwarding the modified packets to the other stream, before forwarding the modified packets to the other
interested participants. This means that, if not properly interested participants. 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. For this reason, it is very
for a B2BUA modifying RTP-related information across two related RTP important for a B2BUA modifying RTP-related information across two
streams to also modify, in a coherent way, the same information in related RTP streams to also modify, in a coherent way, the same
RTCP messages as well. information in RTCP messages.
It is worthwile to point out that such a B2BUA may not necessarily It is worthwile to point out that such a B2BUA may not necessarily
forward all the packets it is receiving, though. Selective forward all the packets it receives, though. Selective Forwarding
Forwarding Units (SFU) [RFC7667], for instance, may aggregate or drop Units (SFU) [RFC7667], for instance, may aggregate or drop incoming
incoming RTCP messages, while at the same time originating new ones RTCP messages, while at the same time originating new ones on their
on their own. For the messages that are forwarded and/or aggregated, own. For the messages that are forwarded and/or aggregated, though,
though, it's important to make sure the information is coherent. 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 handle incoming
incoming RTCP messages to forward following this guideline: RTCP messages to forward following this guideline:
SR: [RFC3550] 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 sequence number when forwarding RTP packets, then this change
needs to be properly addressed in the 'extended highest sequence needs to be properly addressed in the 'extended highest sequence
skipping to change at page 8, line 16 skipping to change at page 8, line 13
also changed the base RTP sequence number when forwarding RTP also changed the base RTP sequence number when forwarding RTP
packets, then this change needs to be properly addressed in the packets, then this change needs to be properly addressed in the
'begin_seq' and 'end_seq' fields that are available in most of the 'begin_seq' and 'end_seq' fields that are available in most of the
Report Block types that are part of the XR specification. 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 of RTP streams addressed in a If the B2BUA has changed any SSRC of RTP streams addressed in a
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, in case a Collision sender participant, the summarized SSRC and, when a Collision Sub-
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 in case the message is participant, and the Requesting Client SSRC when the message is a
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 feedack 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, though, 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. Besides, considering that many feedback messages rewriting apply. Considering that many feedback messages also
also include additional data as part of their specific Feedback include additional data as part of their specific Feedback Control
Control Information (FCI), a media-aware B2BUA MUST take care of Information (FCI), a media-aware B2BUA MUST take care of them
them accordingly, if it can parse and regenerate them, according accordingly, if it can parse and regenerate them, according to the
to the following guidelines. following guidelines:
NACK: [RFC4585] NACK: [RFC4585]
Besides the common packet format management for feedback messages, A media-aware B2BUA MUST 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.
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, A media-aware B2BUA MUST properly rewrite the additional SSRC
a media-aware B2BUA MUST also 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 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, A media-aware B2BUA MUST properly rewrite the additional SSRC
a media-aware B2BUA MUST also properly rewrite the additional SSRC identifier(s) in REMB packets, if it changed the related RTP
identifier(s) in REMB packets, if it changed the related RTP SSRC 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, The same guidelines given for SR/RR management apply,
the same guidelines given for SR/RR management apply as well, considering the presence of sequence numbers in the ECN
considering the presence of sequence numbers in the ECN Feedback Feedback Report format. For what concerns the management of
Report format. For what concerns 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 XR 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.
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 applies to media-aware B2BUAs. This
This means that, if a B2BUA is going to change any SSRC, it SHOULD means that, if a B2BUA changes any SSRC, it MUST update the related
update the related 'ssrc' attributes, if present, before sending it 'ssrc' attributes, if present, before sending it to the recipient.
to the recipient. Besides, it MUST rewrite the 'rtcp' attribute if Besides, it MUST rewrite the 'rtcp' attribute if provided. At the
provided. At the same time, while a media-aware B2BUA is typically same time, while a media-aware B2BUA is typically able to inspect/
able to inspect/modify RTCP messages, it may not support all RTCP modify RTCP messages, it may not support all RTCP messages. This
messages. This means that a B2BUA may choose to drop RTCP messages means that a B2BUA may choose to drop RTCP messages it can't parse.
it can't parse. In that case, a media-aware B2BUA MUST also In that case, a media-aware B2BUA MUST advertize its RTCP level of
advertize its RTCP level of support in the SDP in a coherent way, in support in the SDP in a coherent way, in order to prevent, for
order to prevent, for instance, a UAC to make use of NACK messages instance, a UAC to from sending NACK messages that would never reach
that would never reach the intended recipients. It's important to the intended recipients. It's important to point out that, in case a
point out that, in case any RTCP message needs to be dropped, then compound RTCP packet was received and any RTCP message in it needs to
the B2BUA SHOULD NOT drop the whole compound RTCP message it may be dropped, then the B2BUA SHOULD NOT drop the whole compound RTCP
belong to, but only the RTCP message itself. packet, but only the selected messages.
A different set of considerations, instead, is worthwhile for what A different set of considerations is worthwhile for what concerns
concerns RTP/RTCP multiplexing [RFC5761] and Reduced-Size RTCP RTP/RTCP multiplexing [RFC5761] and Reduced-Size RTCP [RFC5506].
[RFC5506]. While the former allows for a better management of While the former allows for a better management of network resources
network resources by multiplexing RTP packets and RTCP messages over by multiplexing RTP packets and RTCP messages over the same
the same transport, the latter allows for a compression of RTCP transport, the latter allows for a compression of RTCP messages, thus
messages, thus leading to less network traffic. For what concerns leading to less network traffic. For what concerns RTP/RTCP
RTP/RTCP multiplexing, a B2BUA acting as a Media Relay may use it on multiplexing, a B2BUA acting as a Media Relay may use it on either
either RTP session independently. This means that, for instance, a RTP session independently. This means that, for instance, a Media
Media Relay B2BUA may use RTP/RTCP multiplexing on one side of the 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 the endpoint does
supported. This allows for a better management of network resources not support it. This allows for a better management of network
on the side that does support it. In case any of the parties in the resources on the side that does support it. In case any of the
communications supports it and the B2BUA does too, the related 'rtcp- parties in the communications supports it and the B2BUA does too, the
mux' SDP attribute MUST be forwarded on the other side(s). If the related 'rtcp-mux' SDP attribute MUST be forwarded on the other
B2BUA detects that any of the parties in the communication does not side(s). If the B2BUA detects that any of the parties in the
support the feature, it may decide to either disable it entirely or communication do not support the feature, it may decide to either
still advertize it for the RTP sessions with parties that do support disable it entirely or still advertize it for the RTP sessions with
it. In case the B2BUA decides to involve RTP/RTCP multiplexing, it parties that do support it. In case the B2BUA decides to involve
MUST ensure that there are no conflicting RTP payload type numbers on RTP/RTCP multiplexing, it MUST ensure that there are no conflicting
both sides. In case there are, it MUST rewrite RTP payload type RTP payload type numbers on either side. When there are, it MUST
numbers to ensure no conflict in the domain where the RTP/RTCP rewrite RTP payload type numbers to prevent conflicts in the session
multiplexing is applied. Should RTP payload types be rewritten, the where the RTP/RTCP multiplexing is applied. Should RTP payload types
related information in the SDP MUST be updated accordingly. be rewritten, the 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 available bandwidth is different on the two counterproductive if the available bandwidth is different on the two
sides. That said, the B2BUA can choose whether or not to advertize sides. That said, the B2BUA can choose whether or not to advertize
support for Reduced-Size RTCP on either side by means of the 'rtcp- support for Reduced-Size RTCP on either side by means of the 'rtcp-
rsize' SDP attribute. Should a B2BUA decide to allow the sides to rsize' SDP attribute. Negotiating a session with both sides would
independently use Reduced-Size or not, then the B2BUA MUST advertize allow the B2BUA to discover which one supports Reduced-Size and which
support for the feature on the sides that support it, and MUST NOT doesn't, and in case decide whether to allow the sides to
advertize it on the sides that don't, by removing the related independently use Reduced-Size or not. Should the B2BUA decide to
attribute from the SDP before forwarding it. Should the B2BUA decide disable the feature on all sides, it MUST NOT advertize support for
to disable the feature on all sides, instead, it MUST NOT advertize the Reduced-Size RTCP functionality on either side, by removing the
support for the Reduced-Size RTCP functionality on either side, by 'rtcp-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. As such, it can inspect and/ is also able to terminate media itself. As such, it can inspect and/
or modify RTP payloads as well. This means that such components, for or modify RTP payloads as well. This means that such components, for
instance, can act as media transcoders and/or originate specific RTP instance, can act as media transcoders and/or originate specific RTP
media. Using the RTP Topologies terminology, this can be seen as a media. Using the RTP Topologies terminology, this can be seen as a
RTP Media Translator. Such a topology can also be seen as a Back-to- RTP Media Translator. Such a topology can also be seen as a Back-to-
back RTP sessions through a Middlebox, as described in Section 3.2.2 back RTP sessions through a Middlebox, as described in Section 3.2.2
skipping to change at page 11, line 16 skipping to change at page 11, line 8
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 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 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 also
apply for a Media Terminator as well. Some different considerations apply for a Media Terminator. Some different considerations might be
might be given as to the Reduced-Size RTCP functionality, instead: in given as to the Reduced-Size RTCP functionality, instead. In fact,
fact, in the Media Terminator case it is safe to use the feature in the Media Terminator case it is safe to use the feature
independently on each side. In that case, the same considerations independently on each side, as the B2BUA would terminate RTCP. In
about advertizing the support, or lack of, of the feature on either that case, the B2BUA SHOULD advertize and negotiate support for
side as described for the Media Relay case apply here as well. Reduced-Size if available, and MUST NOT otherwise.
4. Media Path Security 4. IANA Considerations
This document makes no request of IANA.
5. Security Considerations
This document, does not introduce any additional consideration to
those described by the aforementioned standard documents. There are
some aspects related to security that should be highlighted, though.
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 worked under the assumption that the B2BUA
assumption that the B2BUA has actually access to the RTP/RTCP has actually access to the RTP/RTCP information itself. This is
information itself. This is indeed true if we assume that plain RTP indeed true if we assume that plain RTP and RTCP is being handled,
and RTCP is being handled, but may not be once any security is but may not be once any security is enforced on RTP packets and RTCP
enforced on RTP packets and RTCP messages by means of SRTP [RFC3711]. messages by means of 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 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 envisage a SRTP/SRTCP session across a B2BUA, where example, if we envisage a SRTP/SRTCP session across a B2BUA, where
the B2BUA itself has no access to the keys used to secure the the B2BUA itself has no access to the keys used to secure the
session, there would be no way to manipulate SRTP headers without session, there would be no way to manipulate SRTP headers without
violating the hashing on the packet. At the same time, there would violating the hashing on the packet. At the same time, there would
be no way to rewrite the RTCP information accordingly either. 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, in case 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 unaware Relay scenario can be properly addressed. Attempting to
cover Media-aware Relay and Media Terminarion scenarios when cover Media-aware Relay and Media Termination 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 consequently its behaviour is unspecified
discouraged. More considerations on this are provided in and discouraged. More considerations on this are provided in
[I-D.ietf-straw-b2bua-dtls-srtp]. [I-D.ietf-straw-b2bua-dtls-srtp].
5. IANA Considerations It is also worth pointing out that there are scenarios where an
This document makes no request of IANA.
6. Security Considerations
This document, being a summary and a best common practice overview
that covers different standards, does not introduce any additional
consideration to those described by the aforementioned standard
documents.
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 or misleading information to its for a user, may lead to missing or misleading information to its
peer. This may cause the peer to increase the encoder bitrate, maybe peer. This may cause the peer to increase the encoder bitrate, maybe
up to a point where a user with poor connectivity will inevitably be up to a point where a user with poor connectivity will inevitably be
choked by an amount of data it cannot process. This scenario may as choked by an amount of data it cannot process. This scenario may
such result in what looks like a Denial of Service (DOS) attack thus result in what looks like a Denial of Service (DOS) attack
towards the user. towards the user.
7. Change Summary 6. 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 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 The following are the major changes between the 09 and the 10
versions of the draft: versions of the draft:
o Replaced references to obsoleted RFC 5117 with [RFC7667]. o Replaced references to obsoleted RFC 5117 with [RFC7667].
o Made reference to [RFC7656] normative. o Made reference to [RFC7656] normative.
o Clarified text across the whole document to address Ben's review. 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
skipping to change at page 14, line 25 skipping to change at page 14, line 19
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 message 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 7. 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,
Albrecht Schwarz, Hadriel Kaplan, Keith Drage, Jonathan Lennox, Albrecht Schwarz, Hadriel Kaplan, Keith Drage, Jonathan Lennox,
Stephen Farrell, Magnus Westerlund and Simon Perreault for their Stephen Farrell, Magnus Westerlund and Simon Perreault for their
constructive comments, suggestions, and reviews that were critical to constructive comments, suggestions, and reviews that were critical to
the formulation and refinement of this document. the formulation and refinement of this document.
9. References 8. References
9.1. Normative References 8.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,
skipping to change at page 15, line 21 skipping to change at page 15, line 16
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 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>. <http://www.rfc-editor.org/info/rfc7656>.
9.2. Informative References 8.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>.
[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>.
skipping to change at page 16, line 36 skipping to change at page 16, line 31
[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>.
[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>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
<http://www.rfc-editor.org/info/rfc4568>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010, DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>. <http://www.rfc-editor.org/info/rfc5761>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <http://www.rfc-editor.org/info/rfc5506>. 2009, <http://www.rfc-editor.org/info/rfc5506>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
DOI 10.17487/RFC4588, July 2006,
<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] [I-D.ietf-straw-b2bua-dtls-srtp]
R, R., Reddy, T., Salgueiro, G., Pascual, V., and P. R, R., Reddy, T., Salgueiro, G., Pascual, V., and P.
Ravindran, "DTLS-SRTP Handling in Session Initiation Ravindran, "DTLS-SRTP Handling in Session Initiation
Protocol (SIP) Back-to-Back User Agents (B2BUAs)", draft- Protocol (SIP) Back-to-Back User Agents (B2BUAs)", draft-
ietf-straw-b2bua-dtls-srtp-12 (work in progress), April ietf-straw-b2bua-dtls-srtp-12 (work in progress), April
 End of changes. 51 change blocks. 
266 lines changed or deleted 244 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/