The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document explains how Geolocations, Geolocation Filters, and Logical Partitioning can be used in countries, such as India, who need to separate their Off-net calls from their On-net calls. The Class of Service provided by Calling Search Spaces (CSSs) and Partitions might not provide the level of granularity that is required in order to comply with certain laws and regulations. You might also find that these same elements are used in Extension Mobility Cross Cluster (EMCC) configurations. Refer to the Cisco Unified Communications Manager Features and Services Guide for Release 7.1(2), which explains how to filter to a more specific location. The geographical components are not discussed further in this document. Rather, the focus of this document is to review how it all works together logistically.
There are no specific requirements for this document.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Refer to Cisco Technical Tips Conventions for information on document conventions.
These major elements can be found on the Cisco Unified Communications Manager (CUCM) (CallManager) CCMAdmin page:
Under CCMAdmin, go to Enterprise Parameters > Logical Partitioning Configuration. There are four parameters that can affect Geolocations and Logical Partitioning. Be aware that:
If you make configuration changes and cannot figure out why it does not function as expected, examine the Geolocation(s) assigned directly to your endpoints, such as phone, as well as your trunks and gateways, such as SIP Trunk. If there is no Geolocation directly assigned to a phone, trunk, or gateway, then examine the Geolocation and Geolocation Filter assigned to the Device Pool(s), respectively. If both are blank, examine the Default Policy listed among the aforementioned Enterprise Parameters.
Now that you know the details assigned to the phone (an Interior device) and a trunk or gateway (a Border device), you can match the Logical Partition Policies. Go to Call Routing > Logical Partition Policy Configuration. Knowledge and comprehension of Policies can be a challenge. One of the goals of this document is to provide examples that are helpful and comprehensive.
You configure two Policies named Bangalore and Chennai. Understand that when you pull up the Logical Partitioning Policy Configuration page, it has a name at the top that is always linked to the first of the two Device Types you selected. When you configure the Bangalore Logical Partitioning Policy (Geolocation Policy), then the Allow/Deny relationship always begins with Bangalore Interior or Bangalore Border.
With these two policies, the possible permutations on the Bangalore Policy page include:
With these two policies, there are also eight possible permutations on the Chennai Policy page, which include:
Note: There is no need to configure so many policy relationships for various reasons. The relationship logic does not examine direction. Therefore, Bangalore Interior to Chennai Border is the same as Chennai Border to Bangalore Interior. Try to avoid configurations that conflict with each other.
Q: What happens if there are conflicts or policies that overlap?
A: There is some logic, but it can be difficult to track. The logic is related to the last policy that was added, not a modified policy, but a newly added policy.
If a policy that contained the value Allow is then later changed to Deny, then it remains Deny. The opposite is also true. A policy previously set to Deny, later changed to Allow is an Allow. The Cisco Unified Reporting > Geolocation Policy Report can help you identify policies that overlap.
Q: What if Bangalore Interior to Chennai Border is configured to Allow while Chennai Border to Bangalore Interior is configured to be Deny?
A: If the Chennai Border to Bangalore Interior is the last one added, its policy takes precedence.
Note: Policies only affect Interior-to-Border, Border-to-Interior, and Border-to-Border relationships, not Interior-to-Interior relationships.
With this additional information in mind, the sample policies in this document can be drastically reduced from a combined sixteen entries to seven entries. Remember, Interior-to-Interior is not affected. The Interior-to-Interior and Overlap policies are shown with strikethrough, and therefore, would no longer appear in the list.
The Bangalore Policy page now includes:
The Chennai Policy page now includes:
An IP Phone with a Chennai Geolocation that matches a Chennai Policy is a Chennai Interior device. A SIP trunk with a Chennai Geolocation that matches a Chennai Policy is a Chennai Border device. There is no need to specifically assign the Device-Type. CUCM automatically categorizes trunks, gateways, and phones. If you want the Chennai Interior device (phone) to be able to call out a Chennai Border device (SIP trunk) without the call being rejected, for example, the call receives a fast busy signal, then you must ensure the Chennai Interior to Chennai Border policy is set to Allow, without any policy overlap configured later.
Note: Changes to Device Pools should require that the Device Pools are reset in order for the change to be committed. As this is likely to impact many devices, changes should be configured after hours.
Note: In the CallManager SDI (ccm.txt) traces, you might find that a call can be rejected because of Logical Partitioning (LP) without a Digit Analysis (DA) performed. Here is an example: SIP Invite, Trying, 503 Service Unavailable with no DA in between.
Here is an example of a full rejection message:
09/18/2012 21:53:48.379 CCM|Cdcc::CcRejInd: ccRejInd.c.cv = -1493172161|
CV=-1493172161 in CcRejInd refers to Logical Partitioning denial as per this
junked Defect CSCsz91044
09/18/2012 21:53:48.380 CCM|//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP
message to 10.50.15.127 on port 50380 index 90345
SIP/2.0 503 Service Unavailable
This diagram provides an example of Geolocation and Logical Partitioning.
Figure 1: Network Diagram
This diagram shows the desired call flow, which is likely because of government regulations to restrict TEHO (Tail-End-Hop-Off) and Toll-Bypass:
This section shows the steps taken in order to setup and configure the Geolocations and Logical Partitions in CUCM.
Step 1: Configure these settings within the Enterprise Service Parameters. Be aware whether you set the Logical Partitioning Default Policy to Deny or Allow. This is important. It is set to Deny for this configuration example.
Figure 2: CUCM Logical Partitioning Configuration
Step 2: Go to the Geolocation Filter Configuration and specify a single filter for this specific configuration. You can specify more if your configuration becomes very advanced. In this case, specify that it match only on Country.
Figure 3: CUCM Geolocation Filter Configuration
Step 3: Go to the Geolocation Configuration and setup the certain specified locations that it should prefer to filter against. This is very simple and does not have to be configured any more than for what you set your Geolocation Filter, but this example does show some additional configurations.
Figure 4: CUCM List of Geolocations
Figure 5: Geolocation Configuration
Figure 6: Geolocation Configuration Page 2
Step 4: Go to the Device Pool Configuration and find the Geolocation Configuration parameters. Set this in the location that the phone is physically located.
Figure 7: Device Pool Configuration
Step 5: Go to the Device Configuration page for the phone and select the location that the phone is located.
Figure 8: Phone Configuration
Step 6: Go to the Device Configuration page for the PRI interfaces and configure them as individual units and as if they are the same.
Figure 9: PRI for India
Figure 10: PRI for US
Step 7: This step is the more difficult part in the configuration of the Logical Partition Policies.
Note: You need two policies.
Figure: 11: Logical Partitioning Policy List
Figure 12: India Policy
Figure 13: India Policy Continued
Figure 14: US Policy
Figure 15: US Policy Continued
This section explains the meaning of Border and Interior and how to know which device is Border verses Interior.
The terminology used in order to categorize the CUCM devices is based on their function.
Typical Border devices include:
Typical Interior devices include:
This source of Border and Interior is fixed, based on CUCM device, and is not configurable in CUCM Release 7.1.
The entire configuration example in this document was completed with the Enterprise Parameter set to a Deny state. See Figure 2. In some circumstances, you might want to modify this value to Allow and then setup everything that you want to Deny because it is more difficult to do it as this configuration is set up.
For this setup, this is all you need to configure: