> 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".)
On the surface, it sounds interesting although I haven't spent the time yet to really disect it. I'll try to do this before end-of-week. _______________________________________________ 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/
