draft-ietf-straw-b2bua-rtcp-03.txt   draft-ietf-straw-b2bua-rtcp-04.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: August 13, 2015 Medooze Expires: September 10, 2015 Medooze
V. Pascual V. Pascual
Quobis Quobis
February 9, 2015 March 9, 2015
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-03 draft-ietf-straw-b2bua-rtcp-04
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 August 13, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 9 3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 10
4. Media Path Security . . . . . . . . . . . . . . . . . . . . . 10 4. Media Path Security . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 11 7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Session Initiation Protocol [RFC3261] Back-to-Back User Agents Session Initiation Protocol [RFC3261] Back-to-Back User Agents
(B2BUAs) are SIP entities that can act as a logical combination of (B2BUAs) are SIP entities that can act as a logical combination of
both a User Agent Server (UAS) and a User Agent Client (UAC). As both a User Agent Server (UAS) and a User Agent Client (UAC). As
such, their behaviour is not always completelely adherent to the such, their behaviour is not always completelely adherent to the
standards, and can lead to unexpected situations the IETF is trying standards, and can lead to unexpected situations the IETF is trying
to address. [RFC7092] presents a taxonomy of the most deployed B2BUA to address. [RFC7092] presents a taxonomy of the most deployed B2BUA
implementations, describing how they differ in terms of the implementations, describing how they differ in terms of the
skipping to change at page 7, line 47 skipping to change at page 7, line 47
If the B2BUA has changed any SSRC in any direction, it MUST update If the B2BUA has changed any SSRC in any direction, it MUST update
the SSRC-related information in all the chunks in the incoming the SSRC-related information in all the chunks in the incoming
SDES packet before forwarding it. SDES packet before forwarding it.
BYE: [RFC3550] BYE: [RFC3550]
If the B2BUA has changed any SSRC in any direction, it MUST update If the B2BUA has changed any SSRC in any direction, it MUST update
the SSRC in the BYE message. the SSRC in the BYE message.
APP: [RFC3550] APP: [RFC3550]
If the B2BUA has changed any SSRC in any direction, it MUST update If the B2BUA has changed any SSRC in any direction, it MUST update
the SSRC in the BYE message. Should the B2BUA be aware of any the SSRC in the APP message. Should the B2BUA be aware of any
specific APP message format that contains additional information specific APP message format that contains additional information
related to SSRCs, it SHOULD update them as well. related to SSRCs, it SHOULD update them as well.
Extended Reports (XR): [RFC3611] Extended Reports (XR): [RFC3611]
If the B2BUA has changed any SSRC in any direction, it MUST update If the B2BUA has changed any SSRC in any direction, it MUST update
the SSRC-related information in the incoming XR message header the SSRC-related information in the incoming XR message header
before forwarding it. This includes the source SSRC, which MUST before forwarding it. This includes the source SSRC, which MUST
be rewritten with the one the B2BUA uses to send RTP packets to be rewritten with the one the B2BUA uses to send RTP packets to
each sender participant, and the SSRC information in all the block each sender participant, and the SSRC information in all the block
types that include it, which MUST be rewritten using the related types that include it, which MUST be rewritten using the related
skipping to change at page 9, line 17 skipping to change at page 9, line 17
a media-aware B2BUA MUST also properly rewrite 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 rewrite 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.
Explicit Congestion Notification (ECN): [RFC6679]
Besides the common packet format management for feedback messages,
the same guidelines given for SR/RR management apply as well,
considering the presence of sequence numbers in the ECN Feedback
Report format. For what concerns the management of RTCP XR ECN
Summary Report messages, the same guidelines given 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
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, just as it original description before sending it to the recipient, just as it
MUST rewrite the 'rtcp' attribute if provided. At the same time, the MUST rewrite the 'rtcp' attribute if provided. At the same time, the
ability for a media-aware B2BUA to inspect/modify RTCP packets may ability for a media-aware B2BUA to inspect/modify RTCP packets may
also mean such a B2BUA may choose to drop RTCP packets it can't also mean such a B2BUA may choose to drop RTCP packets it can't
parse: in that case, a media-aware B2BUA SHOULD also advertize its parse: in that case, a media-aware B2BUA MUST also advertize its RTCP
RTCP level of support in the SDP in a coherent way, in order to level of support in the SDP in a coherent way, in order to prevent,
prevent, for instance, a UAC to make use of NACK messages that would for instance, a UAC to make use of NACK messages that would never
never reach the intended recipients. reach the intended recipients. It's important to point out that, in
case any RTCP packet needs to be dropped, then only the offending
RTCP packet needs to be dropped, and not the whole compound RTCP
packet it may belong to.
A different set of considerations, instead, is worthwhile for what
concerns RTP/RTCP multiplexing [RFC5761] and Reduced-Size RTCP
[RFC5506]. While the former allows for a better management of
network resources by multiplexing RTP packets and RTCP messages over
the same transport, the latter allows for a compression of RTCP
messages, thus leading to less network traffic. For what concerns
RTP/RTCP multiplexing, a B2BUA acting as a Media Relay can use it on
either RTP session independently: this means that, for instance, a
Media Relay B2BUA may use RTP/RTCP multiplexing on one side of the
communication, and not use it on the other side, if it's not
supported. This allows for a better management of network resources
on the side that does support it. In case any of the parties in the
communications supports it and the B2BUA does too, the related 'rtcp-
mux' SDP attribute MUST be forwarded on the other side(s); if the
B2BUA detects that any of the parties in the communication does not
support the feature, it may decide to either disable it entirely or
still advertize it for the RTP sessions with parties that do support
it. In case the B2BUA decides to involve RTP/RTCP multiplexing, it
MUST ensure that there are no conflicting RTP payload type numbers on
both sides, and in case there are, it MUST rewrite RTP payload type
numbers to ensure no conflict in the domain where the RTP/RTCP
multiplexing is applied. Should RTP payload types be rewritten, the
related information in the SDP MUST be updated accordingly.
For what concerns Reduced-Size RTCP, instead, the considerations are
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,
there are other aspects to take into account before doing so. While
Reduced-Size allows indeed for less network traffic related to RTCP
messaging in general, this gain may lead a Reduced-Size RTCP
implementation to also issue a higher rate of RTCP feedback messages.
This would result in an increased RTCP traffic on the side that does
not support Reduced-Size, and could as a consequence be actually
counterproductive if the bandwidth is different on each side. That
said, the B2BUA can choose whether or not to advertize support for
Reduced-Size RTCP on either side by means of the 'rtcp-rsize' SDP
attribute. Should a B2BUA decide to allow the sides to independently
use or not Reduced-Size, then the B2BUA MUST advertize support for
the feature on the sides that support it, and MUST NOT advertize it
on the sides that don't, by removing the related attribute from the
SDP before forwarding it. Should the B2BUA decide to disable the
feature on all sides, instead, it MUST NOT advertize support for the
Reduced-Size RTCP functionality on any side, by removing the 'rtcp-
rsize' attribute from the SDP.
3.3. Media Terminator 3.3. Media Terminator
A Media Terminator B2BUA, unlike simple relays and media-aware ones, A Media Terminator B2BUA, unlike simple relays and media-aware ones,
is also able to terminate media itself, that is taking care of RTP is also able to terminate media itself, that is taking care of RTP
payloads as well and not only headers. This means that such payloads as well and not only headers. This means that such
components, for instance, can act as media transcoders and/or components, for instance, can act as media transcoders and/or
originate specific RTP media. Using the RTP Topologies terminology, originate specific RTP media. Using the RTP Topologies terminology,
this can be seen as a RTP Media Translator. Such a capability makes this can be seen as a RTP Media Translator. Such a topology can also
be seen as a Back-to-back RTP sessions through a Middlebox, as
described in Section 3.2.2 of
[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
involved participants at all, as the B2BUA would terminate them all involved participants at all, as the B2BUA would terminate them all
and take care of them accordingly. Nevertheless, should any RTCP and take care of them accordingly. Nevertheless, should any RTCP
packet actually need to be forwarded to another participant in the packet actually need to be forwarded to another participant in the
multimedia session, the same guidelines provided for the media-aware multimedia session, the same guidelines provided for the media-aware
B2BUA case apply. B2BUA case apply.
For what concerns RTP/RTCP multiplexing support, the same
considerations already given for the Media Relay management basically
apply for a Media Terminator as well. Some different considerations
might be given as to the Reduced-Size RTCP functionality, instead: in
fact, in the Media Terminator case it is safe to use the feature
independently on each leg. In that case, the same considerations
about advertizing the support, or lack of support, of the feature on
either side as described for the Media Relay case apply here as well.
4. Media Path Security 4. Media Path Security
The discussion made in the previous sections on the management of The discussion made in the previous sections on the management of
RTCP messages by a B2BUA has so far mostly worked under the RTCP messages by a B2BUA has so far mostly worked under the
assumption that the B2BUA has actually access to the RTP/RTCP assumption that the B2BUA has actually access to the RTP/RTCP
information itself. This is indeed true if we assume that plain RTP information itself. This is indeed true if we assume that plain RTP
and RTCP is being handled, but this may not be true once any security and RTCP is being handled, but this may not be true once any security
is enforced on RTP packets and RTCP messages by means of SRTP is enforced on RTP packets and RTCP messages by means of SRTP
[RFC3711], whether the keying is done using Secure Descriptions [RFC3711], whether the keying is done using Secure Descriptions
[RFC4568] or DTLS-SRTP [RFC5764]. [RFC4568] or DTLS-SRTP [RFC5764].
skipping to change at page 11, line 20 skipping to change at page 12, line 41
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 03 and the 04
versions of the draft:
o Addressed review by Magnus Westerlund.
o Added guidelines for ECN RTCP messages.
o Clarified that if an RTCP packet is dropped because unsupported,
only the unsupported packet is dropped and not the compound packet
that contains it.
o Added reference to Section 3.2.2 of
[I-D.ietf-avtcore-rtp-topologies-update] to Section 3.3.
o Added considerations on RTP/RTCP multiplexing and Reduced-Size
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:
skipping to change at page 12, line 43 skipping to change at page 14, line 39
Initiation Protocol (SIP) Back-to-Back User Agents", RFC Initiation Protocol (SIP) Back-to-Back User Agents", RFC
7092, December 2013. 7092, December 2013.
9.2. Informative References 9.2. Informative References
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008. January 2008.
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-05 (work in progress), ietf-avtcore-rtp-topologies-update-06 (work in progress),
November 2014. March 2015.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro,
"A Taxonomy of Grouping Semantics and Mechanisms for Real- "A Taxonomy of Grouping Semantics and Mechanisms for Real-
Time Transport Protocol (RTP) Sources", draft-ietf-avtext- Time Transport Protocol (RTP) Sources", draft-ietf-avtext-
rtp-grouping-taxonomy-05 (work in progress), January 2015. rtp-grouping-taxonomy-06 (work in progress), March 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, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
2006. 2006.
skipping to change at page 13, line 39 skipping to change at page 15, line 34
2003. 2003.
[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, February 2010. Sessions with Unicast Feedback", RFC 5760, February 2010.
[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,
June 2011. June 2011.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, August 2012.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
Authors' Addresses Authors' Addresses
 End of changes. 15 change blocks. 
23 lines changed or deleted 119 lines changed or added

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