On Mon, 2009-06-15 at 11:35 -0400, Joly, Robert (CAR:9D30) wrote:
> > The domain-per-branch approach was eliminated fairly early in
> > the discussion because DNS configuration complexity and
>
> I'm trying to compare the DNS difficulties associated with this approach
> vs. the ones associated with the ("third") approach proposed later. In
> one case, you need to create one record for each domain and in the other
> case you need to create multiple records for one domain. The way I
> understand this, I would not single out this approach as being
> significantly more complex compared to the 'third' approach from a DNS
> stand-point.
>
> > domain alias implementation in multiple services are already
> > significant problems - building branch routing on them would
> > make things worse.
>
> This is a problem that we should probably solve anyways. Perhaps a
> simple approach would be to substitute a domain alias for the real
> domain when a request enters the system as opposed to making all the
> services domain-alias-aware (just thinking out loud here, sorry).
I probably didn't express all that well. The complexity I was/am
concerned about is really a combination of the DNS and aliasing problems
- the more DNS names you have that can appear in an AOR, the more
aliases you have to worry about, and in a large configuration the
combinations explode.
What I'm thinking/hoping is that we can always use the one SIP domain
for any user AOR - these are the ones that create aliasing problems. We
will still need to create 'branch' subdomains at least in order to
create a preference for using the local server. My belief/hope is that
we can use these subdomains only for addressing services, either in
Route (and Record-Route) headers or in service addresses
([email protected]).
So the phone for a user in the Boston branch of Example Corp would be
configured to register as 'sip:[email protected]', but told to use the
outbound proxy 'sip:boston.example.com'. That branch domain name
(boston.example.com) would be an SRV record that maps first to all
proxies in the Boston office (at equal priority, as in any HA install),
with a lower-priority fallback to some other branch.
> > This left us with adding structure to the user part of the
> > SIP addresses. There were a few things about that approach
> > that really bothered me:
> >
> > * We would relegate 'email style' SIP URI addresses
> > (sip:[email protected]) to a second class status - the only
> > 'real' addresses would be the numeric ones
> > (sip:[email protected]), which "feels" like a step backward, and
> > might create problems for existing deployments that had started out
> > with non-numeric user identities.
> >
> > * The approach has very poor mobility properties: a numeric address
> > is permanently tied to a branch - moving a user from one branch to
> > another means changing their phone number, and registering a mobile
> > user agent at a different branch means that I really route the call
> > back to my 'home' branch. It seems to me that it has bad
> > properties when the network is partitioned, and probably causes
> > other non-optimal routing decisions.
> >
> > * By putting structure into the user part, we abandon (or at least
> > put some limits on) the flexibility we have now to use different
> > number lengths (not all extensions need to be the same size) and
> > other nice qualities that result from the fact that the user part
> > is just a token to be matched.
> >
> > So I've been spending some time thinking about alternatives,
> > and would like to float a 'third way'...
> >
> > In a multi-branch installation, there is only one 'SIP
> > Domain' for the enterprise, managed by a single instance of
> > sipXconfig. Within that domain, there are many servers, each
> > of which is associated with a Branch (the 'central' site is
> > just another Branch that happens to have the global services
> > like sipXconfig in it).
>
> To ensure signaling symmetry for requests and responses, all the
> sipXecs's in the signaling path need to Record-Route the request. The
> Record-Route will have to continue to be done using the IP addresses as
> opposed to using domain names to avoid the first proxy popping off the
> routes for all the sipXecs's thinking that it is its own.
I'm not sure this is always true. A Record-Route added for the purpose
of something stateful like NAT traversal must be an IP address (or,
slightly better for esthetic purposes perhaps a fully qualified host
name), but otherwise using a branch subdomain route should work (we have
an item in the 4.1.0 plan to actually test this...).
> > A User can register at any call router in any Branch, and any
> > other authorization decision can be made in any service in
> > any Branch, because the credentials and permissions databases
> > are uniformly replicated to all servers in all Branches.
>
> In order for call pickup and call park scenarios to work when remote
> workers are involved, all phones must have their outbound proxy set to
> their sipXecs. In that respect, phones will always register with their
> home proxies no matter where they happen to be in the network which
> kinda defeats the purpose of the back-up registrar.
My current working assumption is that Park/Retrieve and Call Pickup are
always branch-local services.
* You cannot pickup a phone that's ringing in another branch. The
pickup code is handled by the pickup server in the branch where
the call is made. (It's possible that this actually works
remotely, but if it's _any_ additional effort to make it work,
then I don't think that we need to commit to it).
* You cannot park a call from one branch and retrieve it in
another. The park orbits are specific to a branch.
I don't think that making either of these 'global' makes much sense -
both rely on some out-of-band indications to work. I don't pickup a call
unless I can hear it ringing. Park/Retrieve assumes that I park it and
then tell someone (by yelling or using the intercom) to retrieve it; if
that someone is in another branch, then park/retrieve must becomes a
very elaborate way to do a consultative transfer.
Remote workers are something of a special case, in that they will always
need to route their calls to _some_ specific externally accessible
proxy. This could be the branch domain, or could even be some other
special external access domain (a pseudo-branch for mobile users,
perhaps). In any event, as I noted above, the proxy that they initially
go through must use a host-specific Record-Route to ensure that they
remain bound to it.
> > One thing that argued against global identities in our
> > earlier discussion was the complexity of global replication
> > of registrations (the flip side of the mobility argument - if
> > I can register anywhere, then my registrations need to be
> > replicated everywhere). I think that there is a way around
> > this, however, that exploits the Home Brach concept to modify
> > registry/redirect:
> >
> > * A new service is introduced: the Backup Registrar. A Backup
> > Registrar is a sipXregistrar instance that is configured with only
> > the registry plugins: it does not do any of the other sources of
> > redirection such as mapping rules, ENUM, or gateway routing - those
> > are done only in a Branch call router. All registrars are
> > configured to synchronize registration data with the Backup
> > registrar (in addition to any HA peers within the Branch).
> >
> > * The redirect service is modified so that in addition to returning
> > Contacts for any registrations it knows about, it also returns a
> > contact at equal priority with other registrations for:
> >
> > [email protected]
> >
> > where 'backup.domain' goes to the Backup Registrar(s). The proxy
> > forks to that like any other Contact, and (as with any other
> > registrar) gets back either a '404 Not Found' or another redirect
> > (302) with more Contacts. This finds any Contacts that have been
> > registered at other Branches. [Note that with no other changes,
> > this will also return the Contacts that are registered at the local
> > branch, but the proxy will filter them out because the are already
> > in the transaction tree. If we find that doesn't work correctly or
> > want to optimize them out, the Contact for backup.domain could be
> > annotated with keys to eliminate those duplicates.]
>
> This is very clever indeed but it also has a lot of moving parts. I
> wonder if we could not have a simpler solution. Given that every system
> in the branch knows the 'home branch' of every user, we could postulate
> that the registrations of a user will always be handled by its home
> registrar. More specifically, when a user sends a REGISTER to a branch
> system that it not its home, it could forward that user's REGISTER
> request to the user's home registrar using user->home mapping it already
> has instead of processing it. This would focalize a user's
> registrations to the home registrar.
> Now, when a branch system receives an INVITE for a user that is homed at
> another system, its RegDB redirect plug-in will not find any match in
> its registration DB. When that occurs, it checks if the user is homed
> somewhere else using available user->home mapping info and adds a
> Contact to the user's home system. The home system will receive the
> INVITE and process it accordingly.
>
> If it actually works, this proposal has the advantage of keeping things
> relatively simple, does not require the addition of a new component and
> new server role and does not have the backup-proxy as a single point of
> contact/failure.
But that wouldn't be highly available - if my branch is down or
unreachable, my phone can't register (and thus can't get calls)
anywhere.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
