From nobody Thu Sep 22 15:38:26 2016 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F4512B507; Thu, 22 Sep 2016 15:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.215 X-Spam-Level: X-Spam-Status: No, score=-4.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOil0U23vTNN; Thu, 22 Sep 2016 15:38:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A1D12BA6E; Thu, 22 Sep 2016 15:38:18 -0700 (PDT) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u8MMcDAk074221 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 22 Sep 2016 17:38:14 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Christer Holmberg" Date: Thu, 22 Sep 2016 17:38:13 -0500 Message-ID: <444B3957-1A78-4572-B3A8-AFC6BD24B977@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B38046839@ESESSMB209.ericsson.se> References: <1E42F55A-8365-45B5-A08F-25D513514AB1@nostrum.com> <20160531131223.176ff3ef@lminiero> <7594FB04B1934943A5C02806D1A2204B38046839@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_15E9ECAC-3F40-4C4A-9030-6E8A19262E5C_=" Embedded-HTML: [{"HTML":[655, 7379], "plain":[105, 5398], "uuid":"8FE3764B-1BB0-4A4B-B9B9-3917B72177C7"}] X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: "draft-ietf-straw-b2bua-rtcp.all@ietf.org" , Lorenzo Miniero , "straw@ietf.org" Subject: Re: [straw] Review of draft-ietf-straw-b2bua-rtcp-10 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 22:38:24 -0000 --=_MailMate_15E9ECAC-3F40-4C4A-9030-6E8A19262E5C_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Where did we end up with this? Thanks! Ben. On 9 Jun 2016, at 16:07, Christer Holmberg wrote: > (As co-chair) > > ACK! > > Regards, > > Christer > > Sent from my Windows Phone > ________________________________ > From: Ben Campbell > Sent: =E2=80=8E10/=E2=80=8E06/=E2=80=8E2016 00:04 > To: Lorenzo Miniero > Cc: = > draft-ietf-straw-b2bua-rtcp.all@ietf.org; = > straw@ietf.org; Christer = > Holmberg > Subject: Re: [straw] Review of draft-ietf-straw-b2bua-rtcp-10 > > I did a quick scan of the new revision, and I think it's addressed = > most of my editorial concerns. I encourage the chairs to re-request = > publication as soon as the authors address the one or two outstanding = > items mentioned below. > > Thanks! > > Ben. > > On 9 Jun 2016, at 15:51, Ben Campbell wrote: > > Hi, > > Comments to your email inline. I removed sections that don't seem to = > need further discussion. I will send any comments about the new draft = > revision separately. > > Thanks! > > Ben. > > On 31 May 2016, at 6:12, Lorenzo Miniero wrote: > > On Fri, 27 May 2016 17:17:35 -0500 > "Ben Campbell" ben@nostrum.com wrote: > > [...] > > Hello again, Ben, > > I just posted a new version of the document (an announcement should = > get > to the ML soon) that tries to address most, if not all, of your = > points. > You can find some additional comments inline on the parts I haven't > addressed yet (or I only partly addressed), for one reason or another. > To make this more readable, I snipped the parts that I already > integrated. > > * The intended status is proposed standard. Do people really = > expect b2bua vendors to implement the rules in this draft? Do they = > expect existing b2bua implementations to be updated? > > I already answered to this in my previous mail, but just to reinstate, > I'll leave the decision to WG and chairs/ADs as to what the intended > status should be. I personally would keep it a proposed standard, but > again wouldn't object to a BCP, if needed. > > Let's leave this as PS for now, but realize that may change at some = > point as we go forward. As far as getting the WG's opinion goes, it = > might be worth it to send a separate email to the list about this one = > question. Otherwise people may miss it buried in the rest of the = > review comments. > > * Section 3, last paragraph - This paragraph seems to argue that = > the fact that existing b2buas do not follow specs is a reason to = > create more specs. That seems questionable. > > Fair point. I haven't changed that part in the doc yet, as I wanted to > be sure I'd get it right, first. Do you think it would be ok to say > something along the lines of "due to the mixed nature of B2BUAs, they > sometimes can't or won't implement all specifications, so they should > at least do this"? > > I think that logic is reasonable. > > [...] > > * Section 4 > * Last paragraph, 2nd to last sentence - If you think people = > will really pay attention, then this might be a good place for a MUST = > or SHOULD > > Do you mean where we say "behaviour is unspecified and discouraged"? = > Or > more in general about the fact that a B2BUA can only follow the > guidelines when it has access to editing fields without breaking > hashes? Not sure which MUST or SHOULD we might add there, considering > that, if the media the B2BUA is encrypted, it can't possibly edit RTP > related information without disrupting the communication, which in > turn means no RTCP editing will be needed/possible either. > > Do you think a "B2BUAs MUST NOT modify RTP/RTCP data if media is > encrypted" to be enough, in case? > > In retrospect, I wrote that comment without thinking about it in = > context of b2bua-dtls-srtp. Since you already reference that draft, I = > withdraw that comment. No change is really needed. > > * Third paragraph: > * "It SHOULD NOT, though, blindly forward all SDP > > attributes," > - Isn=E2=80=99t > the idea that it should forward any attributes that it > doesn=E2=80=99t > have a specific reason not to forward? (i.e. default to > forwarding?) > > The issue here is the reason not to forward itself. In order to figure > out whether an attribute can be forwarded or not, the B2BUA must have > some knowledge of it and of its impact. What I wanted to highlight in > that sentence is that there are attributes that, if left where they = > are > by a B2BUA unaware of their purpose, can actually cause issues. Just > think, for instance, of 'rtcp' attribute that is explained in the = > text, > or other attributes supporting features a B2BUA may not support = > itself. > > Aren't those attributes that the b2bua must, by definition, know about = > and have a "specific reason" not to forward. > > Of course, as you point out there could be reasons to actually keep > attributes you don't know about in there, e.g., because they advertize > support for an end-to-end feature the B2BUA doesn't need to worry > about. Besides, the attributes that can cause issues are probably not > that many anyway. > > Right. One of the big issues with b2buas is that they tend to make SIP = > networks brittle to new features. I think we need to discourage that = > as much as possible. I realize we can't write guidance on how to = > handle a "foo" attribute that works in all cases of "foo", but we can = > at least err on the side of letting things through. > > I'll think about a way to make this clearer in the next for next > version. > > Okay. > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw --=_MailMate_15E9ECAC-3F40-4C4A-9030-6E8A19262E5C_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,
Where did we end up with this?
Thanks!
Ben.
On 9 Jun 2016, at 16:07, Christer Holmberg wrote:=
(As co-chai= r)

