From nobody Tue Sep 2 01:47:25 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4619F1A0141 for ; Tue, 2 Sep 2014 01:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 hkSWxGE20ZuM for ; Tue, 2 Sep 2014 01:47:22 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE281A0ADF for ; Tue, 2 Sep 2014 01:47:22 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so13875609wiv.11 for ; Tue, 02 Sep 2014 01:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6k8DfK6RE6uRIsWWkO2VB5Y+FsW3giTOUiQgAoqRZAs=; b=l/k4yl1NzFv3aC3wdbSP6Wo6+fwAok8BucXU6HwNmzVGshj1qtoq4oIzxJo/rEz+2S eJpa6Z6UURljGx51pCcyMvmfXURURaAQQqOgB0dTmx7PKiPy/RNJ5rIDbF2ULBrTk/ri CDfrPaIqq4fI9qXOd0GkQ60X7EyTjjLfaEqnBgCkiAIdIDwBlpGrACxTWdRCo2lP2PcG rKbj0Dn6npZeln3lWxgAIA6ZBwH82hMasdnwWFotxXKIGfkE6B6kcHINfida38Vlxw+d ZuVw0+7azAMNMYb9pXKHytxRU8HLIzePTUThjH51G6sIaxT7NxXgATF68EaFt4mNI/H5 6Nkw== MIME-Version: 1.0 X-Received: by 10.180.207.105 with SMTP id lv9mr26287818wic.23.1409647640976; Tue, 02 Sep 2014 01:47:20 -0700 (PDT) Received: by 10.194.39.231 with HTTP; Tue, 2 Sep 2014 01:47:20 -0700 (PDT) In-Reply-To: <5400F838.9060000@alum.mit.edu> References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201408292056.s7TKuWok015949@hobgoblin.ariadne.com> <5400F838.9060000@alum.mit.edu> Date: Tue, 2 Sep 2014 09:47:20 +0100 Message-ID: From: Michael Procter To: dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Z9FfJqCz1M5geU0mWnktiaEsLDo Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 08:47:24 -0000 On 29 August 2014 23:01, Paul Kyzivat wrote: > > On 8/29/14 4:56 PM, Dale R. Worley wrote: >> >> How the phone, the registrar, and the edge proxy negotiate whether to >> use Outbound is described in RFC 5626 section 4.2 -- that is, assuming >> that everyone understands that *if* Outbound is to be used, *either* >> the outbound-proxy-set is to be taken from DNS *or* the administrative >> authority responsible for the DNS has configured the phone by some >> other means. This is a part that I don't think is defined. I can't see a reading of RFC 5626 that supports the *either*/*or* part of your description. Without a document stating it, I am unsure whether everyone will share the same understanding! >> (There is no need for additional negotiation, because how the >> administrator of the phone has configured it already tells it where to >> get the outbound-proxy-set.) This might be key: I agree that you could configure a UA to do this, in a similar way to how you could simply configure the outbound-proxy-set in the first place. Are you suggesting that by not configuring the outbound-proxy-set, you are implicitly configuring the UA to use proxies derived from DNS SRV records? > Dale - your proposal is that if a single registration receives an indication of > outbound support, then we can infer that other servers from DNS can be > used that way. That seems plausible. It is *possible* that it is inconsistent > with deployed implementations of outbound. One problem that this might cause is if a provider uses a low-priority SRV record as a canary. If it sees any traffic, then a number of faults must have occurred. Using all SRV records as outbound proxies will obviously send REGISTER traffic to the canary, and probably will result in call traffic too (from the provider), reducing the benefit of the canary. I don't know how many providers use such a technique, but I thought having the negotiation token was a small price to pay to eliminate this and any other problems the changed behaviour might cause. Michael From nobody Tue Sep 2 12:19:39 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A108F1A0669 for ; Tue, 2 Sep 2014 12:19:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 2PqUhIdUE-dQ for ; Tue, 2 Sep 2014 12:19:35 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDF51A0687 for ; Tue, 2 Sep 2014 12:19:35 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta02.westchester.pa.mail.comcast.net with comcast id mClY1o00327AodY51KKbUg; Tue, 02 Sep 2014 19:19:35 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta19.westchester.pa.mail.comcast.net with comcast id mKKa1o00i1KKtkw3fKKbCA; Tue, 02 Sep 2014 19:19:35 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s82JJYC2029942; Tue, 2 Sep 2014 15:19:34 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s82JJYsf029941; Tue, 2 Sep 2014 15:19:34 -0400 Date: Tue, 2 Sep 2014 15:19:34 -0400 Message-Id: <201409021919.s82JJYsf029941@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Michael Procter In-reply-to: (michael.ietf@gmail.com) References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201408292056.s7TKuWok015949@hobgoblin.ariadne.com> <5400F838.9060000@alum.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409685575; bh=pHvXyoAHEG6siDEpWNIL6KGbO3xYz6LTwBCTCuPaRjY=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=e3yWaBDsFAl+12XTbkirTB0ec5EbWoDtcA1XwoIqwzkLe4MxNhebPk97VxghHjP77 QGCKuxg+qL3SAOELuRPnnEKIIcdFxcgOMOSw2G5nc99sRNh0MEyT/M3hgD44c190Ro LRQjLtKzushBQxYMtEoO+Rb6dfNhCnq6fyk0LMK5hkQVlZKCfu+1qkWrwLwaHBhA9V i4H01kXeF923BEULIWPgfPkWU1DJS7wLvluG97YbXibfuUkDQdSpCAJLtm53PYvU47 DQ9pGZueRbDj6XcxN9lIdrEGf4D1bYzl3DosepalaIupGBWSDEfy/hIbPMkuoDeaDP PQsVh5A6CvAKA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/GgPBISc8WA2CDHXx_59VVal6qYg Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 19:19:37 -0000 Let me try to take things in order from "least controversial" to "most controversial": > From: Michael Procter > > This is a part that I don't think is defined. I can't see a reading > of RFC 5626 that supports the *either*/*or* part of your > description. Without a document stating it, I am unsure whether > everyone will share the same understanding! I've already stated that I agree that there should be a document stating the use of multiple SRV choices for selecting the targets for multiple Outbound proxies. However, I think the subject needs to be extended for the case where the AOR domain name has no SRV records, but it does have multiple A or AAAA records. Multiple A/AAAA records are commonly used for redundancy, and their use in Outbound seems natural. (It's probably already being done.) In any case, it doesn't seem to require any serious expansion of the software -- the RFC 3263 code is already extracting a list of contact addresses for the domain name. > One problem that this might cause is if a provider uses a > low-priority SRV record as a canary. If it sees any traffic, then a > number of faults must have occurred. Using all SRV records as > outbound proxies will obviously send REGISTER traffic to the canary, > and probably will result in call traffic too (from the provider), > reducing the benefit of the canary. This is an interesting problem and probably ought to be discussed in the draft. In theory, if the domain provides more SRV records than (allowed number of redundant connections) + (allowance for proxies that are unavailable), then the lowest-priority record will still function properly as a canary, but its detection capability will be diminished . But there is no mechanism in RFC 5626 for the server(s) to control the number of connections UAs establish. (Although the text of section 4.2.1 suggests that the number is likely to be limited to the range 2 to 4.) In regard to negotiating outbound support, the UA and the registrar go through this sequence: - the UA sends a REGISTER with reg-id in the Contact, and adds "Supported: outbound". - The edge proxy adds a Path value containing its URI, with an ob URI parameter. - the registrar verifies that edge proxy has indicated Outbound support, adds "Require: outbound" to its response. Only when this is successful is the UA allowed to establish a second flow. There are a number of ways that the SIP system can provide the outbound-proxy-set to the UA: - via DNS records - via "manual" configuration (usually through a Web interface provided by the UA) - via the profile delivery system (But I don't think this been defined.) - via a vendor-defined configuration delivery system It seems to me that in all of these cases except the first, the UA will have already received specific information as to how it should obtain its outbound-proxy-set (indeed, it will have already received its outbound-proxy-set). Which is why I don't see the need for a specific indication to flow from the registrar to the UA; there is only one case where the UA has not already been instructed. When we define a *second* mechanism in which the UA must actively obtain the outbound-proxy-set, then we will need an indicator -- for the new mechanism. (It's possible that the situation doesn't work as simply in practice as it does in theory. In that case, can we present an example of the difficulty?) > Are you suggesting that by not configuring the outbound-proxy-set, > you are implicitly configuring the UA to use proxies derived from > DNS SRV records? Yes -- because there is no other implicit mechanism for obtaining the proxies. > > Dale - your proposal is that if a single registration receives an > > indication of outbound support, then we can infer that other > > servers from DNS can be used that way. That seems plausible. It is > > *possible* that it is inconsistent with deployed implementations > > of outbound. Well, I don't recall how the UA is supposed to behave if it makes one Outbound registration and when attempting to make a second registration, Outbound support fails. My memory is that combination isn't allowed to happen -- the UA is allowed to maintain one registration without Outbound, or one or more registrations all of which use Outbound. > I don't know how many providers use such a technique, but I thought having the > negotiation token was a small price to pay to eliminate this and any other > problems the changed behaviour might cause. I guess I don't see this as "changed behavior" -- how else would UAs behave in the past? Or rather, what are the problematic examples that we need to accommodate? > From: Paul Kyzivat > ISTM that the *minimum* that a UA needs to have configured for itself is > an AOR. > > From the AOR it can derive a URI of the corresponding registrar by > removing the user part. > > Are you assuming *that* is then what is used as the URI for the outbound > proxy set? Or are you assuming some other URI is configured, that is > expected to identify an outbound-proxy-set? Unless the UA has been positively instructed in some manner, the only way that it can obtain the outbound-proxy-set is by looking up the domain name of the AOR. > If the UA is starting with just an AOR, without any expectation of > whether the registrar supports outbound, then it is at least a bit > tricky. A registrar that doesn't support outbound isn't going to be > happy with multiple simultaneous registrations to multiple servers for > its domain. True, but the registrar tells the UA whether it supports Outbound in the response to the first REGISTER. If the UA doesn't receive that indication, it isn't supposed to register anot flow. Dale From nobody Tue Sep 2 15:37:58 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18631A88CE for ; Tue, 2 Sep 2014 15:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 ECJkWbM-ilM0 for ; Tue, 2 Sep 2014 15:37:48 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936F81A06DB for ; Tue, 2 Sep 2014 15:37:48 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id z107so7283074qgd.40 for ; Tue, 02 Sep 2014 15:37:47 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=j4NiRHPvikPnXX4vsYqchbbq8EIekvYLCDuMU8o7EjM=; b=QH8JyzDgx5fchLVqnrG1Dn6VGDFB72/hAgmTJ06QbJ6y4undJARPnT+Fx7yT1UcYUr 7V31tjS41FSjzTmca9TskdJnPJKQNMHrNN2h6yEe1hAxgzRCzOIDZu2L2rwKLwvr4KZt k7VbTyumjUBUexyW7dxwDjRqRkBfzFM80FZ+hu2r07Hch299jj48yHEfLp7oXoAbCKxc v/tNoKFavCyyrynyCb8C+RUNhcYHpFChubfVu3iDRN5ZVMlaMBNWQbQ1FY8HMSDu5THO MNrtvgJsjWeFeG6ML3Jbw0I8/V9PkapYbe4Ek9B//604/08SVdW+2R0OZGhg7tLmsLsj 0Tqg== X-Gm-Message-State: ALoCoQmJ5JV8voNI/gnqHbCjrWOFoqmqQo9hoqL9Nf+veTY3w6mV2dsxflDIxf6tO7pa+SeeTOTR X-Received: by 10.224.46.138 with SMTP id j10mr59953062qaf.85.1409697467345; Tue, 02 Sep 2014 15:37:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Tue, 2 Sep 2014 15:37:26 -0700 (PDT) In-Reply-To: <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 3 Sep 2014 00:37:26 +0200 Message-ID: To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/C2EE5AvA4ql_CNGKIzQnCQhtGPQ Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 22:37:49 -0000 2014-08-27 23:34 GMT+02:00 Dale R. Worley : > Certainly the functionality is needed. But what I don't see is why > the ordinary use of RFC 3263 and DNS SRV records does not suffice. > That has been the practice in systems that I've seen: You arrange for > phones in the "outside universe" to see a set of SRV records that list > the available edge proxies, and the phone attempts to establish one or > more connections through one or more of the proxies. This > establishment "just happens" when the phone attempts to send its > REGISTER to the DNS name of its SIP domain. IMHO there is a problem here: outbound proxy !=3D inbound proxy. For exampl= e: - sip:alice@atlanta.com and sip:bob@biloxi.com. - If Alice wants to contact Bob she would perform a NAPTR/SRV DNS stuff on biloxi.com so she will reach the inbound server (or one of them) associated to Bob. - But when Bob wants to register through an outbound proxy he needs the address of the outbound proxy which may not be the same as the inbound proxies for biloxi.com (those discovered by Alice via DNS procedures). Do I miss something? --=20 I=C3=B1aki Baz Castillo From nobody Wed Sep 3 08:27:30 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BAE1A03E8 for ; Wed, 3 Sep 2014 08:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3] 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 4_weG9N64EVr for ; Wed, 3 Sep 2014 08:27:27 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF801A0464 for ; Wed, 3 Sep 2014 08:26:47 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta07.westchester.pa.mail.comcast.net with comcast id meXX1o00417dt5G57fSmuH; Wed, 03 Sep 2014 15:26:46 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta13.westchester.pa.mail.comcast.net with comcast id mfSl1o00x1KKtkw3ZfSmXA; Wed, 03 Sep 2014 15:26:46 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s83FQjv8000721; Wed, 3 Sep 2014 11:26:45 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s83FQiXf000720; Wed, 3 Sep 2014 11:26:44 -0400 Date: Wed, 3 Sep 2014 11:26:44 -0400 Message-Id: <201409031526.s83FQiXf000720@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: =?utf-8?Q?I=C3=B1aki?= Baz Castillo In-reply-to: (ibc@aliax.net) References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409758006; bh=STVeYo1E/l30phMLp0As8bfajGpZlJqbWTsrDqvAB0k=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject:MIME-version:Content-type; b=UYBIlkCuwPPm57KcjnhX7+fUnOAWFNwNN2FwA1R7HVvPfxSP2RztK14FwlUNZsNnt WieFCG4hYOJyaugohH5zFQ3vfOsHmJWRvoIoYaRltgCgN3/XVcTZ5Er1blaGe/LY5d CgwjXi9HitG09aCv/2mTGAj45nBI2nXcyF7ZG0QbTUonxltJhK7JGXBB33BFQPUhzp tKk0fayBQzl4VNB2VWNEOzQxsaAvcJk8t+ZjdHnaZQhrrBSVEBwlksWdxhFSXTksoB wDbSwVkHO0A2nmSlSkiO3aMNdXyolA18+4+W2MuUJOI2MH5vO02VdGiFfq/R30kh/P 54ViDZ5fHPVSg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/RvfsAd7JPogEO2nTjQ4phpJL-Kg Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 15:27:28 -0000 > From: IƱaki Baz Castillo > IMHO there is a problem here: outbound proxy != inbound proxy. For example: > - If Alice wants to contact Bob she would perform a NAPTR/SRV DNS > stuff on biloxi.com so she will reach the inbound server (or one of > them) associated to Bob. > > - But when Bob wants to register through an outbound proxy he needs > the address of the outbound proxy which may not be the same as the > inbound proxies for biloxi.com (those discovered by Alice via DNS > procedures). I've never seen such a configuration, although that doesn't mean they don't exist. But if there is such a configuration, how does the UA find the proxies it is supposed to use to register? The only standardized mechanism is through DNS, but we assume it does not give the correct result. Dale From nobody Wed Sep 3 09:05:27 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A891A8A71 for ; Wed, 3 Sep 2014 09:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.267 X-Spam-Level: X-Spam-Status: No, score=-101.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 5dr1LRszGglG for ; Wed, 3 Sep 2014 09:05:19 -0700 (PDT) Received: from mx0a-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 3F46A1A8A5F for ; Wed, 3 Sep 2014 09:05:17 -0700 (PDT) Received: from pps.filterd (m0049376.ppops.net [127.0.0.1]) by m0049376.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s83G1cD0010096; Wed, 3 Sep 2014 12:05:10 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049376.ppops.net-0018ba01. with ESMTP id 1p5n56t3xm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 03 Sep 2014 12:05:10 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Wed, 3 Sep 2014 12:05:09 -0400 From: "Peterson, Jon" To: "Dale R. Worley" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt Thread-Index: AQHPwTgc2OTFstcjk06dVbmC5ex4QZvk+vjpgAnClgCAANc1Nv//2CwA Date: Wed, 3 Sep 2014 16:05:08 +0000 Message-ID: References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201409031526.s83FQiXf000720@hobgoblin.ariadne.com> In-Reply-To: <201409031526.s83FQiXf000720@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.168.129.1] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6A0AEDAA66E20846AB5081F822D9178D@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7549 signatures=670509 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.49622536582683e-11 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 urlsuspect_oldscore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.993311949948012 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409030168 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/3JQiefyw4EjTPUaPEBJonf_XtMs Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 16:05:21 -0000 Beside this potential asymmetry, I think the more fundamental scope issue is that your AoR is associated with the administrative domain where you register - but locating outbound proxies in various roaming-type scenarios might have little to do with that administrative domain. If solving for this were in scope, it would require a fairly generic service discovery protocol. Like, for the network I am in, how do I discover the necessary set of outbound proxy servers that will let outbound traffic escape. In some cases, forming a TLS connection to my home administrative domain will be enough. In others, I need to interrogate the local network in some fashion to identify a local outbound proxy. That could look like DHCP, or for DNS U-NAPTR (RFC4848), or a toolbox of other options. I may need to chain from that local outbound proxy to the outbound proxy of my administrative domain, too. To the point of this thread, this is why this is all hand-wavy in RFC5626, if I recall correctly. I don't think looking up your home administrative domain in the DNS and finding the SRV records placed there for inbound traffic would be likely to solve for the entire problem space, anyway. Jon Peterson Neustar, Inc. On 9/3/14, 8:26 AM, "Dale R. Worley" wrote: >> From: I=F1aki Baz Castillo > >> IMHO there is a problem here: outbound proxy !=3D inbound proxy. For >>example: > >> - If Alice wants to contact Bob she would perform a NAPTR/SRV DNS >> stuff on biloxi.com so she will reach the inbound server (or one of >> them) associated to Bob. >>=20 >> - But when Bob wants to register through an outbound proxy he needs >> the address of the outbound proxy which may not be the same as the >> inbound proxies for biloxi.com (those discovered by Alice via DNS >> procedures). > >I've never seen such a configuration, although that doesn't mean they >don't exist. > >But if there is such a configuration, how does the UA find the proxies >it is supposed to use to register? The only standardized mechanism is >through DNS, but we assume it does not give the correct result. > >Dale > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Sep 3 13:24:39 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B84D1A6F70 for ; Wed, 3 Sep 2014 13:24:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 99Jtk8X6WuA3 for ; Wed, 3 Sep 2014 13:24:32 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id A738F1A6FB0 for ; Wed, 3 Sep 2014 13:24:26 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id mieQ1o0041c6gX85DkQS6M; Wed, 03 Sep 2014 20:24:26 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta23.westchester.pa.mail.comcast.net with comcast id mkQR1o00p1KKtkw3jkQRli; Wed, 03 Sep 2014 20:24:26 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s83KOPhM016887; Wed, 3 Sep 2014 16:24:25 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s83KOOWl016885; Wed, 3 Sep 2014 16:24:24 -0400 Date: Wed, 3 Sep 2014 16:24:24 -0400 Message-Id: <201409032024.s83KOOWl016885@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Peterson\, Jon" In-reply-to: References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201409031526.s83FQiXf000720@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409775866; bh=0XGt/r0fKNzG3MnoNV5XrFLfRCBWy1KKRtQhbCOMIK0=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=lDI/lAUPCYn/1q9JhbEJZJcXItQgd4+jH/2X8cZrda3RMwAgUFcHId/4VBzZwCAXx f/+i05tuqcV86x0p/FCMij2tFwFmzB5mOdNFyowEsUw8HNei2foiZ6wegx9nOuYgx/ iiNsnI7Fyu+TbEpnRXFL5lvWMztoZBc4pmvOkKLk54m1SG7Ks5caK/cJgGqIOMcGbP WSF0mGjShGLI8U2jo7pjqbHiJjnjvIST+RkoX/eizhzGlUrnlRNzxlqy2YsvxdqJW4 DwOXNVmenW/g6bNMTrJS+SrZENx+LTA13EMcZy4pzID9fVBWc/X/ttYYonhXL445o9 goLFa6OJdKdOw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/GjR2Ryk67tS96_6i-bPndFxiU3M Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 20:24:36 -0000 > From: "Peterson, Jon" > If solving for this were in scope, it would require a fairly generic > service discovery protocol. Like, for the network I am in, how do I > discover the necessary set of outbound proxy servers that will let > outbound traffic escape. This is getting close to what the "User Agent Profile Delivery" (RFC 6080) was trying to do. But that never reached solidity. > To the point of this thread, this is why this is all hand-wavy in RFC5626, > if I recall correctly. IIRC, the UA profile delivery work was proceeding in parallel, which is why 5626 avoided discussing the topic. Dale From nobody Wed Sep 3 15:43:09 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EA01A6FD8 for ; Wed, 3 Sep 2014 15:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.567 X-Spam-Level: X-Spam-Status: No, score=-101.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 lriVaxjBmyRL for ; Wed, 3 Sep 2014 15:43:05 -0700 (PDT) Received: from mx0a-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 DC3821A6FC8 for ; Wed, 3 Sep 2014 15:43:05 -0700 (PDT) Received: from pps.filterd (m0049402.ppops.net [127.0.0.1]) by m0049402.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s83Mfj8e025040; Wed, 3 Sep 2014 18:43:00 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049402.ppops.net-0018ba01. with ESMTP id 1p5n55b8u3-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 03 Sep 2014 18:43:00 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Wed, 3 Sep 2014 18:42:59 -0400 From: "Peterson, Jon" To: "Dale R. Worley" Thread-Topic: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt Thread-Index: AQHPwTgc2OTFstcjk06dVbmC5ex4QZvk+vjpgAnClgCAANc1Nv//2CwAgAC9yQD//7FagA== Date: Wed, 3 Sep 2014 22:42:58 +0000 Message-ID: References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201409031526.s83FQiXf000720@hobgoblin.ariadne.com> <201409032024.s83KOOWl016885@hobgoblin.ariadne.com> In-Reply-To: <201409032024.s83KOOWl016885@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.168.129.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7550 signatures=670510 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=7.7715611723761e-16 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 urlsuspect_oldscore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.993311949948012 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409030242 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/OVJM7IvqAONr14_R9oAERvFGQhE Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 22:43:06 -0000 You're right that config profiles were supposed to be a potential way of learning about outbound proxies, and RFC6080 does have some text about finding a local profile. I'm not sure I'd call it a robust mechanism - it basically assumes that DHCP or static configuration is giving you a local domain name (like via RFC3361 or at worst RFC2132), and then you subscribe to the config profile at that domain - but if you can bootstrap from that, you could use it to get a config profile from the local administrative domain. But to your solidity point: did anyone ever specify a config profile for actually configuring outbound proxies? Or for anything else, really? RFC6080 is probably another solution to consider for this problem space, but as far as I can recall there'd still be work to do there. Jon Peterson Neustar, Inc. On 9/3/14, 1:24 PM, "Dale R. Worley" wrote: >> From: "Peterson, Jon" > >> If solving for this were in scope, it would require a fairly generic >> service discovery protocol. Like, for the network I am in, how do I >> discover the necessary set of outbound proxy servers that will let >> outbound traffic escape. > >This is getting close to what the "User Agent Profile Delivery" (RFC >6080) was trying to do. But that never reached solidity. > >> To the point of this thread, this is why this is all hand-wavy in >>RFC5626, >> if I recall correctly. > >IIRC, the UA profile delivery work was proceeding in parallel, which >is why 5626 avoided discussing the topic. > >Dale From nobody Thu Sep 4 03:00:37 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212F21A6F2E for ; Thu, 4 Sep 2014 03:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 mxgT7hnxqAsn for ; Thu, 4 Sep 2014 03:00:34 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695CA1A6F29 for ; Thu, 4 Sep 2014 03:00:34 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so9796181wes.8 for ; Thu, 04 Sep 2014 03:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a+4BsRWN7qZY7gkFNoc3Db99Sq82ArcNW5Uh/EZ1wS8=; b=iZJ5z/0CWMtvPEYHzYVYMlfxnes3xmo4f9xQIfwbj4Q53CxZfeDJw5JntUBf9XRu4A KyXyTCVcstFH2wwwwdPrW5ObXN8tH4c87aW7GJxYD1PiUMmcL8X069HffbvSkFwpzqfu cewh8Yvu4SmLxMXsr3nWhVRwGGQAyPE7AALXZggeA9ksggaBe9VCpQlC+jImJobGNQDb XajfY8HFuYTz76yeNs41mQdZsFLIqlAhO6I8tBuBymRmAR9NJP8VWCs5Hsj+CYc4vlIj zeLf6ur6I9KhEmzEsRc1Abyn157vep8cTCpammHxvw3g59FYi5G51qE6k5QEUKu78/QB mtgw== MIME-Version: 1.0 X-Received: by 10.194.5.162 with SMTP id t2mr4442693wjt.97.1409824831004; Thu, 04 Sep 2014 03:00:31 -0700 (PDT) Received: by 10.194.39.231 with HTTP; Thu, 4 Sep 2014 03:00:30 -0700 (PDT) In-Reply-To: <201409021919.s82JJYsf029941@hobgoblin.ariadne.com> References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201408292056.s7TKuWok015949@hobgoblin.ariadne.com> <5400F838.9060000@alum.mit.edu> <201409021919.s82JJYsf029941@hobgoblin.ariadne.com> Date: Thu, 4 Sep 2014 11:00:30 +0100 Message-ID: From: Michael Procter To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/3srnwQl3sc-Xkhe4KzVEraBxsjI Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 10:00:36 -0000 Hi Dale, Comments inline, although I've reordered things slightly! On 2 September 2014 20:19, Dale R. Worley wrote: > > I've already stated that I agree that there should be a document > stating the use of multiple SRV choices for selecting the targets for > multiple Outbound proxies. >> Are you suggesting that by not configuring the outbound-proxy-set, >> you are implicitly configuring the UA to use proxies derived from >> DNS SRV records? > Yes -- because there is no other implicit mechanism for obtaining the > proxies. OK. If I were to remove the 'obfromsrv' negotiation token from my draft, would that make the draft a reasonable starting point for defining this? > However, I think the subject needs to be extended for the case where > the AOR domain name has no SRV records, but it does have multiple A or > AAAA records. I was initially sceptical about going this far, but on reflection, I think you are probably right. The key part for me is that this is only done when there are no SRV records. In particular, I don't want to expand SRV and then expand A/AAAA and register to everything that I find. > [Effect on a low priority SRV canary] > > This is an interesting problem and probably ought to be discussed in > the draft. I will add a section discussing this, although I think it will basically highlight the effect that you will see (registrations using the canary record) rather than offer any solutions or workarounds. > In regard to negotiating outbound support, the UA and the registrar go > through this sequence: Yes. The sequence is unchanged and requires an initial successful registration with the registrar indicating support before the additional registrations can be made. > There are a number of ways that the SIP system can provide the > outbound-proxy-set to the UA: > > - via DNS records > > - via "manual" configuration (usually through a Web interface provided > by the UA) > > - via the profile delivery system (But I don't think this been defined.) > > - via a vendor-defined configuration delivery system > > It seems to me that in all of these cases except the first, the UA > will have already received specific information as to how it should > obtain its outbound-proxy-set (indeed, it will have already received > its outbound-proxy-set). Which is why I don't see the need for a > specific indication to flow from the registrar to the UA; there is > only one case where the UA has not already been instructed. One case I wanted to distinguish was when "manual configuration" was intended, but the configuration had been erroneously omitted. I can't fix this case by adding a negotiation token anyway, so I think you have convinced me. I'll remove the token. Regards, Michael From nobody Thu Sep 4 03:00:44 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776601A6FF1 for ; Thu, 4 Sep 2014 03:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 hdbc-4JvY0Gb for ; Thu, 4 Sep 2014 03:00:39 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0778E1A6FEF for ; Thu, 4 Sep 2014 03:00:38 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so741288wib.14 for ; Thu, 04 Sep 2014 03:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7HZMMVniOs7O1OusC4dhwPBPbZgF/GwsDcBTPzhTdEk=; b=o/SI1jjHOm+l2XpS4nPGawwG8eeT0+MAQiJQ5bPpeKPhiSt17ndy6DxU1/rKe1PEve B32Q7xfRqfVT1WAnxQhzdgE0oxGuOgyY1mlM702He6eHcQ3MTo7/eWaK4GlJ0IP0K5/i Mb3TAw98cJibRnquE8u3UFbD0b/Jd5ZjJS/6y+gG+2NLnjIWd4dz2bcN3Sft9E2YzYlC QRqP2ZNk5m2U8BKPubU9uW9eWBhw1IkQDS/thEJJIQHg5AJfXSvQJI+ip/hh1a4hf7jq n4l3b/SIrSiEfeGTWbBwWNVY2S1DI97h+/L1ezvZ+DIyeZ6wpX9xLM+LvHcxIp0fQWa5 OVzw== MIME-Version: 1.0 X-Received: by 10.180.75.17 with SMTP id y17mr4383084wiv.3.1409824836731; Thu, 04 Sep 2014 03:00:36 -0700 (PDT) Received: by 10.194.39.231 with HTTP; Thu, 4 Sep 2014 03:00:36 -0700 (PDT) In-Reply-To: References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201409031526.s83FQiXf000720@hobgoblin.ariadne.com> <201409032024.s83KOOWl016885@hobgoblin.ariadne.com> Date: Thu, 4 Sep 2014 11:00:36 +0100 Message-ID: From: Michael Procter To: "Peterson, Jon" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ykhqaq_tLQAqn-HxGiLDO9sR3L0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 10:00:42 -0000 On 3 September 2014 23:42, Peterson, Jon wrote: > But to your solidity point: did anyone ever specify a config profile for > actually configuring outbound proxies? Or for anything else, really? > RFC6080 is probably another solution to consider for this problem space, > but as far as I can recall there'd still be work to do there. I'm not aware of any outbound proxy config profile work, and I did try to find traces of other work in this area before writing the draft. I am reluctant to make RFC6080 part of the solution given the current small scope of the draft. Indeed, given some of Dale's comments, the draft is getting ever closer to describing a current practice rather than defining new features. Regards, Michael From nobody Thu Sep 4 05:13:08 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2A61A8855 for ; Thu, 4 Sep 2014 05:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 oqPcfBOPEMdU for ; Thu, 4 Sep 2014 05:13:03 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C1F1A885F for ; Thu, 4 Sep 2014 05:11:44 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id el20so3067998lab.6 for ; Thu, 04 Sep 2014 05:11:42 -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=7HMzVF2BF6taw6bDm0C3O+MB7cqHcGvOtuVoxOzzyEg=; b=Tg/0apDykbtDaXHejqskxkjTm3lK3AyST3V54Kld+7DsVy0ceFxs5WhNZiGjen0ptm YMUd++90iEXFyawpIcGyKcWHql/BKml1Vndq59BDUHQUmabUZAuXAG9iC79cfAIHwtnv cxcLWkCVwUBdAh5fJLPNJ4ym8+ERtc+WUGTcjR3CIzav9EROd9aL0vbQW6O0bav+ppQT FFH2iarfJ25IC+o3UV39rukecP+OGZe9Dq6dg3LMsFmxzfxf1mGjVaTA9MA+YHQSfyh+ 7t4TMmSoxJ9BqxlWIOtlgxU/f0Dm4rF9n/bz/ohvAJYiZL/eD+Hpv0GbByU+RcEcdCUc zbmw== X-Gm-Message-State: ALoCoQlOcjAJEHuEjSypkXNSePai3nvhFf75chV3nktimsVAHOQoFd0PWG+BlIfRLT5sAXtw7PDX MIME-Version: 1.0 X-Received: by 10.112.170.138 with SMTP id am10mr4032790lbc.74.1409832702782; Thu, 04 Sep 2014 05:11:42 -0700 (PDT) Received: by 10.25.137.6 with HTTP; Thu, 4 Sep 2014 05:11:42 -0700 (PDT) In-Reply-To: References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201409031526.s83FQiXf000720@hobgoblin.ariadne.com> <201409032024.s83KOOWl016885@hobgoblin.ariadne.com> Date: Thu, 4 Sep 2014 08:11:42 -0400 Message-ID: From: Simon Perreault To: Michael Procter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/yfsOJICliU6_D2kRNwQDbiuXur4 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 12:13:06 -0000 On Thu, Sep 4, 2014 at 6:00 AM, Michael Procter wrote: > I am reluctant to make RFC6080 part of the solution given the current > small scope of the draft. Indeed, given some of Dale's comments, the > draft is getting ever closer to describing a current practice rather > than defining new features. +1 That is the direction I would like seeing this go. Thanks, Simon From nobody Thu Sep 4 12:08:23 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8941A02D6 for ; Thu, 4 Sep 2014 12:08:18 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 rL_rBYoLr1Lr for ; Thu, 4 Sep 2014 12:08:14 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id B4E251A02BB for ; Thu, 4 Sep 2014 12:08:13 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta08.westchester.pa.mail.comcast.net with comcast id n2ZQ1o0081uE5Es5878DAN; Thu, 04 Sep 2014 19:08:13 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta16.westchester.pa.mail.comcast.net with comcast id n78C1o0071KKtkw3c78Cq6; Thu, 04 Sep 2014 19:08:13 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s84J8BfP024047; Thu, 4 Sep 2014 15:08:11 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s84J8A5n024046; Thu, 4 Sep 2014 15:08:10 -0400 Date: Thu, 4 Sep 2014 15:08:10 -0400 Message-Id: <201409041908.s84J8A5n024046@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Peterson\, Jon" In-reply-to: References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201409031526.s83FQiXf000720@hobgoblin.ariadne.com> <201409032024.s83KOOWl016885@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409857693; bh=qOyPj0ydmBUVwcce14Gu3ZuyN2m3OHkNPO3x8KRkkWg=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=QKUgN84aE0/+ERA5Qyq6Mrj10ASPcDLLgUSRUB1iPxEVkxxAq/1EbyPWOqqIePRwo We4zVkewHUbomkJEOCpVay354j3WuJ2OsugQOjB6UnFvGH97JtDdzaiM45aRMUuZiZ 091QV+esH/qM2mDpIH8N4ZBtTjpApXltczI/bN3twztdlfxukjxSpCTm2QVBjcD00o YxK594P3oM/HzbHsqtyeiHcacnNUX5+6aFDQ3y/6+xFffvpJh5ZThRjrmJldchMV/u CdVeuXmQFrIfuwdWFRLj9ciH4dM0LwnMysFJ/A+TSnu/xD9YzW7CayzLodEaDgNhlT TsJTq8hcrOUag== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/7H5Anlw6NqhF7KzniJbM0SJ95MA Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 19:08:19 -0000 > From: "Peterson, Jon" > But to your solidity point: did anyone ever specify a config profile for > actually configuring outbound proxies? Or for anything else, really? > RFC6080 is probably another solution to consider for this problem space, > but as far as I can recall there'd still be work to do there. There is a "profile data set" for "media policy" (which media are allowed to be sent at what bandwidth). It's RFC 6796. But that's the only profile data set that has made it to RFC. draft-petrie-sipping-profile-datasets-05 section 6 gives Dan Petrie's proposed list of profile datasets: 6. Candidate Data Sets The following sections name some of the candidate data sets that are or may be defined. These data sets can be aggregated to form profiles appropriate to the capabilities of a user agent implementation. o SIP Protocol Data Set: the lowest common denominator set of properties common to all SIP user agents of any capability. A schema covering the elements of this data set can be found in [I-D.petrie-sipping-sip-dataset]. o Media Data Set: this data set contains media related policies. A schema covering the elements of this data set can be found in [I-D.ietf-sipping-media-policy-dataset]. o Identity Data Set: AORs and lines (see [I-D.petrie-sipping-identity-dataset]) o HTTP Protocol Data Set: server settings. Proxy for clients. o NAT Traversal Data Set: settings for STUN, TURN etc. o SIP Digit Maps Data Set: [I-D.petrie-sipping-voip-features-dataset] o VoIP Features: [I-D.petrie-sipping-voip-features-dataset] o Address Book: o Buddy List: draft-petrie-sipping-sip-dataset-03 provides an element, but it seems to be used to carry a route set. The intention seems to be that any alternatives or redundancies will be specified in the DNS records for the provided proxy name-addrs. Dale From nobody Thu Sep 4 13:27:37 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB681A00A2 for ; Thu, 4 Sep 2014 13:27:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 wjjK0nKzbHLw for ; Thu, 4 Sep 2014 13:27:34 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 25CBC1A0073 for ; Thu, 4 Sep 2014 13:27:34 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta05.westchester.pa.mail.comcast.net with comcast id n77E1o0051GhbT8558TZiP; Thu, 04 Sep 2014 20:27:33 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta07.westchester.pa.mail.comcast.net with comcast id n8TZ1o00A1KKtkw3T8TZj4; Thu, 04 Sep 2014 20:27:33 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s84KRWui028173; Thu, 4 Sep 2014 16:27:32 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s84KRWnL028172; Thu, 4 Sep 2014 16:27:32 -0400 Date: Thu, 4 Sep 2014 16:27:32 -0400 Message-Id: <201409042027.s84KRWnL028172@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Michael Procter In-reply-to: (michael.ietf@gmail.com) References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201408292056.s7TKuWok015949@hobgoblin.ariadne.com> <5400F838.9060000@alum.mit.edu> <201409021919.s82JJYsf029941@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409862453; bh=lA9Wg8Cf0JZTX6MKtQFg180EUK+cv+7iLPL904eg99k=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=KYXB0XsW/nY5+EotcUZyCQTeEXDg52Mg3gyjTSB44nja5H5hF91dzMLNqIuGftPZY xvtrY/T7K2H6d45PAO665IlMewGp/RRFWGSUWNxLIan2mrFQcAAiXQbSCRcfMEY9HQ 4xOKvvxmZ6BKVaOlVXlgWGGKR5ii39Mrqc8FKWm9Y/ZEY8mDKIF6tiOfIEUpTyOrBa lZ+GC2Cg3FskXN6pWVcNIniaxSaDlBdvpDUBSMsFZitmkmuu9XhMAmn9MdQlfzrTEY l5BhbfSnyXgt+BxEFNB95yhwE2xv5htLhvCspsg6ogHhRi5eJwGzQ6OaAJM7Qpvoy9 h7Rb0ogiJOLFg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/zhfZCV0EVrU-qTZ5oUo1BJTZAUk Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 20:27:35 -0000 > From: Michael Procter > > > I've already stated that I agree that there should be a document > > stating the use of multiple SRV choices for selecting the targets for > > multiple Outbound proxies. > > >> Are you suggesting that by not configuring the outbound-proxy-set, > >> you are implicitly configuring the UA to use proxies derived from > >> DNS SRV records? > > Yes -- because there is no other implicit mechanism for obtaining the > > proxies. > > OK. If I were to remove the 'obfromsrv' negotiation token from my > draft, would that make the draft a reasonable starting point for > defining this? Yes -- I've always wanted to progress this, with the single objection that "obfromsrv" is not needed. > > However, I think the subject needs to be extended for the case where > > the AOR domain name has no SRV records, but it does have multiple A or > > AAAA records. > > I was initially sceptical about going this far, but on reflection, I > think you are probably right. The key part for me is that this is > only done when there are no SRV records. In particular, I don't want > to expand SRV and then expand A/AAAA and register to everything that I > find. Let me explain how I look at this: RFC 3263 defines a resolution process which takes as input parts of a URI (SIP scheme vs. SIPS scheme), hostport, and optional "transport" parameter), and produces as output a sequence of contact addresses (IP address/port/protocol triples). A SIP agent then attempts the contact addresses in order in order to send the message. (The resolution process is responsible for doing any randomization, as specified by SRV records or as implied by other records.) (And you can implement SIP transmission this way, as we did in the sipX system.) Within this context, I see the process of establishing Outbound flows as a matter of going through the resolution output list in order until the desired number of flows are established. And within *that* context, multiple A/AAAA records are just one source of alternative contact addresses. > One case I wanted to distinguish was when "manual configuration" was > intended, but the configuration had been erroneously omitted. I can't > fix this case by adding a negotiation token anyway, so I think you > have convinced me. I'll remove the token. I agree with that. Dale From nobody Thu Sep 4 16:40:46 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2CA1A0282 for ; Thu, 4 Sep 2014 16:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.567 X-Spam-Level: X-Spam-Status: No, score=-101.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 DWiJRYe97WZR for ; Thu, 4 Sep 2014 16:40:44 -0700 (PDT) Received: from mx0a-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 7C60E1A026F for ; Thu, 4 Sep 2014 16:40:44 -0700 (PDT) Received: from pps.filterd (m0049376.ppops.net [127.0.0.1]) by m0049376.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s84NeAP3015673; Thu, 4 Sep 2014 19:40:38 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049376.ppops.net-0018ba01. with ESMTP id 1p6pun9vqd-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 04 Sep 2014 19:40:38 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc10.cis.neustar.com ([169.254.4.83]) with mapi id 14.03.0158.001; Thu, 4 Sep 2014 19:40:36 -0400 From: "Peterson, Jon" To: "Dale R. Worley" Thread-Topic: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt Thread-Index: AQHPwTgc2OTFstcjk06dVbmC5ex4QZvk+vjpgAnClgCAANc1Nv//2CwAgAC9yQD//7FagIABy64A///WwYA= Date: Thu, 4 Sep 2014 23:40:36 +0000 Message-ID: References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201409031526.s83FQiXf000720@hobgoblin.ariadne.com> <201409032024.s83KOOWl016885@hobgoblin.ariadne.com> <201409041908.s84J8A5n024046@hobgoblin.ariadne.com> In-Reply-To: <201409041908.s84J8A5n024046@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.168.129.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7551 signatures=670511 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 urlsuspect_oldscore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.993311949948012 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409040220 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/SZGxtXh3_23KHsNseKnnIz78f2E Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 23:40:45 -0000 >draft-petrie-sipping-sip-dataset-03 provides an >element, but it seems to be used to carry a route set. The intention >seems to be that any alternatives or redundancies will be specified in >the DNS records for the provided proxy name-addrs. Intuitively, I am still having a hard time accepting that the hosts one advertises as the targets of inbound requests for a SIP domain would necessarily be the hosts a user agent would need to discover to send traffic out of that administrative domain. Again, we went down the config profile path because it had an option to discover things associated with the local network, not just the domain where you register, and I don't hear anyone claiming you don't need to resolve that local network problem if you want to discover outbound proxies. But beyond that, the asymmetry question does still bother me too. Not that I endorse unrighteous architectures along these lines, but my understanding is that some SIP networks have ingress elements that enforce policies at the network borders and do all sorts of mucking about with signaling. Those are what you would advertise in your SRVs for such networks (if anything). It seems unlikely to me that the interface of a border controller you would advertise to the outside world is the same interface that clients inside the network should use in an outbound Route set. In many cases I imagine those interface are not in the same address space, even. Jon Peterson Neustar, Inc. From nobody Fri Sep 5 08:32:24 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFB31A071D for ; Fri, 5 Sep 2014 08:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 AK4qlW_WJG4p for ; Fri, 5 Sep 2014 08:32:23 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830DE1A071C for ; Fri, 5 Sep 2014 08:32:22 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so1051764wib.3 for ; Fri, 05 Sep 2014 08:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/+1K3oX6Xp7z8kE/h7mVoErPFfGa9/fRL9OkX7sK6bc=; b=N01I/0umHC0d37LJgmwuZrjste9fUBJZlieO4nhQjyKbbMjme/WZ3xDW9IJOYDByLa KffqJ1xXNjl8u/xlc5ITa+vihDo/JRpkz+NH91erYjQQDrUYpohkEojaNgKeKBW5GiXl mYJOaDXZZyc5V4odfmHYhBQ68n1Xr3dC9Ix+UgkclezugX1lxYLpBBBNAM9e/uieQeaH 2l89qpWBBP3l800llz4uIU3Ozom3GEGsceLkDvqDx64ykta6veOKKRNS3+Y34mI5ckSU sChFcUd90NShY/PEp685BOZbXmXpj41AsbUNxsxXMmDLNVAJC22LMNjOAmUlG3ZJuu2d VPhA== MIME-Version: 1.0 X-Received: by 10.194.5.162 with SMTP id t2mr15584363wjt.97.1409931138774; Fri, 05 Sep 2014 08:32:18 -0700 (PDT) Received: by 10.194.39.231 with HTTP; Fri, 5 Sep 2014 08:32:18 -0700 (PDT) In-Reply-To: <201409042027.s84KRWnL028172@hobgoblin.ariadne.com> References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201408292056.s7TKuWok015949@hobgoblin.ariadne.com> <5400F838.9060000@alum.mit.edu> <201409021919.s82JJYsf029941@hobgoblin.ariadne.com> <201409042027.s84KRWnL028172@hobgoblin.ariadne.com> Date: Fri, 5 Sep 2014 16:32:18 +0100 Message-ID: From: Michael Procter To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/crdIQySw9vXuhXJUeMwDap6Ap2c Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:32:24 -0000 On 4 September 2014 21:27, Dale R. Worley wrote: > Within this context, I see the process of establishing Outbound flows > as a matter of going through the resolution output list in order until > the desired number of flows are established. And within *that* > context, multiple A/AAAA records are just one source of alternative > contact addresses. OK - you have unconvinced me again! I think I understand where you are coming from, in that the normal 3263 resolution mechanism will naturally yield a list of IP/port, regardless of which ones apply to which SRV records. However, I don't think it will give the results we want in a few key cases. In this problem, there are two ways to set up redundant services. One is to advertise multiple SRV records, and one is to advertise multiple A/AAAA records. I fully support the first way, and accept that the second way is sometimes used. However, the part I am not happy about is that if a domain is set up with multiple SRV records, each of which names a host with multiple A/AAAA records, then we should register to each A/AAAA record separately. I want to avoid the situation where a UA limited to 2 (or 4, the number doesn't really matter) proxies in the outbound-proxy-set ends up with a bunch of registrations all bound to the same edge proxy. I don't think it gives sufficient diversity, and I don't think it matches the expectations of whoever set up the SRV records. To that end, if there are SRV records, I'd like to register to each one once (and allow any multiple A/AAAA records to be used for routing to that logical proxy). However, if there are no SRV records, I can see the merit of looking up multiple A/AAAA records to populate the outbound-proxy-set instead. Does that make sense to you? I have updated the draft to reflect the removal of negotiation, but I haven't added words about the use of multiple A/AAAA records yet, since we haven't agreed what they should be. Regards, Michael From nobody Fri Sep 5 08:35:05 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178151A0864 for ; Fri, 5 Sep 2014 08:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 DoVUJcflacXI for ; Fri, 5 Sep 2014 08:35:00 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556A61A0842 for ; Fri, 5 Sep 2014 08:35:00 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id n12so1002843wgh.29 for ; Fri, 05 Sep 2014 08:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZEj8L9NNcySqVNN/YFA7q11GW8+Z4d0vvMjw1vteQjE=; b=M0bSzQMz5YAeDbUhKff5x4E1LRMOzNpMIWUZAeGXvxfRbQP4N58MlcOR3jL9wTYA33 fcSk2Cfi++/vyP1ZM/QhhbMMStqHQfVk3vpDOhtDp8h4pEkQXYVXgkyrj8T06frIZSrL wGxntSWimn/GHy/WR0S07hIlyYyGBrbfZ89n4sPmhlM/nKz7ipu8Nszc78rdrDuY+PTx dEkyPY8KYxHRRBtvaU2jmna0PGc0tFJv0sd2NqrTII3rVjxZpmI66u34BvKjGIoqTbmq PgWeUh9ruzA1cT4UrydJI9v8/2/5IUBniAdrRlSP+WZnY/munSaBDyMtsmKFS53YHOON GEUA== MIME-Version: 1.0 X-Received: by 10.180.184.166 with SMTP id ev6mr4662924wic.23.1409931299053; Fri, 05 Sep 2014 08:34:59 -0700 (PDT) Received: by 10.194.39.231 with HTTP; Fri, 5 Sep 2014 08:34:58 -0700 (PDT) In-Reply-To: References: <20140905133523.23106.99247.idtracker@ietfa.amsl.com> Date: Fri, 5 Sep 2014 16:34:58 +0100 Message-ID: From: Michael Procter To: "dispatch@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/qPitMb67bEPlPXaCsYm0E7_cM2k Subject: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:35:04 -0000 I've updated the draft in the light of comments, mainly from Dale and Paul. It is now shorter! Name: draft-procter-dispatch-outbound-discovery Revision: 01 Title: Automatic discovery of RFC 5626 Edge Proxies Document date: 2014-09-05 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-procter-dispatch-outbound-discovery-01.txt Status: https://datatracker.ietf.org/doc/draft-procter-dispatch-outbound-discovery/ Htmlized: http://tools.ietf.org/html/draft-procter-dispatch-outbound-discovery-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-procter-dispatch-outbound-discovery-01 Abstract: [RFC5626] (commonly known as 'SIP outbound') defines mechanisms that permit SIP (Session Initiation Protocol) UAs (User Agents) to maintain multiple connections to a registrar or proxy via multiple Edge Proxies, known as the outbound-proxy-set. Discovering the URIs that make up the outbound-proxy-set is left to configuration or future discovery mechanisms. This draft defines a simple discovery mechanism that enables UAs to discover the URIs of all the Edge Proxies in the outbound-proxy-set without requiring additional configuration on the UA. From nobody Fri Sep 5 09:19:35 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AE91A0AD8 for ; Fri, 5 Sep 2014 09:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yghkilqgoT5D for ; Fri, 5 Sep 2014 09:19:32 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 789891A0AD1 for ; Fri, 5 Sep 2014 09:19:32 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta13.westchester.pa.mail.comcast.net with comcast id nR7x1o0040cZkys5DUKXhw; Fri, 05 Sep 2014 16:19:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta10.westchester.pa.mail.comcast.net with comcast id nUKX1o0083Ge9ey3WUKXwj; Fri, 05 Sep 2014 16:19:31 +0000 Message-ID: <5409E293.7010705@alum.mit.edu> Date: Fri, 05 Sep 2014 12:19:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201408292056.s7TKuWok015949@hobgoblin.ariadne.com> <5400F838.9060000@alum.mit.edu> <201409021919.s82JJYsf029941@hobgoblin.ariadne.com> <201409042027.s84KRWnL028172@hobgoblin.ariadne.com> In-Reply-To: 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=1409933971; bh=IX7ze2qZgDTUenGqwdh4y8MfdWvNsucXWEQBgxeqtgs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IFqS4tjynbjEci3eb4vbKl8ECxjrTozGPO3YcAmHLVIZpH7MsPJViElCP53VvrQl/ uHQQY844yKLfCwwxscjtxJh2hyk/wJyp6mP1FtKKfC+Rn0pKo/0aUJSfVO+PJ6exeU tz23rFlYcE66ULy9+jWVAoMI/bq2tzyZLrt6oGNf8oY/nRkUUU5IYaBOf+G9jUzEZq 4le9pyCAbenWhyjn/8ek93W98FJ4YLMS7J/JpLeXktTTYI2SFOiA1ab2pXqHlFWaBR M5FuiuYdfkOI+o96bPzF3z6KDSChiRplx8Xd00KVyHsxcHzYTUs6ZEGoVsaYLKtJKK jbmobVjQV3xKg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/rlrgVKXbl4yzSQImwh2wgjf18mI Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 16:19:34 -0000 Multiple A/AAAA records may well be for different interfaces on a single server. I don't think two interfaces on the same server would be good choices for multiple outbound connections. I'm not sure if that is one of the points Michael is making below or not. Thanks, Paul On 9/5/14 11:32 AM, Michael Procter wrote: > On 4 September 2014 21:27, Dale R. Worley wrote: >> Within this context, I see the process of establishing Outbound flows >> as a matter of going through the resolution output list in order until >> the desired number of flows are established. And within *that* >> context, multiple A/AAAA records are just one source of alternative >> contact addresses. > > OK - you have unconvinced me again! I think I understand where you > are coming from, in that the normal 3263 resolution mechanism will > naturally yield a list of IP/port, regardless of which ones apply to > which SRV records. However, I don't think it will give the results we > want in a few key cases. > > In this problem, there are two ways to set up redundant services. One > is to advertise multiple SRV records, and one is to advertise multiple > A/AAAA records. I fully support the first way, and accept that the > second way is sometimes used. However, the part I am not happy about > is that if a domain is set up with multiple SRV records, each of which > names a host with multiple A/AAAA records, then we should register to > each A/AAAA record separately. I want to avoid the situation where a > UA limited to 2 (or 4, the number doesn't really matter) proxies in > the outbound-proxy-set ends up with a bunch of registrations all bound > to the same edge proxy. I don't think it gives sufficient diversity, > and I don't think it matches the expectations of whoever set up the > SRV records. > > To that end, if there are SRV records, I'd like to register to each > one once (and allow any multiple A/AAAA records to be used for routing > to that logical proxy). However, if there are no SRV records, I can > see the merit of looking up multiple A/AAAA records to populate the > outbound-proxy-set instead. Does that make sense to you? > > I have updated the draft to reflect the removal of negotiation, but I > haven't added words about the use of multiple A/AAAA records yet, > since we haven't agreed what they should be. > > Regards, > > Michael > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Fri Sep 5 09:33:05 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76511A0AD9 for ; Fri, 5 Sep 2014 09:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uZ5gQPPnHqnS for ; Fri, 5 Sep 2014 09:33:03 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 367CA1A092F for ; Fri, 5 Sep 2014 09:33:02 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id nQ7F1o0011ap0As5CUZ1ql; Fri, 05 Sep 2014 16:33:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta22.westchester.pa.mail.comcast.net with comcast id nUZ11o00P3Ge9ey3iUZ199; Fri, 05 Sep 2014 16:33:01 +0000 Message-ID: <5409E5BD.8010007@alum.mit.edu> Date: Fri, 05 Sep 2014 12:33:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201409031526.s83FQiXf000720@hobgoblin.ariadne.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409934781; bh=MPpXX6pDx9b2+9qaGupBIXrH/7qYfc//cDkbIUlJVGM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m6nNrJX5KeTw7d0SnNhRxal7uQEjGrRgo6HULcPNLPU62xS8d3vsfHnG9qVa44zYP uHSsHkq6Ih3uH+HBrry5y3Lf1omV7TCwqzC64v7h3jArlaIlgB9YIAgAHxCCzAmLvp UK3Ge7imIIAl/MD4rwV+gJ9AlSg60wHqRqq3pucLeJ8WKFql09lUEjhK4t+IkOp5nf mwm+1oNgLaJ7JJrQLTG1tPsN/1N6fgYh/K1zU7COVTWqGq74hq381SDhXvfSjsydIW 9o3a5MDcf1hE0MOAtk837KSqQxMptSt2WMfHDwPt8TyUpKHW6JKIrqil/klyWRWJoj 4/o21Po3Yf9uw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/IYVFE3JU9ixbKFnAGNI1zI8Usv0 Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 16:33:05 -0000 On 9/3/14 12:05 PM, Peterson, Jon wrote: > > Beside this potential asymmetry, I think the more fundamental scope issue > is that your AoR is associated with the administrative domain where you > register - but locating outbound proxies in various roaming-type scenarios > might have little to do with that administrative domain. Certainly this is a factor in some environments. I consider that out of scope for Michael's draft. Maybe it should mention that. But there are also cases where there won't be any proxies from other administrative domains between UA and the registrar. An interesting question is whether the servers resolved from the domain of the AOR are actually registrars, or are proxies leading to the registrar. Another potential issue is the use of Service-Route during registration. Is there any way that it can be compatible with outbound? Thanks, Paul > If solving for this were in scope, it would require a fairly generic > service discovery protocol. Like, for the network I am in, how do I > discover the necessary set of outbound proxy servers that will let > outbound traffic escape. In some cases, forming a TLS connection to my > home administrative domain will be enough. In others, I need to > interrogate the local network in some fashion to identify a local outbound > proxy. That could look like DHCP, or for DNS U-NAPTR (RFC4848), or a > toolbox of other options. I may need to chain from that local outbound > proxy to the outbound proxy of my administrative domain, too. > > To the point of this thread, this is why this is all hand-wavy in RFC5626, > if I recall correctly. I don't think looking up your home administrative > domain in the DNS and finding the SRV records placed there for inbound > traffic would be likely to solve for the entire problem space, anyway. > > Jon Peterson > Neustar, Inc. > > On 9/3/14, 8:26 AM, "Dale R. Worley" wrote: > >>> From: Ińaki Baz Castillo >> >>> IMHO there is a problem here: outbound proxy != inbound proxy. For >>> example: >> >>> - If Alice wants to contact Bob she would perform a NAPTR/SRV DNS >>> stuff on biloxi.com so she will reach the inbound server (or one of >>> them) associated to Bob. >>> >>> - But when Bob wants to register through an outbound proxy he needs >>> the address of the outbound proxy which may not be the same as the >>> inbound proxies for biloxi.com (those discovered by Alice via DNS >>> procedures). >> >> I've never seen such a configuration, although that doesn't mean they >> don't exist. >> >> But if there is such a configuration, how does the UA find the proxies >> it is supposed to use to register? The only standardized mechanism is >> through DNS, but we assume it does not give the correct result. >> >> Dale >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Sun Sep 7 10:09:06 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38C71A0476 for ; Sun, 7 Sep 2014 10:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -116.153 X-Spam-Level: X-Spam-Status: No, score=-116.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 QcR_6hwB5NVb for ; Sun, 7 Sep 2014 10:08:59 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030661A02FC for ; Sun, 7 Sep 2014 10:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3564; q=dns/txt; s=iport; t=1410109739; x=1411319339; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mSd8MI3OYOt3zAnfj3ssUVvY6wztSW9ZTrzA96aTqBk=; b=WyVSUhkJNzYv8cZbqFPUHlV4Zl0MPG5kldYqURi54a3929N6aidM8K1J Zu2jzKxbf7u5d3A/XXHkEKE4PZN2ICfSuiIV/9bFqaZ01rot8BG71WOpA tDyKzli0PNwSnO/69PUjrF9i176nsNHh7PWbglZDwO5n9Aj7Fe8fwpWPO I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAICQDFStJA2L/2dsb2JhbABYgmojU1cEyV0MhndTAYECFniEAwEBAQMBAQEBNzQJAgULAgEIEQMBAh8QJwsdCAIEDgUJiDEIAQy7SgEXjSuBbzMHBoMpgR0FhhqLJoQwhwKBX5NNghuBRmwBgUeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,483,1406592000"; d="scan'208";a="353231166" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP; 07 Sep 2014 17:08:56 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s87H8ucw031726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Sep 2014 17:08:56 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Sun, 7 Sep 2014 12:08:55 -0500 From: "Cullen Jennings (fluffy)" To: Michael Procter Thread-Topic: [dispatch] New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt Thread-Index: AQHPyr5ngEyaQzrtaUSIflDWkeAgAw== Date: Sun, 7 Sep 2014 17:08:54 +0000 Message-ID: References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <57475E58E291AC47A945B157DAD6816E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/z3ambHqhm_V2PtNewtNc_bLqVg4 Cc: IETF Dispatch Subject: Re: [dispatch] New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 17:09:00 -0000 Michael,=20 Interesting draft. I have a small proposed change that might solve some of = the problems that have been raised.=20 In your current draft, the UA registering to example.net does a DNS SRV loo= kup of=20 _sip._tcp.example.net Instead of this, make a UA that implemented this draft do a SRV lookup of=20 _sip-outbound._tcp.example.net This separates the configuration of outbound proxies from other ways the th= e SIP SRV record is bing used for load balancing and reliability. Other tha= n that, the draft would stay about the same.=20 Cullen=20 On Aug 26, 2014, at 8:10 AM, Michael Procter wrote: > Dear all, >=20 > SIP Outbound (RFC5626) is a useful mechanism to allow User Agents to > reliably communicate through NATs to proxies and registrars. However, > there is one part of the problem that isn't addressed: how do UAs > discover the edge proxies to use? The RFC leaves this to either > static configuration or future discovery mechanisms. >=20 > I've written a draft which discusses a simple mechanism to help SIP > User Agents discover SIP proxies for use with RFC5626 (SIP Outbound). > As far as I am aware, there is currently no standard approach to this. > It is my hope that by defining a simple mechanism, the overall > deployment of SIP Outbound can be increased, with a corresponding > increase in reliability and maintainability of SIP networks. >=20 > I welcome comments and feedback, not least about whether you agree > that the problem exists and is worth solving! >=20 > Regards, >=20 > Michael >=20 >=20 > ---------- Forwarded message ---------- > From: > Date: 4 July 2014 16:51 > Subject: New Version Notification for > draft-procter-dispatch-outbound-discovery-00.txt > To: Michael Procter >=20 >=20 >=20 > A new version of I-D, draft-procter-dispatch-outbound-discovery-00.txt > has been successfully submitted by Michael Procter and posted to the > IETF repository. >=20 > Name: draft-procter-dispatch-outbound-discovery > Revision: 00 > Title: Automatic discovery of RFC 5626 Edge Proxies > Document date: 2014-07-04 > Group: Individual Submission > Pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-procter-dispatch-outbound-disco= very-00.txt > Status: > https://datatracker.ietf.org/doc/draft-procter-dispatch-outbound-discover= y/ > Htmlized: > http://tools.ietf.org/html/draft-procter-dispatch-outbound-discovery-00 >=20 >=20 > Abstract: > [RFC5626] (commonly known as 'SIP outbound') defines mechanisms that > permit SIP (Session Initiation Protocol) UAs (User Agents) to > maintain multiple connections to a registrar or proxy via multiple > Edge Proxies, known as the outbound-proxy-set. Discovering the URIs > that make up the outbound-proxy-set is left to configuration or > future discovery mechanisms. This draft defines a simple discovery > mechanism that enables UAs to discover the URIs of all the Edge > Proxies in the outbound-proxy-set without requiring additional > configuration on the UA. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From nobody Mon Sep 8 08:23:20 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1FB1A885A for ; Mon, 8 Sep 2014 08:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 7Sgkqm4Uot7q for ; Mon, 8 Sep 2014 08:23:16 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id B34341A03E1 for ; Mon, 8 Sep 2014 08:23:16 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta05.westchester.pa.mail.comcast.net with comcast id oezK1o0020xGWP855fPGtL; Mon, 08 Sep 2014 15:23:16 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta12.westchester.pa.mail.comcast.net with comcast id ofPF1o00f1KKtkw3YfPGtu; Mon, 08 Sep 2014 15:23:16 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s88FNExb003921; Mon, 8 Sep 2014 11:23:14 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s88FNEFs003920; Mon, 8 Sep 2014 11:23:14 -0400 Date: Mon, 8 Sep 2014 11:23:14 -0400 Message-Id: <201409081523.s88FNEFs003920@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Michael Procter In-reply-to: (michael.ietf@gmail.com) References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201408292056.s7TKuWok015949@hobgoblin.ariadne.com> <5400F838.9060000@alum.mit.edu> <201409021919.s82JJYsf029941@hobgoblin.ariadne.com> <201409042027.s84KRWnL028172@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410189796; bh=+UmZuA6cP9g9uZ8XRo+rLSgfgDz39esBieNzyx4uAz4=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=mtHeI1uPSnc2foR/QUV28woZqf4rZdHj5XO/lx3F16BZclWgVwO48cNJROPAShUTJ 4t/MeVss5+dyEJ3aOvVz4fi7jQjGFUJ96VGjtoGJByI+du8WZnbOcXu8sTckTdWs+4 WLtS7uLb1xChP0tiX8AeLmSIqcEES2jrFJmh8/VWwbkid6LKK5Wj09yExPw8Unm1O+ iBSlGJNY/T+RoYiSwQuTWvhLhpSjQWJZR4h2ga4TchCE8UD6Vcxt2dszXQMSbdtXkc gtupadsj8U1KjtZRr1nBQUg88jTXZfGtLN6BXbZJlFn7rnxraqojdDgUC4Yjc7Jguj X5y6tyTK1dn8g== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/FkY62NPiobqBrN2RvQI_5Ppwkms Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 15:23:18 -0000 > From: Michael Procter > > In this problem, there are two ways to set up redundant services. One > is to advertise multiple SRV records, and one is to advertise multiple > A/AAAA records. I fully support the first way, and accept that the > second way is sometimes used. However, the part I am not happy about > is that if a domain is set up with multiple SRV records, each of which > names a host with multiple A/AAAA records, then we should register to > each A/AAAA record separately. I want to avoid the situation where a > UA limited to 2 (or 4, the number doesn't really matter) proxies in > the outbound-proxy-set ends up with a bunch of registrations all bound > to the same edge proxy. I don't think it gives sufficient diversity, > and I don't think it matches the expectations of whoever set up the > SRV records. My opinion is that one should not set up multiple SRV records with host names that have multiple A/AAAA records; instead each SRV record should generate only one address. Otherwise, you get into situations like this. > To that end, if there are SRV records, I'd like to register to each > one once (and allow any multiple A/AAAA records to be used for routing > to that logical proxy). The difficulty with this rule is that it creates a way of converting a domain name into an address list that is similar to, but not exactly the same as, RFC 3263 resolution. Indeed, to assure diversity, the situation is more complicated than that. Suppose there are two SRV records, one for each of two servers, and each server has two A records, one for each of two interfaces on two different networks. Registering via two interfaces on the same server is not diverse relative to serrvers, but is diverse relative to the access network. Worse, if both servers are in the same building, there isn't diversity in regard to power supply and similar infrastructure issues. We'd really like to have some direct way to identify "similarity" of contact addresses. Dale From nobody Mon Sep 8 08:26:02 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D232B1A886E for ; Mon, 8 Sep 2014 08:25:54 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 35N7l36yrQQE for ; Mon, 8 Sep 2014 08:25:53 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 854751A886D for ; Mon, 8 Sep 2014 08:25:53 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta02.westchester.pa.mail.comcast.net with comcast id oewX1o0031ei1Bg51fRtK4; Mon, 08 Sep 2014 15:25:53 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta24.westchester.pa.mail.comcast.net with comcast id ofRs1o00l1KKtkw3kfRsV5; Mon, 08 Sep 2014 15:25:53 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s88FPqmL004072; Mon, 8 Sep 2014 11:25:52 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s88FPpV4004071; Mon, 8 Sep 2014 11:25:51 -0400 Date: Mon, 8 Sep 2014 11:25:51 -0400 Message-Id: <201409081525.s88FPpV4004071@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Cullen Jennings \(fluffy\)" In-reply-to: (fluffy@cisco.com) References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410189953; bh=xHZ+/RKOBk3QLt5zWz3rmCJABUV3RkmDMosK5f1foic=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=Y4DRPVAF4aHC8u7bBSt0Hths4/NHOOU4d0KmCZ8DBPQLqkp5Q25k94LCNOsYfUluf Caghlrz1tHfzIFAQ4v42YfTRD7/MxxkeCiOfntIikOR+Qxb0j+cuSgxgt8oNmWuLYE Mj7/gq5EOjU08K7/ZjcpnBsUKWIko+2cWXbUEvi2b/fhP/1KVVRjQhulVIoFZvcLDS o8MfQxZLk7CwEiwDGR0ZsYuamQB+dD5TGulB7N1nrNaZ2USoJmX6Qaw/kWJ3q0Lhxg DNkt6O/gZJAqg6UoF7ZO62IEc4nXQtquHpxrkgn8z8UHLgDlip3LNxgJHW7wn9BWyS defjUtfDN/p8w== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/eMbO2efbAqjKEGQPtGJ0-k9UWU4 Cc: dispatch@ietf.org Subject: Re: [dispatch] New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 15:25:55 -0000 > From: "Cullen Jennings (fluffy)" > > Instead of this, make a UA that implemented this draft do a SRV lookup of > > _sip-outbound._tcp.example.net > > This separates the configuration of outbound proxies from other ways > the the SIP SRV record is bing used for load balancing and > reliability. Other than that, the draft would stay about the same. Which makes it straightforward to define a fallback to the current behavior: If *no* _sip-outbound records are found, use the _sip records. Dale From nobody Tue Sep 9 01:33:12 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BE01A885C for ; Tue, 9 Sep 2014 01:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 C3qbnIHIgmMy for ; Tue, 9 Sep 2014 01:33:10 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F211E1A8853 for ; Tue, 9 Sep 2014 01:33:09 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id z12so2271475wgg.28 for ; Tue, 09 Sep 2014 01:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S0jsGAYmIFnDrJBUZGuuSri4fpRraj07zIJUXcgiip8=; b=tJFRaEz0Fy5Tu+xLrQbt9e2iG9bxQWhgo62exTlRW2cvYPph5YgaDuKF/EWjeY0INR TFnqNFzIU0tmZ2T5DHzL8OWOWX7Us/DKgpPRr/qMmkXvTB9z8aiZd81F/EYp2CBoigEh miQYuXOnZz+dbhk5VkbNg1VzoxRd0j1GxerOfIawbDyVHUfVb6va0SXxrbktH8BqLNYS 58J5tCQjIF5Qd9TKh9vM1RIVG4Zz/kFGuX32eQlnvl4F0wdWqSAyoZKRmCTx2IRd3iOB 4NGZBfHOfRnGXylAIgppnbh9CCRjqNOBWZhT1C/sxJfVxvq8D9G/bNKNpgzUma8aPQMI GlBA== MIME-Version: 1.0 X-Received: by 10.180.211.36 with SMTP id mz4mr20384097wic.39.1410251588596; Tue, 09 Sep 2014 01:33:08 -0700 (PDT) Received: by 10.194.39.231 with HTTP; Tue, 9 Sep 2014 01:33:08 -0700 (PDT) In-Reply-To: <5409E5BD.8010007@alum.mit.edu> References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201409031526.s83FQiXf000720@hobgoblin.ariadne.com> <5409E5BD.8010007@alum.mit.edu> Date: Tue, 9 Sep 2014 09:33:08 +0100 Message-ID: From: Michael Procter To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/tQ9pmbODHNY05Qze3krWmzeQwCA Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 08:33:11 -0000 Hi Paul, On 5 September 2014 17:33, Paul Kyzivat wrote: > Another potential issue is the use of Service-Route during registration. Is > there any way that it can be compatible with outbound? >From a quick reading of RFC3608, I can't see any particular reason that it would be incompatible with outbound. As far as I can tell, a Service-Route is expected to be used for new dialogs, and not to modify how registrations are routed, so I don't think they interact. Happy to be corrected by those more familiar with the mechanism though. Michael From nobody Tue Sep 9 01:33:33 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAA71A8894 for ; Tue, 9 Sep 2014 01:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 jMiO0qpQvpTq for ; Tue, 9 Sep 2014 01:33:27 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993931A8853 for ; Tue, 9 Sep 2014 01:33:26 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id q5so725861wiv.5 for ; Tue, 09 Sep 2014 01:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HMQiVyGAuC6pGhaWXP34ywcCY7u9AmHxGo7rJ5CsDvg=; b=OLL4r86o/LmANqKhWX8R5aRweGtqVUR8YXEzHvrSQPjZm0YWCAeDBVdFinG9PjO003 CphcRKn8x2qw+i/6Z/bsh1dmMkwJjTxxm3H3h2er/AHS5deQXUNoAdZlYQDfgguzLonK 6iAisK6KlsklETcPCGuOeBouNyBCngByquYpJswc6w9yNZr4VgGRnA5wjvPNfgzdKzN/ OL2YLLI4Xf3VyvJmg8Of5QzoAtVYTE/b/c1vfv/byG3xAyFaKBlbhTxFekPML08glsuH e8JEd0R+VJnYpi6uxI8/sl5meF3s4lcB4Kr5+j71Wz9iaNk9b5uOyKhuSypy35OEhLWU 6iTQ== MIME-Version: 1.0 X-Received: by 10.180.39.200 with SMTP id r8mr17529017wik.23.1410251605231; Tue, 09 Sep 2014 01:33:25 -0700 (PDT) Received: by 10.194.39.231 with HTTP; Tue, 9 Sep 2014 01:33:25 -0700 (PDT) In-Reply-To: References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> Date: Tue, 9 Sep 2014 09:33:25 +0100 Message-ID: From: Michael Procter To: "Cullen Jennings (fluffy)" , IETF Dispatch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/bKbmKsmQ_WLucRGFDJzmKgj-hYc Subject: Re: [dispatch] New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 08:33:32 -0000 Hi Cullen, On 7 September 2014 18:08, Cullen Jennings (fluffy) wrote: > > Michael, > > Interesting draft. I have a small proposed change that might solve some of the problems that have been raised. > > In your current draft, the UA registering to example.net does a DNS SRV lookup of > > _sip._tcp.example.net > > Instead of this, make a UA that implemented this draft do a SRV lookup of > > _sip-outbound._tcp.example.net > > This separates the configuration of outbound proxies from other ways the the SIP SRV record is bing used for load balancing and reliability. Other than that, the draft would stay about the same. Thanks, Cullen. I like this as it is very simple, and is only a minor change from the current approach. I was going to push back slightly, because it does move us further from what appears to be a current practice, but as Dale has already commented that he likes it, I am happy to include it! As you say, it offers a mechanism to separate the configuration, which will hopefully address some of Jon's concerns. In conjunction with Service-Route as Paul mentions, it could also become the basis of a useful model for SIP federation. Whilst that isn't my immediate goal, it is good to not rule that out. Michael From nobody Tue Sep 9 01:33:47 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA8C1A885C for ; Tue, 9 Sep 2014 01:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 qplaqFr2pZHR for ; Tue, 9 Sep 2014 01:33:39 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35C11A8898 for ; Tue, 9 Sep 2014 01:33:38 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id em10so77664wid.5 for ; Tue, 09 Sep 2014 01:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RdS/EpqkKbbv3xtJ6I+zEKmgDW1rLH90wRiKOelu9eg=; b=sdF9gHNf7Oguxg+Cs+Q9I2bj3wDJw82qkorYlag/Ut/gh9fjF7a1K2u1DHAliP5Ks1 npb9DsNu9gPU3QPQaI3EgzbrQSkPeeQrfhYjsxbsT1FDUsyNvLQgQpAyy/hbVhottIh/ pJ+mq8Q34YG6DBb1TqzKYARHAl8RhrjOdU9Rg6fBkBp+875x/jR4PttNpX7k23yL5K7A A7a2ZIRXkIC2pBcd6g9Dd7TtUvOsTdR0V8nHZVOevVUdPDvI3iBYV9i8PO55QwLzwawr hO0RyxtFhIq5632bCvz8urdWDSuyrrgL7Iknh9agdY9/d8IultqDo4QH8uLCsYhsQZQm QR0g== MIME-Version: 1.0 X-Received: by 10.180.75.17 with SMTP id y17mr28046190wiv.3.1410251617687; Tue, 09 Sep 2014 01:33:37 -0700 (PDT) Received: by 10.194.39.231 with HTTP; Tue, 9 Sep 2014 01:33:37 -0700 (PDT) In-Reply-To: <201409081523.s88FNEFs003920@hobgoblin.ariadne.com> References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201408292056.s7TKuWok015949@hobgoblin.ariadne.com> <5400F838.9060000@alum.mit.edu> <201409021919.s82JJYsf029941@hobgoblin.ariadne.com> <201409042027.s84KRWnL028172@hobgoblin.ariadne.com> <201409081523.s88FNEFs003920@hobgoblin.ariadne.com> Date: Tue, 9 Sep 2014 09:33:37 +0100 Message-ID: From: Michael Procter To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/xXaTqFyMSFMCEbZxiE8ghu26VHE Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 08:33:44 -0000 Hi Dale, On 8 September 2014 16:23, Dale R. Worley wrote: > My opinion is that one should not set up multiple SRV records with > host names that have multiple A/AAAA records; instead each SRV record > should generate only one address. Otherwise, you get into situations > like this. What about the case where a host advertises one A and one AAAA record, which is not uncommon? If the UA only supports two records in the outbound-proxy-set, but also happens to be dual-stack, we have now lost resilience. I don't want to provide a mechanism that leads to any myths about "disable IPv6 on your phone to make it more reliable". > The difficulty with this rule is that it creates a way of converting a > domain name into an address list that is similar to, but not exactly > the same as, RFC 3263 resolution. Yes, that is true. But we are solving a problem that is similar to, but not exactly the same as, RFC3263 resolution ;-) Because we expect the output of the resolution to be truncated somewhat (maybe first 2 results, maybe 4), we need the resolution to generate diversity first. But RFC3263 essentially does a depth-first traversal of the SRV/A/AAAA tree rather than breadth-first, and I think breadth-first will give us the best chance of diversity in the first n results. > Indeed, to assure diversity, the situation is more complicated than > that. Suppose there are two SRV records, one for each of two servers, > and each server has two A records, one for each of two interfaces on > two different networks. Registering via two interfaces on the same > server is not diverse relative to serrvers, but is diverse relative to > the access network. Worse, if both servers are in the same building, > there isn't diversity in regard to power supply and similar > infrastructure issues. We'd really like to have some direct way to > identify "similarity" of contact addresses. Quite a few of those assumptions are not true for many systems. And because of that, I don't think we can have some direct way to identify address similarity from the UA's perspective. The only people who will know the answers to the issues you raise are the people running that network. The best way I know of them communicating that information is to publish it in the DNS. SRV records advertise a bunch of hosts, all of which can provide the service we need. This seems like a good fit for advertising how to establish multiple diverse flows for that service. Michael From nobody Wed Sep 10 08:02:55 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACC31A0730 for ; Fri, 5 Sep 2014 08:53:06 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 WuTeSzzjABKI for ; Fri, 5 Sep 2014 08:53:03 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2B31A0739 for ; Fri, 5 Sep 2014 08:53:03 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta07.westchester.pa.mail.comcast.net with comcast id nRK01o00127AodY57Tt2iz; Fri, 05 Sep 2014 15:53:02 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta19.westchester.pa.mail.comcast.net with comcast id nTt11o00P1KKtkw3fTt23C; Fri, 05 Sep 2014 15:53:02 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s85Fr0ot010639; Fri, 5 Sep 2014 11:53:01 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s85Fr08w010636; Fri, 5 Sep 2014 11:53:00 -0400 Date: Fri, 5 Sep 2014 11:53:00 -0400 Message-Id: <201409051553.s85Fr08w010636@hobgoblin.ariadne.com> From: worley@alum.mit.edu (Dale R. Worley) Sender: worley@alum.mit.edu (Dale R. Worley) To: "Peterson\, Jon" In-reply-to: References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201409031526.s83FQiXf000720@hobgoblin.ariadne.com> <201409032024.s83KOOWl016885@hobgoblin.ariadne.com> <201409041908.s84J8A5n024046@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409932382; bh=vmgmiMtNYEVA9e9wqItsulMGzQcW+a+XLXZeN/Q3rjU=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=OG1sBgYsNA/s8HHRfwHjVKtYMvdGCFqRR1K9ztjTmaYNreRc4s1eIasIFPdOpwEeX hpAmWtYSeFMO9gOzyCNtfwpLpqlLJzdJWoGBcuoeF+usLN3xsUoN71ZjptgxeiKuBM 86mkkKuHdvyYu0dM2EV24V5RKb/49sSpi0AzCNqD/vX2YXSBwpmEifkhl2Iu6m2pWC TBTncaKwNNsjJi28QTL86s/DUqUPcxIMwl9QJT+AiCXVwTTghbJr2obzEoAvQWt6/3 SJqJ44KNByxKplwM0phPtb97EV2aV+rsDZ02HTD75NQ00ady6Q7ymjltYpJ17OL14f Olg5VpwgHnVwg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/vcm-tq8BsaxEkHhvoKcOBmUaESc X-Mailman-Approved-At: Wed, 10 Sep 2014 08:02:54 -0700 Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:53:06 -0000 > From: "Peterson, Jon" > It seems unlikely to me that the interface of a > border controller you would advertise to the outside world is the same > interface that clients inside the network should use in an outbound Route > set. In many cases I imagine those interface are not in the same address > space, even. That's true, but you're likely to have split DNS in regard to the SIP domain; UAs inside the domain's network will see a different resolution for the domain name than UAs outside the domain's network. The question is whether the interface that clients *outside* the domain's network use to register for the domain is going to be the same as the interface that the domain wants to advertise to the outside world for incoming calls. In all the cases I've seen, they are the same. With a full configuration profile system, the UA could be told "the addresses to use for registering an AOL for this domain" independently of the RFC 3263 resolution of the domain name. (But that doesn't seem to be defined yet.) Dale From nobody Wed Sep 10 13:27:10 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B871A87B1 for ; Wed, 10 Sep 2014 13:27:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 PcHIIVCDIydw for ; Wed, 10 Sep 2014 13:27:07 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 69F0C1A0196 for ; Wed, 10 Sep 2014 13:27:07 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id pY9u1o00127AodY55YT6j6; Wed, 10 Sep 2014 20:27:06 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta19.westchester.pa.mail.comcast.net with comcast id pYT61o00g1KKtkw3fYT6MF; Wed, 10 Sep 2014 20:27:06 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s8AKR61E004561; Wed, 10 Sep 2014 16:27:06 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s8AKR5qZ004560; Wed, 10 Sep 2014 16:27:05 -0400 Date: Wed, 10 Sep 2014 16:27:05 -0400 Message-Id: <201409102027.s8AKR5qZ004560@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Michael Procter In-reply-to: (michael.ietf@gmail.com) References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201408292056.s7TKuWok015949@hobgoblin.ariadne.com> <5400F838.9060000@alum.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410380826; bh=BgjPg1sEbTPjhS/Hard5z2tP5f15s9vcxVUZwA6kO7w=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=W+zh4eWhmSKWogARjRbGhIlsKmePNnO48ckrp+XapN1nDcA4JDunwJPSRrgMNbQlt wwIJF1jpVoD5QWDhEoavjY39E1+ama2DkBOf7aSKIfmdHfsTLA2V+BtooilFJ1fY8F /438RHxKf//1SvpZANRwblVJPqywjRnqh2sX+K6u/CAmMEEZYNYO6+KeL4tHj/+WbY jpnACZlKNZATj1XlxLlAiP+dJ3669RE55dUoj+QdM6JAmOvIUkI0TyIUBmezf0JcdN q+HcPimd8u1eG+PEGCvAH8fJ5d8wHpRkeV7z0p4dmCicR0UQbL+JJZ+lGDZaNkid5h AWK4ekEtyFLbw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/HHM6oYoCX_SyHpxUG2et09iJzHM Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 20:27:08 -0000 > From: Michael Procter > Yes, that is true. But we are solving a problem that is similar to, > but not exactly the same as, RFC3263 resolution ;-) Because we expect > the output of the resolution to be truncated somewhat (maybe first 2 > results, maybe 4), we need the resolution to generate diversity first. > But RFC3263 essentially does a depth-first traversal of the SRV/A/AAAA > tree rather than breadth-first, and I think breadth-first will give us > the best chance of diversity in the first n results. "depth-first" Yes, ugh, especially regarding A/AAAA records for the same host name. > I don't think we can have some direct way to identify address > similarity from the UA's perspective. The only people who will know > the answers to the issues you raise are the people running that > network. The best way I know of them communicating that information > is to publish it in the DNS. SRV records advertise a bunch of > hosts, all of which can provide the service we need. This seems > like a good fit for advertising how to establish multiple diverse > flows for that service. You're convincing me. Especially if we set up new rules for the "_sip-outbound" records. For them, we can explicitly specify that all addresses generated from one SRV record are to be considered "similar", and that the UA should establish no two of its flows to "similar" transport addresses. That would not even be changing previous specifications, because there hasn't been an explicit specification of how the UA is to select its flow destinations. We might want to also say that the UA should not establish two flows to similar transport addresses, even if that entails not establishing the configured number of flows. (Because there wouldn't be an added reliability from doing so.) Hmmm, we have to worry about the fact that there usually are _sip._tcp.domain and _sip._udp.domain SRV records which are essentially duplicates of each other. Ditto for _sips records. Perhaps the real index of "similarity" of _sip-outbound SRV records is "having the same target value" rather than "being the same record"? Since the domain can establish separate DNS records for SIP Outbound targets, this has little impact on how a domain's existing SRV records are configured. Would we want to extend the new rules to the situation where there are no _sip-outbound records, and the UA is using the _sip records? Given the "A/AAAA records for a host name" case, we probably want to. Another point: How does this interact with NAPTR records? They are theoretically the first point of reference for resolving a domain name. But I've never used them, so I don't know how this issue interacts with them. Dale From nobody Mon Sep 15 04:20:46 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9FD1A0B71 for ; Mon, 15 Sep 2014 04:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 iEQfVvXIFX1L for ; Mon, 15 Sep 2014 04:20:36 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561621A0B11 for ; Mon, 15 Sep 2014 04:20:35 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-e2-5416cb80c863 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E4.5E.21334.08BC6145; Mon, 15 Sep 2014 13:20:33 +0200 (CEST) Received: from [131.160.36.95] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.174.1; Mon, 15 Sep 2014 13:20:32 +0200 Message-ID: <5416CB80.10000@ericsson.com> Date: Mon, 15 Sep 2014 14:20:32 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" , DISPATCH References: <1D1C6384-E5C0-4770-928A-D7575F08305D@cisco.com> In-Reply-To: <1D1C6384-E5C0-4770-928A-D7575F08305D@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+JvjW7jabEQg/PrBS2WTlrAatExmc2B yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgytj/vIWpYBNvxfVJx9gaGA9xdTFyckgImEjs 3zqXGcIWk7hwbz1bFyMXh5DAUUaJyef3MkM4qxkl1v6ZyNLFyMHBK6ApMXeLL0gDi4CqRNP6 fnYQm03AQmLLrfssILaoQJTEqxU3WEFsXgFBiZMzn4C1iggESuy+UAkSZhbQk3jS1cUGYgsL uEpcapwINkZIwEai8f1ORhCbU8BW4tW6DkaQVgkBcYmexiCIVgOJI4vmsELY8hLNW2czQ7Rq Syx/1sIygVFoFpLFs5C0zELSsoCReRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYAAf3PJb dwfj6teOhxgFOBiVeHgX7BALEWJNLCuuzD3EKM3BoiTOu+jcvGAhgfTEktTs1NSC1KL4otKc 1OJDjEwcnFINjEVLT0td/fO5SvPFE63PDtK8vG85W+KCjtZNe9nrPsfkT/AfPv2LXxx/7ip8 sC9x5rWHLaqav+bmbtafquS6Q+uqeo1L8E47GeV9OeUcT84JcZjK8p5KS7vXu+m7+4WvYn7z H2nxeIb/MVj542b1tVbxXY3hhyVOnuu0P7P1d03asm69t1NYfZRYijMSDbWYi4oTAWdZInFB AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/YgBDW-WaJN4CG3llnor-fHd85pM Cc: Jaime Jimenez Subject: Re: [dispatch] Review of draft-jimenez-p2psip-coap-reload-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 11:20:44 -0000 Hi Cullen, thanks for your review! Jaime (in the cc:) is currently editing the draft. He will provide you with answers to your comments shortly. Cheers, Gonzalo On 23/08/2014 8:38 PM, Cullen Jennings (fluffy) wrote: > > This is an excellent draft and I support it’s publication but I think there are a few little details to clean up first. > > The informal ref to 3621 should be removed. > > Section 9 talks about the associated URI in the signers certificate. I think it would be good to a bit more specific about what exactly this is. Would be a URI type entry in the SubjectAltName? > > I think section 10 needs a few more paragraphs. The high level pointsI I would want to have covered are > > - all the consideration in both Reload and Coap apply here > > - the caching means that the values of the sensor that get cached will be stored on some random node in the overlay and thus readable by that node. As peer come and go, different nodes will get the data. So at some level, all the nodes in the overlay need to be trusted to see this information. Caching can not be used unless the threat model is such that it OK for any node to see the cached data. There are many use cases where either all the nodes in the overlay are trusted to see this data or the data public and fine for the world to see so though this is an impotent consideration it is not an issue in many cases. > > Look forward to seeing this published - I think it has some really interesting uses as we move forward. > > Cullen > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From nobody Thu Sep 18 23:36:43 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7F61A8F3B for ; Thu, 18 Sep 2014 23:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 JYqZ6apOffH5 for ; Thu, 18 Sep 2014 23:36:38 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4F41A8A4F for ; Thu, 18 Sep 2014 23:36:37 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail21.telekom.de with ESMTP; 19 Sep 2014 08:36:35 +0200 X-IronPort-AV: E=Sophos;i="5.04,553,1406584800"; d="scan'208,217";a="533477473" Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 19 Sep 2014 08:36:35 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 19 Sep 2014 08:36:34 +0200 From: To: Date: Fri, 19 Sep 2014 08:36:34 +0200 Thread-Topic: New draft draft-jesske-dispatch-forking-answer-correlation-00 Thread-Index: Ac/T1A4YV+PXc/bGRxK/BYBt2/rlsQ== Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0F@HE113667.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0FHE113667eme_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/wy5N1iiRhfr_EYlX6k8sJ19szjo Subject: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 06:36:41 -0000 --_000_058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0FHE113667eme_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We've submitted a new draft, draft-jesske-dispatch-forking-answer-correlati= on-00 Since forking was defined for SIP problems on the functionality are existin= g. We have identified that not all entities in networks will understand mul= tiples provisional responses sent back for each forking leg where an INVITE= was sent to. This will either result in an restriction of the reachability= of the terminating user or in worst case scenarios in non successful call.= In cases of where different networks are within the call path involved, th= is will restrict the terminating service provider to satisfy his customers = in providing the forking feature and also transit service providers in pro= viding a high rate of successful calls. The draft describes use cases and shows possibilities how to correlate all = received provisional responses (including preconditions and 100rel) in a i= ntermediate entity to allow to interact with networks/entities (UA's, netwo= rks, MGCF) which are not able/willing to understand and handle responses of= a forked call. A first draft (which needs improvement) can be seen under: http://tools.ietf.org/html/draft-jesske-dispatch-forking-answer-correlation= -00 I would be happy to have comments. Thank you and Best Regards Roland Mit freundlichen Gr=FC=DFen; With Best Regards Roland Jesske Deutsche Telekom Technik GmbH Fixed Mobile Engineering Deutschland Roland Jesske Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 58-12766 (Tel.) +49 6151 58-13395 (Fax) +49 171 8618-445 (Mobil) http://www.telekom.com Erleben, was verbindet. Deutsche Telekom Technik GmbH Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Carsten M=FCller Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262 Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken. --_000_058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0FHE113667eme_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
We’ve submitted a new draft, draft-jesske-dispatch-forking-answe= r-correlation-00
 
