On F= ri, Apr 11, 2014 at 2:08 PM, Hadriel Kaplan <hadriel.kaplan@orac= le.com> wrote:

On Apr 11, 2014, at 1:40 PM, Richard Barnes <rlb@ipv.sx> wrote:

> I have reviewed this document in preparation for IETF LC. =A0Overall, = it looks good to me; I have requested LC. =A0One editorial nit and one comm= ent below.
>
> Thanks,
> --Richard
>
> In Section 5, the antecedent of "which SHOULD be 70" appears= to be the generated Max-Forwards header, so this doesn't really parse.= =A0"The value for this header field SHOULD be 70..."

You're right: that is an nit. :)
I think it's understandable, though a bit odd yes.

Can the RFC Editor change it?

Added the fol= lowing RFC Editor note:

OLD:=A0

=A0= =A0If the received request did not contain a Max-Forwards header field,

=A0 =A0one MUST be created in any request generated in the UAC side, w= hich

=A0 =A0SHOULD be 70, as described for Proxies in section 16.= 6 part 3 of

=A0 =A0[RFC3261].

NEW:=A0

=A0 =A0= If the received request did not contain a Max-Forwards header field,

=A0 =A0one MUST be created in any request generated in the UAC side, a= s=A0

=A0 =A0described for Proxies in section 16.6 part 3 of [RFC3= 261]. =A0As in that

=A0 =A0specification, the value of the new Ma= x-Forwards header SHOULD be=A0

=A0 =A070.

=A0

=
> In the security considerations, you mention resetting the Max-* header= s. Is there a way this could be done that is compatible with the goals of t= his doc? =A0E.g., setting any random value for Max-Forwards, as long as it&= #39;s lower than what came in? =A0Allowing something like this could bring = more proxies into conformance with the overall objective of this document.<= br>

I'd rather ask that up for WG consensus I think.

Personally I'd rather not advocate any form of randomized modification.= =A0My employer's products can do it if configured to (most other SBCs = can too I assume), but it's a good way to get failed calls. You have to= pick a random decrement number in some range, and the range can't be t= oo small or it's worthless to do... but if the range is big, then cross= ing multiple SBCs and B2BUAs will quickly get it to 0 before it reaches the= target.

In some real-world call flows the SIP request crosses a surprising number o= f SIP hops. Even just decrementing by 1 people have reached the hop limit (= though that was with a starting Max-Forwards of 40 if I recall correctly, b= ut still...).

And that's not to mention how hard it is to troubleshoot if some hop in= the middle decrements by random values. And it would make the trace route = mechanism have inconsistent behavior to the user.

So personally I'd vote no - either the SIP device follows this RFC and = decrements by 1, or they don't comply with the RFC. =A0Nice and binary.= :)

I'm fine with either answer. = =A0

--Richard

=A0

-hadriel

--047d7b33cd7cc0d27204f6c925b5-- From nobody Fri Apr 11 12:29:37 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE291A02D4 for ; Fri, 11 Apr 2014 12:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 qs6dPmJFNbAS for ; Fri, 11 Apr 2014 12:29:32 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7E24B1A03BC for ; Fri, 11 Apr 2014 12:29:32 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wn1so6598467obc.30 for ; Fri, 11 Apr 2014 12:29:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=45ddyL0dIFapMw+eit0MWHcbwZVDoFQCmghJgsqVIY4=; b=Z2AA97FKxPCaM0RR2DeNyh1ZNRVBwl3c0vclWaWD189NaLqTEU2XX9IrsvErIsc8Gz T55BS59Ht4lTsIxe7Hh+W8uC3N9XxVanDin+Ql7JcCVSB+jTtyBjrlZB8Z1X1zEN1nPB YEqIBLHnAgvlZrm1MSaPsaN6sfHN2McMLhViGNug4K/JnUqKceYsg9UKXmsy8TEHqaZf b4KpI0aWoPLQK1+7wkmdMYqr14/0J4VGZonOsEeQDza8ca04CA0DSHbv4s5QiQM9cVTg 637d03oep4WN7Vd5Tqy7roEksYM3/cAnjCWvaOF9m1arwuV/gdrn7D9HyokIbHFvWPmB 2SSg== X-Gm-Message-State: ALoCoQln7AWB1N4WYd98K82m27S13J/rKbnkSqu9j5IWZY0yFSv8W8W4NcMBpviJSh4DTC3kYx6y MIME-Version: 1.0 X-Received: by 10.182.248.131 with SMTP id ym3mr3341030obc.58.1397244571089; Fri, 11 Apr 2014 12:29:31 -0700 (PDT) Received: by 10.60.136.231 with HTTP; Fri, 11 Apr 2014 12:29:31 -0700 (PDT) In-Reply-To: References:

Date: Fri, 11 Apr 2014 15:29:31 -0400 Message-ID: From: Richard Barnes To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=001a11c20a04530e5304f6c95a3d Archived-At: http://mailarchive.ietf.org/arch/msg/straw/TljiCGK3HQNgQaqogEjlfFS-J1w Cc: draft-ietf-straw-sip-traceroute@tools.ietf.org, straw@ietf.org Subject: Re: [straw] AD review of draft-ietf-straw-sip-traceroute-02 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 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, 11 Apr 2014 19:29:34 -0000 --001a11c20a04530e5304f6c95a3d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 11, 2014 at 2:22 PM, Hadriel Kaplan wrote: > > On Apr 11, 2014, at 1:44 PM, Richard Barnes wrote: > > > I have reviewed this document in preparation for IETF LC. It is clearly > written, but I have one technical concerns that I would like to address > before IETF LC. > > > > I'm concerned that, as described, the mechanism will lead to confusion > by UAs. How does a UA that initiates a loopback call know if it got the > real endpoint or just some intermediate B2BUA that happened to be the last > one to handle the INVITE? > > Section 3.2: > ... When the ultimate target UAS answers a loopback-based INVITE > with a Max-Forwards greater than or equal to 0, the Reason header > would not be added to the response and the UAC will know the > traceroute is complete. > > > > Even if there is some indicator, it seems better to have the B2BUAs only > respond if there's some consent flag (e.g. Supported: middlebox-answer). > Otherwise, you're requiring every existing UA to check that it actually > got all the way through. > > It's only requiring UAs that implement this doc to do so; and it's not a > very hard thing for the UAC to check. > > If a UAC just wants to do media-loopback to the final UAS, it would set > Max-Forwars to 70 on its first attempt. Though it would still need to check > the answer's Reason header field to verify some B2BUA hadn't answer it due > to reaching the hop limit, but that's a good thing to check for. Ultimately > the purpose of media-loopback is for testing+troubleshooting, so giving > more info isn't a bad thing. :) > > If B2BUAs implement this spec as-is, then they'll see Max-Forwards: 0 and answer the call -- they don't know whether this is part of a traceroute or not. So if a legacy UAC sends out a normal, non-traceroute, INVITE with loopback, and it happens to time out at one of these B2BUAs, and the UAC doesn't know to check for the Reason header for this value (because it's legacy), then it ends up talking to the B2BUA instead of the UAS. It seems like in order to resolve this, you need to either: 1. Require UACs that use loopback to check for Reason (and thus update RFC 6849) 2. Add some consent flag to the INVITE so that the B2BUA can tell traceroutes from other INVITEs --Richard > -hadriel > > --001a11c20a04530e5304f6c95a3d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On F= ri, Apr 11, 2014 at 2:22 PM, Hadriel Kaplan <hadriel.kaplan@orac= le.com> wrote:

On Apr 11, 2014, at 1:44 PM, Richard Barnes <rlb@ipv.sx> wrote:

> I have reviewed this document in preparation for IETF LC. =A0It is cle= arly written, but I have one technical concerns that I would like to addres= s before IETF LC.
>
> I'm concerned that, as described, the mechanism will lead to confu= sion by UAs. =A0How does a UA that initiates a loopback call know if it got= the real endpoint or just some intermediate B2BUA that happened to be the = last one to handle the INVITE?

Section 3.2:
=A0 =A0... When the ultimate target UAS answers a loopback-based INVITE
=A0 =A0with a Max-Forwards greater than or equal to 0, the Reason header =A0 =A0would not be added to the response and the UAC will know the
=A0 =A0traceroute is complete.

> Even if there is some indicator, it seems better to have the B2BUAs on= ly respond if there's some consent flag (e.g. Supported: middlebox-answ= er). =A0Otherwise, you're requiring every existing UA to check that it = actually got all the way through.

It's only requiring UAs that implement this doc to do so; and it&= #39;s not a very hard thing for the UAC to check.

