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