ACK!

Regards,

Christer

Sent from my Windows Phone
From: Ben Campbell
Sent: =E2= =80=8E10/=E2=80=8E06/=E2=80=8E2016 00:04
To: Lorenzo Miniero
Cc: draft-ietf-straw= -b2bua-rtcp.all@ietf.org; straw@ietf.org; Christer Holmberg
Subject: Re:= [straw] Review of draft-ietf-straw-b2bua-rtcp-10

I did a quick scan of the new revision, and I think it's = addressed most of my editorial concerns. I encourage the chairs to re-req= uest publication as soon as the authors address the one or two outstandin= g items mentioned below.

Thanks!

Ben.

On 9 Jun 2016, at 15:51, Ben Campbell wrote:

Hi,

Comments to your email inline. I removed sections that do= n't seem to need further discussion. I will send any comments about the n= ew draft revision separately.

Thanks!

Ben.

On 31 May 2016, at 6:12, Lorenzo Miniero wrote:

On Fri, 27 May 2016 17:17:35 -0500
"Ben Campbell" ben@nostrum.c= om wrote:

[...]

Hello again, Ben,

I just posted a new version of the document (an announcem= ent should get
to the ML soon) that tries to address most, if not all, of your points. You can find some additional comments inline on the parts I haven't
addressed yet (or I only partly addressed), for one reason or another. To make this more readable, I snipped the parts that I already
integrated.

  • The intended status is proposed standard. Do people really expect b2b= ua vendors to implement the rules in this draft? Do they expect existing = b2bua implementations to be updated?

