draft-ietf-straw-b2bua-rtcp-08.txt   draft-ietf-straw-b2bua-rtcp-09.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: April 15, 2016 Medooze Expires: October 13, 2016 Medooze
V. Pascual V. Pascual
Quobis Quobis
October 13, 2015 April 11, 2016
Guidelines to support RTCP end-to-end in Back-to-Back User Agents Guidelines to support RTCP end-to-end in Back-to-Back User Agents
(B2BUAs) (B2BUAs)
draft-ietf-straw-b2bua-rtcp-08 draft-ietf-straw-b2bua-rtcp-09
Abstract Abstract
SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be
on the media path, rather than just intercepting signalling. This on the media path, rather than just intercepting signalling. This
means that B2BUAs often implement an RTP/RTCP stack as well, whether means that B2BUAs often implement an RTP/RTCP stack as well, whether
to act as media transcoders or to just passthrough the media to act as media transcoders or to just passthrough the media
themselves, thus leading to separate multimedia sessions that the themselves, thus leading to separate multimedia sessions that the
B2BUA correlates and bridges together. If not disciplined, though, B2BUA correlates and bridges together. If not disciplined, though,
this behaviour can severely impact the communication experience, this behaviour can severely impact the communication experience,
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 April 15, 2016. This Internet-Draft will expire on October 13, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Signalling/Media Plane B2BUAs . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . 11 3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 11
4. Media Path Security . . . . . . . . . . . . . . . . . . . . . 11 4. Media Path Security . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 13 7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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
skipping to change at page 3, line 14 skipping to change at page 3, line 14
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 participants with incompatible codecs, or it may functionality for participants with incompatible codecs, or it may
need the traffic to be directly handled for different reasons like need the traffic to be directly handled for different reasons like
billing, lawful interception, session recording and so on. This can billing, lawful interception, session recording and so on. This can
lead to 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]. [RFC7667].
Whatever the reason, such a behaviour does not come without a cost. Whatever the reason, such a behaviour does not come without a cost.
In fact, whenever a media-aware component is placed on the path In fact, whenever a media-aware component is placed on the path
between two or more participants that want to communicate by means of between two or more participants that want to communicate by means of
RTP/RTCP, the end-to-end nature of such protocols is broken, and RTP/RTCP, the end-to-end nature of such protocols is broken, and
their effectiveness may be affected as a consequence. While this may their effectiveness may be affected as a consequence. While this may
not be a problem for RTP packets, which from a protocol point of view not be a problem for RTP packets, which 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
skipping to change at page 4, line 47 skipping to change at page 4, line 47
such feedback, in order to be sure that their activities on the media such feedback, in order to be sure that their activities on the media
plane do not break anything they're not supposed to. plane do not break anything they're not supposed to.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Besides, this document addresses, where relevant, the RTP-related Besides, this document addresses, where relevant, the RTP-related
terminology as disciplined in terminology as disciplined in [RFC7656].
[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
skipping to change at page 7, line 18 skipping to change at page 7, line 18
they're using to receive the media. This means that, if not properly they're using to receive the media. This means that, if not properly
disciplined, such a behaviour may easily lead to issues like the one disciplined, such a behaviour may easily lead to issues like the one
described in the introductory section. As such, it is very important described in the introductory section. As such, it is very important
for a B2BUA modifying RTP-related information across two related RTP for a B2BUA modifying RTP-related information across two related RTP
streams to also modify the same information in RTCP packets as well, streams to also modify the same information in RTCP packets as well,
and in a coherent way, so that not to confuse any of the participants and in a coherent way, so that not to confuse any of the participants
involved in a communication. 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) [RFC7667], for instance, could aggregate or drop incoming
could aggregate or drop incoming RTCP messages, while at the same RTCP messages, while at the same time originating new ones on their
time originating new ones on their own. For the messages that are own. For the messages that are forwarded and/or aggregated, though,
forwarded and/or aggregated, though, it's important to make sure the 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 RTP streams relation, it If the B2BUA has changed any SSRC in any RTP streams relation, it
MUST update the SSRC-related information in the incoming SR packet MUST update the SSRC-related information in the incoming SR packet
before forwarding it. This includes the sender SSRC, which MUST before forwarding it. This includes the sender SSRC, which MUST
be rewritten with the one the B2BUA uses in the RTP stream used to be rewritten with the one the B2BUA uses in the RTP stream used to
skipping to change at page 11, line 16 skipping to change at page 11, line 14
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. 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 topology can also this can be seen as a RTP Media Translator. Such a topology can also
be seen as a Back-to-back RTP sessions through a Middlebox, as be seen as a Back-to-back RTP sessions through a Middlebox, as
described in Section 3.2.2 of described in Section 3.2.2 of [RFC7667]. Such a capability makes
[I-D.ietf-avtcore-rtp-topologies-update]. 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 other participants in the and does not need to be relayed to the other participants in the
multimedia session. 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
skipping to change at page 13, line 9 skipping to change at page 12, line 50
for a user, may lead to missing information to its peer, who may end for a user, may lead to missing information to its peer, who may end
up increasing the encoder bitrate up to a point where the user with up increasing the encoder bitrate up to a point where the user with
poor connectivity will inevitably be choked by an amount of data it poor connectivity will inevitably be choked by an amount of data it
cannot process. This scenario may as such result in what looks like cannot process. This scenario may as such result in what looks like
a Denial of Service (DOS) attack towards the user. a Denial of Service (DOS) attack towards the user.
7. Change Summary 7. Change Summary
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
The following are the major changes between the 08 and the 09
versions of the draft:
o Updated references to documents which have become RFC in the
meanwhile, [RFC7667] and [RFC7656].
The following are the major changes between the 06 and the 07 The following are the major changes between the 06 and the 07
versions of the draft: versions of the draft:
o Clarified the suggested changed by Colin Perkins on the management o Clarified the suggested changed by Colin Perkins on the management
of CNAME items in SDES, and added reference to [RFC7022]. of CNAME items in SDES, and added reference to [RFC7022].
o Addressed comment by Simon Perreault on CNAME collisions o Addressed comment by Simon Perreault on CNAME collisions
management. management.
The following are the major changes between the 05 and the 06 The following are the major changes between the 05 and the 06
skipping to change at page 13, line 42 skipping to change at page 13, line 41
versions of the draft: versions of the draft:
o Addressed review by Magnus Westerlund. o Addressed review by Magnus Westerlund.
o Added guidelines for ECN RTCP messages. o Added guidelines for ECN RTCP messages.
o Clarified that if an RTCP packet is dropped because unsupported, o Clarified that if an RTCP packet is dropped because unsupported,
only the unsupported packet is dropped and not the compound packet only the unsupported packet is dropped and not the compound packet
that contains it. that contains it.
o Added reference to Section 3.2.2 of o Added reference to Section 3.2.2 of [RFC7667] to Section 3.3.
[I-D.ietf-avtcore-rtp-topologies-update] to Section 3.3.
o Added considerations on RTP/RTCP multiplexing and Reduced-Size o Added considerations on RTP/RTCP multiplexing and Reduced-Size
RTCP. RTCP.
The following are the major changes between the 02 and the 03 The following are the major changes between the 02 and the 03
versions of the draft: versions of the draft:
o Rephrased the Media Path Security section to take into account the o Rephrased the Media Path Security section to take into account the
MITM-related discussion in Honolulu. MITM-related discussion in Honolulu.
o Added some Security Considerations. o Added some Security Considerations.
The following are the major changes between the 01 and the 02 The following are the major changes between the 01 and the 02
versions of the draft: versions of the draft:
o Updated terminology to better adhere to o Updated terminology to better adhere to [RFC7656].
[I-D.ietf-avtext-rtp-grouping-taxonomy].
o Rephrased the Media Path Security section to take into account the o Rephrased the Media Path Security section to take into account the
MITM-related discussion in Toronto. MITM-related discussion in Toronto.
o Clarified that NACK management might be trickier when SRTP is o Clarified that NACK management might be trickier when SRTP is
involved. involved.
The following are the major changes between the 00 and the 01 The following are the major changes between the 00 and the 01
versions of the draft: versions of the draft:
skipping to change at page 15, line 36 skipping to change at page 15, line 36
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents", Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013, RFC 7092, DOI 10.17487/RFC7092, December 2013,
<http://www.rfc-editor.org/info/rfc7092>. <http://www.rfc-editor.org/info/rfc7092>.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
DOI 10.17487/RFC5117, January 2008, DOI 10.17487/RFC5117, January 2008,
<http://www.rfc-editor.org/info/rfc5117>. <http://www.rfc-editor.org/info/rfc5117>.
[I-D.ietf-avtcore-rtp-topologies-update] [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
Westerlund, M. and S. Wenger, "RTP Topologies", draft- DOI 10.17487/RFC7667, November 2015,
ietf-avtcore-rtp-topologies-update-10 (work in progress), <http://www.rfc-editor.org/info/rfc7667>.
July 2015.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
B. Burman, "A Taxonomy of Semantics and Mechanisms for for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
Real-Time Transport Protocol (RTP) Sources", draft-ietf- DOI 10.17487/RFC7656, November 2015,
avtext-rtp-grouping-taxonomy-08 (work in progress), July <http://www.rfc-editor.org/info/rfc7656>.
2015.
[I-D.alvestrand-rmcat-remb] [I-D.alvestrand-rmcat-remb]
Alvestrand, H., "RTCP message for Receiver Estimated Alvestrand, H., "RTCP message for Receiver Estimated
Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in
progress), October 2013. progress), October 2013.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
 End of changes. 15 change blocks. 
30 lines changed or deleted 29 lines changed or added

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