draft-ietf-straw-b2bua-rtcp-01.txt   draft-ietf-straw-b2bua-rtcp-02.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: December 22, 2014 Medooze Expires: April 27, 2015 Medooze
V. Pascual V. Pascual
Quobis Quobis
June 20, 2014 October 24, 2014
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-01 draft-ietf-straw-b2bua-rtcp-02
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 media legs that the B2BUA themselves, thus leading to separate multimedia sessions that the
correlates and bridges together. If not disciplined, though, this B2BUA correlates and bridges together. If not disciplined, though,
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. packets 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
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 December 22, 2014. This Internet-Draft will expire on April 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Signalling/Media Plane B2BUAs . . . . . . . . . . . . . . . . 4 3. Signalling/Media Plane B2BUAs . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . 9 3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 9
4. Media Path Security . . . . . . . . . . . . . . . . . . . . . 9 4. Media Path Security . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 10 7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 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 parties 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 RTP
and RTCP [RFC3550] pass through it as well within the context of an and RTCP [RFC3550] pass through it as well within the context of an
SDP offer/answer [RFC3264]. The reasons for such a behaviour can be SDP offer/answer [RFC3264]. The reasons for such a behaviour can be
different: the B2BUA may want, for instance, to provide transcoding different: the B2BUA may want, for instance, to provide transcoding
functionality for peers with incompatible codecs, or it may need the functionality for participants with incompatible codecs, or it may
traffic to be directly handled for different reasons like billing, need the traffic to be directly handled for different reasons like
lawful interception, session recording and so on. This can lead to billing, lawful interception, session recording and so on. This can
several different topologies for RTP-based communication, as lead to several different topologies for RTP-based communication, as
documented in [RFC5117]. These topologies are currently being documented in [RFC5117]. These topologies are currently being
updated to address new commonly encountered scenarios as well updated to address new commonly encountered scenarios as well
[I-D.ietf-avtcore-rtp-topologies-update]. [I-D.ietf-avtcore-rtp-topologies-update].
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 peers that want to communicate by means of RTP/RTCP, the between two or more participants that want to communicate by means of
end-to-end nature of such protocols is broken, and their RTP/RTCP, the end-to-end nature of such protocols is broken, and
effectiveness may be affected as a consequence. While this may not their effectiveness may be affected as a consequence. While this may
be a problem for RTP packets, which from a protocol point of view not be a problem for RTP packets, which from a protocol point of view
just contain opaque media packets and as such can be quite easily just contain opaque media packets and as such can be quite easily
relayed, it definitely can cause serious issue for RTCP packets, relayed, it definitely can cause serious issue for RTCP packets,
which carry important information and feedback on the communication which carry important information and feedback on the communication
quality the peers are experiencing. In fact, RTCP packets make use quality the participants are experiencing. In fact, RTCP packets
of specific ways to address the media they are referring to. make use of specific ways to address the media they are referring to.
Consider, for instance, the simple scenario only involving two Consider, for instance, the simple scenario only involving two
parties and a single media flow depicted in Figure 1: 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 party (Alice) is communicating with a peer In this common scenario, a participant (Alice) is communicating with
(Bob) as a result of a signalling session managed by a B2BUA: this another participant (Bob) as a result of a signalling session managed
B2BUA is also on the media path between the two, and is acting as a by a B2BUA: this B2BUA is also on the media path between the two, and
media relay. It is also, though, rewriting some of the RTP header is acting as a media relay. This means that two separate RTP
information on the way, for instance because that's how its RTP sessions are involved (one per side), each carrying two RTP streams
relaying stack works: in this example, just the audio SSRC is (one per media direction). As part of this process, though, it is
changed, but more information may be changed as well (e.g., sequence also rewriting some of the RTP header information on the way, for
numbers, timestamps, etc.). In particular, whenever Alice sends an instance because that's how its RTP relaying stack works: in this
audio RTP packet, she adds her SSRC (SSRC1) to the RTP header; the example, just the SSRC of the incoming RTP audio streams is changed,
B2BUA rewrites the SSRC (SSRC3) before relaying the packet to Bob. At but more information may be changed as well (e.g., sequence numbers,
the same time, RTP packets sent by Bob (SSRC4) get their SSRC timestamps, etc.). In particular, whenever Alice sends an audio RTP
rewritten as well (SSRC2) before being relayed to Alice. packet, she sets her SSRC (SSRC1) to the RTP header of her RTP source
stream; the B2BUA rewrites the SSRC (SSRC3) before relaying the
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.
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, maybe because of a network
congestion, she would of course place the related peer audio SSRC she congestion, she would of course place the related received RTP stream
is aware of (SSRC2), together with her own (SSRC1), in RTCP Reports SSRC she is aware of (SSRC2), together with her own (SSRC1), in RTCP
and/or NACKS to do so, hoping for a retransmission or for Bob to slow Reports and/or NACKS to do so, hoping for a retransmission or for Bob
down. Since the B2BUA is making use of different SSRCs for the RTP to slow down. Since the B2BUA is making use of different SSRCs for
communication with the party and the peer, a blind relaying of the the RTP streams in the RTP session it established with each
RTCP packets to Bob would in this case result, from his perspective, participant, a blind relaying of the RTCP packets to Bob would in
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 he's originating) and SSRC3 (the one he's receiving from the In fact, Bob is only aware of SSRCs SSRC4 (the one his source RTP
B2BUA), and knows nothing about SSRCs SSRC1 and SSRC2 in the RTCP stream uses) and SSRC3 (the one he's receiving from the B2BUA in the
packets he receives. As a consequence of the feedback being dropped, received RTP stream), and knows nothing about SSRCs SSRC1 and SSRC2
unaware of the issue Bob may continue to flood the party with even in the RTCP packets he would receive instead. As a consequence of
more media packets and/or not send Alice the packets she misses, the feedback being dropped, unaware of the issue Bob may continue to
which may easily lead to a very bad communication experience, if not flood Alice with even more media packets and/or not retransmit Alice
eventually to an unwanted termination of the communication itself. the packets she missed, which may easily lead to a very bad
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 trivial mishandling
of precious information may lead to serious consequences, especially of precious information may lead to serious consequences, especially
considering that more complex scenarios may involve several parties considering that more complex scenarios may involve several
at the same time and multiple media flows rather than a single one. participants at the same time, multiple RTP sessions (e.g., a video
Considering how common B2BUA deployments are, it is very important stream along audio) rather than a single one, redundancy RTP streams,
for them to properly address such feedback, in order to be sure that SSRC multiplexing and so on. Considering how common B2BUA
their activities on the media plane do not break anything they're not deployments are, it is very important for them to properly address
supposed to. such feedback, in order to be sure that their activities on the media
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
terminology as disciplined in
[I-D.ietf-avtext-rtp-grouping-taxonomy].
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, according to the level of activities
performed on the media plane: 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 packets as they flow by; or it may be a full-fledged
skipping to change at page 5, line 38 skipping to change at page 5, line 51
section would not occur. Similar problems could occur, though, section would not occur. Similar problems could occur, though,
should the session description end up providing incorrect information should the session description end up providing incorrect information
about the media flowing (e.g., if the SDP on either side contain about the media flowing (e.g., if the SDP on either side contain
'ssrc' [RFC5576] attributes that don't match the actual SSRC being 'ssrc' [RFC5576] attributes that don't match the actual SSRC being
advertized on the media plane) or about the supported RTCP mechanisms advertized on the media plane) or about the supported RTCP mechanisms
(e.g., in case the B2BUA advertized support for NACK because it (e.g., in case the B2BUA advertized support for NACK because it
implements it, but the original INVITE didn't). Such an issue might implements it, but the original INVITE didn't). Such an issue might
occur, for instance, in case the B2BUA acting as a media relay is occur, for instance, in case the B2BUA acting as a media relay is
generating a new session description when bridging an incoming call, generating a new session description when bridging an incoming call,
rather than taking into account the original session description in rather than taking into account the original session description in
the first place. This may cause the peers to find a mismatch between the first place. This may cause the participants to find a mismatch
the SSRCs advertized in SDP and the ones actually observed in RTP and between the SSRCs advertized in SDP and the ones actually observed in
RTCP packets (which may indeed change during a session anyway, but RTP and RTCP packets (which may indeed change during a multimedia
having them synced during setup would help nonetheless), or having session anyway, but having them synced during setup would help
them either ignore or generate RTCP feedback packets that were not nonetheless), or having them either ignore or generate RTCP feedback
explicitly advertized as supported. 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 session all the SSRC- and RTCP-related SDP attributes when handling a
setup between interested parties: this includes attributes like multimedia session setup between interested participants: this
'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr-attrib' [RFC3611] and includes attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585],
others. It SHOULD NOT, though, blindly forward all SDP attributes, 'rtcp-xr-attrib' [RFC3611] and others. It SHOULD NOT, though,
as some of them (e.g., candidates, fingerprints, crypto, etc.) may blindly forward all SDP attributes, as some of them (e.g.,
lead to call failures for different reasons out of scope to this candidates, fingerprints, crypto, etc.) may lead to call failures for
document. One notable example is the 'rtcp' [RFC3605] attribute that different reasons out of scope to this document. One notable example
UAC may make use of to explicitly state the port they're willing to is the 'rtcp' [RFC3605] attribute that UAC may make use of to
use for RTCP: considering the B2BUA would relay RTCP packets, the explicitly state the port they're willing to use for RTCP:
port as seen by the other UAC involved in the communication would considering the B2BUA would relay RTCP packets, the port as seen by
differ from the one negotiated originally, and as such it MUST be the other UAC involved in the communication would differ from the one
rewritten accordingly. negotiated originally, and as such it MUST be rewritten accordingly.
Besides, it is worth mentioning that, leaving RTCP packets untouched, Besides, it is worth mentioning that, leaving RTCP packets untouched,
a media relay may also let through information that, according to a media relay may also let through information that, according to
policies, may be best left hidden or masqueraded, e.g., domain names policies, may be best left hidden or masqueraded, e.g., domain names
in CNAME items. Nevertheless, that information cannot break the end- in CNAME items. Nevertheless, that information cannot break the end-
to-end RTCP behaviour. to-end RTCP behaviour.
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
skipping to change at page 6, line 33 skipping to change at page 6, line 46
seen as a RTP Translator. A B2BUA implementing this role would seen as a RTP Translator. A B2BUA implementing this role would
typically not, though, inspect the RTP payloads as well, which would typically not, though, inspect the RTP payloads as well, which would
be opaque to them: this means that the actual media would not be be opaque to them: this means that the 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 (and hence CSRC lists, that must of course be updated
accordingly), sequence numbers, timestamps and the like before accordingly), sequence numbers, timestamps and the like in an RTP
forwarding packets from one peer to another. This means that, if not stream, before forwarding the modified packets to the other
properly disciplined, such a behaviour may easily lead to issues like interested participants in the multimedia sessions on the RTP streams
the one described in the introductory section. As such, it is very they're using to receive the media. This means that, if not properly
important for a B2BUA modifying RTP-related information to also disciplined, such a behaviour may easily lead to issues like the one
modify the same information in RTCP packets as well, and in a described in the introductory section. As such, it is very important
coherent way, so that not to confuse any of the peers involved in a for a B2BUA modifying RTP-related information across two related RTP
communication. streams to also modify the same information in RTCP packets as well,
and in a coherent way, so that not to confuse any of the participants
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 would not necessarily
forward all the packets it is receiving, though: Selective Forwarding forward all the packets it is receiving, though: Selective Forwarding
Units (SFU) [I-D.ietf-avtcore-rtp-topologies-update], for instance, Units (SFU) [I-D.ietf-avtcore-rtp-topologies-update], for instance,
could aggregate or drop incoming RTCP messages, while at the same could aggregate or drop incoming RTCP messages, while at the same
time originating new ones on their own. For the messages that are time originating new ones on their own. For the messages that are
forwarded and/or aggregated, though, it's important to make sure the forwarded and/or aggregated, though, it's important to make sure the
information is coherent. information is coherent.
Besides the behaviour already mandated for RTCP translators in Besides the behaviour already mandated for RTCP translators in
Section 7.2 of [RFC3550], a media-aware B2BUA MUST 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 direction, it MUST update If the B2BUA has changed any SSRC in any RTP streams relation, it
the SSRC-related information in the incoming SR packet before MUST update the SSRC-related information in the incoming SR packet
forwarding it. This includes the sender SSRC, which MUST be before forwarding it. This includes the sender SSRC, which MUST
rewritten with the one the B2BUA uses to send RTP packets to the be rewritten with the one the B2BUA uses in the RTP stream used to
sender peer, and the SSRC information in all the blocks, which receive RTP packets from each participant, and the SSRC
MUST be rewritten using the related sender peer(s) SSRC. If the information in all the blocks, which MUST be rewritten using the
B2BUA has also changed the base RTP sequence number when related sender participant(s) SSRC. If the B2BUA has also changed
forwarding RTP packets, then this change needs to be properly the base RTP sequence number when forwarding RTP packets, then
addressed in the 'extended highest sequence number received' field this change needs to be properly addressed in the 'extended
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 any SSRC in any direction, it MUST update
the SSRC-related information in all the chunks in the incoming the SSRC-related information in all the chunks in the incoming
SDES packet before forwarding it. SDES packet before forwarding it.
BYE: [RFC3550] BYE: [RFC3550]
skipping to change at page 7, line 44 skipping to change at page 8, line 8
If the B2BUA has changed any SSRC in any direction, it MUST update If the B2BUA has changed any SSRC in any direction, it MUST update
the SSRC in the BYE message. Should the B2BUA be aware of any the SSRC in the BYE message. Should the B2BUA be aware of any
specific APP message format that contains additional information specific APP message format that contains additional information
related to SSRCs, it SHOULD update them as well. related to SSRCs, it SHOULD update them as well.
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 any SSRC in any direction, it MUST update
the SSRC-related information in the incoming XR message header the SSRC-related information in the incoming XR message header
before forwarding it. This includes the source SSRC, which MUST before forwarding it. This includes the source SSRC, which MUST
be rewritten with the one the B2BUA uses to send RTP packets to be rewritten with the one the B2BUA uses to send RTP packets to
the sender peer, and the SSRC information in all the block types each sender participant, and the SSRC information in all the block
that include it, which MUST be rewritten using the related sender types that include it, which MUST be rewritten using the related
peer(s) SSRC. If the B2BUA has also changed the base RTP sequence sender participant(s) SSRC. If the B2BUA has also changed the
number when forwarding RTP packets, then this change needs to be base RTP sequence number when forwarding RTP packets, then this
properly addressed in the 'begin_seq' and 'end_seq' fields that change needs to be properly addressed in the 'begin_seq' and
are available in most of the Report Block types that are part of 'end_seq' fields that are available in most of the Report Block
the XR specification. types that are part of the XR specification.
Receiver Summary Information (RSI): [RFC5760] Receiver Summary Information (RSI): [RFC5760]
If the B2BUA has changed any SSRC in any direction, it MUST update If the B2BUA has changed any SSRC in any direction, it MUST update
the SSRC-related information in the incoming RSI message header the SSRC-related information in the incoming RSI message header
before forwarding it. This includes the distribution source SSRC, before forwarding it. This includes the distribution source SSRC,
which MUST be rewritten with the one the B2BUA uses to send RTP which MUST be rewritten with the one the B2BUA uses to send RTP
packets to the sender peer, the summarized SSRC and, in case a packets to each sender participant, the summarized SSRC and, in
Collision Sub-Report Block is available, the SSRCs in the related case a Collision Sub-Report Block is available, the SSRCs in the
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 in any direction, it MUST update
the SSRC-related information in the incoming TOKEN message before the SSRC-related information in the incoming TOKEN message before
forwarding it. This includes the Packet Sender SSRC, which MUST forwarding it. This includes the Packet Sender SSRC, which MUST
be rewritten with the one the B2BUA uses to send RTP packets to be rewritten with the one the B2BUA uses to send RTP packets to
the sender peer, and the Requesting Client SSRC in case the each sender participant, and the Requesting Client SSRC in case
message is a response, which MUST be rewritten using the related the message is a response, which MUST be rewritten using the
sender peer(s) SSRC. related sender 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 of the packet sender and the one of the media source the
feedack is related to. Just as described for the previous feedack is related to. Just as described for the previous
messages, these SSRC identifiers MUST be updated if the B2BUA has messages, these SSRC identifiers MUST be updated if the B2BUA has
changed any SSRC in any direction. It MUST NOT, though, change a changed any SSRC in any direction. It MUST NOT, though, change a
media source SSRC that was originally set to zero. Besides, media source SSRC that was originally set to zero. Besides,
considering that many feedback messages also include additional considering that many feedback messages also include additional
data as part of their specific Feedback Control Information (FCI), data as part of their specific Feedback Control Information (FCI),
skipping to change at page 9, line 34 skipping to change at page 9, line 46
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, that is taking care of RTP
payloads as well and not only headers. This means that such payloads as well and not only headers. This means that such
components, for instance, can act as media transcoders and/or components, for instance, can act as media transcoders and/or
originate specific RTP media. Using the RTP Topologies terminology, originate specific RTP media. Using the RTP Topologies terminology,
this can be seen as a RTP Media Translator. Such a capability makes this can be seen as a RTP Media Translator. Such a capability makes
them quite different from the previously introduced B2BUA typologies, them quite different from the previously introduced B2BUA typologies,
as this means they are going to terminate RTCP as well: in fact, as this means they are going to terminate RTCP as well: in fact,
since the media is terminated by themselves, the related statistics since the media is terminated by themselves, the related statistics
and feedback functionality can be taken care directly by the B2BUA, and feedback functionality can be taken care directly by the B2BUA,
and does not need to be relayed to the logical peer in the multimedia and does not need to be relayed to the other participants in the
communication. 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 peers at all, as the B2BUA would terminate them all and take involved participants at all, as the B2BUA would terminate them all
care of them accordingly. Nevertheless, should any RTCP packet and take care of them accordingly. Nevertheless, should any RTCP
actually need to be delivered to the actual peer, the same guidelines packet actually need to be forwarded to another participant in the
provided for the media-aware B2BUA case apply. multimedia session, the same guidelines provided for the media-aware
B2BUA case apply.
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 this may not be true once any security
is enforced on RTP packets and RTCP messages by means of SRTP is enforced on RTP packets and RTCP messages by means of SRTP
[RFC3711], whether the keying is done using Secure Descriptions [RFC3711], whether the keying is done using Secure Descriptions
[RFC4568] or DTLS-SRTP [RFC5764]. [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 think of a SRTP/SRTCP session across a B2BUA where the
B2BUA itself has no access to the keys used to secure the session, B2BUA itself has no access to the keys used to secure the session,
there would be no way to manipulate SRTP headers without violating there would be no way to manipulate SRTP headers without violating
skipping to change at page 10, line 25 skipping to change at page 10, line 37
the hashing on the packet; at the same time, there would be no way to the hashing on the packet; at the same time, there would be no way to
rewrite the RTCP information accordingly either, as most of the rewrite the RTCP information accordingly either, as most of the
packet (especially when RTCP compound packets are involved) would be packet (especially when RTCP compound packets are involved) would be
encrypted. 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, the B2BUA This means that, in case media security is involved, the B2BUA
willing to act as either a Media-aware Relay or a Media Terminator willing to act as either a Media-aware Relay or a Media Terminator
must act as an intermediary with respect to the secure sessions. As can only do so when acting as an intermediary with respect to the
such, different secure sessions need to be negotiated (either via secure sessions. As such, different secure sessions would need to be
SDES or DTLS-SRTP) with the involved parties, in order to be able to negotiated (either via SDES or DTLS-SRTP) with the involved
have access to the unencrypted packets and, if needed, modify them participants, in order to be able to have access to the unencrypted
before encrypting them again and forwarding them. It is important to packets and, if needed, modify them before encrypting them again and
point out that this breaks any end-to-end security mechanism that may forwarding them.
be in place, though, as all the involved parties would have a secure
communication up to the B2BUA and would have to rely on the B2BUA Of course, this is only a viable solution if all the involved
actually encrypting the communication on the other end as well. participants trust the B2BUA. In fact, it is very important to point
out that a B2BUA acting as an intermediary would break any end-to-end
security mechanism that may be in place, as all the involved
participants would have a secure communication up to the B2BUA and
would have to rely on the B2BUA actually encrypting the communication
on the other end(s) as well. This means that the participants
involved in a multimedia session through a B2BUA have to trust the
B2BUA to secure the session on the other end(s), taking care of any
validation and protection that may be required as part of the
process.
It is worth noting that some additional care may be needed, with
respect to RTCP, when acting as an intermediary between two secure
sessions. Specifically, issues may arise when relaying NACK feedback
originated by a user who failed to receive some RTP packets, that
were instead received by the B2BUA: such an issue might occur when
the packet loss happens between the user and the B2BUA itself, and
not between the RTP packet sender and the B2BUA. Such a situation
might result in the RTP media sender retransmitting the encrypted
packet, which would then be rejected by the B2BUA as a replayed one.
However, this issue is well known and addressed in [RFC4588], which
both the B2BUA and the involved participants in the communication
SHOULD make use of to prevent it from happening. This mechanism
allows for a Redundancy RTP Stream to be used for the purpose, which
would prevent the replay error. Of course, all recommendations given
previously with respect to managing SSRCs across the B2BUA still
apply here as well: in fact, such a redundant RTP stream would make
use of a different SSRC, that would need to be taken care of both at
the RTP and the SDP level. If [RFC4588] is not supported, the B2BUA
SHOULD handle NACK packets directly, and only forward feedback on
lost packets it has not access to.
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
TBD. Not any additional consideration to what the standards already TBD. Not any additional consideration to what the standards already
give? Probably this section will need a few words about how NOT give? Probably this section will need a few words about how NOT
following the guidelines can lead to security issues: e.g., not following the guidelines can lead to security issues: e.g., not
properly translating REMB messages can cause an increasing flow of properly translating REMB messages can cause an increasing flow of
media packets, that may be seen as attacks to devices that can't media packets, that may be seen as attacks to devices that can't
handle the amount of data. handle the amount of data.
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 01 and the 02
versions of the draft:
o Updated terminology to better adhere to
[I-D.ietf-avtext-rtp-grouping-taxonomy].
o Rephrased the Media Path Security section to take into account the
MITM-related discussion in Toronto.
o Clarified that NACK management might be trickier when SRTP is
involved.
The following are the major changes between the 00 and the 01 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 packet types to the Media-Aware section.
skipping to change at page 12, line 12 skipping to change at page 13, line 16
Initiation Protocol (SIP) Back-to-Back User Agents", RFC Initiation Protocol (SIP) Back-to-Back User Agents", RFC
7092, December 2013. 7092, December 2013.
9.2. Informative References 9.2. Informative References
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008. January 2008.
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-02 (work in progress), ietf-avtcore-rtp-topologies-update-04 (work in progress),
May 2014. August 2014.
[I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro,
"A Taxonomy of Grouping Semantics and Mechanisms for Real-
Time Transport Protocol (RTP) Sources", draft-ietf-avtext-
rtp-grouping-taxonomy-02 (work in progress), June 2014.
[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, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
2006. 2006.
skipping to change at page 13, line 13 skipping to change at page 14, line 25
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
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. 30 change blocks. 
129 lines changed or deleted 193 lines changed or added

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