Since forking was defined for SIP problems on the functionality are ex= isting. We have identified that not all entities in networks will understan= d multiples provisional responses sent back for each forking leg where an I= NVITE was sent to. This will either result in an restriction of the reachability of the terminating user or in = worst case scenarios in non successful call. In cases of where different ne= tworks are within the call path involved, this will restrict the terminatin= g service provider to satisfy his customers in providing the forking feature and  also transit service p= roviders in providing a high rate of successful calls.
The draft describes use cases and shows possibilities how to correlate= all received provisional responses (including preconditions and 100rel)&nb= sp; in a intermediate entity to allow to interact with networks/entities (U= A’s, networks, MGCF) which are not able/willing to understand and handle responses of a forked call.
 
A first draft (which needs improvement) can be seen under:
 
 
I would be happy to have comments.
 
Thank you and Best Regards
 
Roland
 
Mit freundlichen Gr=FC=DFen; With Best Regards
Roland Jesske

Deutsche Telekom Technik GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
+49 6151 58-12766 (Tel.)
+49 6151 58-13395 (Fax)
+49 171 8618-445 (Mobil)
http://www.telekom.com

Erleben, was verbindet.

Deutsche Telekom Technik Gmb= H
Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Carsten M=FCller
Handelsregister: Amtsgericht Bonn= HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262
Gro= =DFe Ver=E4nderungen fangen klein an = – Ressourcen schonen und nicht jede E-Mail drucken.<= /b>
 
 
 
 --_000_058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0FHE113667eme_-- From nobody Fri Sep 19 11:25:10 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067091A06A1 for ; Fri, 19 Sep 2014 11:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0Aoxjf267FiM for ; Fri, 19 Sep 2014 11:25:05 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 5110C1A069E for ; Fri, 19 Sep 2014 11:25:04 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta13.westchester.pa.mail.comcast.net with comcast id t6Au1o0031ap0As5D6R3eW; Fri, 19 Sep 2014 18:25:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta22.westchester.pa.mail.comcast.net with comcast id t6R31o0043Ge9ey3i6R3il; Fri, 19 Sep 2014 18:25:03 +0000 Message-ID: <541C74FF.7070901@alum.mit.edu> Date: Fri, 19 Sep 2014 14:25:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0F@HE113667.emea1.cds.t-internal.com> In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0F@HE113667.emea1.cds.t-internal.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1411151103; bh=GmIDKHnnlDoj+d0m+GgFOqtVFzXP0xXNpt6g1Q0kYk4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FFtimG2/4TwqoQKDPWDDmjs9rCTWPdr2OxrAmpz9OnsLpxMSanRUyG9bpVZXJezcD s8aajtQhEpdlGaBFCRIYgun2LC4BfI8bhiJr5xxKZx/TVsu5/X4iP57mJ8becRx/Os JAeE+rFrhcdV1YwZNHzvCDxlS9JHIF4WbS2qXT4vSZeaPuMa3iEawvW/Np+DzzKg9l nIoShscPhhphObn1g81tosNhv/yvHocIEBDy0QNJdXYIFOSSxuH67sge4k5YNjcXMe 7KBQ7tujt9eqCysWph+mP3vjQDEKeIHcLWHOW7apgZW5k8q5Bynk+IBNldlo+jN/HT ZZmkn6UR3OqXg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/dFVANv3tGJh4CiJaCK4oC2DgEbE Subject: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:25:08 -0000 Roland, Some comments: Section 1 says: Now the originating SIP device has to understand that two devices are ringing and one will answer the call. No Problem since RFC3261 [RFC3261] allows this and allows also the originating device to handle multiples responses. But this is not mandated by RFC3261 [RFC3261] and ted to implementers choice. There will the first problem apply that only one of the Responses will be taken into consideration. I disagree that 3261 doesn't mandate handling responses from multiple forks. By defining that the request MAY be forked, it implies that the UAC must be prepared for responses from multiple forks. What it doesn't do is require *how* the responses from multiple forks are to be handled, as long as the basic transaction and dialog semantics are followed. The minimum that the UAC can do is recognize when multiple early or final dialogs are established and then dispose of them. Final responses on *each* dialog require an ACK. And then if the final response was a 2xx, then the dialog must (eventually) be terminated in some way. UACs that can't do this are *broken*. This document will describe how a correlation for multiples early dialogs and other received Responses can done within a B2BUA as described in the taxonomy document RFC7029 [RFC7029] The role of the B2BUA is a Signaling/Media Plane B2BUA Role. Thus many possible use cases which will be possible looking on the used features are considered in this document If this is really about how B2BUAs do it, then perhaps this belongs in STRAW. Section 1.2 says: SIP defined in RFC3261 [RFC3261]describes how forking should apply. Also rules for UA for responses and merged requests are defined. But it is not stated how a forking correlation should apply and what is needed. ... I don't understand what you mean. Responses on different forks have distinct to-tags but share the same from-tag and call-id. This is all clear in 3261. This is the *purpose* of the to-tag! If you mean it doesn't describe how a B2BUA should do correlation, then yes, I agree it does not. It doesn't say how a B2BUA does *anything*. (Other than that it must act properly as a UA on each "side".) Figure 1: This has errors. It shows dialog-specific CANCEL requests. There is no such thing. CANCEL is addressed exactly the way the INVITE was (no to-tag and hence not dialog-specific), and operates in a hop-by-hop basis. It is the responsibility of the forking proxy to send CANCEL to each remaining early dialog after it has forwarded the 200 back to the UAC. (And it is the responsibility of the UAC to be prepared to deal with a subsequent 2xx from another fork, if one happens to get through.) Section 1.3: Figure 1 shows an normal example of forking. With receiving 18x the UAC has to open transaction. where UAS_2 and UAS_3 does reject the call with a 4xx. So only UAA_4 answers the dialog correctly. I can't understand this paragraph. Is it describing a variant of figure 1 that isn't shown? Section 1.4, Figure 2: Exactly what do the numbers in the parentheses (e.g., "18x (2)") mean? In the prior figure I took them to identify dialog ids. But that doesn't work in this figure. And how is the B2BUA managing dialog ids? Is it presenting a single to-tag to the UAC, or is it using separate to-tags corresponding to the different to-tags it is receiving from the forking proxy? Both are possible, but the resulting signaling is distinctly different. I'm guessing that it is trying to maintain a single dialog to the UAC. With arriving a new 18x with additional codecs included have to result in an UPDATE containing the SDP of the preceding 18x. The important fact is that the B2BUA has to anchor the media plane as well as acting as signalling B2BUA. You aren't showing PRACKs so reliable provisionals must not be in use. In that case, the initial O/A isn't complete until the 200 response to the INVITE. Until then there can be no changes to the SDP. So the UPDATEs can't do what you want them to do. You *could* do this if 18x (2) to the UAC was a reliable provisional. In that case the B2BUA would *not* be required to anchor the media. It appears that sections 1.5, 1.6, 1.7 were intended to be subsections of 1.5. Section 1.6: Where the B2BUA decides to path the required 100rel the UAC will send then the PRACK and waits for the 200 OK. In case there are further 18x with other type of SDP arriving at the B2BUA the UAC needs to be informed about change of codec. The UAC has again to sent the PRACK. I think you meant "pass" rather than "path". There are multiple possibilities here. The B2BUA could treat each fork separately - different to-tags - just like would happen if it were a true proxy. In that case it doesn't need to anchor the media, though it still can if it wants. The UAC must be capable of supporting multiple early dialogs. If it only uses a single to-tag toward the UAC, then it can/must use UPDATEs as you show in figure 2. Again it may/may-not anchor the media. Section 1.7: This use case describes the case where preconditions will be used. This apply in mobile networks where resource reservation is used. The Precondition mechanism in RFC3312 [RFC3312] shows the needed additional procedures. A B2BUA doing correlation in between to allows only one early dialog sent back to the UAC. The B2BUA has to anchor the SIP Dialogs as well as the media reservation streams. This depends on the cases I mentioned for 1.6. Certainly the straightforward way is to anchor the media and handle the preconditions separately on the two sides. Section 1.8: This seems incomplete, so I can't comment. General comment: are you intending to cover both B2BUAs that do and don't anchor media, or only those that do? If you are only intending to handle media anchoring B2BUAs, then say that clearly, and it will be easier to discuss all the rest. If you also intend to handle B2BUAs that *don't* anchor media, then it is probably better to treat those cases separately, because they are very different. If you are thinking that a B2BUA might dynamically decide whether to anchor or not based on the details of the offers, then do the other cases first. I think this is very hard, and maybe not possible. Thanks, Paul On 9/19/14 2:36 AM, R.Jesske@telekom.de wrote: > Hi, > We’ve submitted a new draft, > draft-jesske-dispatch-forking-answer-correlation-00 > Since forking was defined for SIP problems on the functionality are > existing. We have identified that not all entities in networks will > understand multiples provisional responses sent back for each forking > leg where an INVITE was sent to. This will either result in an > restriction of the reachability of the terminating user or in worst case > scenarios in non successful call. In cases of where different networks > are within the call path involved, this will restrict the terminating > service provider to satisfy his customers in providing the forking > feature and also transit service providers in providing a high rate of > successful calls. > The draft describes use cases and shows possibilities how to correlate > all received provisional responses (including preconditions and 100rel) > in a intermediate entity to allow to interact with networks/entities > (UA’s, networks, MGCF) which are not able/willing to understand and > handle responses of a forked call. > A first draft (which needs improvement) can be seen under: > _http://tools.ietf.org/html/draft-jesske-dispatch-forking-answer-correlation-00_ > I would be happy to have comments. > Thank you and Best Regards > Roland > Mit freundlichen Grüßen; With Best Regards > Roland Jesske > > Deutsche Telekom Technik GmbH > Fixed Mobile Engineering Deutschland > Roland Jesske > Heinrich-Hertz-Straße 3-7, 64295 Darmstadt > +49 6151 58-12766 (Tel.) > +49 6151 58-13395 (Fax) > +49 171 8618-445 (Mobil) > _http://www.telekom.com_ > > Erleben, was verbindet. > > Deutsche Telekom Technik GmbH > Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender) > Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert > Matheis, Carsten Müller > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr.: DE 814645262 > *Große Veränderungen fangen klein an **–**Ressourcen schonen und nicht > jede E-Mail drucken.* > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Fri Sep 19 11:34:24 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9E61A6F92 for ; Fri, 19 Sep 2014 11:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 VcfpZYI5GnEa for ; Fri, 19 Sep 2014 11:34:22 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B35A1A6F8B for ; Fri, 19 Sep 2014 11:34:21 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-0b-541c772cb6e1 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 60.E1.21432.C277C145; Fri, 19 Sep 2014 20:34:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Fri, 19 Sep 2014 20:34:19 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00 Thread-Index: AQHP1DcNAo4/CjxPh0aDSdhtHQRxTpwIxydw Date: Fri, 19 Sep 2014 18:34:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4541A4@ESESSMB209.ericsson.se> References: <058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0F@HE113667.emea1.cds.t-internal.com> <541C74FF.7070901@alum.mit.edu> In-Reply-To: <541C74FF.7070901@alum.mit.edu> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvja5OuUyIwaMJIhZLJy1gtVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWxpuEhW8Ff1oqzf66wNjAeY+li5OSQEDCR OPv2BTuELSZx4d56ti5GLg4hgaOMEhOOPmOEcJYwSvS/2wDkcHCwCVhIdP/TBmkQEQiWOHh4 JwtIWFggXKL3vgdEOELi4ZybzBC2kUTrpt2MIDaLgKrElbWf2EBsXgFfiY+9X1hBWoUE6iQe njIBCXMK6Eg83/mOFcRmBDrn+6k1TCA2s4C4xK0n85kgzhSQWLLnPDOELSrx8vE/VghbSWLt 4e0sEPU6Egt2Q6xiFtCWWLbwNTPEWkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNocWpx Um66kZFealFmcnFxfp5eXmrJJkZgjBzc8ttgB+PL546HGAU4GJV4eBX6pEOEWBPLiitzDzFK c7AoifMuPDcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjnUGYxpVMQ/3PDjo1rI0KAQs5 p7CoLA7carEsUPJ7TVyzFP+BGv0zjH4K/Tv4u1KX8oevnrKz2mbm7tXtq07artyYyKTuliDC J+Eyff97wVa2qhDTSd5bbPatXnZEcdGfg9+lqy2Zp3bkXdCSuVIxVaZdt+oOS8Tq8ukzRBLa rD3+fLRluq7EUpyRaKjFXFScCAC7Sie/cgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/jzOWgJbiA58rtm3rsVyNp85uLD8 Subject: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:34:23 -0000 (As STRAW co-chair) Hi Paul, > This document will describe how a correlation for multiples early > dialogs and other received Responses can done within a B2BUA as > described in the taxonomy document RFC7029 [RFC7029] The role of the > B2BUA is a Signaling/Media Plane B2BUA Role. Thus many possible use > cases which will be possible looking on the used features are > considered in this document > > If this is really about how B2BUAs do it, then perhaps this belongs in ST= RAW. I actually told Roland to submit the draft to DISPATCH, as it doesn't addre= ss any of the current STRAW deliveries. But, if there is no need to go via DISPATCH, we can ask Roland to submit to= STRAW directly :) Regards, Christer From nobody Fri Sep 19 11:40:57 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750401A702F for ; Fri, 19 Sep 2014 11:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wutUhwqY7PFy for ; Fri, 19 Sep 2014 11:40:54 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E291A7023 for ; Fri, 19 Sep 2014 11:40:54 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by resqmta-ch2-11v.sys.comcast.net with comcast id t6Zs1o0061c6gX8016grci; Fri, 19 Sep 2014 18:40:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta23.westchester.pa.mail.comcast.net with comcast id t6gr1o00D3Ge9ey3j6gr4a; Fri, 19 Sep 2014 18:40:51 +0000 Message-ID: <541C78B3.4020901@alum.mit.edu> Date: Fri, 19 Sep 2014 14:40:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "dispatch@ietf.org" References: <058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0F@HE113667.emea1.cds.t-internal.com> <541C74FF.7070901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4541A4@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4541A4@ESESSMB209.ericsson.se> 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=1411152051; bh=JQRJbnyqKSaOhzATH8UgEzlqb/frk7RotCyXFXfjaIE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Pv4sZ8uG9JUsQol9H/xXq6K3gXz+vtCwBKzr0KjUg+4ABWaennP+O36baW9u7wr0X VTeE6V22o9BK0huFHJPZinFU+9r4tVBudkLi5i+kYEL/4RVaAW+HBvssBT+F0nokw+ X7ZsZJGut1ldfCkJdzuFbuTdZoxIKmFAOVqiNuu9CcpZkz89hFHXMzmb1vbvDOzI7W PN+m0LYUSW3wxkwszo5J8fGjL8rAet1yJcEe87WybUZvmFZX/v+s2BFo69+ZdKlm4L RLVVByaOO5apKOxQ6mefhqOVx24sierQRx3SEj/wd9yS/G633sEtv41zg5PhcKjgxi +0r3xA4QOxREg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Bi8w0gwHJfBUzIbQwKenScieAgg Subject: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:40:55 -0000 On 9/19/14 2:34 PM, Christer Holmberg wrote: > > (As STRAW co-chair) > > Hi Paul, > >> This document will describe how a correlation for multiples early >> dialogs and other received Responses can done within a B2BUA as >> described in the taxonomy document RFC7029 [RFC7029] The role of the >> B2BUA is a Signaling/Media Plane B2BUA Role. Thus many possible use >> cases which will be possible looking on the used features are >> considered in this document >> >> If this is really about how B2BUAs do it, then perhaps this belongs in STRAW. > > I actually told Roland to submit the draft to DISPATCH, as it doesn't address any of the current STRAW deliveries. > > But, if there is no need to go via DISPATCH, we can ask Roland to submit to STRAW directly :) It is perhaps proper that it first come to dispatch. Consider my comment a suggestion that DISPATCH ought to dispatch it to STRAW. Thanks, Paul From nobody Wed Sep 24 10:35:58 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9808D1A02C0 for ; Wed, 24 Sep 2014 10:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.364 X-Spam-Level: X-Spam-Status: No, score=0.364 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, 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 3MSkQJaj_18m for ; Wed, 24 Sep 2014 10:35:53 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 870691A02BD for ; Wed, 24 Sep 2014 10:35:53 -0700 (PDT) Received: from [62.227.171.26] by 3capp-webde-bs14.dlan.cinetic.de (via HTTP); Wed, 24 Sep 2014 19:35:50 +0200 MIME-Version: 1.0 Message-ID: From: "Roland Jesske" To: "Paul Kyzivat" , dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Date: Wed, 24 Sep 2014 19:35:50 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <541C74FF.7070901@alum.mit.edu> References: <058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0F@HE113667.emea1.cds.t-internal.com>, <541C74FF.7070901@alum.mit.edu> Content-Transfer-Encoding: quoted-printable X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:hEMEJm3N9qLvSeTFMa3AGBprEpL29bd87UK2zcwe7oP Fgk7hNDPFty/X2wFwLOWBTBVzvIUi6DqxgoDAuatSa1kGVesnF L2fadTCJcy659vCX7DbrkRoEkl2QIev/rEAJ6Xb8+muPRH7Rpn ih9UVua5IbpWJEnVNyg9UU3DDmNcG8DijUKOGsKjmFo8sNX+ub AdYLO0dQK2bl8yfEk1sQUWjq0Kn0eEJ6Gjh3TU9nMJw7ojE3m9 ijdXpEjjgRisEOu7g+SGlGtk+tgUGHtxExxyW8K/XFXMeWum0p 25fWoKv5F2h2eM5gJRTfyx2RQgt X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/goHqCExhD1mA_lkiyy4wFx0YoJ4 Subject: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 17:35:56 -0000 =C2=A0Hello Paul, Thank you very much for your review of my draft. Comments are inline. I'm working at the next version of the document and will incoperate your v= alunable input. Thank you and Best Regards Roland =C2=A0 > Gesendet:=C2=A0Freitag, 19. September 2014 um 20:25 Uhr > Von:=C2=A0"Paul Kyzivat" > An:=C2=A0dispatch@ietf.org > Betreff:=C2=A0Re: [dispatch] New draft draft-jesske-dispatch-forking-ans= wer-correlation-00 > Roland, >=20 > Some comments: >=20 > Section 1 says: >=20 > Now the originating SIP device has to understand that two devices are > ringing and one will answer the call. No Problem since RFC3261 > [RFC3261] allows this and allows also the originating device to > handle multiples responses. But this is not mandated by RFC3261 > [RFC3261] and ted to implementers choice. There will the first > problem apply that only one of the Responses will be taken into > consideration. > I disagree that 3261 doesn't mandate handling responses from multiple > forks. By defining that the request MAY be forked, it implies that the > UAC must be prepared for responses from multiple forks. What it doesn't > do is require *how* the responses from multiple forks are to be handled, > as long as the basic transaction and dialog semantics are followed. >=20 [RJ] I could agree if the forking proxy knows what UAC the request is from= . But I cannot=20 identify it. I thought that was one the reason to provide the caller prefe= rences. If I as service provider know what clients my customers are using and send= ing it with the request then the proxy could decide to fork based on that information. But when I terminate my request in another network and fork it to a couple= of UAS I have no clue if the UAC is able to accept multiple responses. Or do did I oversee something? > The minimum that the UAC can do is recognize when multiple early or > final dialogs are established and then dispose of them.=20 [RJ] So looking on your comment below. Ignore the early dialogs and then c= ancel when 200 OK is arriving. > Final responses > on *each* dialog require an ACK. And then if the final response was a > 2xx, then the dialog must (eventually) be terminated in some way. [RJ] So in case a UAC receives two 200 OK even not supporting multipes dia= logs=20 it must choose one to terminate it with a BYE after sending ACK. > UACs that can't do this are *broken*. [RJ] OK. So I will reword my section taking that into consideration. > This document will describe how a correlation for multiples early > dialogs and other received Responses can done within a B2BUA as > described in the taxonomy document RFC7029 [RFC7029] The role of the > B2BUA is a Signaling/Media Plane B2BUA Role. Thus many possible use > cases which will be possible looking on the used features are > considered in this document > If this is really about how B2BUAs do it, then perhaps this belongs in > STRAW. [RJ] Yes this is my intention > Section 1.2 says: > SIP defined in RFC3261 [RFC3261]describes how forking should apply. > Also rules for UA for responses and merged requests are defined. But > it is not stated how a forking correlation should apply and what is > needed. ... > I don't understand what you mean. Responses on different forks have > distinct to-tags but share the same from-tag and call-id. This is all > clear in 3261. This is the *purpose* of the to-tag! [RJ] Yes I agree > If you mean it doesn't describe how a B2BUA should do correlation, then > yes, I agree it does not. It doesn't say how a B2BUA does *anything*. > (Other than that it must act properly as a UA on each "side".) [RJ] Yes I agree. This is what we want to describe since we have a couple = of B2BUA in our network. > Figure 1: > This has errors. It shows dialog-specific CANCEL requests. There is no > such thing. CANCEL is addressed exactly the way the INVITE was (no > to-tag and hence not dialog-specific), and operates in a hop-by-hop > basis. It is the responsibility of the forking proxy to send CANCEL to > each remaining early dialog after it has forwarded the 200 back to the > UAC. (And it is the responsibility of the UAC to be prepared to deal > with a subsequent 2xx from another fork, if one happens to get through.) [RJ] So only one CANCEL and that will forked to the remaining dialogs. I will change the figure. > Section 1.3: > Figure 1 shows an normal example of forking. With receiving 18x the > UAC has to open transaction. where UAS_2 and UAS_3 does reject the > call with a 4xx. So only UAA_4 answers the dialog correctly. > I can't understand this paragraph. Is it describing a variant of figure > 1 that isn't shown? [RJ] Yes I will rewrite the text and sections in an other way. > Section 1.4, Figure 2: > Exactly what do the numbers in the parentheses (e.g., "18x (2)") mean? > In the prior figure I took them to identify dialog ids. But that doesn't > work in this figure. [RJ] I'd like to show to which UA the SIP messages are belonging to. I try= to do it in a more unresandable way. > And how is the B2BUA managing dialog ids? Is it presenting a single > to-tag to the UAC, or is it using separate to-tags corresponding to the > different to-tags it is receiving from the forking proxy? Both are > possible, but the resulting signaling is distinctly different. > I'm guessing that it is trying to maintain a single dialog to the UAC. [RJ] Yes you are right. This needs more text to describe this. ALso how to= handle the to-tags and dialog ID's > With arriving a new 18x with additional codecs included have to > result in an UPDATE containing the SDP of the preceding 18x. The > important fact is that the B2BUA has to anchor the media plane as > well as acting as signalling B2BUA. > You aren't showing PRACKs so reliable provisionals must not be in use. > In that case, the initial O/A isn't complete until the 200 response to > the INVITE. Until then there can be no changes to the SDP. So the > UPDATEs can't do what you want them to do. [RJ] OK will change it. > You *could* do this if 18x (2) to the UAC was a reliable provisional. In > that case the B2BUA would *not* be required to anchor the media. [RJ] This use case I describe in the next section. > It appears that sections 1.5, 1.6, 1.7 were intended to be subsections > of 1.5. [RJ] I will do a complete reorder of all sections. I hope that will fit th= en. > Section 1.6: > Where the B2BUA decides to path the required 100rel the UAC will send > then the PRACK and waits for the 200 OK. In case there are further > 18x with other type of SDP arriving at the B2BUA the UAC needs to be > informed about change of codec. The UAC has again to sent the PRACK. > I think you meant "pass" rather than "path". [RJ] Yes > There are multiple possibilities here. The B2BUA could treat each fork > separately - different to-tags - just like would happen if it were a > true proxy. In that case it doesn't need to anchor the media, though it > still can if it wants. The UAC must be capable of supporting multiple > early dialogs. > If it only uses a single to-tag toward the UAC, then it can/must use > UPDATEs as you show in figure 2. Again it may/may-not anchor the media. [RJ] Yes that is what I want to describe. > Section 1.7: > This use case describes the case where preconditions will be used. > This apply in mobile networks where resource reservation is used. > The Precondition mechanism in RFC3312 [RFC3312] shows the needed > additional procedures. A B2BUA doing correlation in between to > allows only one early dialog sent back to the UAC. The B2BUA has to > anchor the SIP Dialogs as well as the media reservation streams. > This depends on the cases I mentioned for 1.6. Certainly the > straightforward way is to anchor the media and handle the preconditions > separately on the two sides. [RJ] Yes that is what I will describe in this section. > Section 1.8: > This seems incomplete, so I can't comment. [RJ] Agreed I have to do ther more work > General comment: are you intending to cover both B2BUAs that do and > don't anchor media, or only those that do? > If you are only intending to handle media anchoring B2BUAs, then say > that clearly, and it will be easier to discuss all the rest. [RJ] I like to deskribe some cases where the B2BUA anchor the media and at= least one where not. But I will do the description exactly and state where I see that the B2BUA= has to anchor media and=20 the case where tha B2BUA has not to anchor the media.=20 > If you also intend to handle B2BUAs that *don't* anchor media, then it > is probably better to treat those cases separately, because they are > very different. [RJ] Yes I agree. > If you are thinking that a B2BUA might dynamically decide whether to > anchor or not based on the details of the offers, then do the other > cases first. I think this is very hard, and maybe not possible. [RJ] I agree with you. As longer I'm looking into this issue I see that so= me cases will not=20 work as I thought first. Thanks, Paul [RJ] Thank you very much for your comments. On 9/19/14 2:36 AM, R.Jesske@telekom.de wrote: > Hi, > We=E2=80=99ve submitted a new draft, > draft-jesske-dispatch-forking-answer-correlation-00 > Since forking was defined for SIP problems on the functionality are > existing. We have identified that not all entities in networks will > understand multiples provisional responses sent back for each forking > leg where an INVITE was sent to. This will either result in an > restriction of the reachability of the terminating user or in worst case > scenarios in non successful call. In cases of where different networks > are within the call path involved, this will restrict the terminating > service provider to satisfy his customers in providing the forking > feature and also transit service providers in providing a high rate of > successful calls. > The draft describes use cases and shows possibilities how to correlate > all received provisional responses (including preconditions and 100rel) > in a intermediate entity to allow to interact with networks/entities > (UA=E2=80=99s, networks, MGCF) which are not able/willing to understand = and > handle responses of a forked call. > A first draft (which needs improvement) can be seen under: > _http://tools.ietf.org/html/draft-jesske-dispatch-forking-answer-correla= tion-00_ > I would be happy to have comments. > Thank you and Best Regards > Roland > Mit freundlichen Gr=C3=BC=C3=9Fen; With Best Regards > Roland Jesske > > Deutsche Telekom Technik GmbH > Fixed Mobile Engineering Deutschland > Roland Jesske > Heinrich-Hertz-Stra=C3=9Fe 3-7, 64295 Darmstadt > +49 6151 58-12766 (Tel.) > +49 6151 58-13395 (Fax) > +49 171 8618-445 (Mobil) > _http://www.telekom.com[http://www.telekom.com]_ > > Erleben, was verbindet. > > Deutsche Telekom Technik GmbH > Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender) > Gesch=C3=A4ftsf=C3=BChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Alb= ert > Matheis, Carsten M=C3=BCller > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr.: DE 814645262 > *Gro=C3=9Fe Ver=C3=A4nderungen fangen klein an **=E2=80=93**Ressourcen s= chonen und nicht > jede E-Mail drucken.* > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch[https://www.ietf.org/mail= man/listinfo/dispatch] > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch[https://www.ietf.org/mailma= n/listinfo/dispatch] From nobody Wed Sep 24 10:38:22 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4621A02BC for ; Wed, 24 Sep 2014 10:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 5XQZp7mdYfib for ; Wed, 24 Sep 2014 10:38:19 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.11]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1E31A0127 for ; Wed, 24 Sep 2014 10:38:18 -0700 (PDT) Received: from [62.227.171.26] by 3capp-webde-bs14.dlan.cinetic.de (via HTTP); Wed, 24 Sep 2014 19:38:16 +0200 MIME-Version: 1.0 Message-ID: From: "Roland Jesske" To: "Paul Kyzivat" Content-Type: text/html; charset=UTF-8 Date: Wed, 24 Sep 2014 19:38:16 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <541C78B3.4020901@alum.mit.edu> References: <058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0F@HE113667.emea1.cds.t-internal.com> <541C74FF.7070901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4541A4@ESESSMB209.ericsson.se>, <541C78B3.4020901@alum.mit.edu> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:0lgGyJPuq0K5gM9HT5ynmtCVwW27ZaouVsAHdTefd/x YThy0s6s6svuNcCGdGfEsg4UuGzdvOW68Y7/44ASizjScigDni tGbuWdwYgx6GDkAspbKq+tSeBt10QUC2bUfbw2RWHDV/nFL6aj QX3CuXYjlMEuZFdaW4b7PnV9/Oug1ExFRsAGEtOF/uh/ndjd8v w+YGwqhl9BX8yd9Fz+A6DgiystA+AdmVKioI3oSa3GQEehDc5H 8DU69w4IFxfqeSY/aladYXD9o08uCQH3swchqDyz1h7QTXBkWD EyFpK5afWrBxG6+WeEq5ULDlI7D X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/2Zfu007kKhnTekVOeSZRzeFCoD4 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 17:38:20 -0000
