When you configure CallManager servers (either Publisher or Subscriber) to be part of the same cluster, they basically don't care where they are located as long as they communicate with each other. So, whether they are in the same room or different continents, they don't care and view the universe the same way. If you want to split dialing for users at each site to be different, you will likely configure identical route patterns that will access different route lists with the different gateways in each. So, assume 10-digit dialing for your users. Site A with have a route pattern of 9.@ (or whatever, maybe your not using route filters). This route patter should refer to a route list that refers to route groups that will have access to gateway only in site A. A new 9.@ will be created for site B which will refer to a route list that will refer to a route group that will contain gateways for site B. Maybe, depending on your situation, you will set up the route groups to refer to their respective remote gateways for backup, but that depends on whether they obey the same dialing rules or not (is longdistance the same for both sites, etc.).
Create separate Calling Search Spaces for each location
Inside the Calling Search space you will have your normal Partitions, but the last one (presumably) will be the above Partition that matches the Calling Search Space location.
Create Route Groups. I create a separate Route Group for each PRI interface.
Create a separate Route List for each location. Add the Route Groups with the actual location first and then the remote.
Add two Route Patterns. Partition and Route List will be the matching location. To keep Caller ID consistent with each location during a failure you can change the Calling Party Transform Mask to match the locations caller ID if they are different. (i.e.. 770645XXXX for a 4 digit extension.) The phone company will probably need to update the screening tables on each circuit for this to be possible.
Now when a call is made, it will route out the local circuit first and then fail over to the remote if the local fails or is full. Caller ID will function correctly out either circuits as well.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...