{"id":844,"date":"2009-10-12T19:44:27","date_gmt":"2009-10-13T01:44:27","guid":{"rendered":"http:\/\/gregsowell.com\/?p=844"},"modified":"2009-10-12T19:44:27","modified_gmt":"2009-10-13T01:44:27","slug":"cisco-%e2%80%93-multisite-single-cluster-call-manager-4-1-design","status":"publish","type":"post","link":"https:\/\/gregsowell.com\/?p=844","title":{"rendered":"Cisco \u2013 Multisite Single Cluster Call Manager 4.1 Design"},"content":{"rendered":"\n\n\n
On the heels of my CIPT test (call manager test), I\u2019ve completely redesigned from the ground up our call manager configuration. I\u2019ve changed the way the system works pretty much completely\u2026hehe. I spent a good bit of time putting together the Visio, so I figured I would share it with you guys, and also explain it in laymen\u2019s terms.Here\u2019s the PDF version that you can download(
\n\n\tCallManager Design\t(1284 downloads\t)\n<\/a>\n<\/div>\n), or simply take a peek at the below jpg.
\nNames and places have been changed to protect the innocent.<\/p>\n

\"callmanagerDesign\"<\/p>\n

As you can see, it looks somewhat confusing at first\u2026that\u2019s what I call job security! Actually, if you familiarize yourself with the different components, it will actually make sense.<\/p>\n

What we have are two separate sites, S1 and S2. This is a single cluster with the publisher at S1. Since callmanager 4 runs on windows using SQL 2000, you are limited to 8 subscribers. The publisher has a writable database and the subscribers replicate that database to themselves. The subscribers maintain a READ-ONLY copy of the database. Since we are limited to only 8 subscribers, this limits the number of servers we can have in a single cluster. There is also a restriction of a round trip time(the time it takes for a packet to hit a remote callmanager and return) of 40ms. Since our sites are only across town, we will be well within this limitation. We are going to have L2 transit between the sites, which also helps the speed <\/img-smiley><\/img-smiley><\/img-smiley><\/img-smiley>.<\/p>\n

So, we have our cluster and within this cluster, we have two callmanager groups. A callmanager group is a prioritized list of callmanager servers within your cluster. This will list the callmanagers your phone will attempt to register with. We have two, one for site 1 and one for site 2. The idea being, site 2 will home off of callmanager 2 first and failover to callman1, and vice-versa; site 1 will home off of callman1 and failover to callman2.
\nCallmanager Group is designated as :<\/p>\n

\"Callmanager<\/p>\n

We then create the Device Pools. These allow you to apply like attributes to groups of phones. We are creating two so that we can specify a handful of settings along with specifying the callman group. We are creating two, one for S1 and one for S2. There will be a handful of phones that deviate from these settings, but device level settings override the device pool settings.<\/p>\n

\"
Device Pool<\/figcaption><\/figure>\n

We create partitions next. Partitions are a method to segregate route patterns, phones and translation patterns. We have a set of SQL queries that bill based on partition, so we have each group in a partition. I also put my route patterns in partitions.\n<\/p-caption-text>\n<\/p-caption-text>\n<\/p-caption-text>\n<\/p-caption-text>\n

\"partitions\"
partitions<\/figcaption><\/figure>\n

Our next step is to create some gateways in our system. Gateways are conduits to the PSTN, be it a digital PRI or a good old fashioned FXO pots line. We also add each gateway to a route group. A route group is a prioritized list of gateways. One generally adds gateways that are geographically close into a single route group. I want my route groups as flexible as possible, so I add a single gateway her route group. Another quark about route groups is that you can only use a gateway once. This means you can only assign a single gateway to a single route group OR you can only point a route patter to a gateway once. You can\u2019t have a route patter point directly to a gateway and add that same gateway to a route group. The best course of action is to add each gateway to a route group for later use in a route list.<\/p>\n

\"Gateway
Gateway and Route Group<\/figcaption><\/figure>\n<\/p-caption-text>\n<\/p-caption-text>\n<\/p-caption-text>\n<\/p-caption-text>After you create your route groups, you create route lists. Route lists are prioritized lists of route groups. You can use route groups in as many route lists as you want! This is the workaround for the whole\u2026use route groups only once problem. For each site, for standard PSTN, the local site\u2019s PRI route list uses the local PRI first, then uses the remote PRI as the secondary. This way, if the local PRI is full or down, it will failover. Also, we create 911 route lists for whatever building you are in. It will use the local pots 911 first, then alternately use the next available.<\/p>\n
\"Route
Route Lists<\/figcaption><\/figure>\n<\/p-caption-text>\n<\/p-caption-text>\n<\/p-caption-text>\n<\/p-caption-text>Might as well go ahead and create our calling search spaces. CSSs are what you assign to devices that manipulate calls, be it a phone, gateway or translation pattern. In the CSS, you specify a prioritized list of partitions the CSS has access to. In our CSS, we specify first the 911 partition they are to use first, then we specify the standard PRI partition, and afterwards, we list the standard customer partitions. We have special CSSs for the door phones. They are allowed to dial 911 and internal partitions, nothing else.<\/p>\n
\"calling
calling search space<\/figcaption><\/figure>\n<\/p-caption-text>\n<\/p-caption-text>\n<\/p-caption-text>\n<\/p-caption-text>We have translation patterns defined also. These guys basically do digit manipulation. TPs have both partitions and CSSs. Once they do their digit manipulation, they spit the new digits back out into the specified CSS. We use TPs to take in the 10 digits from the telco and convert them to their internal 4 digit extension. I have a special partition specifically for the inbound PRI connections in there I have some TPs to adjust the digits. I also use two TPs for outgoing calls, just in case a users tries to use the full 10 digit # for a user on our system, it will adjust their digits and not exit the PRIs.<\/p>\n
\"Translation
Translation Pattern<\/figcaption><\/figure>\n<\/p-caption-text>\n<\/p-caption-text>\n<\/p-caption-text>\n<\/p-caption-text>Pretty much the last element is the route pattern. Route patterns are must like routes in your router. When you dial digits, the callman first tries to deliver them locally to an extension, if that isn\u2019t possible, it checks the route patterns to see what to do with the call. I have my route patterns in a special partition, so that I can assign them to specific CSSs. This gives me a good bit of control over who gets access to everything.<\/p>\n

So, with this blue print, you can build a scalable redundant callmanager. There are more nuts and bolts that are necessary, setting up your resources, voicemail ports, users, blah blah blah\u2026;) Adding users is a snap using the bulk administrative tool. There is another cool tool to use with adding new users called JTAPS. It basically lets you dial a number with an auto registered phone, and it will pull the proper config. SOOOOoooooOOoo, if you guys found this interesting or useful in the least, let me know in the comments section.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"excerpt":{"rendered":"

On the heels of my CIPT test (call manager test), I\u2019ve completely redesigned from the ground up our call manager configuration. I\u2019ve changed the\u2026<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22,16,19],"tags":[],"class_list":["post-844","post","type-post","status-publish","format-standard","hentry","category-callmanager","category-cisco","category-voip"],"_links":{"self":[{"href":"https:\/\/gregsowell.com\/index.php?rest_route=\/wp\/v2\/posts\/844","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/gregsowell.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/gregsowell.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/gregsowell.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/gregsowell.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=844"}],"version-history":[{"count":2,"href":"https:\/\/gregsowell.com\/index.php?rest_route=\/wp\/v2\/posts\/844\/revisions"}],"predecessor-version":[{"id":854,"href":"https:\/\/gregsowell.com\/index.php?rest_route=\/wp\/v2\/posts\/844\/revisions\/854"}],"wp:attachment":[{"href":"https:\/\/gregsowell.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=844"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/gregsowell.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=844"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/gregsowell.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=844"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}