Hi Paul,
I intend to do so.
 
Best Regards
 
Roland
 
Gesendet: Freitag, 19. September 2014 um 20:40 Uhr
Von: "Paul Kyzivat" <pkyzivat@alum.mit.edu>
An: "Christer Holmberg" <christer.holmberg@ericsson.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Betreff: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00
On 9/19/14 2:34 PM, Christer Holmberg wrote:
>
> (As STRAW co-chair)
>
> Hi Paul,
>
>> This document will describe how a correlation for multiples early
>> dialogs and other received Responses can done within a B2BUA as
>> described in the taxonomy document RFC7029 [RFC7029] The role of the
>> B2BUA is a Signaling/Media Plane B2BUA Role. Thus many possible use
>> cases which will be possible looking on the used features are
>> considered in this document
>>
>> If this is really about how B2BUAs do it, then perhaps this belongs in STRAW.
>
> I actually told Roland to submit the draft to DISPATCH, as it doesn't address any of the current STRAW deliveries.
>
> But, if there is no need to go via DISPATCH, we can ask Roland to submit to STRAW directly :)

It is perhaps proper that it first come to dispatch.

Consider my comment a suggestion that DISPATCH ought to dispatch it to
STRAW.

Thanks,
Paul

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
From nobody Wed Sep 24 10:40:38 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCD11A02D6 for ; Wed, 24 Sep 2014 10:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 DUO_OVUKwbst for ; Wed, 24 Sep 2014 10:40:36 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513001A02D4 for ; Wed, 24 Sep 2014 10:40:36 -0700 (PDT) Received: from [62.227.171.26] by 3capp-webde-bs14.dlan.cinetic.de (via HTTP); Wed, 24 Sep 2014 19:40:33 +0200 MIME-Version: 1.0 Message-ID: From: "Roland Jesske" To: "Christer Holmberg" Content-Type: text/html; charset=UTF-8 Date: Wed, 24 Sep 2014 19:40:33 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4541A4@ESESSMB209.ericsson.se> References: <058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0F@HE113667.emea1.cds.t-internal.com> <541C74FF.7070901@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1D4541A4@ESESSMB209.ericsson.se> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:Ezicl9eluv+7vjiGWcFztA8VQ4mcfQDvFNreFX99KaD oPz4kaIWkQt0uruWhIgPFPbAzhFoGYTBbTaBZMQgtU5cdVS4Ur 8hNFA7wX4w8Htb+PIETjw9h5V+FUZpXtmAa5pCkWqu/ue1vxdF kkiXeEeKQnq0gL6UOoW5dK1cFhXRdaasWNOdinutaaAXEeEUPZ gPQxfMmkWgx9xAWJmESrhUeV/S3fSue9XBETdZ8YcbF6/ESl54 D0PanQY+Xdqp09s6QWVndhhjE1PaZ5pu6GHpnv6oqs+JXbC7U0 i8FjHGGaKVKsPhKgKeoW66lTWx7 X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Mvl-dZqVf1meRJh0fhC4wLQF73M Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 17:40:37 -0000
If people would like to have it I can do this.
 
