[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-ietf-sip-outbound
On May 10, 2008, at 12:40 AM, Juha Heinanen wrote:
> Dean Willis writes:
>
>> Then you're reading a different outbound draft than I am, because as
>> far as I know, enabling From sip-bounces at ietf.org Sat May 10 00:51:19 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 1E5143A67EA;
Sat, 10 May 2008 00:51:19 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 1AADE3A67A1
for <sip at core3.amsl.com>; Sat, 10 May 2008 00:51:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id VLhclyaMcYvm for <sip at core3.amsl.com>;
Sat, 10 May 2008 00:51:16 -0700 (PDT)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164])
by core3.amsl.com (Postfix) with ESMTP id 587C73A67EA
for <sip at ietf.org>; Sat, 10 May 2008 00:50:58 -0700 (PDT)
Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com
[76.185.142.113]) (authenticated bits=0)
by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
m4A7jBDc017566
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
Sat, 10 May 2008 02:45:12 -0500
Message-Id: <B0CF5278-8A23-4033-A5AF-4924BA98B9B4 at softarmor.com>
From: Dean Willis <dean.willis at softarmor.com>
To: jh at tutpro.com (Juha Heinanen)
In-Reply-To: <18469.13630.852013.419236 at taimen.test.fi>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Sat, 10 May 2008 02:45:05 -0500
References: <18465.17834.732392.527310 at taimen.test.fi>
<CA9998CD4A020D418654FCDEF4E707DF046C776E at esealmw113.eemea.ericsson.se>
<18465.32545.345585.820414 at taimen.test.fi>
<E6C2E8958BA59A4FB960963D475F7AC30BD8050F5A at mail.acmepacket.com>
<18465.55659.177188.471351 at taimen.test.fi>
<1ECE0EB50388174790F9694F77522CCF16A01DDF at zrc2hxm0.corp.nortel.com>
<18466.880.342656.104598 at taimen.test.fi>
<E6C2E8958BA59A4FB960963D475F7AC30BD80514C7 at mail.acmepacket.com>
<48222D54.7020006 at iptel.org>
<E6C2E8958BA59A4FB960963D475F7AC30BD8051669 at mail.acmepacket.com>
<CA9998CD4A020D418654FCDEF4E707DF046C7775 at esealmw113.eemea.ericsson.se>
<18466.42180.621089.330513 at taimen.test.fi>
<4822AB7C.9000108 at iptel.org>
<1ECE0EB50388174790F9694F77522CCF16A5306F at zrc2hxm0.corp.nortel.com>
<18467.10759.517606.958702 at taimen.test.fi>
<1ECE0EB50388174790F9694F77522CCF16A5321E at zrc2hxm0.corp.nortel.com>
<18467.12939.938913.841738 at taimen.test.fi>
<1ECE0EB50388174790F9694F77522CCF16A53410 at zrc2hxm0.corp.nortel.com>
<18467.16! ! 487.171324.508479 at ! t aimen.te st.fi> <E6C2E
8958BA59A4FB960963D475F7AC30BD80C2A8B at mail.acmepacket.com>
<18467.17492.323683.861768 at taimen.test.fi>
<CA9998CD4A020D418654FCDEF4E707DF05C0F825 at esealmw113.eemea.ericsson.se>
<A8948F50-3BAC-4CA2-BA42-E2F4F9493BEF at softarmor.com>
<18468.3962.993600.980552 at taimen.test.fi>
<6A699061-514E-40F9-8949-B44EF76D9A02 at softarmor.com>
<18469.13630.852013.419236 at taimen.test.fi>
X-Mailer: Apple Mail (2.919.2)
Cc: sip at ietf.org, Francois Audet <audet at nortel.com>, drage at alcatel-lucent.com,
Christer Holmberg <christer.holmberg at ericsson.com>
Subject: Re: [Sip] draft-ietf-sip-outbound
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
On May 10, 2008, at 12:40 AM, Juha Heinanen wrote:
> Dean Willis writes:
>
>> Then you're reading a different outbound draft than I am, because as
>> far as I know, enabling the UA tthe UA to bind multiple proxies is what the
>> outbound draft does. Without it, you have no real way to do this.
>
> ob draft does not "anable UA to bind to multiple proxies". rfc3261
> already allows and enables UA to bind to multiple proxies.
Not and detect when they've dropped and need to be re-connected, and
not in a way that allows the proxies to reach the UAs back across a
NAT reliably,
>
>
>> Since the mechanism works with a single binding, there's no rationale
>> under RFC 2119 for making usage of multiple bindings a MUST. If we
>> did that , then we'd have to make it a MUST for proxies to always be
>> deployed in pairs, and that clearly isn't going to happen in every
>> deployment scenario. I can only afford one proxy!
>
> then the ob set that you tell to your UAs would consist of only one
> proxy, which would be perfectly fine.
Earlier, you were apparently arguing that having only one proxy
configured should be a violation of the spec, and that Outbound is
useless because it does not require a UA to register with multiple
proxies. Now you're saying that this would be perfectly fine.
Are you saying that the configuration mechanism should have an
indicator to tell a configured UA which or how many proxies it should
bind to, out of a larger set of available proxies that it can choose
from? For example, we might have a configuration that says "Here are
the six proxies available for you to use. We expect you to register
with at least two of them, and if you lose any bindings, please make a
new one. Registering with only one is a violation of your terms of
service and will force us to neuter your cat." Or perhaps another
config that says "Here are four proxies. You must register with all of
them."
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
o bind multiple proxies is what the
>> outbound draft does. Without it, you have no real way to do this.
>
> ob draft does not "anable UA to bind to multiple proxies". rfc3261
> already allows and enables UA to bind to multiple proxies.
Not and detect when they've dropped and need to be re-connected, and
not in a way that allows the proxies to reach the UAs back across a
NAT reliably,
>
>
>> Since the mechanism works with a single binding, there's no rationale
>> under RFC 2119 for making usage of multiple bindings a MUST. If we
>> did that , then we'd have to make it a MUST for proxies to always be
>> deployed in pairs, and that clearly isn't going to happen in every
>> deployment scenario. I can only afford one proxy!
>
> then the ob set that you tell to your UAs would consist of only one
> proxy, which would be perfectly fine.
Earlier, you were apparently arguing that having only one proxy
configured should be a violation of the spec, and that Outbound is
useless because it does not require a UA to register with multiple
proxies. Now you're saying that this would be perfectly fine.
Are you saying that the configuration mechanism should have an
indicator to tell a configured UA which or how many proxies it should
bind to, out of a larger set of available proxies that it can choose
from? For example, we might have a configuration that says "Here are
the six proxies available for you to use. We expect you to register
with at least two of them, and if you lose any bindings, please make a
new one. Registering with only one is a violation of your terms of
service and will force us to neuter your cat." Or perhaps another
config that says "Here are four proxies. You must register with all of
them."
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip