draft-ietf-straw-b2bua-rtcp-00.txt   draft-ietf-straw-b2bua-rtcp-01.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: June 22, 2014 Medooze Expires: December 22, 2014 Medooze
V. Pascual V. Pascual
Quobis Quobis
December 19, 2013 June 20, 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-00 draft-ietf-straw-b2bua-rtcp-01
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 media legs that the B2BUA
correlates and bridges together. If not disciplined, though, this correlates and bridges together. If not disciplined, though, this
behaviour can severely impact the communication experience, behaviour can severely impact the communication experience,
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 June 22, 2014. This Internet-Draft will expire on December 22, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . 4
3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Media-aware Relay . . . . . . . . . . . . . . . . . . . . 5 3.2. Media-aware Relay . . . . . . . . . . . . . . . . . . . . 6
3.3. Media-terminator . . . . . . . . . . . . . . . . . . . . 8 3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. Media Path Security . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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. [I-D.ietf-straw-b2bua-taxonomy] presents a taxonomy of to address. [RFC7092] presents a taxonomy of the most deployed B2BUA
the most deployed B2BUA implementations, describing how they differ implementations, describing how they differ in terms of the
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 parties willing to communicate, such components also manipulate two or more parties willing to communicate, such components also
the session description [RFC4566] in order to have all RTP and RTCP manipulate the session description [RFC4566] in order to have all RTP
[RFC3550] pass through it as well. The reasons for such a behaviour and RTCP [RFC3550] pass through it as well within the context of an
can be different: the B2BUA may want, for instance, to provide SDP offer/answer [RFC3264]. The reasons for such a behaviour can be
transcoding functionality for peers with incompatible codecs, or it different: the B2BUA may want, for instance, to provide transcoding
may need the traffic to be directly handled for different reasons functionality for peers with incompatible codecs, or it may need the
like billing, lawful interception, session recording and so on. traffic to be directly handled for different reasons like billing,
lawful interception, session recording and so on. This can lead to
several different topologies for RTP-based communication, as
documented in [RFC5117]. These topologies are currently being
updated to address new commonly encountered scenarios as well
[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 peers that want to communicate by means of RTP/RTCP, the
end-to-end nature of such protocols is broken, and their end-to-end nature of such protocols is broken, and their
effectiveness may be affected as a consequence. While this may not effectiveness may be affected as a consequence. While this may not
be a problem for RTP packets, which from a protocol point of view 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 peers are experiencing. In fact, RTCP packets make use
of specific ways to address the media they are referring to. of specific ways to address the media they are referring to.
Consider, for instance, the scenario depicted in Figure 1: Consider, for instance, the simple scenario only involving two
parties and a single media flow 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 party (Alice) is communicating with a peer
skipping to change at page 4, line 13 skipping to change at page 4, line 23
in unknown SSRCs being addressed, thus resulting in the precious in unknown SSRCs being addressed, thus resulting in the precious
information being dropped. In fact, Bob is only aware of SSRCs SSRC4 information being dropped. In fact, Bob is only aware of SSRCs SSRC4
(the one he's originating) and SSRC3 (the one he's receiving from the (the one he's originating) and SSRC3 (the one he's receiving from the
B2BUA), and knows nothing about SSRCs SSRC1 and SSRC2 in the RTCP B2BUA), and knows nothing about SSRCs SSRC1 and SSRC2 in the RTCP
packets he receives. As a consequence of the feedback being dropped, packets he receives. As a consequence of the feedback being dropped,
unaware of the issue Bob may continue to flood the party with even unaware of the issue Bob may continue to flood the party with even
more media packets and/or not send Alice the packets she misses, more media packets and/or not send Alice the packets she misses,
which may easily lead to a very bad communication experience, if not which may easily lead to a very bad communication experience, if not
eventually to an unwanted termination of the communication itself. eventually to an unwanted termination of the communication itself.
This is just a simple 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. of precious information may lead to serious consequences, especially
considering that more complex scenarios may involve several parties
at the same time and multiple media flows rather than a single one.
Considering how common B2BUA deployments are, it is very important Considering how common B2BUA deployments are, it is very important
for them to properly address such feedback, in order to be sure that for them to properly address such feedback, in order to be sure that
their activities on the media plane do not break anything they're not their activities on the media plane do not break anything they're not
supposed to. 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].
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, [I-D.ietf-straw-b2bua-taxonomy] signalling alone. In particular, [RFC7092] describes three different
describes three different categories of such B2BUAs, according to the categories of such B2BUAs, according to the level of activities
level of activities performed on the media plane: a B2BUA, in fact, performed on the media plane: a B2BUA, in fact, may act as a simple
may act as a simple media relay (1), effectively unaware of anything media relay (1), effectively unaware of anything that is transported;
that is transported; it may be a media-aware relay (2), also it may be a media-aware relay (2), also inspecting and/or modifying
inspecting and/or modifying RTP and RTCP packets as they flow by; or RTP and RTCP packets as they flow by; or it may be a full-fledged
it may be a full-fledged media-termination entity, terminating and media termination entity, terminating and generating RTP and RTCP
generating RTP and RTCP packets as needed. packets as needed.
The following subsections will describe the proper behaviour B2BUAs, While [RFC3550] and [RFC5117] already mandate some specific
whatever above category they fall in, should follow in order to behaviours when specific topologies are deployed, not all deployments
avoid, or at least minimize, any impact on end-to-end RTCP strictly adhere to the specifications and as such it's not rare to
effectiveness. encounter issues that may be avoided with a more disciplined
behaviour in that regard. For this reason, the following subsections
will describe the proper behaviour B2BUAs, whatever above category
they fall in, should follow in order to avoid, or at least minimize,
any impact on end-to-end RTCP effectiveness.
3.1. Media Relay 3.1. Media Relay
A media relay as identified in [I-D.ietf-straw-b2bua-taxonomy] A media relay as identified in [RFC7092] basically just forwards,
basically just forwards, from an application level point of view, all from an application level point of view, all RTP and RTP packets it
RTP and RTP packets it receives, without either inspecting or receives, without either inspecting or modifying them. Using the RTP
modifying them. As such, B2BUA acting as media relays are not aware Topologies terminology, this can be seen as a RTP Transport
of what traffic they're handling, meaning that not only the packet Translator. As such, B2BUA acting as media relays are not aware of
what traffic they're handling, meaning that not only the packet
payloads are opaque to them, but headers as well. Many Session payloads are opaque to them, but headers as well. Many Session
Border Controllers (SBC) implement this kind of behaviour, e.g., when Border Controllers (SBC) implement this kind of behaviour, e.g., when
acting as a bridge between an inner and outer network. acting as a bridge between an inner and outer network.
Considering all headers and identifiers in both RTP and RTCP are left Considering all headers and identifiers in both RTP and RTCP are left
untouched, issues like the SSRC mismatch described in the previous untouched, issues like the SSRC mismatch described in the previous
section would not occur. Similar problems could occur, though, section would not occur. Similar problems could 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' attributes that don't match the actual SSRC being advertized 'ssrc' [RFC5576] attributes that don't match the actual SSRC being
on the media plane) or about the supported RTCP mechanisms (e.g., in advertized on the media plane) or about the supported RTCP mechanisms
case the B2BUA advertized support for NACK because it implements it, (e.g., in case the B2BUA advertized support for NACK because it
but the original INVITE didn't). Such an issue might occur, for implements it, but the original INVITE didn't). Such an issue might
instance, in case the B2BUA acting as a media relay is generating a occur, for instance, in case the B2BUA acting as a media relay is
new session description when bridging an incoming call, rather than generating a new session description when bridging an incoming call,
taking into account the original session description in the first rather than taking into account the original session description in
place. This may cause the peers to find a mismatch between the SSRCs the first place. This may cause the peers to find a mismatch between
advertized in SDP and the ones actually observed in RTP and RTCP the SSRCs advertized in SDP and the ones actually observed in RTP and
packets, or having them either ignore or generate RTCP feedback RTCP packets (which may indeed change during a session anyway, but
packets that were not explicitly advertized as supported. having them synced during setup would help nonetheless), or having
them either ignore or generate RTCP 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 session all the SSRC- and RTCP-related SDP attributes when handling a session
setup between interested parties: this includes attributes like setup between interested parties: this includes attributes like
'ssrc' [RFC3261] and 'rtcp-fb' [RFC4585]. It SHOULD NOT, though, 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr-attrib' [RFC3611] and
blindly forward all SDP attributes, as some of them (e.g., others. It SHOULD NOT, though, blindly forward all SDP attributes,
candidates, fingerprints, crypto, etc.) may lead to call failures for as some of them (e.g., candidates, fingerprints, crypto, etc.) may
different reasons out of scope to this document. lead to call failures for different reasons out of scope to this
document. One notable example is the 'rtcp' [RFC3605] attribute that
UAC may make use of to explicitly state the port they're willing to
use for RTCP: considering the B2BUA would relay RTCP packets, the
port as seen by the other UAC involved in the communication would
differ from the one 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
previous section, is actually aware of the media traffic it is previous section, is actually aware of the media traffic it is
handling. As such, it is able to inspect RTP and RTCP packets handling. As such, it is able to inspect RTP and RTCP packets
flowing by, and may even be able to modify the headers in any of them flowing by, and may even be able to modify the headers in any of them
before forwarding them. A B2BUA implementing this role would not, before forwarding them. Using the RFC3550 terminology, this can be
though, inspect the RTP payloads as well, which would be opaque to seen as a RTP Translator. A B2BUA implementing this role would
them. typically not, though, inspect the RTP payloads as well, which would
be opaque to them: this means that the actual media would not be
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, sequence numbers, timestamps and the like before like SSRC (and hence CSRC lists, that must of course be updated
accordingly), sequence numbers, timestamps and the like before
forwarding packets from one peer to another. This means that, if not forwarding packets from one peer to another. This means that, if not
properly disciplined, such a behaviour may easily lead to issues like properly disciplined, such a behaviour may easily lead to issues like
the one described in the introductory section. the one described in the introductory section. As such, it is very
important for a B2BUA modifying RTP-related information to also
modify the same information in RTCP packets as well, and in a
coherent way, so that not to confuse any of the peers involved in a
communication.
As such, it is very important for a B2BUA modifying RTP-related It is worthwile to point out that such a B2BUA would not necessarily
information to also modify the same information in RTCP packets as forward all the packets it is receiving, though: Selective Forwarding
well, and in a coherent way, so that not to confuse any of the peers Units (SFU) [I-D.ietf-avtcore-rtp-topologies-update], for instance,
involved in a communication. Besides the behaviour already mandated could aggregate or drop incoming RTCP messages, while at the same
for RTCP translators in Section 7.2 of [RFC3550], a media-aware B2BUA time originating new ones on their own. For the messages that are
MUST also handle incoming RTCP messages to forward following this forwarded and/or aggregated, though, it's important to make sure the
guideline: information is coherent.
Besides the behaviour already mandated for RTCP translators in
Section 7.2 of [RFC3550], a media-aware B2BUA MUST also handle
incoming RTCP messages to forward following this guideline:
SR: [RFC3550] SR: [RFC3550]
If the B2BUA has changed the SSRC of 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 SR packet before the SSRC-related information in the incoming SR packet before
forwarding it. This includes the sender SSRC, which MUST be forwarding it. This includes the sender SSRC, which MUST be
replaced by the one the B2BUA uses to send RTP packets to the rewritten with the one the B2BUA uses to send RTP packets to the
sender peer, and the SSRC information in all the blocks, which sender peer, and the SSRC information in all the blocks, which
MUST be replaced using the related sender peer(s) SSRC. If the MUST be rewritten using the related sender peer(s) SSRC. If the
B2BUA has also changed the base RTP sequence number when B2BUA has also changed the base RTP sequence number when
forwarding RTP packets, then this change needs to be properly forwarding RTP packets, then this change needs to be properly
addressed in the 'extended highest sequence number received' field addressed in the 'extended highest sequence number received' field
in the Report Blocks. 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 the SSRC of 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]
If the B2BUA has changed the SSRC of any direction, it MUST update If the B2BUA has changed any SSRC in any direction, it MUST update
the SSRC in the BYE message. the SSRC in the BYE message.
APP: [RFC3550] APP: [RFC3550]
If the B2BUA has changed the SSRC of 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]
If the B2BUA has changed any SSRC in any direction, it MUST update
the SSRC-related information in the incoming XR message header
before forwarding it. This includes the source SSRC, which MUST
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
that include it, which MUST be rewritten using the related sender
peer(s) SSRC. If the B2BUA has also changed the base RTP sequence
number when forwarding RTP packets, then this change needs to be
properly addressed in the 'begin_seq' and 'end_seq' fields that
are available in most of the Report Block types that are part of
the XR specification.
Receiver Summary Information (RSI): [RFC5760]
If the B2BUA has changed any SSRC in any direction, it MUST update
the SSRC-related information in the incoming RSI message header
before forwarding it. This includes the distribution source SSRC,
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
Collision Sub-Report Block is available, the SSRCs in the related
list.
Port Mapping (TOKEN): [RFC6284]
If the B2BUA has changed any SSRC in any direction, it MUST update
the SSRC-related information in the incoming TOKEN message before
forwarding it. This includes the Packet Sender SSRC, which MUST
be rewritten with the one the B2BUA uses to send RTP packets to
the sender peer, and the Requesting Client SSRC in case the
message is a response, which MUST be rewritten using the related
sender peer(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 the SSRC of 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),
a media-aware B2BUA MUST take care of them accordingly, if it can a media-aware B2BUA MUST take care of them accordingly, if it can
parse and regenerate them, according to the following guidelines. parse and regenerate them, according to the following guidelines.
NACK: [RFC4585] NACK: [RFC4585]
Besides the common packet format management for feedback messages, Besides the common packet format management for feedback messages,
a media-aware B2BUA MUST also properly replace the Packet ID (PID) a media-aware B2BUA MUST also properly rewrite the Packet ID (PID)
of all addressed lost packets in the NACK FCI if it changed the of all addressed lost packets in the NACK FCI if it changed the
RTP sequence numbers before forwarding a packet. RTP sequence numbers before forwarding a packet.
TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM: [RFC5104] TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM: [RFC5104]
Besides the common packet format management for feedback messages, Besides the common packet format management for feedback messages,
a media-aware B2BUA MUST also properly replace the additional SSRC a media-aware B2BUA MUST also properly rewrite the additional SSRC
identifier all those messages envisage as part of their specific identifier all those messages envisage as part of their specific
FCI if it changed the related RTP SSRC of the media sender. FCI if it changed the related RTP SSRC of the media sender.
REMB: [I-D.alvestrand-rmcat-remb] REMB: [I-D.alvestrand-rmcat-remb]
Besides the common packet format management for feedback messages, Besides the common packet format management for feedback messages,
a media-aware B2BUA MUST also properly replace the additional SSRC a media-aware B2BUA MUST also properly rewrite the additional SSRC
identifier(s) REMB packets envisage as part of their specific FCI identifier(s) REMB packets envisage as part of their specific FCI
if it changed the related RTP SSRC of the media sender. if it changed the related RTP SSRC of the media sender.
Apart from the generic guidelines related to Feedback messages, no Apart from the generic guidelines related to Feedback messages, no
additional modifications are needed for PLI, SLI and RPSI feedback additional modifications are needed for PLI, SLI and RPSI feedback
messages instead. messages instead.
Of course, the same considerations about the need for SDP and RTP/ Of course, the same considerations about the need for SDP and RTP/
RTCP information to be coherent also applies to media-aware B2BUAs. RTCP information to be coherent also applies to media-aware B2BUAs.
This means that, if a B2BUA is going to change any SSRC, it SHOULD This means that, if a B2BUA is going to change any SSRC, it SHOULD
update the related 'ssrc' attributes if they were present in the update the related 'ssrc' attributes if they were present in the
original description before sending it to the recipient. At the same original description before sending it to the recipient, just as it
time, the ability for a media-aware B2BUA to inspect/modify RTCP MUST rewrite the 'rtcp' attribute if provided. At the same time, the
packets may also mean such a B2BUA may choose to drop RTCP packets it ability for a media-aware B2BUA to inspect/modify RTCP packets may
can't parse: in that case, a media-aware B2BUA SHOULD also advertize also mean such a B2BUA may choose to drop RTCP packets it can't
its RTCP level of support in the SDP in a coherent way, in order to parse: in that case, a media-aware B2BUA SHOULD also advertize its
RTCP level of support in the SDP in a coherent way, in order to
prevent, for instance, a UAC to make use of NACK messages that would prevent, for instance, a UAC to make use of NACK messages that would
never reach the intended recipients. never reach the intended recipients.
3.3. Media-terminator 3.3. Media Terminator
A media-terminator B2BUA, unlike simple relays and media-aware ones, A Media Terminator B2BUA, unlike simple relays and media-aware ones,
is also able to terminate media itself, that is taking care of RTP is also able to terminate media itself, 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. Such a capability makes them quite originate specific RTP media. Using the RTP Topologies terminology,
different from the previously introduced B2BUA typologies, as this this can be seen as a RTP Media Translator. Such a capability makes
means they most likely are going to terminate RTCP as well: in fact, them quite different from the previously introduced B2BUA typologies,
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 logical peer in the multimedia
communication. communication.
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 peers at all, as the B2BUA would terminate them all and take
care of them accordingly. Nevertheless, should any RTCP packet care of them accordingly. Nevertheless, should any RTCP packet
actually need to be delivered to the actual peer, the same guidelines actually need to be delivered to the actual peer, the same guidelines
provided for the media-aware B2BUA case apply. provided for the media-aware B2BUA case apply.
4. IANA Considerations 4. Media Path Security
The discussion made in the previous sections on the management of
RTCP messages by a B2BUA has so far mostly worked under the
assumption that the B2BUA has actually access to the RTP/RTCP
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
is enforced on RTP packets and RTCP messages by means of SRTP
[RFC3711], whether the keying is done using Secure Descriptions
[RFC4568] or DTLS-SRTP [RFC5764].
While typically not an issue in the Media Relay case, where RTP and
RTCP packets are forwarded without any modification no matter whether
security is involved or not, this could definitely have an impact on
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
B2BUA itself has no access to the keys used to secure the session,
there would be no way to manipulate SRTP headers without violating
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
packet (especially when RTCP compound packets are involved) would be
encrypted.
For this reason, it is important to point out that the operations
described in the previous sections are only possible if the B2BUA has
a way to effectively manipulate the packets and messages flowing by.
This means that, in case media security is involved, the B2BUA
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
such, different secure sessions need to be negotiated (either via
SDES or DTLS-SRTP) with the involved parties, in order to be able to
have access to the unencrypted packets and, if needed, modify them
before encrypting them again and forwarding them. It is important to
point out that this breaks any end-to-end security mechanism that may
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
actually encrypting the communication on the other end as well.
5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
5. 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.
6. Acknowledgements 7. Change Summary
Note to RFC Editor: Please remove this whole section.
The following are the major changes between the 00 and the 01
versions of the draft:
o Updated references and mapping per taxonomy RFC (7092).
o Added a reference to RTP topologies, and tried a mapping as per-
discussion in London.
o Added more RTCP packet types to the Media-Aware section.
o Clarified that fixing the 'rtcp' SDP attribute is important.
o Added a new section on the impact of media security.
8. Acknowledgements
TBD. TBD.
7. References 9. References
7.1. Normative References 9.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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,
June 2002. June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
skipping to change at page 9, line 19 skipping to change at page 11, line 46
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
7.2. Informative References [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents", RFC
7092, December 2013.
[I-D.ietf-straw-b2bua-taxonomy] 9.2. Informative References
Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents", [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
draft-ietf-straw-b2bua-taxonomy-03 (work in progress), January 2008.
October 2013.
[I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-02 (work in progress),
May 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.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, June 2009.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, October
2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, November
2003.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping
between Unicast and Multicast RTP Sessions", RFC 6284,
June 2011.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[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, May 2010.
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
Email: sergio.garcia.murillo@gmail.com Email: sergio.garcia.murillo@gmail.com
Victor Pascual Victor Pascual
Quobis Quobis
Email: victor.pascual@quobis.com Email: victor.pascual@quobis.com
 End of changes. 45 change blocks. 
104 lines changed or deleted 263 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/