This is another proposal for the multi-branch architecture.  The major
difference from previous proposals is that the "Backup Router" has been
turned into a proxy/router pair.  This change allows this "auxiliary"
pair to function effectively as an HA partner of every branch's
proxy/router pair(s), allowing the system to provide redundancy via SRV
processing rather than via additional Contacts generated in 302
responses.  This removes much of the extra message traffic and allows
managing the system more like simple sipXecs installations.

The "central branch" has a sipXconfig which manages all the sipXecs
components in the system.

Each branch (including the central branch, which is much like any other
branch) is provided with a SIP subdomain.  E.g., branch1.xxx,
branch2.xxx.

Each branch has one or more proxy/router pairs on a series of hosts.
E.g., host1-1.branch1.xxx, host1-2.branch1.xxx, host1-3.branch1.xxx,
host 2-1.branch2.xxx.  These hosts may be low-powered, as they will
handle only traffic to/from phones/services for which this is the home
branch.  They will be configured to consider their branch's SIP
subdomain as their domain, with the main SIP domain as an alias.  They
are configured with aliases to route every SIP user for which they are
not the home branch to the home branch of the user.

There are one or more "auxiliary" proxy/router pairs on a series of
hosts.  E.g., host1.aux.xxx, host2.aux.xxx.  These hosts are
high-powered, since they will replicate all registrations and may handle
traffic for users with any home branch.  They are *not* configured with
aliases for SIP users.

(Only SRV records internal to the enterprise network are considered
here.)

For each branch, its proxy/router pairs, and all auxiliary proxy/router
pairs, are configured as SRV targets for the branch's subdomain.  The
auxiliary pairs are less preferred than the branch pairs.

The main SIP domain is provided with SRV records that specify one or
more proxy/router pairs.  These are not normally used for routing, since
*every* UA (phone and service) is configured with its home branch
subdomain as its outbound proxy.

Each user is assigned a "home branch".  Any UA appearance for that user
is configured with its home branch subdomain as its outbound proxy.
(UA's that may be used outside the enterprise network are considered
later.)

Registrar-based services (user forwarding, voicemail processing) for a
user are configured for the user's home branch's registrar(s), but no
others.  (Or, if the auxiliary hosts have sufficient power, they may be
configured with these services as well.)

Services are partitioned among branches.  Services which are specific
for a user (e.g., BLF subscription server) are allocated to a service
process on the host(s) of the user's home branch.  Other services (e.g.,
paging group processing, park orbits) are allocated to a service process
on host(s) chosen for efficiency/reliability -- usually the host(s) of
the home branch of the majority of the service's users or targets.

In regard to externally-visible SIP domains and their SRV records:

The enterprise domain has external SRV records for the public addresses
of the proxy/registrar(s) of the "central branch".  The central branch
provides services seen by outside callers (e.g., the main
autoattendant).

Other branches may have external SRV records for the branch SIP
subdomain.  These SRV records target the public addresses of the
proxy/registrar(s) of the branch.  (Note that these public addresses may
be just additional listening ports on the enterprise gateway, forwarded
to the appropriate hosts.)

Any user appearance on a UA that is used outside the enterprise network
must have a home branch that has external SRV records.  (This may
restrict the set of branches available as home branches for "remote
workers".)

Dale


_______________________________________________
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/

Reply via email to