Subject: [straw] I-D Action: draft-ietf-straw-b2bua-rtcp-06.txt

From: [email-masked]
Date: Thu, 16 Apr 2015 08:52:06 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Sip Traversal Required for Applications to Work Working Group of the IETF.

        Title           : Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs)
        Authors         : Lorenzo Miniero
                          Sergio Garcia Murillo
                          Victor Pascual
	Filename        : draft-ietf-straw-b2bua-rtcp-06.txt
	Pages           : 16
	Date            : 2015-04-16

Abstract:
   SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be
   on the media path, rather than just intercepting signalling.  This
   means that B2BUAs often implement an RTP/RTCP stack as well, whether
   to act as media transcoders or to just passthrough the media
   themselves, thus leading to separate multimedia sessions that the
   B2BUA correlates and bridges together.  If not disciplined, though,
   this behaviour can severely impact the communication experience,
   especially when statistics and feedback information contained in RTCP
   packets get lost because of mismatches in the reported data.

   This document defines the proper behaviour B2BUAs should follow when
   also acting on the signalling/media plane in order to preserve the
   end-to-end functionality of RTCP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-rtcp-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Colin Perkins <[email-masked]>
Date: Fri, 17 Apr 2015 09:09:32 +0100

> http://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-rtcp-06

Apologies, looking at this, it seems my comment on -05 wasn't clear. Let me try again:

In section 3.1, last paragraph, passing RTCP untouched not only leaks domain names, it can also leak IP addresses in the RTCP SDES CNAME item. If NATs are in use, this can lead to CNAME collisions, which could potentially break end-to-end RTCP behaviour. You might need to rewrite CNAME items, unless RFC 7022 is used.

Similar in Section 3.2, the issue isn't that you need to update the CNAME if the SSRC changes, but that a B2BUA that's forwarding RTCP also needs to check if it needs to rewrite the CNAME, because of CNAME collisions due to NATs.

-- 
Colin Perkins
https://csperkins.org/

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 17 Apr 2015 10:20:14 +0200

On Fri, 17 Apr 2015 09:09:32 +0100
Colin Perkins <[email-masked]> wrote:

> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories. This draft is a work item of the Sip Traversal
> > Required for Applications to Work Working Group of the IETF.
> > 
> >        Title           : Guidelines to support RTCP end-to-end in
> > Back-to-Back User Agents (B2BUAs) Authors         : Lorenzo Miniero
> >                          Sergio Garcia Murillo
> >                          Victor Pascual
> >   SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also
> > be on the media path, rather than just intercepting signalling.
> > This means that B2BUAs often implement an RTP/RTCP stack as well,
> > whether to act as media transcoders or to just passthrough the media
> >   B2BUA correlates and bridges together.  If not disciplined,
> > though, this behaviour can severely impact the communication
> > experience, especially when statistics and feedback information
> > contained in RTCP packets get lost because of mismatches in the
> > reported data.
> > 
> >   This document defines the proper behaviour B2BUAs should follow
> > when also acting on the signalling/media plane in order to preserve
> > the end-to-end functionality of RTCP.
> > 
> > 
> In section 3.1, last paragraph, passing RTCP untouched not only leaks
> domain names, it can also leak IP addresses in the RTCP SDES CNAME
> item. If NATs are in use, this can lead to CNAME collisions, which
> could potentially break end-to-end RTCP behaviour. You might need to
> rewrite CNAME items, unless RFC 7022 is used.
> 
> Similar in Section 3.2, the issue isn't that you need to update the
> CNAME if the SSRC changes, but that a B2BUA that's forwarding RTCP
> also needs to check if it needs to rewrite the CNAME, because of
> CNAME collisions due to NATs.
> 
> 

Thanks for the clarification, I'm sorry for misunderstanding what you
suggested. I'll fix this in a new version as soon as I can.

Thanks!
Lorenzo

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 17 Apr 2015 12:57:38 +0200

Colin,

I just modified the draft to try and clarify what you suggested.
Rather than pushing a potentially still flawed document, I've put a diff
to the current version here:

http://www.meetecho.com/draft-ietf-straw-b2bua-rtcp-07-from-6.diff.html

Could you let me know if this is indeed more in line with the
issue you raised? I also added a non-normative reference to RFC7022.

Thanks!
Lorenzo 

On Fri, 17 Apr 2015 10:20:14 +0200
Lorenzo Miniero <[email-masked]> wrote:

> > > Back-to-Back User Agents (B2BUAs) Authors         : Lorenzo
> > > Miniero Sergio Garcia Murillo
> > >                          Victor Pascual
> > >   SIP Back-to-Back User Agents (B2BUAs) are often envisaged to
> > > also be on the media path, rather than just intercepting
> > > signalling. This means that B2BUAs often implement an RTP/RTCP
> > > stack as well, whether to act as media transcoders or to just
> > > passthrough the media themselves, thus leading to separate
> > > multimedia sessions that the B2BUA correlates and bridges
> > > together.  If not disciplined, though, this behaviour can
> > > severely impact the communication experience, especially when
> > > statistics and feedback information contained in RTCP packets get
> > > lost because of mismatches in the reported data.
> > > 
> > > when also acting on the signalling/media plane in order to
> > > preserve the end-to-end functionality of RTCP.
> > > 
> > > 
> > In section 3.1, last paragraph, passing RTCP untouched not only
> > leaks domain names, it can also leak IP addresses in the RTCP SDES
> > CNAME item. If NATs are in use, this can lead to CNAME collisions,
> > which could potentially break end-to-end RTCP behaviour. You might
> > need to rewrite CNAME items, unless RFC 7022 is used.
> > 
> _______________________________________________
> straw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/straw

---

From: Simon Perreault <[email-masked]>
Date: Fri, 17 Apr 2015 08:59:08 -0400

> issue you raised? I also added a non-normative reference to RFC7022.

About that last sentence:

"As such, the B2BUA SHOULD rewrite CNAME items if any potential
collision is detected, even in the Media Relay case."

CNAME collisions may happen with or without a relay. I don't think it's
a relay's job to fix that. That is, it's fine for a relay to do it, but
it's also fine for a relay to let endpoints deal with it. So I guess
what I'm saying is s/SHOULD/MAY/.

Now, we could be more prescriptive about the case where a relay does
rewrite CNAMEs: "If a B2BUA does rewrite CNAME items, then it MUST
generate new CNAMEs following [RFC7022]."

Thanks!
Simon

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 17 Apr 2015 15:49:01 +0200

On Fri, 17 Apr 2015 08:59:08 -0400
Simon Perreault <[email-masked]> wrote:

> > Rather than pushing a potentially still flawed document, I've put a
> > diff to the current version here:
> > 
> CNAME collisions may happen with or without a relay. I don't think
> it's a relay's job to fix that. That is, it's fine for a relay to do
> it, but it's also fine for a relay to let endpoints deal with it. So
> I guess what I'm saying is s/SHOULD/MAY/.
> 

Simon,

thanks for your feedback! I just updated the text, so now the diff I
posted previously reflects your proposed changes:

Lorenzo

---

From: Colin Perkins <[email-masked]>
Date: Mon, 20 Apr 2015 21:46:02 +0100

> http://www.meetecho.com/draft-ietf-straw-b2bua-rtcp-07-from-6.diff.html

The changes look good to me.

-- 
Colin Perkins
https://csperkins.org/