Thank you
 
Roland
 
Gesendet: Freitag, 19. September 2014 um 20:34 Uhr
Von: "Christer Holmberg" <christer.holmberg@ericsson.com>
An: "Paul Kyzivat" <pkyzivat@alum.mit.edu>, "dispatch@ietf.org" <dispatch@ietf.org>
Betreff: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00

(As STRAW co-chair)

Hi Paul,

> This document will describe how a correlation for multiples early
> dialogs and other received Responses can done within a B2BUA as
> described in the taxonomy document RFC7029 [RFC7029] The role of the
> B2BUA is a Signaling/Media Plane B2BUA Role. Thus many possible use
> cases which will be possible looking on the used features are
> considered in this document
>
> If this is really about how B2BUAs do it, then perhaps this belongs in STRAW.

I actually told Roland to submit the draft to DISPATCH, as it doesn't address any of the current STRAW deliveries.

But, if there is no need to go via DISPATCH, we can ask Roland to submit to STRAW directly :)

Regards,

Christer


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
From nobody Fri Sep 26 10:25:28 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2BC1A8030 for ; Fri, 26 Sep 2014 10:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 U_KoJe6H9HEh for ; Fri, 26 Sep 2014 10:25:25 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E641A0194 for ; Fri, 26 Sep 2014 10:25:25 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id z12so12204524lbi.37 for ; Fri, 26 Sep 2014 10:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9DWr5+tHG8BJ/uQo1lz5gfdublarmyOY0tua/lU8kTw=; b=0YkJU1qMborJjMQBYfvuQj9iPXWi+0AtU00DiY10dhPzXalZ8oEdHFKKGlKKq76N1m cxbUdkgJ1rkisRDUIoBu3roiNpt5YxBdmfXZSrSB/xb4t5wGbW3NNvyhgXpFcz3Y2q51 vtttq1EQZrq0dnjbl26D544DM8NLR8aET4WikmPOFRZKp4qB4kfyi86IspnfvIX5Md3T VTgJNA04qN6uHZVKCuIcHIjr/MeV533JJd9VQ3/gmHIZeVgnPl3qxfoRlsGoP7hKeexa 1JGP7+Wa5IohWeWPAMifek3aaRJTh1t5LmC/Ty0LpQchS/e8JltJK80ZzWDUuZbwIZFq EzKA== MIME-Version: 1.0 X-Received: by 10.152.21.168 with SMTP id w8mr22146214lae.59.1411752323502; Fri, 26 Sep 2014 10:25:23 -0700 (PDT) Received: by 10.25.12.207 with HTTP; Fri, 26 Sep 2014 10:25:23 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4541A4@ESESSMB209.ericsson.se> References: <058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0F@HE113667.emea1.cds.t-internal.com> <541C74FF.7070901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4541A4@ESESSMB209.ericsson.se> Date: Fri, 26 Sep 2014 12:25:23 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0158ad54c0d6f70503fb3309 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/IVVFk8IvsYNDyvSonE7yaOW4B90 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 17:25:27 -0000 --089e0158ad54c0d6f70503fb3309 Content-Type: text/plain; charset=UTF-8 This discussion should continue in the DISPATCH WG until we get community consensus that people think this problem is worth solving and that there are people willing to do the work to complete a solution. As Christer notes, this work is currently not within the scope of the current STRAW charter and so it's not clear it should be immediately dispatched there. Per the deadlines on the DISPATCH WG wiki, based on the DISPATCH WG chairs discussion with the ADs, we will post the list of topics and the handling thereof for the IETF-91 timeframe on October 13th. At this point, the only technical comments have been from Paul. Regards, Mary as DISPATCH WG co-chair On Fri, Sep 19, 2014 at 1:34 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > (As STRAW co-chair) > > Hi Paul, > > > This document will describe how a correlation for multiples early > > dialogs and other received Responses can done within a B2BUA as > > described in the taxonomy document RFC7029 [RFC7029] The role of the > > B2BUA is a Signaling/Media Plane B2BUA Role. Thus many possible use > > cases which will be possible looking on the used features are > > considered in this document > > > > If this is really about how B2BUAs do it, then perhaps this belongs in > STRAW. > > I actually told Roland to submit the draft to DISPATCH, as it doesn't > address any of the current STRAW deliveries. > > But, if there is no need to go via DISPATCH, we can ask Roland to submit > to STRAW directly :) > > Regards, > > Christer > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --089e0158ad54c0d6f70503fb3309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This discussion should continue in the DISPATCH WG until w= e get community consensus that people think this problem is worth solving a= nd that there are people willing to do the work to complete a solution.=C2= =A0 As Christer notes, this work is currently not within the scope of the c= urrent STRAW charter and so it's not clear it should be immediately dis= patched there.=C2=A0

