draft-ietf-straw-b2bua-rtcp-15.txt   draft-ietf-straw-b2bua-rtcp-16.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: May 4, 2017 Medooze Expires: June 19, 2017 Medooze
V. Pascual V. Pascual
Oracle Oracle
October 31, 2016 December 16, 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-15 draft-ietf-straw-b2bua-rtcp-16
Abstract Abstract
SIP Back-to-Back User Agents (B2BUAs) are often designed to also be SIP Back-to-Back User Agents (B2BUAs) are often designed 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, thus means that B2BUAs often implement an RTP/RTCP stack as well, thus
leading to separate multimedia sessions that the B2BUA correlates and leading to separate multimedia sessions that the B2BUA correlates and
bridges together. If not disciplined, though, this behaviour can bridges together. If not disciplined, though, this behaviour can
severely impact the communication experience, especially when severely impact the communication experience, especially when
statistics and feedback information contained in RTCP messages get statistics and feedback information contained in RTCP messages get
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 May 4, 2017. This Internet-Draft will expire on June 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Media-aware Relay . . . . . . . . . . . . . . . . . . . . 6 3.2. Media-aware Relay . . . . . . . . . . . . . . . . . . . . 6
3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 10 3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 12 7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 completely adherent to the such, their behaviour is not always completely adherent to the
standards, and can lead to unexpected situations. [RFC7092] presents standards, and can lead to unexpected situations. [RFC7092] presents
a taxonomy of the most commonly deployed B2BUA implementations, a taxonomy of the most commonly deployed B2BUA implementations,
describing how they differ in terms of the functionality and features describing how they differ in terms of the functionality and features
they provide. they provide.
Such components often do not only act on the signalling plane, that Such components often do not only act on the signalling plane, that
is intercepting and possibly modifying SIP messages, but also on the is intercepting and possibly modifying SIP messages, but also on the
media plane. This means that, in order to receive and manage all RTP media plane. This means that, in order to receive and manage all RTP
and RTCP [RFC3550] packets in a session, these components also and RTCP [RFC3550] packets in a session, these components also
manipulate the session descriptions [RFC4566] in the related offer/ manipulate the session descriptions [RFC4566] in the related offer/
answer exchanges [RFC3264]. The reasons for such a behaviour can be answer exchanges [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. This
billing, lawful interception, session recording and so on. This can can lead to several different topologies for RTP-based communication,
lead to several different topologies for RTP-based communication, as as documented in [RFC7667].
documented in [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. While RTP/RTCP, the end-to-end nature of such protocols is broken. While
this may not be a problem for RTP packets, which can be quite easily this may not be a problem for RTP packets, which can be quite easily
relayed, it definitely can cause serious issue for RTCP messages, relayed, it definitely can cause serious issue for RTCP messages,
which carry important information and feedback on the communication which carry important information and feedback on the communication
quality the participants are experiencing. Consider, for instance, quality the participants are experiencing. Consider, for instance,
the simple scenario only involving two participants and a single RTP the simple scenario only involving two participants and a single RTP
skipping to change at page 6, line 6 skipping to change at page 6, line 5
participants to find a mismatch between the SSRCs advertized in the participants to find a mismatch between the SSRCs advertized in the
SDP and the ones actually observed in RTP and RTCP messages, or to SDP and the ones actually observed in RTP and RTCP messages, or to
have them either ignore or generate RTCP feedback packets that were have them either ignore or generate RTCP feedback packets that were
not explicitly advertized as supported. not explicitly advertized as supported.
In order to prevent such an issue, a media-relay B2BUA SHOULD forward In order to prevent such an issue, a media-relay B2BUA SHOULD forward
all the SSRC- and RTCP-related SDP attributes when handling a all the SSRC- and RTCP-related SDP attributes when handling a
multimedia session setup between participants: this includes multimedia session setup between participants: this includes
attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr- attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr-
attrib' [RFC3611] and others. However, certain SDP attributes may attrib' [RFC3611] and others. However, certain SDP attributes may
lead to call failures when forwarded by a media relay. Such lead to call failures when forwarded by a media relay, as they have
attributes SHOULD NOT be forwarded. One notable example is the an implied assumption that the attribute describes the immediate
'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly peer. A clear example of this is the 'rtcp' [RFC3605] attribute,
state the port they're willing to use for RTCP. Considering the which describes the expected RTCP peer port. Other attributes might
B2BUA would relay RTCP messages, the port as seen by the other UAC include the immediate peer's IP address, preferred transport, etc.
involved in the communication would differ from the one negotiated In general, the guideline is to require rewriting of attributes that
originally, and it MUST be rewritten accordingly. Apart from the are implicitly describing the immediate peer. If in doubt during
mentioned attributes, B2BUAs SHOULD forward all other SDP attributes implementation, testing to determine whether a call failure occurs
they don't have a reason not to forward, in order to avoid breaking should be done. If it doesn't, B2BUAs SHOULD forward all other SDP
additional functionality endpoints may be relying on. attributes in order to avoid breaking additional functionality
endpoints may be relying on.
The cited 'rtcp' example is also relevant whenever RTP/RTCP
multiplexing [RFC5761] support is being negotiated. If the B2BUA
acting as a Media Relay is unaware of the specifics of the traffic it
is handling, and as such may not have RTP/RTCP parsing capabilities,
it SHOULD reject RTP/RTCP multiplexing by removing the 'rtcp-mux' SDP
attribute. If instead the Media Relay is able to parse RTP/RTCP, and
can verify that demultiplexing can be performed without any RTP
Payload Type rewrites (i.e., no overlap between any RTP Payload Types
and the RTCP Payload Type space has been detected), then the B2BUA
SHOULD negotiate RTP/RTCP multiplexing support if advertized.
It is worth mentioning that, leaving RTCP messages untouched, a media It is worth mentioning that, leaving RTCP messages untouched, a media
relay may also leak information that, according to policies, may need relay may also leak information that, according to policies, may need
to be hidden or masqueraded, e.g., domain names in CNAME items. to be hidden or masqueraded, e.g., domain names in CNAME items.
Besides, these CNAME items may actually contain IP addresses: this Besides, these CNAME items may actually contain IP addresses: this
means that, should a NAT be involved in the communication, this may means that, should a NAT be involved in the communication, this may
actually result in CNAME collisions, which could indeed break the actually result in CNAME collisions, which could indeed break the
end-to-end RTCP behaviour. While [RFC7022] can prevent this from end-to-end RTCP behaviour. While [RFC7022] can prevent this from
happening, there may be implementations that don't make use of it. happening, there may be implementations that don't make use of it.
As such, a B2BUA MAY rewrite CNAME items if any potential collision As such, a B2BUA MAY rewrite CNAME items if any potential collision
is detected, even in the Media Relay case. If a B2BUA does indeed is detected, even in the Media Relay case. If a B2BUA does indeed
decide to rewrite CNAME items, though, then it MUST generate new decide to rewrite CNAME items, though, then it MUST generate new
CNAMEs following [RFC7022]. CNAMEs following [RFC7022]. The same SHOULD be done in case RTP
extensions involving CNAMEs are involved (e.g., "urn:ietf:params:rtp-
hdrext:sdes:cname", [RFC7941]). If that is not possible, e.g.,
because the Media Relay does not have RTP header editing capabilities
or does not support these extensions, then the B2BUA MUST reject the
negotiation of such extensions when negotiating the session.
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 aware of the media traffic it is handling. This previous section, is aware of the media traffic it is handling. This
means it inspects RTP and RTCP messages flowing by, and may even means it inspects RTP and RTCP messages flowing by, and may even
modify their headers. Using the RFC3550 terminology, this can be modify their headers. Using the RFC3550 terminology, this can be
seen as a RTP Translator. A B2BUA implementing this role, though, seen as a RTP Translator. A B2BUA implementing this role, though,
typically does not inspect the RTP payloads, which would be opaque to typically does not inspect the RTP payloads, which would be opaque to
them: this means that the actual media would not be manipulated (e.g, them: this means that the actual media would not be manipulated (e.g,
skipping to change at page 7, line 9 skipping to change at page 7, line 24
stream, before forwarding the modified packets to the other stream, before forwarding the modified packets to the other
interested participants. This means that, if not properly interested participants. This means that, if not properly
disciplined, such a behaviour may easily lead to issues like the one disciplined, such a behaviour may easily lead to issues like the one
described in the introductory section. For this reason, it is very described in the introductory section. For this reason, it is very
important for a B2BUA modifying RTP-related information across two important for a B2BUA modifying RTP-related information across two
related RTP streams to also modify, in a coherent way, the same related RTP streams to also modify, in a coherent way, the same
information in RTCP messages. information in RTCP messages.
It is worthwile to point out that such a B2BUA may not necessarily It is worthwile to point out that such a B2BUA may not necessarily
forward all the packets it receives, though. Selective Forwarding forward all the packets it receives, though. Selective Forwarding
Units (SFU) [RFC7667], for instance, may aggregate or drop incoming Units (SFU) [RFC7667], for instance, may be implemented to aggregate
RTCP messages, while at the same time originating new ones on their or drop incoming RTCP messages, while at the same time originating
own. For the messages that are forwarded and/or aggregated, though, new ones on their own. It is important to clarify that a B2BUA
it's important to make sure the information is coherent. SHOULD NOT randomly drop or forward RTCP feedback of the same type
(e.g., a specific XR block type, or specific Feedback messages)
within the context of the same session, as that may lead to
confusing, if not broken, feedback to the recipients of the message
due to gaps in the communication. As to the messages that are
forwarded and/or aggregated, though, it's important to make sure the
information is coherent.
Besides the behaviour already mandated for RTCP translators in Besides the behaviour already mandated for RTCP translators in
Section 7.2 of [RFC3550], a media-aware B2BUA MUST handle incoming Section 7.2 of [RFC3550], a media-aware B2BUA MUST handle incoming
RTCP messages to forward following this guideline: RTCP messages to forward following this guideline:
SR: [RFC3550] SR: [RFC3550]
If the B2BUA has changed the SSRC of the sender RTP stream a If the B2BUA has changed the SSRC of the sender RTP stream a
Sender Report refers to, it MUST update the SSRC in the SR packet Sender Report refers to, it MUST update the SSRC in the SR packet
header as well. If the B2BUA has changed the SSRCs of other RTP header as well. If the B2BUA has changed the SSRCs of other RTP
streams too, and any of these streams are addressed in any of the streams too, and any of these streams are addressed in any of the
SR report blocks, it MUST update the related values in the SR SR report blocks, it MUST update the related values in the SR
report blocks as well. If the B2BUA has also changed the base RTP report blocks as well. If the B2BUA has also changed the base RTP
sequence number when forwarding RTP packets, then this change sequence number when forwarding RTP packets, then this change MUST
needs to be properly addressed in the 'extended highest sequence be reflected in the 'extended highest sequence number received'
number received' field in the Report Blocks. field in the Report Blocks. In case the B2BUA is acting as a
Selective Forwarding Units (SFU) [RFC7667], it needs to track in
the outgoing SR the relevant number of packets sent and total
amount of bytes sent to the receiver.
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 RTP stream addressed in If the B2BUA has changed the SSRC of any RTP stream addressed in
any of the chunks of an incoming SDES message, it MUST update the any of the chunks of an incoming SDES message, it MUST update the
related SSRCs in all the chunks. The same considerations made related SSRCs in all the chunks. The same considerations made
with respect to CNAME collisions at the end of Section 3.1 apply with respect to CNAME collisions at the end of Section 3.1 apply
here as well. here as well.
skipping to change at page 8, line 10 skipping to change at page 8, line 34
format that contains additional information related to SSRCs, it format that contains additional information related to SSRCs, it
SHOULD update them as well accordingly. SHOULD update them as well accordingly.
Extended Reports (XR): [RFC3611] Extended Reports (XR): [RFC3611]
If the B2BUA has changed the SSRC of the RTP stream associated If the B2BUA has changed the SSRC of the RTP stream associated
with the originator of an XR packet, it MUST update the SSRC in with the originator of an XR packet, it MUST update the SSRC in
the XR message header. The same guidelines given for SR/RR, with the XR message header. The same guidelines given for SR/RR, with
respect to SSRC identifiers in report blocks, apply for all the respect to SSRC identifiers in report blocks, apply for all the
Report Block types in the XR message as well. If the B2BUA has Report Block types in the XR message as well. If the B2BUA has
also changed the base RTP sequence number when forwarding RTP also changed the base RTP sequence number when forwarding RTP
packets, then this change needs to be properly addressed in the packets, then this change MUST be reflected in the 'begin_seq' and
'begin_seq' and 'end_seq' fields that are available in most of the 'end_seq' fields that are available in most of the Report Block
Report Block types that are part of 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 of RTP streams addressed in a If the B2BUA has changed any SSRC of RTP streams addressed in a
RSI packet, it MUST update the SSRC identifiers in the message. RSI packet, it MUST update the SSRC identifiers in the message.
This includes the distribution source SSRC, which MUST be This includes the distribution source SSRC, which MUST be
rewritten with the one the B2BUA uses to send RTP packets to each rewritten with the one the B2BUA uses to send RTP packets to each
sender participant, the summarized SSRC and, when a Collision Sub- sender participant, the summarized SSRC and, when a Collision Sub-
Report Block is available, the SSRCs in the related list. Report Block is available, the SSRCs in the related list.
Port Mapping (TOKEN): [RFC6284] Port Mapping (TOKEN): [RFC6284]
skipping to change at page 9, line 11 skipping to change at page 9, line 34
A media-aware B2BUA MUST properly rewrite the Packet ID (PID) A media-aware B2BUA MUST properly rewrite the Packet ID (PID)
of all addressed lost packets in the NACK FCI if it changed the of all addressed lost packets in the NACK FCI if it changed the
RTP sequence numbers. RTP sequence numbers.
TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM: [RFC5104] TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM: [RFC5104]
A media-aware B2BUA MUST properly rewrite the additional SSRC A media-aware B2BUA MUST properly rewrite the additional SSRC
identifier in the specific FCI, if it changed the related RTP identifier in the specific FCI, if it changed the related RTP
SSRC of the media sender. SSRC of the media sender.
REMB: [I-D.alvestrand-rmcat-remb] REMB: [I-D.alvestrand-rmcat-remb]
A media-aware B2BUA MUST properly rewrite the additional SSRC This draft describes an RTCP Payload-Specific feedback message
identifier(s) in REMB packets, if it changed the related RTP that reports the receiver's available bandwidth to the the
SSRC of the media sender. sender. As of the time of this writing, REMB has been widely
deployed, but has not been standardized. The REMB mechanism
will not function correctly across a media-aware B2BUA that
changes the SSRC of the media sender unless it also changes the
SSRC values in the REMB packet.
Explicit Congestion Notification (ECN): [RFC6679] Explicit Congestion Notification (ECN): [RFC6679]
The same guidelines given for SR/RR management apply, The same guidelines given for SR/RR management apply,
considering the presence of sequence numbers in the ECN considering the presence of sequence numbers in the ECN
Feedback Report format. For what concerns the management of Feedback Report format. For what concerns the management of
RTCP XR ECN Summary Report messages, the same guidelines given RTCP XR ECN Summary Report messages, the same guidelines given
for generic XR messages apply. for generic XR messages apply.
Apart from the generic guidelines related to Feedback messages, no Apart from the generic guidelines related to Feedback messages, no
additional modifications are needed for PLI, SLI and RPSI feedback additional modifications are needed for PLI, SLI and RPSI feedback
skipping to change at page 9, line 42 skipping to change at page 10, line 21
modify RTCP messages, it may not support all RTCP messages. This modify RTCP messages, it may not support all RTCP messages. This
means that a B2BUA may choose to drop RTCP messages it can't parse. means that a B2BUA may choose to drop RTCP messages it can't parse.
In that case, a media-aware B2BUA MUST advertize its RTCP level of In that case, a media-aware B2BUA MUST advertize its RTCP level of
support in the SDP in a coherent way, in order to prevent, for support in the SDP in a coherent way, in order to prevent, for
instance, a UAC to from sending NACK messages that would never reach instance, a UAC to from sending NACK messages that would never reach
the intended recipients. It's important to point out that, in case a the intended recipients. It's important to point out that, in case a
compound RTCP packet was received and any RTCP message in it needs to compound RTCP packet was received and any RTCP message in it needs to
be dropped, then the B2BUA SHOULD NOT drop the whole compound RTCP be dropped, then the B2BUA SHOULD NOT drop the whole compound RTCP
packet, but only the selected messages. packet, but only the selected messages.
The same considerations on CNAMEs made when talking of Media Relays
apply for Media-aware Relays as well. Specifically, if RTP
extensions involving CNAMEs are involved (e.g., "urn:ietf:params:rtp-
hdrext:sdes:cname", [RFC7941]) and negotiated because the B2BUA
supports them, then the B2BUA MUST update the CNAME value in there as
well, if it was changed. It is worth pointing out that, if the new
CNAME is larger than the old one, this would result in a larger RTP
packet than originally received. If the length of the updated packet
exceeds the MTU of any of the networks the packet will traverse, this
can result in the packet being dropped and lost by the recipient.
A different set of considerations is worthwhile for what concerns A different set of considerations is worthwhile for what concerns
RTP/RTCP multiplexing [RFC5761] and Reduced-Size RTCP [RFC5506]. RTP/RTCP multiplexing [RFC5761] and Reduced-Size RTCP [RFC5506].
While the former allows for a better management of network resources While the former allows for a better management of network resources
by multiplexing RTP packets and RTCP messages over the same by multiplexing RTP packets and RTCP messages over the same
transport, the latter allows for a compression of RTCP messages, thus transport, the latter allows for a compression of RTCP messages, thus
leading to less network traffic. For what concerns RTP/RTCP leading to less network traffic. For what concerns RTP/RTCP
multiplexing, a B2BUA acting as a Media Relay may use it on either multiplexing, a B2BUA acting as a Media Relay may use it on either
RTP session independently. This means that, for instance, a Media RTP session independently. This means that, for instance, a Media
Relay B2BUA may use RTP/RTCP multiplexing on one side of the Relay B2BUA may use RTP/RTCP multiplexing on one side of the
communication, and not use it on the other side, if the endpoint does communication, and not use it on the other side, if the endpoint does
skipping to change at page 10, line 21 skipping to change at page 11, line 11
RTP/RTCP multiplexing, it MUST ensure that there are no conflicting RTP/RTCP multiplexing, it MUST ensure that there are no conflicting
RTP payload type numbers on either side. When there are, it MUST RTP payload type numbers on either side. When there are, it MUST
rewrite RTP payload type numbers to prevent conflicts in the session rewrite RTP payload type numbers to prevent conflicts in the session
where the RTP/RTCP multiplexing is applied. Should RTP payload types where the RTP/RTCP multiplexing is applied. Should RTP payload types
be rewritten, the related information in the SDP MUST be updated be rewritten, the related information in the SDP MUST be updated
accordingly. accordingly.
For what concerns Reduced-Size RTCP, instead, the considerations are For what concerns Reduced-Size RTCP, instead, the considerations are
a bit different. In fact, while a Media Relay B2BUA may choose to a bit different. In fact, while a Media Relay B2BUA may choose to
use it on the side that supports it and not on the side that doesn't, use it on the side that supports it and not on the side that doesn't,
there are other aspects to take into account before doing so. While there are several reasons for discouraging such a behaviour. While
Reduced-Size allows indeed for less network traffic related to RTCP Reduced-Size allows indeed for less network traffic related to RTCP
messaging in general, this gain may lead a Reduced-Size RTCP messaging in general, this gain may lead a Reduced-Size RTCP
implementation to also issue a higher rate of RTCP feedback messages. implementation to also issue a higher rate of RTCP feedback messages.
This would result in an increased RTCP traffic on the side that does This would result in an increased RTCP traffic on the side that does
not support Reduced-Size, and could as a consequence be actually not support Reduced-Size, and could as a consequence be actually
counterproductive if the available bandwidth is different on the two counterproductive if the available bandwidth is different on the two
sides. That said, the B2BUA can choose whether or not to advertize sides. Negotiating a session with both sides would allow the B2BUA
support for Reduced-Size RTCP on either side by means of the 'rtcp- to discover which one supports Reduced-Size and which doesn't, and in
rsize' SDP attribute. Negotiating a session with both sides would case decide whether to allow the sides to independently use Reduced-
allow the B2BUA to discover which one supports Reduced-Size and which Size or not. Should the B2BUA decide to disable the feature on all
doesn't, and in case decide whether to allow the sides to sides, which is suggested in case Reduced-Size is not supported by
independently use Reduced-Size or not. Should the B2BUA decide to all parties involved, it MUST NOT advertize support for the Reduced-
disable the feature on all sides, it MUST NOT advertize support for Size RTCP functionality on either side, by removing the 'rtcp-rsize'
the Reduced-Size RTCP functionality on either side, by removing the attribute from the SDP.
'rtcp-rsize' attribute from the SDP.
3.3. Media Terminator 3.3. Media Terminator
A Media Terminator B2BUA, unlike simple relays and media-aware ones, A Media Terminator B2BUA, unlike simple relays and media-aware ones,
is also able to terminate media itself. As such, it can inspect and/ is also able to terminate media itself. As such, it can inspect and/
or modify RTP payloads as well. This means that such components, for or modify RTP payloads as well. This means that such components, for
instance, can act as media transcoders and/or originate specific RTP instance, can act as media transcoders and/or originate specific RTP
media. Using the RTP Topologies terminology, this can be seen as a media. Using the RTP Topologies terminology, this can be seen as a
RTP Media Translator. Such a topology can also be seen as a Back-to- RTP Media Translator. Such a topology can also be seen as a Back-to-
back RTP sessions through a Middlebox, as described in Section 3.2.2 back RTP sessions through a Middlebox, as described in Section 3.2.2
skipping to change at page 12, line 27 skipping to change at page 13, line 17
towards the user. towards the user.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
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 14 and the 15
versions of the draft:
o Several changes addressing the IESG review (list follows).
o Addressed 'rtcp-mux' in 3.1 as well, and not only 3.2.
o Clarified that, if CNAMEs are rewritten, RTP extensions
referencing them (e.g., [RFC7941]) should be updated too.
Clarified that MTU issues can occur if the rewriting results in a
larger RTP packet.
o Clarified that when handling SR packets, the an SFU B2BUA must
track packets/bytes sent.
o Removed references to billing, lawful interception, etc. from the
intro.
o Moved some references (especially those affected by MUSTs in 3.2)
to Normative.
o Rewritten the "Such attributes SHOULD NOT be forwarded" section to
clarify the context of the attributes that may lead to a failure
if not taken care of.
o Clarified that randomly dropping RTCP packets can lead to
confusion on the recipient.
o Updated text related to REMB.
o Smaller fixes here and there.
The following are the major changes between the 13 and the 14 The following are the major changes between the 13 and the 14
versions of the draft: versions of the draft:
o Removed first paragraph of Security Considerations which was o Removed first paragraph of Security Considerations which was
unclear. unclear.
o Added an IANA Considerations section to clarify there are no o Added an IANA Considerations section to clarify there are no
actions. actions.
The following are the major changes between the 12 and the 13 The following are the major changes between the 12 and the 13
skipping to change at page 15, line 40 skipping to change at page 17, line 16
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>. <http://www.rfc-editor.org/info/rfc7656>.
9.2. Informative References
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013,
<http://www.rfc-editor.org/info/rfc7092>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015,
<http://www.rfc-editor.org/info/rfc7667>.
[I-D.alvestrand-rmcat-remb]
Alvestrand, H., "RTCP message for Receiver Estimated
Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in
progress), October 2013.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>. <http://www.rfc-editor.org/info/rfc4585>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC3605, October 2003,
<http://www.rfc-editor.org/info/rfc3605>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>. <http://www.rfc-editor.org/info/rfc3611>.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, Sessions with Unicast Feedback", RFC 5760,
DOI 10.17487/RFC5760, February 2010, DOI 10.17487/RFC5760, February 2010,
<http://www.rfc-editor.org/info/rfc5760>. <http://www.rfc-editor.org/info/rfc5760>.
[RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping [RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping
between Unicast and Multicast RTP Sessions", RFC 6284, between Unicast and Multicast RTP Sessions", RFC 6284,
DOI 10.17487/RFC6284, June 2011, DOI 10.17487/RFC6284, June 2011,
<http://www.rfc-editor.org/info/rfc6284>. <http://www.rfc-editor.org/info/rfc6284>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <http://www.rfc-editor.org/info/rfc6679>. 2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010, DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>. <http://www.rfc-editor.org/info/rfc5761>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <http://www.rfc-editor.org/info/rfc5506>. 2009, <http://www.rfc-editor.org/info/rfc5506>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <http://www.rfc-editor.org/info/rfc7022>. September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP
Header Extension for the RTP Control Protocol (RTCP)
Source Description Items", RFC 7941, DOI 10.17487/RFC7941,
August 2016, <http://www.rfc-editor.org/info/rfc7941>.
9.2. Informative References
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013,
<http://www.rfc-editor.org/info/rfc7092>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015,
<http://www.rfc-editor.org/info/rfc7667>.
[I-D.alvestrand-rmcat-remb]
Alvestrand, H., "RTCP message for Receiver Estimated
Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in
progress), October 2013.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC3605, October 2003,
<http://www.rfc-editor.org/info/rfc3605>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., [RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V.,
and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back
User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016,
<http://www.rfc-editor.org/info/rfc7879>. <http://www.rfc-editor.org/info/rfc7879>.
Authors' Addresses Authors' Addresses
Lorenzo Miniero Lorenzo Miniero
Meetecho Meetecho
 End of changes. 21 change blocks. 
88 lines changed or deleted 164 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/