draft-ietf-straw-b2bua-rtcp-06.txt   draft-ietf-straw-b2bua-rtcp-07.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: October 18, 2015 Medooze Expires: October 23, 2015 Medooze
V. Pascual V. Pascual
Quobis Quobis
April 16, 2015 April 21, 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-06 draft-ietf-straw-b2bua-rtcp-07
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 October 18, 2015. This Internet-Draft will expire on October 23, 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 . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . 12 7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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
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 6, line 23 skipping to change at page 6, line 23
'rtcp-xr-attrib' [RFC3611] and others. It SHOULD NOT, though, 'rtcp-xr-attrib' [RFC3611] and others. It SHOULD NOT, though,
blindly forward all SDP attributes, as some of them (e.g., blindly forward all SDP attributes, as some of them (e.g.,
candidates, fingerprints, crypto, etc.) may lead to call failures for candidates, fingerprints, crypto, etc.) may lead to call failures for
different reasons out of scope to this document. One notable example different reasons out of scope to this document. One notable example
is the 'rtcp' [RFC3605] attribute that UAC may make use of to is the 'rtcp' [RFC3605] attribute that UAC may make use of to
explicitly state the port they're willing to use for RTCP: explicitly state the port they're willing to use for RTCP:
considering the B2BUA would relay RTCP packets, the port as seen by considering the B2BUA would relay RTCP packets, the port as seen by
the other UAC involved in the communication would differ from the one the other UAC involved in the communication would differ from the one
negotiated originally, and as such it MUST be rewritten accordingly. negotiated originally, and as such it MUST be rewritten accordingly.
Besides, it is worth mentioning that, leaving RTCP packets untouched, It is worth mentioning that, leaving RTCP packets untouched, a media
a media relay may also let through information that, according to relay may also let through information that, according to policies,
policies, may be best left hidden or masqueraded, e.g., domain names may be best left hidden or masqueraded, e.g., domain names in CNAME
in CNAME items. Nevertheless, that information cannot break the end- items. Besides, these CNAME items may actually contain IP addresses
to-end RTCP behaviour. instead: this means that, should a NAT be involved in the
communication, this may actually result in CNAME collisions, which
could indeed break the end-to-end RTCP behaviour. While [RFC7022]
can prevent this from happening, there may be implementations that
don't make use of it. 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 decide to rewrite CNAME items, though, then it
MUST generate new CNAMEs following [RFC7022].
3.2. Media-aware Relay 3.2. Media-aware Relay
A Media-aware relay, unlike the the Media Relay addressed in the A Media-aware relay, unlike the the Media Relay addressed in the
previous section, is actually aware of the media traffic it is previous section, is actually aware of the media traffic it is
handling. As such, it is able to inspect RTP and RTCP packets handling. As such, it is able to inspect RTP and RTCP packets
flowing by, and may even be able to modify the headers in any of them flowing by, and may even be able to modify the headers in any of them
before forwarding them. Using the RFC3550 terminology, this can be before forwarding them. Using the RFC3550 terminology, this can be
seen as a RTP Translator. A B2BUA implementing this role would seen as a RTP Translator. A B2BUA implementing this role would
typically not, though, inspect the RTP payloads as well, which would typically not, though, inspect the RTP payloads as well, which would
skipping to change at page 7, line 39 skipping to change at page 7, line 46
the base RTP sequence number when forwarding RTP packets, then the base RTP sequence number when forwarding RTP packets, then
this change needs to be properly addressed in the 'extended this change needs to be properly addressed in the 'extended
highest sequence number received' field in the Report Blocks. highest sequence number received' field in the Report Blocks.
RR: [RFC3550] RR: [RFC3550]
The same guidelines given for SR apply for RR as well. The same guidelines given for SR apply for RR as well.
SDES: [RFC3550] SDES: [RFC3550]
If the B2BUA has changed 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. In case the SSRC in any of the SDES packet before forwarding it. The same considerations made
chunks is changed, the related CNAME item SHOULD be updated as with respect to CNAME collisions at the end of Section 3.1 apply
well in order to avoid potential CNAME collisions, especially if here as well.
the RFC 3550 CNAME algorithm is used.
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 APP 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.
skipping to change at page 12, line 46 skipping to change at page 13, line 9
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 06 and the 07
versions of the draft:
o Clarified the suggested changed by Colin Perkins on the management
of CNAME items in SDES, and added reference to [RFC7022].
o Addressed comment by Simon Perreault on CNAME collisions
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
versions of the draft: versions of the draft:
o Addressed comment by Colin Perkins on the management of CNAME o Addressed comment by Colin Perkins on the management of CNAME
items in SDES. items in SDES.
The following are the major changes between the 04 and the 05 The following are the major changes between the 04 and the 05
versions of the draft: versions of the draft:
o Clarified behaviour when SSRC is zero. o Clarified behaviour when SSRC is zero.
skipping to change at page 14, line 20 skipping to change at page 14, line 39
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 and Magnus Westerlund for their constructive Stephen Farrell, Magnus Westerlund and Simon Perreault for their
comments, suggestions, and reviews that were critical to the constructive comments, suggestions, and reviews that were critical to
formulation and refinement of this document. 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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
skipping to change at page 16, line 32 skipping to change at page 17, line 9
and Consequences", RFC 5506, April 2009. 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.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013.
Authors' Addresses Authors' Addresses
Lorenzo Miniero Lorenzo Miniero
Meetecho Meetecho
Email: lorenzo@meetecho.com Email: lorenzo@meetecho.com
Sergio Garcia Murillo Sergio Garcia Murillo
Medooze Medooze
 End of changes. 12 change blocks. 
20 lines changed or deleted 39 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/