draft-ietf-straw-b2bua-rtcp-14.txt   draft-ietf-straw-b2bua-rtcp-15.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 24, 2017 Medooze Expires: May 4, 2017 Medooze
V. Pascual V. Pascual
Oracle Oracle
October 21, 2016 October 31, 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-14 draft-ietf-straw-b2bua-rtcp-15
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 April 24, 2017. This Internet-Draft will expire on May 4, 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 6, line 5 skipping to change at page 6, line 5
rather than using the original session description. This may cause rather than using the original session description. This may cause
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. It SHOULD NOT, though, forward SDP attrib' [RFC3611] and others. However, certain SDP attributes may
attributes that may lead to call failures (e.g., candidates, lead to call failures when forwarded by a media relay. Such
fingerprints, crypto, etc.) for different reasons out of scope to attributes SHOULD NOT be forwarded. One notable example is the
this document. One notable example is the 'rtcp' [RFC3605] 'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly
attribute, that UAC may make use of to explicitly state the port state the port they're willing to use for RTCP. Considering the
they're willing to use for RTCP. Considering the B2BUA would relay B2BUA would relay RTCP messages, the port as seen by the other UAC
RTCP messages, the port as seen by the other UAC involved in the involved in the communication would differ from the one negotiated
communication would differ from the one negotiated originally, and it originally, and it MUST be rewritten accordingly. Apart from the
MUST be rewritten accordingly. Apart from the mentioned attributes, mentioned attributes, B2BUAs SHOULD forward all other SDP attributes
B2BUAs SHOULD forward all other SDP attributes they don't have a they don't have a reason not to forward, in order to avoid breaking
reason not to forward, in order to avoid breaking additional additional functionality endpoints may be relying on.
functionality endpoints may be relying on.
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
skipping to change at page 14, line 49 skipping to change at page 14, line 49
o Clarified that fixing the 'rtcp' SDP attribute is important. o Clarified that fixing the 'rtcp' SDP attribute is important.
o Added a new section on the impact of media security. o Added a new section on the impact of media security.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Flavio Battimo and Pierluigi Palma The authors would like to thank Flavio Battimo and Pierluigi Palma
for their invaluable feedback in the early stages of the document. for their invaluable feedback in the early stages of the document.
The authors would also like to thank Colin Perkins, Bernard Aboba, The authors would also like to thank Colin Perkins, Bernard Aboba,
Albrecht Schwarz, Hadriel Kaplan, Keith Drage, Jonathan Lennox, Albrecht Schwarz, Hadriel Kaplan, Keith Drage, Jonathan Lennox,
Stephen Farrell, Magnus Westerlund and Simon Perreault for their Stephen Farrell, Magnus Westerlund, Simon Perreault and Ben Campbell
constructive comments, suggestions, and reviews that were critical to for their constructive comments, suggestions, and reviews that were
the formulation and refinement of this document. critical to the formulation and refinement of this document.
9. References 9. References
9.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
 End of changes. 6 change blocks. 
19 lines changed or deleted 18 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/