Per the deadlines on the DISPATCH W= G wiki, based on the DISPATCH WG chairs discussion with the ADs, we will po= st the list of topics and the handling thereof for the IETF-91 timeframe on= October 13th.

At this point, the only technical c= omments have been from Paul. =C2=A0=C2=A0

Regards,=
Mary
as DISPATCH WG co-chair

On Fri, Sep 19, 2014 at 1:34 PM, Christ= er Holmberg <christer.holmberg@ericsson.com> wr= ote:

(As STRAW co-chair)

Hi Paul,

>=C2=A0 =C2=A0 This document will describe how a correlation for multipl= es early
>=C2=A0 =C2=A0 dialogs and other received Responses can done within a B2= BUA as
>=C2=A0 =C2=A0 described in the taxonomy document RFC7029 [RFC7029] The = role of the
>=C2=A0 =C2=A0 B2BUA is a Signaling/Media Plane B2BUA Role.=C2=A0 Thus m= any possible use
>=C2=A0 =C2=A0 cases which will be possible looking on the used features= are
>=C2=A0 =C2=A0 considered in this document
>
> If this is really about how B2BUAs do it, then perhaps this belongs in= STRAW.

I actually told Roland to submit the draft to DISPATCH, as it doesn&= #39;t address any of the current STRAW deliveries.