If a UAC just wants to do media-loopback to the final UAS, it would set Max= -Forwars to 70 on its first attempt. Though it would still need to check th= e answer's Reason header field to verify some B2BUA hadn't answer i= t due to reaching the hop limit, but that's a good thing to check for. = Ultimately the purpose of media-loopback is for testing+troubleshooting, so= giving more info isn't a bad thing. :)

If B2BUAs implement this spec as-is, then they'l= l see Max-Forwards: 0 and answer the call -- they don't know whether th= is is part of a traceroute or not. =A0So if a legacy UAC sends out a normal= , non-traceroute, INVITE with loopback, and it happens to time out at one o= f these B2BUAs, and the UAC doesn't know to check for the Reason header= for this value (because it's legacy), then it ends up talking to the B= 2BUA instead of the UAS.

It seems like in order to resolve this, you need = to either:
1. Require UACs that use loopback to check for Reason = (and thus update RFC 6849)
2. Add some consent flag to the INVITE= so that the B2BUA can tell traceroutes from other INVITEs

--Richard

=A0
-hadriel

--001a11c20a04530e5304f6c95a3d-- From nobody Fri Apr 11 13:11:50 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEF71A0737; Fri, 11 Apr 2014 13:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 8x2cpABL0EvZ; Fri, 11 Apr 2014 13:11:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE0B1A033B; Fri, 11 Apr 2014 13:11:42 -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: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140411201142.1557.40606.idtracker@ietfa.amsl.com> Date: Fri, 11 Apr 2014 13:11:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/xLrXmDabFmgc0mMMvnwnB1SxZJk Cc: straw@ietf.org Subject: [straw] Last Call: (Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to- Back User Agents (B2BUAs)) to Proposed Standard X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 11 Apr 2014 20:11:44 -0000 The IESG has received a request from the Sip Traversal Required for Applications to Work WG (straw) to consider the following document: - 'Loop Detection Mechanisms for Session Initiation Protocol (SIP) 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 2014-04-25. 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) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values. This document discusses the difficulties associated with loop detection for B2BUAs, and requirements for them to prevent infinite loops. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-loop-detection/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-loop-detection/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Apr 11 13:23:02 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202C31A040C for ; Fri, 11 Apr 2014 13:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham 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 sCIrwJwNPEMm for ; Fri, 11 Apr 2014 13:23:00 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D95011A02F4 for ; Fri, 11 Apr 2014 13:22:59 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s3BKMv9Q016692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Apr 2014 20:22:58 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3BKMtId009539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2014 20:22:55 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s3BKMtdU006329; Fri, 11 Apr 2014 20:22:55 GMT Received: from [10.0.1.10] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 Apr 2014 13:22:54 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: Date: Fri, 11 Apr 2014 16:22:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References:

To: Richard Barnes X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/straw/p6U9N0wIBNWJiGLYP56IsvnAAiE Cc: draft-ietf-straw-sip-traceroute@tools.ietf.org, straw@ietf.org Subject: Re: [straw] AD review of draft-ietf-straw-sip-traceroute-02 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 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, 11 Apr 2014 20:23:01 -0000 On Apr 11, 2014, at 3:29 PM, Richard Barnes wrote: > If B2BUAs implement this spec as-is, then they'll see Max-Forwards: 0 = and answer the call -- they don't know whether this is part of a = traceroute or not. So if a legacy UAC sends out a normal, = non-traceroute, INVITE with loopback, and it happens to time out at one = of these B2BUAs, and the UAC doesn't know to check for the Reason header = for this value (because it's legacy), then it ends up talking to the = B2BUA instead of the UAS. Good point. So that's another benefit then. B2BUAs solve call failure = problems they didn't even know existed. ;) Actually, getting back to serious mode, that could happen even without = this draft. Max-Forward handling in B2BUAs has always been undefined = behavior until the loopback draft, afaik. > It seems like in order to resolve this, you need to either: > 1. Require UACs that use loopback to check for Reason (and thus update = RFC 6849) I'm fine with that. Another option is to re-title this draft to be = "Media-Loopback Usage in SIP" and add some text about that in general = too. > 2. Add some consent flag to the INVITE so that the B2BUA can tell = traceroutes from other INVITEs It won't help solve the problem you raised fully - it will help if all = B2BUAs along the path implement this draft, but not if they just = implement RFC 6849. Because they can still answer calls based on policy, = and Max-Forwards=3D0 technically doesn't apply to them as a UAS unless = they also implement the loopback draft. -hadriel From nobody Fri Apr 11 13:48:52 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F771A0784 for ; Fri, 11 Apr 2014 13:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 IgGxjV1i98kG for ; Fri, 11 Apr 2014 13:48:44 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5071A076E for ; Fri, 11 Apr 2014 13:48:42 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id i7so6760193oag.19 for ; Fri, 11 Apr 2014 13:48:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I33MWHv63898uNYqzWVIYT+28FjvHX9V4VzEquHwOYk=; b=actKN2sAnSbBYNM5afkke6L+UHpAQLYCJYxgd2QydrVojas0B9PSgY/UH2JcnZdYJi bjCkfvhaNIHBRbg/O5AlY+lwhS3JSFDme1DEr0RDcSyWEszPQDF1Wn2yd0DNynubamHz fzGI0sW2Q8wRjg9RuegLVFj1QALzJOIiaJeIeNbyJr68S675cl6oaRo3UF2zarLA9e0E tNvKj7KBG2bDoxm4rzNt38rYvj8X72P3i708/VV0Zi7OYTLAm9+F3wnOGsoezoqLvLcy b94ozSzd9HB6FTSzijuNf+ivFzGHxumyss1YBVDsjv770/8GJ54Bo9zJnwDqHMfidKa6 +s5g== X-Gm-Message-State: ALoCoQkVfzYx6fbrLdY4UkrStZnKAb9r+yPNWPeA0017AIsnvWZCbEBVtlFYLl43Sp1Yrl5wyv+E MIME-Version: 1.0 X-Received: by 10.182.28.195 with SMTP id d3mr21437933obh.19.1397249320464; Fri, 11 Apr 2014 13:48:40 -0700 (PDT) Received: by 10.60.136.231 with HTTP; Fri, 11 Apr 2014 13:48:40 -0700 (PDT) In-Reply-To: References:

Date: Fri, 11 Apr 2014 16:48:40 -0400 Message-ID: From: Richard Barnes To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=001a11c2cd186ae48c04f6ca755e Archived-At: http://mailarchive.ietf.org/arch/msg/straw/fKuxsl2A5CfFSbOOn803iEhP-kY Cc: draft-ietf-straw-sip-traceroute@tools.ietf.org, straw@ietf.org Subject: Re: [straw] AD review of draft-ietf-straw-sip-traceroute-02 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 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, 11 Apr 2014 20:48:49 -0000 --001a11c2cd186ae48c04f6ca755e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 11, 2014 at 4:22 PM, Hadriel Kaplan wrote: > > On Apr 11, 2014, at 3:29 PM, Richard Barnes wrote: > > > If B2BUAs implement this spec as-is, then they'll see Max-Forwards: 0 > and answer the call -- they don't know whether this is part of a traceroute > or not. So if a legacy UAC sends out a normal, non-traceroute, INVITE with > loopback, and it happens to time out at one of these B2BUAs, and the UAC > doesn't know to check for the Reason header for this value (because it's > legacy), then it ends up talking to the B2BUA instead of the UAS. > > Good point. So that's another benefit then. B2BUAs solve call failure > problems they didn't even know existed. > ;) > > Actually, getting back to serious mode, that could happen even without > this draft. Max-Forward handling in B2BUAs has always been undefined > behavior until the loopback draft, afaik. Good point. I did not have this in mind. > It seems like in order to resolve this, you need to either: > > 1. Require UACs that use loopback to check for Reason (and thus update > RFC 6849) > > I'm fine with that. Another option is to re-title this draft to be > "Media-Loopback Usage in SIP" and add some text about that in general too. > > > > 2. Add some consent flag to the INVITE so that the B2BUA can tell > traceroutes from other INVITEs > > It won't help solve the problem you raised fully - it will help if all > B2BUAs along the path implement this draft, but not if they just implement > RFC 6849. Because they can still answer calls based on policy, and > Max-Forwards=0 technically doesn't apply to them as a UAS unless they also > implement the loopback draft. > How about this in 3.2? """ The mechanism defined in this document could cause B2BUAs to send a 200 response to an INVITE that is not part of a traceroute. In such cases, the UAC would believe that it was exchanging media with the end UAS, when in reality it is talking to an intermediate B2BUA. The UAC can recognize this situation by examining the Reason header. It is RECOMMENDED that UACs implementing RFC 6849 perform this check. (Note that this problem is not introduced by this document, since the behavior of B2BUAs with regard to Max-Forwards has been undefined until the publication of [I-D.ietf-straw-b2bua-loop-detection].) """ > > -hadriel > > --001a11c2cd186ae48c04f6ca755e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On F= ri, Apr 11, 2014 at 4:22 PM, Hadriel Kaplan <hadriel.kaplan@orac= le.com> wrote:

