[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Dual registration without Outbound
Right.
Outbound has a "redundancy" mechanism for the proxy embedded in the spec.
What is being asked is a redundancy mechanism for the UA (based on dual homing).
My reaction is that I don't see why a redundancy mechanism for the UA should even
be tied to draft-ietf-sip-outbound. It seems to be attempting to useFrom sip-bounces at ietf.org Tue Oct 7 18:04:18 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 3E69528C0F8;
Tue, 7 Oct 2008 18:04:18 -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 EF0B13A694C
for <sip at core3.amsl.com>; Tue, 7 Oct 2008 18:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ZBHFaggb7p4D for <sip at core3.amsl.com>;
Tue, 7 Oct 2008 18:04:16 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56])
by core3.amsl.com (Postfix) with ESMTP id ABBFC3A6A9B
for <sip at ietf.org>; Tue, 7 Oct 2008 18:04:15 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
[47.103.123.71])
by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
m98127213850; Wed, 8 Oct 2008 01:02:07 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 7 Oct 2008 20:04:48 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF199DA2EB at zrc2hxm0.corp.nortel.com>
In-Reply-To: <5D1A7985295922448D5550C94DE29180023B048B at DEEXC1U01.de.lucent.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Dual registration without Outbound
Thread-Index: AckoyrBq+xKnvI0VSzm5Yp8d+Qx3NAAC3vEQAAKxSbA=
References: <7C532034-8511-4191-9ABA-02D5C42AC74D at softarmor.com><18665.43684.176244.988653 at taimen.test.fi><CA9998CD4A020D418654FCDEF4E707DF05C0F88C at esealmw113.eemea.ericsson.se><18665.45965.827982.821183 at taimen.test.fi><CA9998CD4A020D418654FCDEF4E707DF05C0F88F at esealmw113.eemea.ericsson.se><CA9998CD4A020D418654FCDEF4E707DF05C0F890 at esealmw113.eemea.ericsson.se><18665.47207.397605.244480 at taimen.test.fi><CA9998CD4A020D418654FCDEF4E707DF05C0F892 at esealmw113.eemea.ericsson.se><18665.48080.859460.802945 at taimen.test.fi><CA9998CD4A020D418654FCDEF4E707DF05C0F894 at esealmw113.eemea.ericsson.se><18665.49637.47890.122973 at taimen.test.fi><CA9998CD4A020D418654FCDEF4E707DF05C0F895 at esealmw113.eemea.ericsson.se><18665.51736.268071.502700 at taimen.test.fi><CA9998CD4A020D418654FCDEF4E707DF05C0F896 at esealmw113.eemea.ericsson.se>
<18665.59
269.640606.477292 at taimen.test.fi><CA9998CD4A020D418654FCDEF4E707DF05C0F899 at esealmw113.eemea.ericsson.se><48EBC88B.2030300 at cisco.com>
<46101DEA-677B-4F28-AD1E-32F64385! ! 8535 at so ft armor.com
> <5D1A7985295922448D5550C94DE29180023B048B at DEEXC1U01.de.lucent.com>
From: "Francois Audet" <audet at nortel.com>
To: "DRAGE, Keith (Keith)" <drage at alcatel-lucent.com>,
"Dean Willis" <dean.willis at softarmor.com>,
"Paul Kyzivat" <pkyzivat at cisco.com>
Cc: sip at ietf.org, Christer Holmberg <christer.holmberg at ericsson.com>
Subject: Re: [Sip] Dual registration without 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
Right.
Outbound has a "redundancy" mechanism for the proxy embedded in the spec.
What is being asked is a redundancy mechanism for the UA (based on dual homing).
My reaction is that I don't see why a redundancy mechanism for the UA should even
be tied to draft-ietf-sip-outbound. It seems to be attempting to use a small side effect
of outbound.
Rather, I think this should be a new draft, and it should be independent from outbound.
We already have a mechanism that allows for a q-value in a contact to indicate a desire for
different forking priorities.
I think another URI parameter for a Contact indicating that 2 different contacts are
effectively the same (because of dual homing) would do the trick, and would not
require outbound. Or maybe a parameter that says "alternative" to indicate that it's an
alternative to a specific contact (that has the advantage of telling the Registrar which
one is preferred which is apparently required).
Bottom line is I don't think Outbound is a good sledgehammer to use for this problem.
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of DRAGE, Keith (Keith)
> Sent: Tuesday, October 07, 2008 16:45
> To: Dean Willis; Paul Kyzivat
> Cc: sip at ietf.org; Christer Holmberg
> Subject: Re: [Sip] Dual registration without Outbound
>
> I am becoming concerned that we are now at this late stage
> going into requirement inflation. This appears to be such.
>
> I do not remember a requirement to provide redundant
> connections to registrars as amongst the original requirements.
>
> 1. Must be able to detect that a UA supports these mechanisms.
> 2. Support UAs behind NATs.
> 3. Support TLS to a UA without a stable DNS name or IP address.
> 4. Detect failure of a connection and be able to correct for this.
> 5. Support many UAs simultaneously rebooting.
> 6. Support a NAT rebooting or resetting.
> 7. Minimize initial startup load on a proxy.
> 8. Support architectures with edge proxies.
>
>
> Regards
>
> Keith
>
> > -----Original Message-----
> > From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of
> > Dean Willis
> > Sent: Tuesday, October 07, 2008 11:17 PM
> > To: Paul Kyzivat
> > Cc: sip at ietf.org; Christer Holmberg
> > Subject: Re: [Sip] Dual registration without Outbound
> >
> >
> > On Oct 7, 2008, at 3:37 PM, Paul Kyzivat wrote:
> >
> > > I think I am missing something here. I presume that the
> > knowledge of
> > > the UA is limited to:
> > > - to proxy addresses
> > > - an AOR to register
> > >
> > > Presumably the address of the registrar is derived from
> the AOR to
> > > register by removing the user part. So the UA, when registering,
> > > doesn't specify two different registrars. Whether there are
> > two or not
> > > is a function of how the proxy routes the register request.
> > So whether
> > > the two registers for the same contact go to one registrar
> > or two is
> > > unknown to the UA. In some configurations this would give you
> > > redundancy, and in others it would not.
> > >
> > > Then, what causes the UA to register two different
> > contacts? Are the
> > > wlan contact and the 3g contact registered to *different*
> > AORs? If not
> > > I don't see the point. If anything, I would expect that
> 3g and wlan
> > > represent access networks and hence differing proxies,
> not AORs or
> > > registrars.
> > >
> >
> > Some IMS networks have mechanisms for discovering the edge proxy
> > based on the air interface. This, a UA might discover one proxy for
> > its 3g interface, and another for its WLAN interface. In
> other words,
> > one proxy for each Contact.
> >
> > So, that's "proxy" discovery.
> >
> > Registrar discovery is a separate process. With
> config-framework, the
> > UA is configured with a set of proxies with which it may register.
> > Under outbound-015, if there are two or more outbound
> proxies in the
> > configured set, the UA must register through at least two of those
> > proxies. This assumes a singular contact at the UA.
> >
> > Juha has, IIRC, proposed that the UA must register with at
> least two
> > of those proxies for each contact. This, I believe, has some merit.
> > I'm not sure it's a MUST, but it certainly seems a
> reasonable SHOULD.
> >
> > Of course, when the configuration mechanism is different
> and only one
> > proxy is provided per contact, we have a different case.
> >
> > It seems like we are developing two conflicted use cases here
> > -- one for a singular contact with redundant registration
> paths, and
> > another for redundant contacts, each with singular
> registration path.
> >
> > Then there may be yet another case, multiple contacts, each with
> > redundant registration paths.
> >
> > --
> > 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
> >
> _______________________________________________
> 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
>
_______________________________________________
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
a small side effect
of outbound.
Rather, I think this should be a new draft, and it should be independent from outbound.
We already have a mechanism that allows for a q-value in a contact to indicate a desire for
different forking priorities.
I think another URI parameter for a Contact indicating that 2 different contacts are
effectively the same (because of dual homing) would do the trick, and would not
require outbound. Or maybe a parameter that says "alternative" to indicate that it's an
alternative to a specific contact (that has the advantage of telling the Registrar which
one is preferred which is apparently required).
Bottom line is I don't think Outbound is a good sledgehammer to use for this problem.
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of DRAGE, Keith (Keith)
> Sent: Tuesday, October 07, 2008 16:45
> To: Dean Willis; Paul Kyzivat
> Cc: sip at ietf.org; Christer Holmberg
> Subject: Re: [Sip] Dual registration without Outbound
>
> I am becoming concerned that we are now at this late stage
> going into requirement inflation. This appears to be such.
>
> I do not remember a requirement to provide redundant
> connections to registrars as amongst the original requirements.
>
> 1. Must be able to detect that a UA supports these mechanisms.
> 2. Support UAs behind NATs.
> 3. Support TLS to a UA without a stable DNS name or IP address.
> 4. Detect failure of a connection and be able to correct for this.
> 5. Support many UAs simultaneously rebooting.
> 6. Support a NAT rebooting or resetting.
> 7. Minimize initial startup load on a proxy.
> 8. Support architectures with edge proxies.
>
>
> Regards
>
> Keith
>
> > -----Original Message-----
> > From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of
> > Dean Willis
> > Sent: Tuesday, October 07, 2008 11:17 PM
> > To: Paul Kyzivat
> > Cc: sip at ietf.org; Christer Holmberg
> > Subject: Re: [Sip] Dual registration without Outbound
> >
> >
> > On Oct 7, 2008, at 3:37 PM, Paul Kyzivat wrote:
> >
> > > I think I am missing something here. I presume that the
> > knowledge of
> > > the UA is limited to:
> > > - to proxy addresses
> > > - an AOR to register
> > >
> > > Presumably the address of the registrar is derived from
> the AOR to
> > > register by removing the user part. So the UA, when registering,
> > > doesn't specify two different registrars. Whether there are
> > two or not
> > > is a function of how the proxy routes the register request.
> > So whether
> > > the two registers for the same contact go to one registrar
> > or two is
> > > unknown to the UA. In some configurations this would give you
> > > redundancy, and in others it would not.
> > >
> > > Then, what causes the UA to register two different
> > contacts? Are the
> > > wlan contact and the 3g contact registered to *different*
> > AORs? If not
> > > I don't see the point. If anything, I would expect that
> 3g and wlan
> > > represent access networks and hence differing proxies,
> not AORs or
> > > registrars.
> > >
> >
> > Some IMS networks have mechanisms for discovering the edge proxy
> > based on the air interface. This, a UA might discover one proxy for
> > its 3g interface, and another for its WLAN interface. In
> other words,
> > one proxy for each Contact.
> >
> > So, that's "proxy" discovery.
> >
> > Registrar discovery is a separate process. With
> config-framework, the
> > UA is configured with a set of proxies with which it may register.
> > Under outbound-015, if there are two or more outbound
> proxies in the
> > configured set, the UA must register through at least two of those
> > proxies. This assumes a singular contact at the UA.
> >
> > Juha has, IIRC, proposed that the UA must register with at
> least two
> > of those proxies for each contact. This, I believe, has some merit.
> > I'm not sure it's a MUST, but it certainly seems a
> reasonable SHOULD.
> >
> > Of course, when the configuration mechanism is different
> and only one
> > proxy is provided per contact, we have a different case.
> >
> > It seems like we are developing two conflicted use cases here
> > -- one for a singular contact with redundant registration
> paths, and
> > another for redundant contacts, each with singular
> registration path.
> >
> > Then there may be yet another case, multiple contacts, each with
> > redundant registration paths.
> >
> > --
> > 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
> >
> _______________________________________________
> 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
>
_______________________________________________
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