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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of DRAGE, Keith (Keith) > Sent: Tuesday, October 07, 2008 16:45 > To: Dean Willis; Paul Kyzivat > Cc: [email protected]; 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of > > Dean Willis > > Sent: Tuesday, October 07, 2008 11:17 PM > > To: Paul Kyzivat > > Cc: [email protected]; 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 > > [EMAIL PROTECTED] for questions on current sip Use > > [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