On Apr 11, 2014, at 3:29 PM, Richard Barnes <rlb@ipv.sx> wrote:

> If B2BUAs implement this spec as-is, then they'll see Max-Forwards= : 0 and answer the call -- they don't know whether this is part of a tr= aceroute or not. =A0So if a legacy UAC sends out a normal, non-traceroute, = INVITE with loopback, and it happens to time out at one of these B2BUAs, an= d the UAC doesn't know to check for the Reason header for this value (b= ecause it's legacy), then it ends up talking to the B2BUA instead of th= e UAS.

Good point. So that's another benefit then. B2BUAs solve call fai= lure problems they didn't even know existed.
;)

Actually, getting back to serious mode, that could happen even without this= draft. Max-Forward handling in B2BUAs has always been undefined behavior u= ntil the loopback draft, afaik.

Good point.= =A0I did not have this in mind.

=A0

> It seems like in order to resolve this, you need to either:
> 1. Require UACs that use loopback to check for Reason (and thus update= RFC 6849)

I'm fine with that. =A0Another option is to re-title this draft t= o be "Media-Loopback Usage in SIP" and add some text about that i= n general too.

> 2. Add some consent flag to the INVITE so that the B2BUA can tell trac= eroutes from other INVITEs

It won't help solve the problem you raised fully - it will help i= f all B2BUAs along the path implement this draft, but not if they just impl= ement RFC 6849. Because they can still answer calls based on policy, and Ma= x-Forwards=3D0 technically doesn't apply to them as a UAS unless they a= lso implement the loopback draft.

How about this in 3.2?

"""

The mechanism defined in this document c= ould cause B2BUAs to send a 200 response to an INVITE that is not part of a= traceroute. =A0In such cases, the UAC would believe that it was exchanging= media with the end UAS, when in reality it is talking to an intermediate B= 2BUA. =A0The UAC can recognize this situation by examining the Reason heade= r. =A0It is RECOMMENDED that UACs implementing RFC 6849 perform this check.= =A0(Note that this problem is not introduced by this document, since the b= ehavior of B2BUAs with regard to Max-Forwards has been undefined until the = publication of [I-D.ietf-straw-b2bua-loop-detection].) =A0

"""

=A0

-hadriel