I already answered to this in my previous mail, but just = to reinstate,
I'll leave the decision to WG and chairs/ADs as to what the intended
status should be. I personally would keep it a proposed standard, but
= again wouldn't object to a BCP, if needed.

Let's leave this as PS for now, but realize that may chan= ge at some point as we go forward. As far as getting the WG's opinion goe= s, it might be worth it to send a separate email to the list about this o= ne question. Otherwise people may miss it buried in the rest of the review comments.

  • Section 3, last paragraph - This paragraph seems to argue that the fa= ct that existing b2buas do not follow specs is a reason to create more sp= ecs. That seems questionable.

Fair point. I haven't changed that part in the doc yet, a= s I wanted to
be sure I'd get it right, first. Do you think it would be ok to say
something along the lines of "due to the mixed nature of B2BUAs, the= y
sometimes can't or won't implement all specifications, so they should
= at least do this"?

I think that logic is reasonable.

[...]

  • Section 4
    • Last paragraph, 2nd to last sentence - If you think people will reall= y pay attention, then this might be a good place for a MUST or SHOULD

Do you mean where we say "behaviour is unspecified a= nd discouraged"? Or
more in general about the fact that a B2BUA can only follow the
guidelines when it has access to editing fields without breaking
hashes? Not sure which MUST or SHOULD we might add there, considering
= that, if the media the B2BUA is encrypted, it can't possibly edit RTP
= related information without disrupting the communication, which in
turn means no RTCP editing will be needed/possible either.

Do you think a "B2BUAs MUST NOT modify RTP/RTCP data= if media is
encrypted" to be enough, in case?

In retrospect, I wrote that comment without thinking abou= t it in context of b2bua-dtls-srtp. Since you already reference that draf= t, I withdraw that comment. No change is really needed.

 * Third paragraph:
     * "It SHOULD NOT, though, blindly forward all SDP

attributes,"
- Isn=E2=80=99t
the idea that it should forward any attributes that it
doesn=E2=80=99t
have a specific reason not to forward? (i.e. default to
forwarding?)

The issue here is the reason not to forward itself. In or= der to figure
out whether an attribute can be forwarded or not, the B2BUA must have
= some knowledge of it and of its impact. What I wanted to highlight in
= that sentence is that there are attributes that, if left where they are by a B2BUA unaware of their purpose, can actually cause issues. Just
think, for instance, of 'rtcp' attribute that is explained in the text, or other attributes supporting features a B2BUA may not support itself.

Aren't those attributes that the b2bua must, by definitio= n, know about and have a "specific reason" not to forward.

Of course, as you point out there could be reasons to act= ually keep
attributes you don't know about in there, e.g., because they advertize support for an end-to-end feature the B2BUA doesn't need to worry
about. Besides, the attributes that can cause issues are probably not
= that many anyway.

Right. One of the big issues with b2buas is that they ten= d to make SIP networks brittle to new features. I think we need to discou= rage that as much as possible. I realize we can't write guidance on how t= o handle a "foo" attribute that works in all cases of "foo", but we can at least err on the side of let= ting things through.

I'll think about a way to make this clearer in the next f= or next
version.

Okay.