But, if there is no need to go via DISPATCH, we can ask Roland to submit to= STRAW directly :)

Regards,

Christer


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--089e0158ad54c0d6f70503fb3309-- From nobody Mon Sep 29 22:17:38 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416851A0158 for ; Mon, 29 Sep 2014 22:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 0spm60CD45Dd for ; Mon, 29 Sep 2014 22:17:33 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F791A0151 for ; Mon, 29 Sep 2014 22:17:31 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail11.telekom.de with ESMTP; 30 Sep 2014 07:17:29 +0200 X-IronPort-AV: E=Sophos;i="5.04,625,1406584800"; d="scan'208,217";a="670844002" Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 30 Sep 2014 07:17:29 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 30 Sep 2014 07:17:29 +0200 From: To: , Date: Tue, 30 Sep 2014 07:17:28 +0200 Thread-Topic: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00 Thread-Index: Ac/ZruGxdU2k7VcoT9mifYgjO2jeRQCvPEnQ Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB632E43@HE113667.emea1.cds.t-internal.com> References: <058CE00BD4D6B94FAD033A2439EA1E4B01E488873F0F@HE113667.emea1.cds.t-internal.com> <541C74FF.7070901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4541A4@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_058CE00BD4D6B94FAD033A2439EA1E4B01E4FB632E43HE113667eme_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/RHjn_0Kv1CCcgNO9eeEZKS5E1Ww Cc: dispatch@ietf.org Subject: Re: [dispatch] New draft draft-jesske-dispatch-forking-answer-correlation-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 05:17:36 -0000 --_000_058CE00BD4D6B94FAD033A2439EA1E4B01E4FB632E43HE113667eme_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFyeSwNClRoYW5rIHlvdSBmb3IgeW91ciBtYWlsIGFuZCBjbGFyaWZpY2F0aW9uLg0KDQpO b3cgSSBoYXZlIGEgcmV3b3JrZWQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgd2hpY2ggaXMgbm93IGF2 YWlsYWJsZS4NCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtamVzc2tlLWRpc3BhdGNo LWZvcmtpbmctYW5zd2VyLWNvcnJlbGF0aW9uLTAxLnR4dA0KDQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IFJvbGFuZCBKZXNza2UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Lg0KDQoNCg0KTmFtZTogICAgICAgZHJhZnQtamVzc2tlLWRpc3BhdGNoLWZvcmtpbmct YW5zd2VyLWNvcnJlbGF0aW9uDQoNClJldmlzaW9uOiAgIDAxDQoNClRpdGxlOiAgICAgICAgICAg IENvcnJlbGF0aW9uIG9mIG11bHRpcGxlIHJlc3BvbnNlcyBvZiBmb3JrZWQgSU5WSVRFUyBpbiBC YWNrIHRvIEJhY2sgVXNlciBBZ2VudHMNCg0KRG9jdW1lbnQgZGF0ZTogICAgMjAxNC0wOS0yOQ0K DQpHcm91cDogICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCg0KUGFnZXM6ICAgICAg ICAgICAgMTgNCg0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWplc3NrZS1kaXNwYXRjaC1mb3JraW5nLWFuc3dlci1jb3JyZWxhdGlvbi0w MS50eHQNCg0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWplc3NrZS1kaXNwYXRjaC1mb3JraW5nLWFuc3dlci1jb3JyZWxhdGlvbi8NCg0KSHRt bGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWplc3NrZS1kaXNw YXRjaC1mb3JraW5nLWFuc3dlci1jb3JyZWxhdGlvbi0wMQ0KDQpEaWZmOiAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtamVzc2tlLWRpc3BhdGNoLWZvcmtp bmctYW5zd2VyLWNvcnJlbGF0aW9uLTAxDQoNCg0KDQpBYnN0cmFjdDoNCg0KICAgVGhpcyBkb2N1 bWVudCBkZXNjcmliZSBob3cgYSBjb3JyZWxhdGlvbiBvZiBtdWx0aXBsZSByZXNwb25zZXMgb2Yg YQ0KDQogICBmb3JrZWQgSU5WSVRFIGluIEJhY2sgdG8gQmFjayBVc2VyIEFnZW50cyBjYW4gYXBw bHkuDQoNCg0KDQoNCg0KQmFzZWQgb24gUGF1bOKAmXMgY29tbWVudHMgSSBoYXZlIHJlc3RydWN0 dXJlZCB0aGUgZHJhZnQuIEFuZCBjaGFuZ2VkIHRoZSBjYWxsIGZsb3dzLg0KDQoNCg0KSSB3b3Vs ZCBiZSBoYXBweSB0byBnZXQgY29tbWVudHMgYW5kIG9mIGNvdXJzZSBhbiBpbmRpY2F0aW9uIHRo YXQgcGVvcGxlIHdvdWxkIGxpa2UgdG8gcHJvY2VlZCB3aXRoIHRoZSB3b3JrIG9uIHRoZSBkcmFm dC4NCg0KDQoNClRoYW5rIHlvdSBhbmQgQmVzdCBSZWdhcmRzDQoNCg0KDQpSb2xhbmQNCg0KDQpW b246IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJh ZyB2b24gTWFyeSBCYXJuZXMNCkdlc2VuZGV0OiBGcmVpdGFnLCAyNi4gU2VwdGVtYmVyIDIwMTQg MTk6MjUNCkFuOiBDaHJpc3RlciBIb2xtYmVyZw0KQ2M6IGRpc3BhdGNoQGlldGYub3JnDQpCZXRy ZWZmOiBSZTogW2Rpc3BhdGNoXSBOZXcgZHJhZnQgZHJhZnQtamVzc2tlLWRpc3BhdGNoLWZvcmtp bmctYW5zd2VyLWNvcnJlbGF0aW9uLTAwDQoNClRoaXMgZGlzY3Vzc2lvbiBzaG91bGQgY29udGlu dWUgaW4gdGhlIERJU1BBVENIIFdHIHVudGlsIHdlIGdldCBjb21tdW5pdHkgY29uc2Vuc3VzIHRo YXQgcGVvcGxlIHRoaW5rIHRoaXMgcHJvYmxlbSBpcyB3b3J0aCBzb2x2aW5nIGFuZCB0aGF0IHRo ZXJlIGFyZSBwZW9wbGUgd2lsbGluZyB0byBkbyB0aGUgd29yayB0byBjb21wbGV0ZSBhIHNvbHV0 aW9uLiAgQXMgQ2hyaXN0ZXIgbm90ZXMsIHRoaXMgd29yayBpcyBjdXJyZW50bHkgbm90IHdpdGhp biB0aGUgc2NvcGUgb2YgdGhlIGN1cnJlbnQgU1RSQVcgY2hhcnRlciBhbmQgc28gaXQncyBub3Qg Y2xlYXIgaXQgc2hvdWxkIGJlIGltbWVkaWF0ZWx5IGRpc3BhdGNoZWQgdGhlcmUuDQoNClBlciB0 aGUgZGVhZGxpbmVzIG9uIHRoZSBESVNQQVRDSCBXRyB3aWtpLCBiYXNlZCBvbiB0aGUgRElTUEFU Q0ggV0cgY2hhaXJzIGRpc2N1c3Npb24gd2l0aCB0aGUgQURzLCB3ZSB3aWxsIHBvc3QgdGhlIGxp c3Qgb2YgdG9waWNzIGFuZCB0aGUgaGFuZGxpbmcgdGhlcmVvZiBmb3IgdGhlIElFVEYtOTEgdGlt ZWZyYW1lIG9uIE9jdG9iZXIgMTN0aC4NCg0KQXQgdGhpcyBwb2ludCwgdGhlIG9ubHkgdGVjaG5p Y2FsIGNvbW1lbnRzIGhhdmUgYmVlbiBmcm9tIFBhdWwuDQoNClJlZ2FyZHMsDQpNYXJ5DQphcyBE SVNQQVRDSCBXRyBjby1jaGFpcg0KDQpPbiBGcmksIFNlcCAxOSwgMjAxNCBhdCAxOjM0IFBNLCBD aHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCg0KKEFzIFNUUkFXIGNvLWNo YWlyKQ0KDQpIaSBQYXVsLA0KDQo+ICAgIFRoaXMgZG9jdW1lbnQgd2lsbCBkZXNjcmliZSBob3cg YSBjb3JyZWxhdGlvbiBmb3IgbXVsdGlwbGVzIGVhcmx5DQo+ICAgIGRpYWxvZ3MgYW5kIG90aGVy IHJlY2VpdmVkIFJlc3BvbnNlcyBjYW4gZG9uZSB3aXRoaW4gYSBCMkJVQSBhcw0KPiAgICBkZXNj cmliZWQgaW4gdGhlIHRheG9ub215IGRvY3VtZW50IFJGQzcwMjkgW1JGQzcwMjldIFRoZSByb2xl IG9mIHRoZQ0KPiAgICBCMkJVQSBpcyBhIFNpZ25hbGluZy9NZWRpYSBQbGFuZSBCMkJVQSBSb2xl LiAgVGh1cyBtYW55IHBvc3NpYmxlIHVzZQ0KPiAgICBjYXNlcyB3aGljaCB3aWxsIGJlIHBvc3Np YmxlIGxvb2tpbmcgb24gdGhlIHVzZWQgZmVhdHVyZXMgYXJlDQo+ICAgIGNvbnNpZGVyZWQgaW4g dGhpcyBkb2N1bWVudA0KPg0KPiBJZiB0aGlzIGlzIHJlYWxseSBhYm91dCBob3cgQjJCVUFzIGRv IGl0LCB0aGVuIHBlcmhhcHMgdGhpcyBiZWxvbmdzIGluIFNUUkFXLg0KDQpJIGFjdHVhbGx5IHRv bGQgUm9sYW5kIHRvIHN1Ym1pdCB0aGUgZHJhZnQgdG8gRElTUEFUQ0gsIGFzIGl0IGRvZXNuJ3Qg YWRkcmVzcyBhbnkgb2YgdGhlIGN1cnJlbnQgU1RSQVcgZGVsaXZlcmllcy4NCg0KQnV0LCBpZiB0 aGVyZSBpcyBubyBuZWVkIHRvIGdvIHZpYSBESVNQQVRDSCwgd2UgY2FuIGFzayBSb2xhbmQgdG8g c3VibWl0IHRvIFNUUkFXIGRpcmVjdGx5IDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRpc3BhdGNo IG1haWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KDQo= --_000_058CE00BD4D6B94FAD033A2439EA1E4B01E4FB632E43HE113667eme_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiTnVyIFRleHQgWmNobiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseTpDb25zb2xhczt9 DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5OdXJUZXh0WmNobg0KCXttc28tc3R5bGUtbmFtZToiTnVyIFRleHQgWmNobiI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJOdXIgVGV4dCI7DQoJ Zm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1ERSBsaW5rPWJs dWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGkgTWFyeSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5UaGFuayB5b3UgZm9yIHlvdXIgbWFpbCBhbmQgY2xhcmlmaWNhdGlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ob3cgSSBoYXZlIGEgcmV3b3JrZWQgdmVy c2lvbiBvZiB0aGUgZHJhZnQgd2hpY2ggaXMgbm93IGF2YWlsYWJsZS4gwqA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxz cGFuIGxhbmc9RU4tVVM+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWplc3NrZS1kaXNwYXRj aC1mb3JraW5nLWFuc3dlci1jb3JyZWxhdGlvbi0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+aGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBSb2xhbmQgSmVzc2tlIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48c3BhbiBsYW5nPUVOLVVTPk5hbWU6wqDCoMKgwqDCoMKgIGRyYWZ0LWplc3NrZS1kaXNw YXRjaC1mb3JraW5nLWFuc3dlci1jb3JyZWxhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz5SZXZpc2lvbjrCoMKgIDAxPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPlRp dGxlOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgQ29ycmVsYXRpb24gb2YgbXVsdGlwbGUgcmVzcG9u c2VzIG9mIGZvcmtlZCBJTlZJVEVTIGluIEJhY2sgdG8gQmFjayBVc2VyIEFnZW50czxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz5Eb2N1 bWVudCBkYXRlOsKgwqDCoCAyMDE0LTA5LTI5PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPkdyb3VwOsKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPlBhZ2VzOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg MTg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9 RU4tVVM+VVJMOsKgwqDCoMKgwqDCoMKgIMKgwqDCoMKgPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWplc3NrZS1kaXNwYXRjaC1mb3JraW5n LWFuc3dlci1jb3JyZWxhdGlvbi0wMS50eHQiPjxzcGFuIGxhbmc9RU4tVVM+aHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamVzc2tlLWRpc3BhdGNoLWZvcmtpbmctYW5z d2VyLWNvcnJlbGF0aW9uLTAxLnR4dDwvc3Bhbj48L2E+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+U3Rh dHVzOsKgwqDCoMKgwqDCoMKgwqAgPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWplc3NrZS1kaXNwYXRjaC1mb3JraW5nLWFuc3dlci1jb3JyZWxh dGlvbi8iPjxzcGFuIGxhbmc9RU4tVVM+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtamVzc2tlLWRpc3BhdGNoLWZvcmtpbmctYW5zd2VyLWNvcnJlbGF0aW9uLzwvc3Bhbj48 L2E+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+SHRtbGl6ZWQ6wqDCoMKgwqDCoMKgIDwvc3Bhbj48YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qZXNza2UtZGlzcGF0Y2gtZm9y a2luZy1hbnN3ZXItY29ycmVsYXRpb24tMDEiPjxzcGFuIGxhbmc9RU4tVVM+aHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtamVzc2tlLWRpc3BhdGNoLWZvcmtpbmctYW5zd2VyLWNvcnJl bGF0aW9uLTAxPC9zcGFuPjwvYT48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz5EaWZmOsKgwqDCoMKgwqDC oMKgwqDCoMKgIDwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1qZXNza2UtZGlzcGF0Y2gtZm9ya2luZy1hbnN3ZXItY29ycmVsYXRpb24tMDEiPjxz cGFuIGxhbmc9RU4tVVM+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtamVz c2tlLWRpc3BhdGNoLWZvcmtpbmctYW5zd2VyLWNvcnJlbGF0aW9uLTAxPC9zcGFuPjwvYT48c3Bh biBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+QWJzdHJhY3Q6PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPsKgwqAgVGhpcyBkb2N1bWVu dCBkZXNjcmliZSBob3cgYSBjb3JyZWxhdGlvbiBvZiBtdWx0aXBsZSByZXNwb25zZXMgb2YgYTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1V Uz7CoMKgIGZvcmtlZCBJTlZJVEUgaW4gQmFjayB0byBCYWNrIFVzZXIgQWdlbnRzIGNhbiBhcHBs eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9 RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48 c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkJhc2VkIG9uIFBhdWzi gJlzIGNvbW1lbnRzIEkgaGF2ZSByZXN0cnVjdHVyZWQgdGhlIGRyYWZ0LiBBbmQgY2hhbmdlZCB0 aGUgY2FsbCBmbG93cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5JIHdvdWxkIGJlIGhhcHB5IHRvIGdldCBjb21tZW50cyBhbmQgb2YgY291cnNlIGFuIGlu ZGljYXRpb24gdGhhdCBwZW9wbGUgd291bGQgbGlrZSB0byBwcm9jZWVkIHdpdGggdGhlIHdvcmsg b24gdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPlRoYW5rIHlvdSBhbmQgQmVzdCBSZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+Um9sYW5kPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz5Wb246PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBkaXNwYXRjaCBbbWFpbHRvOmRpc3BhdGNoLWJv dW5jZXNAaWV0Zi5vcmddIDxiPkltIEF1ZnRyYWcgdm9uIDwvYj5NYXJ5IEJhcm5lczxicj48Yj5H ZXNlbmRldDo8L2I+IEZyZWl0YWcsIDI2LiBTZXB0ZW1iZXIgMjAxNCAxOToyNTxicj48Yj5Bbjo8 L2I+IENocmlzdGVyIEhvbG1iZXJnPGJyPjxiPkNjOjwvYj4gZGlzcGF0Y2hAaWV0Zi5vcmc8YnI+ PGI+QmV0cmVmZjo8L2I+IFJlOiBbZGlzcGF0Y2hdIE5ldyBkcmFmdCBkcmFmdC1qZXNza2UtZGlz cGF0Y2gtZm9ya2luZy1hbnN3ZXItY29ycmVsYXRpb24tMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPlRoaXMgZGlzY3Vzc2lvbiBzaG91bGQgY29udGludWUgaW4gdGhlIERJU1BB VENIIFdHIHVudGlsIHdlIGdldCBjb21tdW5pdHkgY29uc2Vuc3VzIHRoYXQgcGVvcGxlIHRoaW5r IHRoaXMgcHJvYmxlbSBpcyB3b3J0aCBzb2x2aW5nIGFuZCB0aGF0IHRoZXJlIGFyZSBwZW9wbGUg d2lsbGluZyB0byBkbyB0aGUgd29yayB0byBjb21wbGV0ZSBhIHNvbHV0aW9uLiZuYnNwOyBBcyBD aHJpc3RlciBub3RlcywgdGhpcyB3b3JrIGlzIGN1cnJlbnRseSBub3Qgd2l0aGluIHRoZSBzY29w ZSBvZiB0aGUgY3VycmVudCBTVFJBVyBjaGFydGVyIGFuZCBzbyBpdCdzIG5vdCBjbGVhciBpdCBz aG91bGQgYmUgaW1tZWRpYXRlbHkgZGlzcGF0Y2hlZCB0aGVyZS4mbmJzcDs8bzpwPjwvbzpwPjwv cD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5QZXIgdGhlIGRlYWRsaW5lcyBvbiB0aGUgRElTUEFUQ0ggV0cg d2lraSwgYmFzZWQgb24gdGhlIERJU1BBVENIIFdHIGNoYWlycyBkaXNjdXNzaW9uIHdpdGggdGhl IEFEcywgd2Ugd2lsbCBwb3N0IHRoZSBsaXN0IG9mIHRvcGljcyBhbmQgdGhlIGhhbmRsaW5nIHRo ZXJlb2YgZm9yIHRoZSBJRVRGLTkxIHRpbWVmcmFtZSBvbiBPY3RvYmVyIDEzdGguPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+QXQgdGhpcyBwb2ludCwgdGhlIG9ubHkgdGVj aG5pY2FsIGNvbW1lbnRzIGhhdmUgYmVlbiBmcm9tIFBhdWwuICZuYnNwOyZuYnNwOzxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlJlZ2FyZHMsPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+TWFyeTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPmFzIERJU1BBVENIIFdHIGNvLWNoYWlyPG86cD48L286cD48L3A+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+T24gRnJpLCBTZXAgMTksIDIwMTQgYXQgMTozNCBQTSwgQ2hyaXN0ZXIgSG9s bWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20i IHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPihBcyBTVFJBVyBjby1j aGFpcik8YnI+PGJyPkhpIFBhdWwsPGJyPjxicj4mZ3Q7Jm5ic3A7ICZuYnNwOyBUaGlzIGRvY3Vt ZW50IHdpbGwgZGVzY3JpYmUgaG93IGEgY29ycmVsYXRpb24gZm9yIG11bHRpcGxlcyBlYXJseTxi cj4mZ3Q7Jm5ic3A7ICZuYnNwOyBkaWFsb2dzIGFuZCBvdGhlciByZWNlaXZlZCBSZXNwb25zZXMg Y2FuIGRvbmUgd2l0aGluIGEgQjJCVUEgYXM8YnI+Jmd0OyZuYnNwOyAmbmJzcDsgZGVzY3JpYmVk IGluIHRoZSB0YXhvbm9teSBkb2N1bWVudCBSRkM3MDI5IFtSRkM3MDI5XSBUaGUgcm9sZSBvZiB0 aGU8YnI+Jmd0OyZuYnNwOyAmbmJzcDsgQjJCVUEgaXMgYSBTaWduYWxpbmcvTWVkaWEgUGxhbmUg QjJCVUEgUm9sZS4mbmJzcDsgVGh1cyBtYW55IHBvc3NpYmxlIHVzZTxicj4mZ3Q7Jm5ic3A7ICZu YnNwOyBjYXNlcyB3aGljaCB3aWxsIGJlIHBvc3NpYmxlIGxvb2tpbmcgb24gdGhlIHVzZWQgZmVh dHVyZXMgYXJlPGJyPiZndDsmbmJzcDsgJm5ic3A7IGNvbnNpZGVyZWQgaW4gdGhpcyBkb2N1bWVu dDxicj4mZ3Q7PGJyPiZndDsgSWYgdGhpcyBpcyByZWFsbHkgYWJvdXQgaG93IEIyQlVBcyBkbyBp dCwgdGhlbiBwZXJoYXBzIHRoaXMgYmVsb25ncyBpbiBTVFJBVy48YnI+PGJyPkkgYWN0dWFsbHkg dG9sZCBSb2xhbmQgdG8gc3VibWl0IHRoZSBkcmFmdCB0byBESVNQQVRDSCwgYXMgaXQgZG9lc24n dCBhZGRyZXNzIGFueSBvZiB0aGUgY3VycmVudCBTVFJBVyBkZWxpdmVyaWVzLjxicj48YnI+QnV0 LCBpZiB0aGVyZSBpcyBubyBuZWVkIHRvIGdvIHZpYSBESVNQQVRDSCwgd2UgY2FuIGFzayBSb2xh bmQgdG8gc3VibWl0IHRvIFNUUkFXIGRpcmVjdGx5IDopPGJyPjxicj5SZWdhcmRzLDxicj48YnI+ Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj48 YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ZGlz cGF0Y2ggbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZyI+ ZGlzcGF0Y2hAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGlzcGF0Y2giIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjwv ZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_058CE00BD4D6B94FAD033A2439EA1E4B01E4FB632E43HE113667eme_-- From nobody Tue Sep 30 10:48:22 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD09C1A6FFF for ; Tue, 30 Sep 2014 10:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 P02rmfKkZkHh for ; Tue, 30 Sep 2014 10:48:19 -0700 (PDT) Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768AC1A6FFC for ; Tue, 30 Sep 2014 10:48:19 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id 131so1421736ykp.6 for ; Tue, 30 Sep 2014 10:48:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=AqbBUnxmXXzc93iiF0KhfQniYpQKxcB7fxIjZ74+uOo=; b=Pq9vAu3362jEJS0F9G3PUHErdpiH8uwean3KZEtbCb+vI7oWmL7uEMUTJ7Wxk7uBZ+ O/hOmvc4JPLjbPPHQsJMJwNAiuH34swI7TVjl/bPjPKGUxfkfKxbQ6HzJCVuw3ZgJ5ck iRais5hSy+sskSkLueXVxWXZkJXyhrrj6cvrVmh/ToVcNH1SB7ieEXifim0SEmGvi9XE A4DVsO/kOXinMJO4l0Hvd7B+om/LhO3GmQDtrmaCJ3wmYFKkIeFog3ehOpx+zVJKgqXx 1dD15Ffor8kEi8VKWVl+CKVJhWWfeFHypaNJleqlbmyvB5eFO+Ki2BbfYlvDlIBKvaEw QDsQ== X-Gm-Message-State: ALoCoQlEIRp5ISlwpUmSo6naMFXTeObMy3dM0I0ULJgcmIqGfN1PwEhU5r3b3NbPZKWcWXj98tx/ X-Received: by 10.236.155.234 with SMTP id j70mr71970877yhk.74.1412099298815; Tue, 30 Sep 2014 10:48:18 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/c1in/6iJaHF2iQRaj03zwsUIHGg== Date: Tue, 30 Sep 2014 13:48:18 -0400 Message-ID: <82a8083a078209c80187a46304ff5532@mail.gmail.com> To: R.Jesske@telekom.de, dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/0uBwzXyhvYZDhy0cXgZvOg_NCnE Subject: [dispatch] draft-jesske-dispatch-forking-answer-correlation-01: comments X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 17:48:21 -0000 Hi, The following are few comments concerning draft-jesske-dispatch-forking-answer-correlation-01. Thanks, Brett ------- 1) Section 1 indicates: " Now the originating SIP device has to understand that two devices are ringing and one will answer the call. No Problem since RFC3261 [RFC3261] allows this and allows also the originating device to handle multiples responses. But this is not mandated by RFC3261 [RFC3261] and led to implementers choice. There will the first problem apply that only one of the Responses will be taken into consideration for creating a dialog." RFC 3261 mandates that the UAC be able to handle interactions with a forking proxy. However, I agree that some B2BUAs attempt to protect clients from needing to support such functionality. 2) Section 2.8 indicates: "Thus the only solution seen is to describe procedures which apply in B2BUA to support an correlation of multiples early dialogs and other received 18x Responses." I disagree with that statement. One solution is to replace/upgrade the deficient device so that it supports forking interactions. 3) Section 3 indicates: " To provide the best user behavior a service provider shall have the possibility to correlate multiples received responses to one dialog leg to the UAC." I disagree with that statement. Folding multiple early dialogs onto a single early dialog does not produce the best user experience. It causes ambiguities as various requests/response/headers/bodies traverse those early dialogs. It can cause the need for UAC to support RFC 3262 and RFC 3311 (if the B2BUA needs to communicate SDP modifications on an early dialog). 4) Section 4.1 figure 1 shows CANCEL/200/487/ACK between UAC, PROXY, and Forking Proxy. This should not be occurring. 5) Section 4.2 figure 2 shows CANCEL/200/487/ACK between B2BUA and Forking Proxy. This should not be occurring. 6) Section 4.2 shows B2BUA only relaying first 18x. What are you proposing to do if the servers sent different 18x responses such as UAC_2 sent 181, UAC_3 sent 182, and UAC_4 sent 183? 7) Section 4.3 figure 3 shows CANCEL/200/487/ACK between B2BUA and Forking Proxy. This should not be occurring. 8) Section 4.4 figure 4 shows CANCEL/200 between B2BUA and Forking Proxy. This should not be occurring. It also looks like there is a subsequent extra 200 response. 9) Section 4.4 figure 4 is missing the 487/ACK interaction with UAS_2. 10) Section 4.4 figure 4 F40 should maybe be drawn from UAS_4 to match numbering and F57. 11) Section 4.4 second figure 4 should be figure 5. My prior section 4.4 comments also apply to the second figure 4 (i.e. figure 5) although the F numbering is different.