[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-ietf-sip-outbound
On May 9, 2008, at 3:46 AM, Juha Heinanen wrote:
> Dean Willis writes:
>
>> One nifty technique is to pair up the proxies, such that there are
>> N/2
>> pairs, then define a hash across the namespace that maps to each user
>> ID to one of those pairs, Your UA wilFrom sip-bounces at ietf.org Fri May 9 17:43:17 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 919853A683D;
Fri, 9 May 2008 17:43:17 -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 6D9983A683D
for <sip at core3.amsl.com>; Fri, 9 May 2008 17:43:16 -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=[AWL=0.000,
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 jOWcvFF+QeYV for <sip at core3.amsl.com>;
Fri, 9 May 2008 17:43:15 -0700 (PDT)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164])
by core3.amsl.com (Postfix) with ESMTP id 7109E3A67A8
for <sip at ietf.org>; Fri, 9 May 2008 17:43:15 -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
m4A0ebqL016172
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
Fri, 9 May 2008 19:40:39 -0500
Message-Id: <6A699061-514E-40F9-8949-B44EF76D9A02 at softarmor.com>
From: Dean Willis <dean.willis at softarmor.com>
To: jh at tutpro.com (Juha Heinanen)
In-Reply-To: <18468.3962.993600.980552 at taimen.test.fi>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Fri, 9 May 2008 19:40:32 -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>
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 9, 2008, at 3:46 AM, Juha Heinanen wrote:
> Dean Willis writes:
>
>> One nifty technique is to pair up the proxies, such that there are
>> N/2
>> pairs, then define a hash across the namespace that maps to each user
>> ID to one of those pairs, Your UA will then el then end up registering to and
>> forming a flow with both proxies in its assigned pair. Other proxies
>> in the pool that receive a request for you can use the hash to find
>> the right pair, and if either proxy in the pair has lost the flow, it
>> knows to consult the other member of the pair.
>
> dean,
>
> i would really love to implement something like this, but the
> problem is
> that because of ob draft you cannot assume that "UA will then end up
> registering to and forming a flow with both proxies in its assigned
> pair".
>
Then you're reading a different outbound draft than I am, because as
far as I know, enabling the UA to bind multiple proxies is what the
outbound draft does. Without it, you have no real way to do this.
Yes, binding multiple proxies is optional with respect to the
protocol. In general, UAs will be configured (and this draft doesn't
specify configuration) to bind multiple proxies, but it's true that
UAs do not absolutely have to bind multiple proxies in order to place
and receive calls. Deployments just scale the number of proxies based
on the desired reliability.
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!
> in order cope with proxy failure, you must then play with all kinds
> tricks to make the still working proxy in the pair to assume the ip
> address and (in case of tcp) the flows of the dead proxy, which is not
> easy at all.
No, in order to deal with proxy failure in a single proxy case, the
easiest thing to do is wait for the UA to note that its flow has
dropped (because its keepalive failed) and rebind. You could certainly
do a state-transfer to the standby-router thing, but that probably
costs more than just deploying dual proxies would have.
But if the UA used the optional multi-proxy binding then there would
be no need to wait. This provides operational advantages, at cost, so
it's up to each deployment to decide whether the advantages outweigh
the costs.
--
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
nd up registering to and
>> forming a flow with both proxies in its assigned pair. Other proxies
>> in the pool that receive a request for you can use the hash to find
>> the right pair, and if either proxy in the pair has lost the flow, it
>> knows to consult the other member of the pair.
>
> dean,
>
> i would really love to implement something like this, but the
> problem is
> that because of ob draft you cannot assume that "UA will then end up
> registering to and forming a flow with both proxies in its assigned
> pair".
>
Then you're reading a different outbound draft than I am, because as
far as I know, enabling the UA to bind multiple proxies is what the
outbound draft does. Without it, you have no real way to do this.
Yes, binding multiple proxies is optional with respect to the
protocol. In general, UAs will be configured (and this draft doesn't
specify configuration) to bind multiple proxies, but it's true that
UAs do not absolutely have to bind multiple proxies in order to place
and receive calls. Deployments just scale the number of proxies based
on the desired reliability.
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!
> in order cope with proxy failure, you must then play with all kinds
> tricks to make the still working proxy in the pair to assume the ip
> address and (in case of tcp) the flows of the dead proxy, which is not
> easy at all.
No, in order to deal with proxy failure in a single proxy case, the
easiest thing to do is wait for the UA to note that its flow has
dropped (because its keepalive failed) and rebind. You could certainly
do a state-transfer to the standby-router thing, but that probably
costs more than just deploying dual proxies would have.
But if the UA used the optional multi-proxy binding then there would
be no need to wait. This provides operational advantages, at cost, so
it's up to each deployment to decide whether the advantages outweigh
the costs.
--
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