___________________________= ____________________
straw mailing list
straw@ietf.org
--=_MailMate_15E9ECAC-3F40-4C4A-9030-6E8A19262E5C_=-- From nobody Thu Sep 22 22:49:13 2016 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A12A12B259 for ; Thu, 22 Sep 2016 22:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoWQNJ-gAM3S for ; Thu, 22 Sep 2016 22:49:10 -0700 (PDT) Received: from smtpcmd05149.aruba.it (smtpcmd0871.aruba.it [62.149.156.71]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5BE12B130 for ; Thu, 22 Sep 2016 22:49:09 -0700 (PDT) Received: from rainpc ([87.19.28.55]) by smtpcmd08.ad.aruba.it with bizsmtp id mtp61t00C1BLVgf01tp6xE; Fri, 23 Sep 2016 07:49:08 +0200 Date: Fri, 23 Sep 2016 07:49:05 +0200 From: Lorenzo Miniero To: "Ben Campbell" Message-ID: <20160923074905.01efefe5@rainpc> In-Reply-To: <444B3957-1A78-4572-B3A8-AFC6BD24B977@nostrum.com> References: <1E42F55A-8365-45B5-A08F-25D513514AB1@nostrum.com> <20160531131223.176ff3ef@lminiero> <7594FB04B1934943A5C02806D1A2204B38046839@ESESSMB209.ericsson.se> <444B3957-1A78-4572-B3A8-AFC6BD24B977@nostrum.com> Organization: Meetecho X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-ietf-straw-b2bua-rtcp.all@ietf.org" , "straw@ietf.org" , Christer Holmberg Subject: Re: [straw] Review of draft-ietf-straw-b2bua-rtcp-10 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 05:49:13 -0000 On Thu, 22 Sep 2016 17:38:13 -0500 "Ben Campbell" wrote: > Hi, >=20 > Where did we end up with this? >=20 Hi Ben, I sent a mail to the chairs and Alissa asking how to proceed a few weeks ag= o (I'm afraid I forgot to add you in copy as well, sorry about that!), sinc= e AFAICT after addressing your points the only change that is now needed is= related to Victor's new affiliation. Is this ready to go through WGLC agai= n or were there any unresolved issues? Thanks, Lorenzo > Thanks! >=20 > Ben. >=20 > On 9 Jun 2016, at 16:07, Christer Holmberg wrote: >=20 > > (As co-chair) > > > > ACK! > > > > Regards, > > > > Christer > > > > Sent from my Windows Phone > > ________________________________ > > From: Ben Campbell > > Sent: =E2=80=8E10/=E2=80=8E06/=E2=80=8E2016 00:04 > > To: Lorenzo Miniero > > Cc:=20 > > draft-ietf-straw-b2bua-rtcp.all@ietf.org;=20 > > straw@ietf.org; Christer=20 > > Holmberg > > Subject: Re: [straw] Review of draft-ietf-straw-b2bua-rtcp-10 > > > > I did a quick scan of the new revision, and I think it's addressed=20 > > most of my editorial concerns. I encourage the chairs to re-request=20 > > publication as soon as the authors address the one or two outstanding=20 > > items mentioned below. > > > > Thanks! > > > > Ben. > > > > On 9 Jun 2016, at 15:51, Ben Campbell wrote: > > > > Hi, > > > > Comments to your email inline. I removed sections that don't seem to=20 > > need further discussion. I will send any comments about the new draft=20 > > revision separately. > > > > Thanks! > > > > Ben. > > > > On 31 May 2016, at 6:12, Lorenzo Miniero wrote: > > > > On Fri, 27 May 2016 17:17:35 -0500 > > "Ben Campbell" ben@nostrum.com wrote: > > > > [...] > > > > Hello again, Ben, > > > > I just posted a new version of the document (an announcement should=20 > > get > > to the ML soon) that tries to address most, if not all, of your=20 > > points. > > You can find some additional comments inline on the parts I haven't > > addressed yet (or I only partly addressed), for one reason or another. > > To make this more readable, I snipped the parts that I already > > integrated. > > > > * The intended status is proposed standard. Do people really=20 > > expect b2bua vendors to implement the rules in this draft? Do they=20 > > expect existing b2bua implementations to be updated? > > > > I already answered to this in my previous mail, but just to reinstate, > > I'll leave the decision to WG and chairs/ADs as to what the intended > > status should be. I personally would keep it a proposed standard, but > > again wouldn't object to a BCP, if needed. > > > > Let's leave this as PS for now, but realize that may change at some=20 > > point as we go forward. As far as getting the WG's opinion goes, it=20 > > might be worth it to send a separate email to the list about this one=20 > > question. Otherwise people may miss it buried in the rest of the=20 > > review comments. > > > > * Section 3, last paragraph - This paragraph seems to argue that=20 > > the fact that existing b2buas do not follow specs is a reason to=20 > > create more specs. That seems questionable. > > > > Fair point. I haven't changed that part in the doc yet, as I wanted to > > be sure I'd get it right, first. Do you think it would be ok to say > > something along the lines of "due to the mixed nature of B2BUAs, they > > sometimes can't or won't implement all specifications, so they should > > at least do this"? > > > > I think that logic is reasonable. > > > > [...] > > > > * Section 4 > > * Last paragraph, 2nd to last sentence - If you think people=20 > > will really pay attention, then this might be a good place for a MUST=20 > > or SHOULD > > > > Do you mean where we say "behaviour is unspecified and discouraged"?=20 > > Or > > more in general about the fact that a B2BUA can only follow the > > guidelines when it has access to editing fields without breaking > > hashes? Not sure which MUST or SHOULD we might add there, considering > > that, if the media the B2BUA is encrypted, it can't possibly edit RTP > > related information without disrupting the communication, which in > > turn means no RTCP editing will be needed/possible either. > > > > Do you think a "B2BUAs MUST NOT modify RTP/RTCP data if media is > > encrypted" to be enough, in case? > > > > In retrospect, I wrote that comment without thinking about it in=20 > > context of b2bua-dtls-srtp. Since you already reference that draft, I=20 > > withdraw that comment. No change is really needed. > > > > * Third paragraph: > > * "It SHOULD NOT, though, blindly forward all SDP > > > > attributes," > > - Isn=E2=80=99t > > the idea that it should forward any attributes that it > > doesn=E2=80=99t > > have a specific reason not to forward? (i.e. default to > > forwarding?) > > > > The issue here is the reason not to forward itself. In order to figure > > out whether an attribute can be forwarded or not, the B2BUA must have > > some knowledge of it and of its impact. What I wanted to highlight in > > that sentence is that there are attributes that, if left where they=20 > > are > > by a B2BUA unaware of their purpose, can actually cause issues. Just > > think, for instance, of 'rtcp' attribute that is explained in the=20 > > text, > > or other attributes supporting features a B2BUA may not support=20 > > itself. > > > > Aren't those attributes that the b2bua must, by definition, know about= =20 > > and have a "specific reason" not to forward. > > > > Of course, as you point out there could be reasons to actually keep > > attributes you don't know about in there, e.g., because they advertize > > support for an end-to-end feature the B2BUA doesn't need to worry > > about. Besides, the attributes that can cause issues are probably not > > that many anyway. > > > > Right. One of the big issues with b2buas is that they tend to make SIP= =20 > > networks brittle to new features. I think we need to discourage that=20 > > as much as possible. I realize we can't write guidance on how to=20 > > handle a "foo" attribute that works in all cases of "foo", but we can=20 > > at least err on the side of letting things through. > > > > I'll think about a way to make this clearer in the next for next > > version. > > > > Okay. =20 >=20 >=20 > > _______________________________________________ > > straw mailing list > > straw@ietf.org > > https://www.ietf.org/mailman/listinfo/straw =20 From nobody Mon Sep 26 03:36:25 2016 Return-Path: X-Original-To: straw@ietf.org Delivered-To: straw@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD8012B00F; Mon, 26 Sep 2016 03:36:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147488618360.5074.8929861470327123296.idtracker@ietfa.amsl.com> Date: Mon, 26 Sep 2016 03:36:23 -0700 Archived-At: Cc: straw@ietf.org Subject: [straw] I-D Action: draft-ietf-straw-b2bua-rtcp-13.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 10:36:23 -0000 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 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-13.txt Pages : 17 Date : 2016-09-26 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, 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 messages 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: https://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-rtcp-13 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 nobody Mon Sep 26 08:24:58 2016 Return-Path: X-Original-To: straw@ietf.org Delivered-To: straw@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 402AB12B125; Mon, 26 Sep 2016 08:24:57 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147490349724.5004.12930485926915806157.idtracker@ietfa.amsl.com> Date: Mon, 26 Sep 2016 08:24:57 -0700 Archived-At: Cc: draft-ietf-straw-b2bua-rtcp@ietf.org, ben@nostrum.com, straw@ietf.org, straw-chairs@ietf.org, christer.holmberg@ericsson.com Subject: [straw] Last Call: (Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs)) to Proposed Standard X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 15:24:57 -0000 The IESG has received a request from the Sip Traversal Required for Applications to Work WG (straw) to consider the following document: - 'Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-10-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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, 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 messages 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7656: A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources (Informational - IETF stream) Note that some of these references may already be listed in the acceptable Downref Registry. From nobody Mon Sep 26 13:13:58 2016 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EF212B2AC for ; Mon, 26 Sep 2016 13:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-kuCcq1I3TT for ; Mon, 26 Sep 2016 13:13:55 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466DC12B2A7 for ; Mon, 26 Sep 2016 13:13:55 -0700 (PDT) X-AuditID: c1b4fb3a-aa3ff7000000099a-8c-57e9817e72bd Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 22.AD.02458.E7189E75; Mon, 26 Sep 2016 22:13:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0301.000; Mon, 26 Sep 2016 22:13:50 +0200 From: Christer Holmberg To: "straw@ietf.org" Thread-Topic: Publication request for draft-ietf-straw-b2bua-rtcp-13 Thread-Index: AdIYMmy0gL/MwT7aSUG7f38yf83ssw== Date: Mon, 26 Sep 2016 20:13:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BCFF624@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BCFF624ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM2K7im5j48twgx1XZCxuNT9mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt2umoKjkhXXzrUwNTAeFuti5OSQEDCRmLV+OmsXIxeHkMB6 Rol3M2azgiSEBBYzShyawtLFyMHBJmAh0f1PGyQsIqAqMeHLTUYQW1jAXqLtdS97FyM7UNxF YjM3RIWexPbj+9hBGlmAquf1uoOEeQV8JRbeegU2m1FATOL7qTVMIDazgLjErSfzmSCOEZBY suc8M4QtKvHy8T9WCFtJYu3h7SwQ9fkSv3/cZoSYKShxcuYTlgmMgrOQjJqFpGwWkjKIuI7E gt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMw4A9u +W21g/Hgc8dDjAIcjEo8vAk3nocLsSaWFVfmHmKU4GBWEuH1q3sZLsSbklhZlVqUH19UmpNa fIhRmoNFSZzXbOX9cCGB9MSS1OzU1ILUIpgsEwenVANj4Zx9yZM37X/Jn5k+z1zqosojnqh9 B+cy8j+oXZf/PMx45ceJ/3bGaKurFgqvc/X6lKiZ15EXr/qp3yd92UaZDQVTy8+6/dm3/SrH viyRBdW+frMmKZzz3nJuts6qm+8anQ6oeDXaZOy7/WnNi6VbDz5t8l6osfF37AO5l0fEkxMO qR+0+8sqoMRSnJFoqMVcVJwIAPEGrYl0AgAA Archived-At: Subject: [straw] Publication request for draft-ietf-straw-b2bua-rtcp-13 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 20:13:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BCFF624ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (As co-chair) Hi, The publication request has been submitted for draft-ietf-straw-b2bua-rtcp-= 13. There were quite a bit of editorial changes based on the AD comments from B= en, so anyone who is interested might take a look of those as part of the I= ETF LC. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4BCFF624ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(As co-chair)

 

Hi,

 

The publication request has been submitted for draft= -ietf-straw-b2bua-rtcp-13.

 

There were quite a bit of editorial changes based on= the AD comments from Ben, so anyone who is interested might take a look of= those as part of the IETF LC.

 

Regards,

 

Christer

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B4BCFF624ESESSMB209erics_--