--001a11c2cd186ae48c04f6ca755e-- From nobody Wed Apr 23 05:46:49 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099C61A0081 for ; Wed, 23 Apr 2014 05:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.479 X-Spam-Level: ** X-Spam-Status: No, score=2.479 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 IZgwVobcvY01 for ; Wed, 23 Apr 2014 05:46:46 -0700 (PDT) Received: from smtpdg12.aruba.it (smtpdg228.aruba.it [62.149.158.228]) by ietfa.amsl.com (Postfix) with ESMTP id ACAE91A0377 for ; Wed, 23 Apr 2014 05:46:45 -0700 (PDT) Received: from lminiero ([143.225.229.180]) by smtpcmd04.ad.aruba.it with bizsmtp id tQmd1n01G3uAlfT01Qmden; Wed, 23 Apr 2014 14:46:38 +0200 Date: Wed, 23 Apr 2014 14:46:37 +0200 From: Lorenzo Miniero To: straw@ietf.org Message-ID: <20140423144637.1694c057@lminiero> Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/straw/IQMQsWBAmejCwLJfXpGDVsuxMOY Subject: [straw] Next steps on the RTCP draft X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 23 Apr 2014 12:46:48 -0000 Hi all, a bit later than I wanted, I was starting to re-order the feedback I got in London on the RTCP draft during the STRAW session. After reviewing the recording, the notes, mniutes, etc., I realized that, while there are some points that have been definitely clarified, some couldn't be fully addressed, due to lack of f2f time. There definitely was agreement, for instance, on the need to rewrite the CSRC list, to take into account more RTCP messages besides the AVPF feedback that is currently addressed, that you can't really write a generic guideline for future RTCP messages that may be defined later on, that there are other aspects to take into account (e.g., the a=rtcp SDP attribute that can mess up, payload types that may change, etc.) and so on. A point that had a long discussion but was left unclear, though, is the one related to the taxonomies/topologies as they are addressed in the current version of the doc. While the terminology definitely needs to be improved in general (again, my fault) to avoid ambiguities, there apparently was not consensus on what exactly should be used as a basis for the document: namely, whether keeping the RFC7092 STRAW taxonomy the document tries to refer to as of now (updating it as needed, since it currently refers to the pre-RFC one that had some changes in the meanwhile), or changing the organization of the draft to have it refer to the RTP Topologies update draft. I had some slides on that, since it was one of the points discussed by Albrecht Schwarz on the AVTCORE list, but unfortunately we had to close the discussion a couple of slides before. Nevertheless, we had already had the chance to start discussing the matter before that. You can find the slides here, for some more details on that: http://www.ietf.org/proceedings/89/slides/slides-89-straw-0.pdf The discussion basically was about whether we really needed to involve RTP topologies in the document, or whether the STRAW taxonomy was indeed more suited to describing the different approaches an interested component (according to where in taxonomy it would fall) could take. Needless to say, taking a decision on this specific point would be quite important, as a change in perspective there would require a refactoring of the whole document to more aptly address the scenarios to take into account, and so I'd like to be sure I'm on the right path before starting to work on a new version of the draft. What are your thoughts about that? Thanks, Lorenzo From nobody Wed Apr 23 07:58:02 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362A31A0104 for ; Wed, 23 Apr 2014 07:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 Hur6wkfVYl3Q for ; Wed, 23 Apr 2014 07:57:57 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 396C21A03C4 for ; Wed, 23 Apr 2014 07:57:57 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id tPyf1n0010cZkys53Sxriw; Wed, 23 Apr 2014 14:57:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id tSxr1n00A3ZTu2S3WSxrQX; Wed, 23 Apr 2014 14:57:51 +0000 Message-ID: <5357D4EF.70900@alum.mit.edu> Date: Wed, 23 Apr 2014 10:57:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: straw@ietf.org References: <20140423144637.1694c057@lminiero> In-Reply-To: <20140423144637.1694c057@lminiero> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398265071; bh=cv2cf93RNCRCQZN8XmiivXdxX/OyvOA3m2/Ri9aoo1o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m0maNdVmAB5ydV9zRvPf7txlh/iBJmXqVpnUwDqHd3WiKN9dl2lVgMWnB4IE9Up+K rthn8xtYCl8+QmuMgYCEqa4RfnimoeJyCOmStv9X7PRUhzcUXftn89QBG7gcOkKJcC WJzW200RHczhUIw2Ts5QcnWt2ZqN22NsPAsJ7mGZuEEPHuKUMqrOrofoI4IqGj25Fg VwAppf7KaigtORA4khAozMFaNLpfXTm0UbgX/TGfoH63OiAS4XxsychnYKFblGwGab VKT3UWTz8DnhP/k8cjOw2Ewe4H6iBJA7rpNtRC2TiDbSTVwho4gm0B8ludfZFozjxm mxYIOeZEnsAfA== Archived-At: http://mailarchive.ietf.org/arch/msg/straw/vAInKRJAivu5J0z5UYZK83By48I Subject: Re: [straw] Next steps on the RTCP draft X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 23 Apr 2014 14:57:58 -0000 Lorenzo, On 4/23/14 8:46 AM, Lorenzo Miniero wrote: [snip] > A point that had a long discussion but was left unclear, though, is the > one related to the taxonomies/topologies as they are addressed in the > current version of the doc. While the terminology definitely needs to be > improved in general (again, my fault) to avoid ambiguities, there > apparently was not consensus on what exactly should be used as a basis > for the document: namely, whether keeping the RFC7092 STRAW taxonomy > the document tries to refer to as of now (updating it as needed, since > it currently refers to the pre-RFC one that had some changes in the > meanwhile), or changing the organization of the draft to have it refer > to the RTP Topologies update draft. [snip] > The discussion basically was about whether we really needed to involve > RTP topologies in the document, or whether the STRAW taxonomy was > indeed more suited to describing the different approaches an interested > component (according to where in taxonomy it would fall) could take. My understanding of the discussion was that it is a problem if the straw taxonomy is incompatible with the RTP topologies. that are missing from the RTP topologies. ISTM it would be worthwhile to expend some effort comparing those two documents and trying to correlate them. If we were lucky, there might be a straightforward correlation. (Though it might not be 1:1.) Or it might turn out that straw has identified topologies that are missing from the RTP topologies draft and ought to be added there. I don't think it should be a job of your draft to do that. It might be a new milestone for straw. Whether that means progression of your draft should be delayed is something that should be part of the discussion. Thanks, Paul From nobody Wed Apr 23 08:35:38 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9BA1A02BD for ; Wed, 23 Apr 2014 08:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 0Q0f6XIEEpCp for ; Wed, 23 Apr 2014 08:35:34 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 530EF1A02A8 for ; Wed, 23 Apr 2014 08:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2392; q=dns/txt; s=iport; t=1398267328; x=1399476928; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Pw32GCJ3c/tHy0fENf47v32aIm3MWge41OOEfdLJrjw=; b=bRXeOg74z6UQyYpX6PqbbZSRkbHDusy7GZ/42U4Fd0jNljsxDJQb9DmY G+uVPkUXjL+EJKLotEX3qs9cvBAioTX/pNdBKYxq0jVM89fwpRSu0P/pp vNRo+IGqLnSc11UupNdpFJAQPo8AohUcqotdLsZzSgCapNDD/fNiWViSG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAWAJLcV1OtJV2Z/2dsb2JhbABZDoJ4T1e8eYMuhAyBGhZ0giUBAQEDAQEBATc0CwULAgEIDgoeECcLJQIEDgWIOQgNzxUTBI4lMweDJIEVBJh1klWCcUCCKw X-IronPort-AV: E=Sophos;i="4.97,912,1389744000"; d="scan'208";a="38098150" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 23 Apr 2014 15:35:28 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3NFZSer021978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Apr 2014 15:35:28 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Wed, 23 Apr 2014 10:35:28 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [straw] Next steps on the RTCP draft Thread-Index: AQHPXvIWzhY3qblII0ewz8PYG8IQhJsfnrmAgAAKgAA= Date: Wed, 23 Apr 2014 15:35:26 +0000 Message-ID: <16DB594B-5AEB-4C86-8268-2017C123F706@cisco.com> References: <20140423144637.1694c057@lminiero> <5357D4EF.70900@alum.mit.edu> In-Reply-To: <5357D4EF.70900@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.213.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <1934E0DB82F4864A9D0A2E8F94B4C87F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/Pzakr19tVhf7t-TvpNUa29UZ-s8 Cc: "straw@ietf.org" Subject: Re: [straw] Next steps on the RTCP draft X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 23 Apr 2014 15:35:36 -0000 On Apr 23, 2014, at 10:57 AM, Paul Kyzivat wrote: > Lorenzo, >=20 > On 4/23/14 8:46 AM, Lorenzo Miniero wrote: >=20 > [snip] >=20 >> A point that had a long discussion but was left unclear, though, is the >> one related to the taxonomies/topologies as they are addressed in the >> current version of the doc. While the terminology definitely needs to be >> improved in general (again, my fault) to avoid ambiguities, there >> apparently was not consensus on what exactly should be used as a basis >> for the document: namely, whether keeping the RFC7092 STRAW taxonomy >> the document tries to refer to as of now (updating it as needed, since >> it currently refers to the pre-RFC one that had some changes in the >> meanwhile), or changing the organization of the draft to have it refer >> to the RTP Topologies update draft. >=20 > [snip] >=20 >> The discussion basically was about whether we really needed to involve >> RTP topologies in the document, or whether the STRAW taxonomy was >> indeed more suited to describing the different approaches an interested >> component (according to where in taxonomy it would fall) could take. >=20 > My understanding of the discussion was that it is a problem if the straw = taxonomy is incompatible with the RTP topologies. that are missing from the= RTP topologies. >=20 > ISTM it would be worthwhile to expend some effort comparing those two doc= uments and trying to correlate them. If we were lucky, there might be a str= aightforward correlation. (Though it might not be 1:1.) Or it might turn ou= t that straw has identified topologies that are missing from the RTP topolo= gies draft and ought to be added there. As a side note: I think it was also mentioned that this document, among sev= eral others, should adhere to the rtp taxonomy draft (draft-ietf-avtext-rtp= -grouping-taxonomy). I do think this is something that can/should be enfor= ced. Cheers, Gonzalo >=20 > I don't think it should be a job of your draft to do that. It might be a = new milestone for straw. Whether that means progression of your draft shoul= d be delayed is something that should be part of the discussion. >=20 > Thanks, > Paul >=20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw