Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Call coverage is part of the dial plan. It ensures that all incoming calls are answered. The
following call-coverage features are typically implemented for individuals:
■ Call forwarding: If the called phone does not answer the call, the call should be
forwarded to another phone or voice mail.
■ Shared lines: A shared line is a directory number (DN) that is assigned to more than
one device, allowing the call to be accepted on more than one phone.
■ Call pickup: Call pickup allows a call that is ringing on a phone to be picked up at
another phone.
In addition, there is a more complex and highly flexible feature providing call coverage
called call hunting. Call hunting is based on a pilot number, which if directly called or used
as a call-forward target allows hunting through multiple line groups. Several hunting
algorithms exist, ranging from a round-robin selection of group members to a broadcast
option that rings all members of a line group.
There are three primary types of call forwarding:
■ Call Forward All (CFA): The CFA feature forwards all calls unconditionally. CFA can
be configured by the phone user from either the user web page (covered in Chapter 16,
“User Features”) or at the phone itself. If CFA is configured, the call is forwarded
immediately without ringing the originally dialed phone. The CUCM administrator
can also configure the CFA target.
■ Call Forward No Answer (CFNA): CFNA forwards calls if the call is not answered
within a specified amount of time. CFNA can be configured by the administrator in
CUCM Administration or by the phone user from the user web page.
■ Call Forward Busy (CFB): CFB forwards calls that are received while the IP phone
is in use with another call. CFB can be configured by the administrator in CUCM
Administration or by the phone user from the user web page.
The administrator can configure separate calling search spaces (CSS) for each call-forward
type. For CFNA and CFB, different CSSs can be set for internal (on-net) calls and for external
(off-net) calls. For CFA, a primary and a secondary CFA can be configured. These two
get concatenated like a device and line CSS. For all call-forward scenarios, the corresponding
call-forward CSSs are used; line and device CSSs are ignored. Therefore, if the system
uses partitions, it is recommended to always set call-forward CSSs because otherwise
forward operations are likely to fail. Figure 14-1 illustrates call forwarding.
Call Coverage 341
Figure 14-1 Call Forwarding
A shared line is implemented by assigning the same DN to multiple phones. If the number
is called, all phones that are configured with this shared line number ring. The first user who
accepts the call is connected to the caller, and all other phones stop ringing. Figure 14-2
illustrates shared lines.
Figure 14-2 Shared Lines
CUCM allows multiple lines to be grouped into call-pickup groups. Each pickup group is
identified by a unique pickup group number. A phone line can be assigned to only one
pickup group.
QuickTime™ and a
Graphics decompressor
are needed to see this picture. IP IP IP
User Dials 2000
2000
2001
CFA (All)
CFNA
(No Answer)
CFB (Busy)
91551234
Voice Mail
U
QuickTime™ and a
Graphics decompressor
are needed to see this picture. IP
User Dials 2000
2000
2000
IP
IP
IP
2000
All 3 Phones Will Ring
1
2
342 Chapter 14: Call Coverage
If a phone rings but there is nobody at the ringing phone to answer the call, another user
can pick up the call by using the Pickup softkey if the ringing phone is in the same pickup
group.
In the same situation, if the phone of the user who wants to pick up the call is not a member
of the pickup group of the ringing phone, the user can use the group pickup feature
(GPickup softkey) to pick up the call. When a user invokes the group pickup feature by
pressing the corresponding softkey, the user has to enter the pickup group number of the
ringing phone to be able to pick up the call.
Wednesday, December 15, 2010
Private Line Automatic Ringdown CCSP Course Training in Delhi Gurgaon India
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Private line automatic ringdown (PLAR) is used when a phone should dial a predefined
number as soon as the phone goes off-hook. PLAR is typically used with button-free
security phones in elevators and stairways.
Implement PLAR in CUCM by following these steps:
Step 1 Configure a translation pattern where the pattern is empty (null string
pattern), and put it into a partition.
Step 2 Configure the number to be dialed by the PLAR-enabled phone in the
called-party transformation mask of the translation pattern.
Step 3 Configure the first line of the phone that should use PLAR with a CSS
that includes only the partition that was applied to the translation pattern.
Step 4 Make sure that the CSS of the translation pattern has access to the
transformed number. The translation pattern CSS is used when making
the call-routing decision for the translated number.
When the phone goes off-hook, the off-hook event triggers call processing (digit analysis)
on CUCM, where the null dialed string matches the translation pattern and is translated to
the PLAR number. The call is then extended toward the PLAR destination. CUCM
performs digit analysis as each digit is received from the phone, starting with the off-hook
event. Different call-processing protocols (SIP, Skinny Client Control Protocol [SCCP],
H.323) and calling methods send their dialed digits in different manners (enbloc or digit by
digit), and thus the way in which a call is routed with an overlapping dial plan. This
information is covered in more detail in Chapter 7, “Endpoints.”
334 Chapter 13: Calling Privileges
In Figure 13-27, a null-string translation pattern is created and put into partition
PLAR1234. The called-party transformation mask is 1234. The translation pattern has a
CSS assigned that includes partition Phones (the partition of destination 1234).
Figure 13-27 PLAR Example
Phone 1 is configured with a CSS that contains the PLAR1234 partition (the partition of the
translation pattern).
Two phones exist with DN 1234: Phone 2 is in partition Phones, and Phone 3 is in partition
Hidden.
When Phone 1 goes off-hook, the null-string pattern is matched, and the translation pattern
transforms the dialed null-string to 1234 and sends a call-routing request to CUCM. This
request uses the CSS of the translation pattern (Phones) and therefore finds only a single
match (Phone 2). The call is extended to Phone 2.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Private line automatic ringdown (PLAR) is used when a phone should dial a predefined
number as soon as the phone goes off-hook. PLAR is typically used with button-free
security phones in elevators and stairways.
Implement PLAR in CUCM by following these steps:
Step 1 Configure a translation pattern where the pattern is empty (null string
pattern), and put it into a partition.
Step 2 Configure the number to be dialed by the PLAR-enabled phone in the
called-party transformation mask of the translation pattern.
Step 3 Configure the first line of the phone that should use PLAR with a CSS
that includes only the partition that was applied to the translation pattern.
Step 4 Make sure that the CSS of the translation pattern has access to the
transformed number. The translation pattern CSS is used when making
the call-routing decision for the translated number.
When the phone goes off-hook, the off-hook event triggers call processing (digit analysis)
on CUCM, where the null dialed string matches the translation pattern and is translated to
the PLAR number. The call is then extended toward the PLAR destination. CUCM
performs digit analysis as each digit is received from the phone, starting with the off-hook
event. Different call-processing protocols (SIP, Skinny Client Control Protocol [SCCP],
H.323) and calling methods send their dialed digits in different manners (enbloc or digit by
digit), and thus the way in which a call is routed with an overlapping dial plan. This
information is covered in more detail in Chapter 7, “Endpoints.”
334 Chapter 13: Calling Privileges
In Figure 13-27, a null-string translation pattern is created and put into partition
PLAR1234. The called-party transformation mask is 1234. The translation pattern has a
CSS assigned that includes partition Phones (the partition of destination 1234).
Figure 13-27 PLAR Example
Phone 1 is configured with a CSS that contains the PLAR1234 partition (the partition of the
translation pattern).
Two phones exist with DN 1234: Phone 2 is in partition Phones, and Phone 3 is in partition
Hidden.
When Phone 1 goes off-hook, the null-string pattern is matched, and the translation pattern
transforms the dialed null-string to 1234 and sends a call-routing request to CUCM. This
request uses the CSS of the translation pattern (Phones) and therefore finds only a single
match (Phone 2). The call is extended to Phone 2.
911 and Vanity Numbers CCNP CourseTraining in Delhi Gurgaon India
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
911 is a single number to call for medical, fire, and police emergencies in the United States
and Canada. Calls to 911 are routed to a public safety answering point (PSAP). The PSAP
is the first-tier triage call center for emergency calls. PSAP operators dispatch medical, fire,
and police resources as necessary.
Emergency calls have to be sent to a local PSAP through the local gateway. In a multisite
deployment, all emergency calls are placed to the same number, but they need to be routed
differently depending on the calling phone’s physical location.
Vanity numbers provide access to a certain local service within an enterprise. Users should
be able to dial the same number to access the appropriate locally provided service no matter
where they are located. Some companies, for example, use the DTMF keypad word HELP
(4357) to dial the IT help desk.
An example of vanity services is a number that connects users to local IT support. Vanity
numbers are not limited to internal services; they could also be configured to reach external
local services (taxi, travel agencies, and so forth) by using abbreviated dialing within the
corporate dial plan.
A vanity number can be configured as a DN, a route pattern, a hunt pilot, or a translation
pattern.
NOTE Emergency calling in the United States and Canada includes many additional
aspects that are not covered in this book.
332 Chapter 13: Calling Privileges
Implementing vanity numbers is similar to configuring selective PSTN outbreak (always
using the local gateway for PSTN or emergency calls) and consists of the following steps:
Step 1 Create a site-specific partition per site.
Step 2 For each service, configure the same vanity number (route pattern, DN,
hunt pilot, or translation pattern) once per site and put it into the sitespecific
partition created earlier.
Step 3 Put the appropriate site-specific partition into the CSS of the phones
located at a site.
Figure 13-26 shows a vanity number for IT support that is configured as 7999. Both the
New York and San Jose sites will use this same IT support vanity number. The DN of 7999
located in San Jose is put into the San Jose partition. The same DN is configured in the New
York partition. Phones located in New York have partition New York listed first in their
CSS; phones located in San Jose have partition San Jose listed first in their CSS.
If a San Jose user dials 7999, the call is routed to the IT help desk in San Jose because the
New York DN of 7999 is not accessible by the San Jose phone. The San Jose CSS does not
include the New York partition. The same call-routing theory applies to users in New York.
Calls placed to 7999 in New York are routed to the local New York IT help desk.
Figure 13-26 Vanity Number Example
If the desired services are provided externally, a translation pattern is configured to translate
the appropriate vanity number. Instead of memorizing a long number for the travel agency
(which may change over time), users can be given a phone number that aligns to the
corporate dial plan. The translation pattern will match on the dialed digits of 7998 and
NOTE If abbreviated dialing is used to reach external local services (such as a local
travel agency by dialing 7998), a translation pattern is used for the vanity number.
IP IP
San Jose Phone IT Help Desk
San Jose
CSS:
San Jose
Standard
DN: 7999
Partition:
San Jose
IP IP
New York Phone IT Help Desk
New York
CSS:
New York
Standard
DN: 7999
Partition:
New York
Private Line Automatic Ringdown 333
manipulate the digits to 1 914 555-1212 by using a called-party transformation mask. Over
time, if there are changes to the external number, users will not need to know the new phone
number. The CUCM administrator can reconfigure the called-party transformation mask.
By creating the vanity number once per site and putting it into a site-specific partition, you
can ensure that users always match the vanity number translation pattern for their respective
site. This is achieved by including the site-specific partition in the phone CSS.
Figure 13-26 would use two translation patterns to achieve this objective. Each translation
pattern would be placed in a site-specific partition. Configure the San Jose translation
pattern with the PSTN number of the San Jose travel agency; configure the New York
translation pattern with the PSTN number of the New York travel agency. Make sure that
the translation patterns have CSSs assigned that allow them to use the local PSTN gateway
for routing the calls out to the translated PSTN numbers.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
911 is a single number to call for medical, fire, and police emergencies in the United States
and Canada. Calls to 911 are routed to a public safety answering point (PSAP). The PSAP
is the first-tier triage call center for emergency calls. PSAP operators dispatch medical, fire,
and police resources as necessary.
Emergency calls have to be sent to a local PSAP through the local gateway. In a multisite
deployment, all emergency calls are placed to the same number, but they need to be routed
differently depending on the calling phone’s physical location.
Vanity numbers provide access to a certain local service within an enterprise. Users should
be able to dial the same number to access the appropriate locally provided service no matter
where they are located. Some companies, for example, use the DTMF keypad word HELP
(4357) to dial the IT help desk.
An example of vanity services is a number that connects users to local IT support. Vanity
numbers are not limited to internal services; they could also be configured to reach external
local services (taxi, travel agencies, and so forth) by using abbreviated dialing within the
corporate dial plan.
A vanity number can be configured as a DN, a route pattern, a hunt pilot, or a translation
pattern.
NOTE Emergency calling in the United States and Canada includes many additional
aspects that are not covered in this book.
332 Chapter 13: Calling Privileges
Implementing vanity numbers is similar to configuring selective PSTN outbreak (always
using the local gateway for PSTN or emergency calls) and consists of the following steps:
Step 1 Create a site-specific partition per site.
Step 2 For each service, configure the same vanity number (route pattern, DN,
hunt pilot, or translation pattern) once per site and put it into the sitespecific
partition created earlier.
Step 3 Put the appropriate site-specific partition into the CSS of the phones
located at a site.
Figure 13-26 shows a vanity number for IT support that is configured as 7999. Both the
New York and San Jose sites will use this same IT support vanity number. The DN of 7999
located in San Jose is put into the San Jose partition. The same DN is configured in the New
York partition. Phones located in New York have partition New York listed first in their
CSS; phones located in San Jose have partition San Jose listed first in their CSS.
If a San Jose user dials 7999, the call is routed to the IT help desk in San Jose because the
New York DN of 7999 is not accessible by the San Jose phone. The San Jose CSS does not
include the New York partition. The same call-routing theory applies to users in New York.
Calls placed to 7999 in New York are routed to the local New York IT help desk.
Figure 13-26 Vanity Number Example
If the desired services are provided externally, a translation pattern is configured to translate
the appropriate vanity number. Instead of memorizing a long number for the travel agency
(which may change over time), users can be given a phone number that aligns to the
corporate dial plan. The translation pattern will match on the dialed digits of 7998 and
NOTE If abbreviated dialing is used to reach external local services (such as a local
travel agency by dialing 7998), a translation pattern is used for the vanity number.
IP IP
San Jose Phone IT Help Desk
San Jose
CSS:
San Jose
Standard
DN: 7999
Partition:
San Jose
IP IP
New York Phone IT Help Desk
New York
CSS:
New York
Standard
DN: 7999
Partition:
New York
Private Line Automatic Ringdown 333
manipulate the digits to 1 914 555-1212 by using a called-party transformation mask. Over
time, if there are changes to the external number, users will not need to know the new phone
number. The CUCM administrator can reconfigure the called-party transformation mask.
By creating the vanity number once per site and putting it into a site-specific partition, you
can ensure that users always match the vanity number translation pattern for their respective
site. This is achieved by including the site-specific partition in the phone CSS.
Figure 13-26 would use two translation patterns to achieve this objective. Each translation
pattern would be placed in a site-specific partition. Configure the San Jose translation
pattern with the PSTN number of the San Jose travel agency; configure the New York
translation pattern with the PSTN number of the New York travel agency. Make sure that
the translation patterns have CSSs assigned that allow them to use the local PSTN gateway
for routing the calls out to the translated PSTN numbers.
Class of Service Approaches CCNA Course Training in Delhi Gurgaon India
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
CoS applications in CUCM can be summarized as two distinctly separate implementations:
the traditional approach and the line-device approach. This section investigates the
difference between these two approaches and explains the advantages of using the linedevice
approach.
Figure 13-22 shows a simple single-site CoS deployment with four distinct classes of
service. Four partitions and four CSSs have been created. The route patterns for each call
type have been put into their respective partitions. The CSSs will be assigned to various
devices in the infrastructure. This is as simple as CoS gets.
Figure 13-22 Single Site with Four CoS Definitions
If the organization chooses to use the centralized call-processing model and an additional
site is added to the cluster, four more site-specific partitions will need to be created, and
four additional CSSs. In addition, the PSTN route patterns will need to be duplicated
and put into their site-specific partitions. The challenge in this scenario is that partitions and
CSSs need to provide two functions: 1) select the local PSTN gateway, and 2) control who
is allowed to dial what number.
Figure 13-23 illustrates a summary of the partitions, CSSs, and route patterns necessary to
achieve this solution. The solution includes four partitions per site: emergency partition,
local partition, national partition, and international partition. The number of required
V
IP
Local_css
LD_css
Intl_css
Internal_css
Calling Search
Spaces Partitions
Route
Lists
Route
Groups Devices
PSTN
Route
Patterns
Calling
Search
Space
Assigned
to Device
Based on
Class of
Service
All IP Phones
9.011!
9.011!#
9.[2-9]XXXXXX
[2-9]XX XXX
9.1[2-9]XX
911
9.911
Internal_pt
Local_pt
LD_pt
Intl_pt
PSTN
RG
PSTN
RL
328 Chapter 13: Calling Privileges
partitions is calculated by multiplying the number of required classes of service by the
number of sites. The example includes four classes of service per site. Implementations
may involve considerably more partitions and CSSs per site.
Figure 13-23 Centralized Call Processing with Four CoS Definitions
The traditional approach, outlined in the preceding section, can result in a large number
of partitions and CSSs when applied to large multisite deployments with centralized call
processing. This configuration is required because the device CSS is used to determine both
the path selection (which PSTN gateway to use for external calls) and the CoS.
It is possible to significantly decrease the total number of partitions and CSSs needed by
dividing the functions of site-specific routing and CoS between the line CSS and the device
CSS. The use of both a line- and a device-based CSS is called the line-device approach.
NOTE The traditional model of designing CoS in CUCM does not scale to large
deployments involving 25 or more sites.
V
V
V
V
Calling Search
Spaces Partitions Route Lists/Route Groups
OnCluster
IP Phones
Shared
Site1Emergency
Site1Local
Site1National 1RL 1RG
NRL NRG
Site1International
9.11
9.[2-9]XXXXXX
9.1 [2-9]XX [2-9]XX XXXX
9.911
9.011!
9.011!#
SiteNEmergency
SiteNLocal
SiteNNational
SiteNInternational
9.11
9.[2-9]XXXXXX
9.1 [2-9]XX [2-9]XX XXXX
9.911
9.011!
9.011!#
VM Ports, MeetMe...
Device Calling Search
Spaces (4 for Site 1)
Device Calling Search
Spaces (4 for Site N)
Site 1
Gateways
Site N
Gateways
Site1Internal
Site1Local
Site1National
Site1International
•••
•••
SiteNInternal
SiteNLocal
SiteNNational
SiteNInternational
Class of Service Approaches 329
In the line-device approach, CUCM performs a concatenation of both the line and device
CSSs for each IP phone. Follow these rules to implement the line-device approach:
■ Use the device CSS to provide site-specific call-routing information (which gateway to
select for PSTN calls). The device CSS will be an unrestricted CSS. This CSS is not
used to enforce CoS.
■ Use the line CSS to block the route patterns that are not allowed by CoS (independent
of the used PSTN gateway). This can be done effectively with translation patterns with
a block action that are put into partitions that only the line CSSs have access to.
■ To implement the line device CSS approach, a per-site unrestricted CSS will be configured.
This CSS will be applied at the phone configuration page to implement a
device-based CSS. Recall that every DN (line) inherits this CSS by default. This CSS
will contain a partition featuring route patterns that route the calls to the appropriate
local gateway per site.
■ Create CSSs containing partitions featuring blocked route patterns for those types of
calls not permitted by a user’s CoS, and assign them to the lines of the user’s phone.
If a user has access to all types of calls except international, that user’s line (or lines)
should be configured with a CSS whose first partition includes a route pattern that
blocks calls to 9.011!. Recall that CUCM will process the line CSS before the device
CSS. Even though the international call is permitted at the device level, the international
call is explicitly blocked at the line level CSS. As soon as CUCM matches on a
pattern in the line CSS, the call is routed or blocked. The user placing the blocked call
will hear a reorder tone or an annunciator message (if the annunciator media resource
is active). Figure 13-24 illustrates this procedure.
Figure 13-24 Line-Device CoS Approach
Line
Line CSS Line CSS
Selectively Blocks
Undesired Routes
(According to
Class of Service)
Device CSS
Allows Access to
All External Routes
Block Int’I Partition
9.011!
Resulting CSS
“Blocked”
Route/Translation Pattern
“Routed” Route Patterns
Block Int’I Partition
9.011!
Device CSS
PSTN Partition
9.[2-9]XXXXXX
9.1 [2-9]XX [2-9]XX XXXX
9.011!
PSTN Partition
9.011!
9.1 [2-9]XX [2-9]XX XXXX
9.011!
Device
IP
330 Chapter 13: Calling Privileges
Figure 13-25 illustrates the line-device approach with multiple sites. This approach results
in a significantly simpler configuration with many fewer partitions and CSSs.
Figure 13-25 Line-Device CoS with Multiple Sites
One partition is used per CoS that blocks those destinations that are not desired by the
appropriate CoS. These partitions are included in the device’s line CSS to always block
access to destinations that are not permitted for the corresponding CoS, regardless of the
PSTN gateway that is going to be used by devices of a certain location.
All possible PSTN route patterns are created once per PSTN gateway and put into a
partition that is included at the device CSS, thus allowing the local gateway to be used
for all PSTN calls that have not been blocked earlier by the line CSS.
Site1Devices
•••
•••
SiteNDevices
Calling Search
Spaces Partitions
Route
Lists
1RL
NRL
1RG
NRG
Route
Groups
OnCluster
IP Phones
Shared
VM Ports, MeetMe...
Site1PSTN
911
9.011!
9.011!#
9.911
9.[2-9]XXXXXX
9.1 [2-9]XX [2-9]XX XXXX
SiteNPSTN
911
9.011!
9.911
9.[2-9]XXXXXX
9.1 [2-9]XX [2-9]XX XXXX
9.011!#
Device CSS (1 for Site N) Device CSS (1 for Site 1)
V
V
Site 1
Gateways
Site N
Gateways
911 and Vanity Numbers 331
This approach has the significant advantage that only a single, site-specific partition (and
device CSS) is required for each site to allow local gateway selection, and only one partition
per CoS (independent of the site) is required to perform CoS enforcement.
Instead of requiring the number of partitions determined by multiplying classes of service
and sites, the number of partitions is determined by adding the required sites and classes of
service.
A deployment with four sites and four classes of service using the traditional approach
would result in 16 partitions, whereas the line-device approach results in only 8 required
partitions.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
CoS applications in CUCM can be summarized as two distinctly separate implementations:
the traditional approach and the line-device approach. This section investigates the
difference between these two approaches and explains the advantages of using the linedevice
approach.
Figure 13-22 shows a simple single-site CoS deployment with four distinct classes of
service. Four partitions and four CSSs have been created. The route patterns for each call
type have been put into their respective partitions. The CSSs will be assigned to various
devices in the infrastructure. This is as simple as CoS gets.
Figure 13-22 Single Site with Four CoS Definitions
If the organization chooses to use the centralized call-processing model and an additional
site is added to the cluster, four more site-specific partitions will need to be created, and
four additional CSSs. In addition, the PSTN route patterns will need to be duplicated
and put into their site-specific partitions. The challenge in this scenario is that partitions and
CSSs need to provide two functions: 1) select the local PSTN gateway, and 2) control who
is allowed to dial what number.
Figure 13-23 illustrates a summary of the partitions, CSSs, and route patterns necessary to
achieve this solution. The solution includes four partitions per site: emergency partition,
local partition, national partition, and international partition. The number of required
V
IP
Local_css
LD_css
Intl_css
Internal_css
Calling Search
Spaces Partitions
Route
Lists
Route
Groups Devices
PSTN
Route
Patterns
Calling
Search
Space
Assigned
to Device
Based on
Class of
Service
All IP Phones
9.011!
9.011!#
9.[2-9]XXXXXX
[2-9]XX XXX
9.1[2-9]XX
911
9.911
Internal_pt
Local_pt
LD_pt
Intl_pt
PSTN
RG
PSTN
RL
328 Chapter 13: Calling Privileges
partitions is calculated by multiplying the number of required classes of service by the
number of sites. The example includes four classes of service per site. Implementations
may involve considerably more partitions and CSSs per site.
Figure 13-23 Centralized Call Processing with Four CoS Definitions
The traditional approach, outlined in the preceding section, can result in a large number
of partitions and CSSs when applied to large multisite deployments with centralized call
processing. This configuration is required because the device CSS is used to determine both
the path selection (which PSTN gateway to use for external calls) and the CoS.
It is possible to significantly decrease the total number of partitions and CSSs needed by
dividing the functions of site-specific routing and CoS between the line CSS and the device
CSS. The use of both a line- and a device-based CSS is called the line-device approach.
NOTE The traditional model of designing CoS in CUCM does not scale to large
deployments involving 25 or more sites.
V
V
V
V
Calling Search
Spaces Partitions Route Lists/Route Groups
OnCluster
IP Phones
Shared
Site1Emergency
Site1Local
Site1National 1RL 1RG
NRL NRG
Site1International
9.11
9.[2-9]XXXXXX
9.1 [2-9]XX [2-9]XX XXXX
9.911
9.011!
9.011!#
SiteNEmergency
SiteNLocal
SiteNNational
SiteNInternational
9.11
9.[2-9]XXXXXX
9.1 [2-9]XX [2-9]XX XXXX
9.911
9.011!
9.011!#
VM Ports, MeetMe...
Device Calling Search
Spaces (4 for Site 1)
Device Calling Search
Spaces (4 for Site N)
Site 1
Gateways
Site N
Gateways
Site1Internal
Site1Local
Site1National
Site1International
•••
•••
SiteNInternal
SiteNLocal
SiteNNational
SiteNInternational
Class of Service Approaches 329
In the line-device approach, CUCM performs a concatenation of both the line and device
CSSs for each IP phone. Follow these rules to implement the line-device approach:
■ Use the device CSS to provide site-specific call-routing information (which gateway to
select for PSTN calls). The device CSS will be an unrestricted CSS. This CSS is not
used to enforce CoS.
■ Use the line CSS to block the route patterns that are not allowed by CoS (independent
of the used PSTN gateway). This can be done effectively with translation patterns with
a block action that are put into partitions that only the line CSSs have access to.
■ To implement the line device CSS approach, a per-site unrestricted CSS will be configured.
This CSS will be applied at the phone configuration page to implement a
device-based CSS. Recall that every DN (line) inherits this CSS by default. This CSS
will contain a partition featuring route patterns that route the calls to the appropriate
local gateway per site.
■ Create CSSs containing partitions featuring blocked route patterns for those types of
calls not permitted by a user’s CoS, and assign them to the lines of the user’s phone.
If a user has access to all types of calls except international, that user’s line (or lines)
should be configured with a CSS whose first partition includes a route pattern that
blocks calls to 9.011!. Recall that CUCM will process the line CSS before the device
CSS. Even though the international call is permitted at the device level, the international
call is explicitly blocked at the line level CSS. As soon as CUCM matches on a
pattern in the line CSS, the call is routed or blocked. The user placing the blocked call
will hear a reorder tone or an annunciator message (if the annunciator media resource
is active). Figure 13-24 illustrates this procedure.
Figure 13-24 Line-Device CoS Approach
Line
Line CSS Line CSS
Selectively Blocks
Undesired Routes
(According to
Class of Service)
Device CSS
Allows Access to
All External Routes
Block Int’I Partition
9.011!
Resulting CSS
“Blocked”
Route/Translation Pattern
“Routed” Route Patterns
Block Int’I Partition
9.011!
Device CSS
PSTN Partition
9.[2-9]XXXXXX
9.1 [2-9]XX [2-9]XX XXXX
9.011!
PSTN Partition
9.011!
9.1 [2-9]XX [2-9]XX XXXX
9.011!
Device
IP
330 Chapter 13: Calling Privileges
Figure 13-25 illustrates the line-device approach with multiple sites. This approach results
in a significantly simpler configuration with many fewer partitions and CSSs.
Figure 13-25 Line-Device CoS with Multiple Sites
One partition is used per CoS that blocks those destinations that are not desired by the
appropriate CoS. These partitions are included in the device’s line CSS to always block
access to destinations that are not permitted for the corresponding CoS, regardless of the
PSTN gateway that is going to be used by devices of a certain location.
All possible PSTN route patterns are created once per PSTN gateway and put into a
partition that is included at the device CSS, thus allowing the local gateway to be used
for all PSTN calls that have not been blocked earlier by the line CSS.
Site1Devices
•••
•••
SiteNDevices
Calling Search
Spaces Partitions
Route
Lists
1RL
NRL
1RG
NRG
Route
Groups
OnCluster
IP Phones
Shared
VM Ports, MeetMe...
Site1PSTN
911
9.011!
9.011!#
9.911
9.[2-9]XXXXXX
9.1 [2-9]XX [2-9]XX XXXX
SiteNPSTN
911
9.011!
9.911
9.[2-9]XXXXXX
9.1 [2-9]XX [2-9]XX XXXX
9.011!#
Device CSS (1 for Site N) Device CSS (1 for Site 1)
V
V
Site 1
Gateways
Site N
Gateways
911 and Vanity Numbers 331
This approach has the significant advantage that only a single, site-specific partition (and
device CSS) is required for each site to allow local gateway selection, and only one partition
per CoS (independent of the site) is required to perform CoS enforcement.
Instead of requiring the number of partitions determined by multiplying classes of service
and sites, the number of partitions is determined by adding the required sites and classes of
service.
A deployment with four sites and four classes of service using the traditional approach
would result in 16 partitions, whereas the line-device approach results in only 8 required
partitions.
Client Matter Codes and Forced Authorization Codes CCIE Security Bootcamp Training in Delhi Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Set fixed time zone or use time zone of call originating device.
Assign time
schedule
to partition.
324 Chapter 13: Calling Privileges
Valid FACs are added to CUCM, and an authorization level is assigned to FACs. If a FAC
is required for a route pattern, the minimum required authorization level has to be specified
at the route pattern. Users have to enter a valid authorization code whose authorization level
is equal to or greater than the level configured at the FAC-enabled router pattern.
Figure 13-18 illustrates a CMC application where UserA dials a number that matches a
route pattern where the Require Client Matter Code parameter is checked. CUCM plays a
tone to indicate to the user that a CMC has to be entered. The user has to enter a valid CMC
for the call to be extended. In the example, CMCs 1234, 1244, and 3489 are configured.
The user entered 1234. If the user does not terminate the code with the # sign, the user will
have to wait until the interdigit timeout (T.302 timer) expires (15 seconds by default). The
call is successful, and the entered CMC is included in the generated CDR.
Figure 13-18 Client Matter Code: Successful Operation
Figure 13-19 uses the same configuration as the preceding example, but this time UserA
enters 5555 at the CMC prompt. This is not a valid CMC; therefore, the call is denied. A
CDR is generated for the attempted call if the CDR Log Calls with a Zero Duration Flag
CallManager service parameter has been enabled. Calls with zero duration flags are not
logged in CDRs by default.
Play Tone
1234# (Code)
912125551212
Extend Call to Gateway
UserA Voice GW
IP
Route Pattern*
Route Partition
9.12125551XXX
LDPSTN_PT
Require Client Matter Code
CMC Codes:
1234
1244
3489
Client Matter Codes and Forced Authorization Codes 325
Figure 13-19 Client Matter Code: Call Failure
In Figure 13-20, UserA dials a number that matches a route pattern where the Require
Forced Authorization Code parameter is checked and the Authorization Level is set to 3.
CUCM plays a tone to indicate to the user that a FAC has to be entered. The user has to
enter a valid FAC with an authorization level of 3 or above for the call to be extended. At
the prompt, the user enters 1888. Because the FAC level of the code was equal to or higher
than the required authorization level, the call is successful, and the name of the entered FAC
is included in the generated CDR.
Figure 13-21 has the same configuration as the preceding example, but this time UserA
enters 1234 at the FAC prompt. The call is denied because the authorization level of the
entered FAC is lower than the required level configured at the route pattern. A CDR is
generated logging the attempted call.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Set fixed time zone or use time zone of call originating device.
Assign time
schedule
to partition.
324 Chapter 13: Calling Privileges
Valid FACs are added to CUCM, and an authorization level is assigned to FACs. If a FAC
is required for a route pattern, the minimum required authorization level has to be specified
at the route pattern. Users have to enter a valid authorization code whose authorization level
is equal to or greater than the level configured at the FAC-enabled router pattern.
Figure 13-18 illustrates a CMC application where UserA dials a number that matches a
route pattern where the Require Client Matter Code parameter is checked. CUCM plays a
tone to indicate to the user that a CMC has to be entered. The user has to enter a valid CMC
for the call to be extended. In the example, CMCs 1234, 1244, and 3489 are configured.
The user entered 1234. If the user does not terminate the code with the # sign, the user will
have to wait until the interdigit timeout (T.302 timer) expires (15 seconds by default). The
call is successful, and the entered CMC is included in the generated CDR.
Figure 13-18 Client Matter Code: Successful Operation
Figure 13-19 uses the same configuration as the preceding example, but this time UserA
enters 5555 at the CMC prompt. This is not a valid CMC; therefore, the call is denied. A
CDR is generated for the attempted call if the CDR Log Calls with a Zero Duration Flag
CallManager service parameter has been enabled. Calls with zero duration flags are not
logged in CDRs by default.
Play Tone
1234# (Code)
912125551212
Extend Call to Gateway
UserA Voice GW
IP
Route Pattern*
Route Partition
9.12125551XXX
LDPSTN_PT
Require Client Matter Code
CMC Codes:
1234
1244
3489
Client Matter Codes and Forced Authorization Codes 325
Figure 13-19 Client Matter Code: Call Failure
In Figure 13-20, UserA dials a number that matches a route pattern where the Require
Forced Authorization Code parameter is checked and the Authorization Level is set to 3.
CUCM plays a tone to indicate to the user that a FAC has to be entered. The user has to
enter a valid FAC with an authorization level of 3 or above for the call to be extended. At
the prompt, the user enters 1888. Because the FAC level of the code was equal to or higher
than the required authorization level, the call is successful, and the name of the entered FAC
is included in the generated CDR.
Figure 13-21 has the same configuration as the preceding example, but this time UserA
enters 1234 at the FAC prompt. The call is denied because the authorization level of the
entered FAC is lower than the required level configured at the route pattern. A CDR is
generated logging the attempted call.
Time-of-Day Call Routing CCIE BootcampTraining in Delhi Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Time-of-day routing can be implemented in CUCM by applying time and date attributes to
partitions using time schedules and time periods. Time periods define time ranges or dates
and are grouped into time schedules. Time schedules are then assigned to partitions.
A CSS that includes a partition that is associated with a time schedule has access only to
the partition if the current date and time match the time and date information specified in
the time schedule that is associated with the partition. If the configured time schedule does
not fall into the current date and time, the partition is logically removed from the CSS.
Time-of-day routing can be used to route calls differently based on time in the following
way:
■ Identical route patterns are created and put into different partitions.
■ At least one of these partitions has a time schedule applied.
■ If the partition with the time schedule is listed first in CSSs, it will take precedence over
other partitions during the time that is associated with the partition. If the current time
does not match the configured time schedule, the partition that has the time schedule
assigned is ignored, and the next partition becomes the partition with highest priority.
Examples of when time-of-day routing can be used include the following:
■ Allowing international calls only during office hours
■ Blocking international calls on holidays
■ Using time-of-day routing to control the call-routing path based on the current time for
maximum cost benefits:
—Multiple providers for international calls might be available, some of
them having different prices depending on the hours of the days
(typically more expensive during business hours and less expensive
during off-hours).
—With time-of-day routing, international calls to certain countries can use
the cheapest available provider based on the current time, and thus make
use of the cheapest offer for any given time instead of using the same
provider for calls to certain countries all the time.
NOTE It is highly advisable to use Network Time Protocol (NTP) when using time-ofday
call routing.
320 Chapter 13: Calling Privileges
A time period specifies a time range defined by start- and end- time and a repetition interval
(days of week or specified calendar date). One or more time periods can be assigned to a
time schedule. The same time period can be assigned to multiple time schedules.
A time schedule is a group of time periods. Time schedules are applied to partitions and
thus make the partition inactive when the applied time schedule does not match the current
date or time.
In Figure 13-12, the partition CiscoAustin_PT is accessible only from Monday to Friday
from 8 a.m. to 5 p.m. (0800 to 1700) from a CSS that includes the partition.
Figure 13-12 Time Periods and Schedules
You can use time-based CoS to allow international calls, for example, during only certain
times of the day. Figure 13-13 is an example where international calls will be blocked on
weekends and holidays (New Year’s Day in the example). Multiple 9.011! route patterns
must be created for this application. The first route pattern is put into the standard partition,
which has no time schedule applied.
A second, identical route pattern is created, which is placed into the weekend partition.
The phone’s line CSS includes the weekend partition, while the device CSS includes the
standard partition. The weekend partition is used to block the international call, because
the route pattern has a block this action associated with it. The weekend partition will match
only on weekends and New Year’s Day.
Partition
weekdayhrs_TP 0800–1700 M–F
weekendhrs_TP 0800–1700 Sat–Sun
newyears_TP 0000–2400 January 1
noofficehours_TP Sat–Sun
RegEmployees_TS weekdayhrs_TP
CiscoAustin_PT RegEmployees_TS
Start–End Repetition
Time Periods
Time Schedule
Time Schedule
Time Periods
Time-of-Day Call Routing 321
Figure 13-13 Time-Based Call-Routing Example
The steps to implement time-of-day routing are as follows:
Step 1 Create time periods.
Step 2 Create time schedules and associate them with time periods.
Step 3 Assign time schedules to partitions that should be active only during the
time specified in the time schedule.
The CUCM Administration navigation to create a time period is Call Routing > Class of
Control > Time Period. Click the Add New button. Use descriptive names in your time
periods that include _TP in the name (for example, weekdays_TP). Figure 13-14 is an
example of a time period configuration with a recurring time range every week from
Saturday to Sunday. Figure 13-15 is a static date every year on January 1.
Time schedules are created by adding one or more time periods to a time schedule. Time
periods are configured in the following navigation path: Call Routing > Class of Control
> Time Schedule. Click the Add New button. Figure 13-16 shows a time schedule that
includes two time periods.
NOTE Route patterns and translation patterns can be configured with the parameter
Block This Pattern to explicitly deny calls to certain patterns if the pattern was selected
by the call-routing logic.
Dials
9.0114369918900009
Current Time: 20:00
Current Day: Sat
CSS:
Weekend
Standard
Route Pattern: 9.011!
Partition: Standard
Route to PSTN
Partition Standard: (No Time Schedule)
Dials 9.0114369918900009
Current Time: 10:00
Current Day: Wed
1
2
Route Pattern: 9.011!
Partition: Weekend
Block This Pattern!
Partition Weekend: Time Schedule: TS1
Time Schedule TS1: Time Period: TP1, TP2
TP1: 00:00–24:00 Sat-Sun
TP2: 00:00–24:00 Jan 1
First Partition (Weekend) is
ignored because no time
match. Pattern not blocked.
First Partition (Weekend) is
active, matched, and listed first.
Pattern blocked.
IP
322 Chapter 13: Calling Privileges
Figure 13-14 Recurring Time Period
Figure 13-15 Static Time Period
Figure 13-16 Time Schedule Configuration
TP1 is active Saturday and Sunday from 0:00 to 24:00.
TP2 is active Jan 1 from 0:00 to 24:00.
Add or remove
highlighted time
period to or from
time schedule.
Client Matter Codes and Forced Authorization Codes 323
Time schedules are then assigned to partitions. In Figure 13-17, the time schedule
OfficeHours_TS is applied to the International partition. The International_PT will
only be included in the CSS during office hours.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Time-of-day routing can be implemented in CUCM by applying time and date attributes to
partitions using time schedules and time periods. Time periods define time ranges or dates
and are grouped into time schedules. Time schedules are then assigned to partitions.
A CSS that includes a partition that is associated with a time schedule has access only to
the partition if the current date and time match the time and date information specified in
the time schedule that is associated with the partition. If the configured time schedule does
not fall into the current date and time, the partition is logically removed from the CSS.
Time-of-day routing can be used to route calls differently based on time in the following
way:
■ Identical route patterns are created and put into different partitions.
■ At least one of these partitions has a time schedule applied.
■ If the partition with the time schedule is listed first in CSSs, it will take precedence over
other partitions during the time that is associated with the partition. If the current time
does not match the configured time schedule, the partition that has the time schedule
assigned is ignored, and the next partition becomes the partition with highest priority.
Examples of when time-of-day routing can be used include the following:
■ Allowing international calls only during office hours
■ Blocking international calls on holidays
■ Using time-of-day routing to control the call-routing path based on the current time for
maximum cost benefits:
—Multiple providers for international calls might be available, some of
them having different prices depending on the hours of the days
(typically more expensive during business hours and less expensive
during off-hours).
—With time-of-day routing, international calls to certain countries can use
the cheapest available provider based on the current time, and thus make
use of the cheapest offer for any given time instead of using the same
provider for calls to certain countries all the time.
NOTE It is highly advisable to use Network Time Protocol (NTP) when using time-ofday
call routing.
320 Chapter 13: Calling Privileges
A time period specifies a time range defined by start- and end- time and a repetition interval
(days of week or specified calendar date). One or more time periods can be assigned to a
time schedule. The same time period can be assigned to multiple time schedules.
A time schedule is a group of time periods. Time schedules are applied to partitions and
thus make the partition inactive when the applied time schedule does not match the current
date or time.
In Figure 13-12, the partition CiscoAustin_PT is accessible only from Monday to Friday
from 8 a.m. to 5 p.m. (0800 to 1700) from a CSS that includes the partition.
Figure 13-12 Time Periods and Schedules
You can use time-based CoS to allow international calls, for example, during only certain
times of the day. Figure 13-13 is an example where international calls will be blocked on
weekends and holidays (New Year’s Day in the example). Multiple 9.011! route patterns
must be created for this application. The first route pattern is put into the standard partition,
which has no time schedule applied.
A second, identical route pattern is created, which is placed into the weekend partition.
The phone’s line CSS includes the weekend partition, while the device CSS includes the
standard partition. The weekend partition is used to block the international call, because
the route pattern has a block this action associated with it. The weekend partition will match
only on weekends and New Year’s Day.
Partition
weekdayhrs_TP 0800–1700 M–F
weekendhrs_TP 0800–1700 Sat–Sun
newyears_TP 0000–2400 January 1
noofficehours_TP Sat–Sun
RegEmployees_TS weekdayhrs_TP
CiscoAustin_PT RegEmployees_TS
Start–End Repetition
Time Periods
Time Schedule
Time Schedule
Time Periods
Time-of-Day Call Routing 321
Figure 13-13 Time-Based Call-Routing Example
The steps to implement time-of-day routing are as follows:
Step 1 Create time periods.
Step 2 Create time schedules and associate them with time periods.
Step 3 Assign time schedules to partitions that should be active only during the
time specified in the time schedule.
The CUCM Administration navigation to create a time period is Call Routing > Class of
Control > Time Period. Click the Add New button. Use descriptive names in your time
periods that include _TP in the name (for example, weekdays_TP). Figure 13-14 is an
example of a time period configuration with a recurring time range every week from
Saturday to Sunday. Figure 13-15 is a static date every year on January 1.
Time schedules are created by adding one or more time periods to a time schedule. Time
periods are configured in the following navigation path: Call Routing > Class of Control
> Time Schedule. Click the Add New button. Figure 13-16 shows a time schedule that
includes two time periods.
NOTE Route patterns and translation patterns can be configured with the parameter
Block This Pattern to explicitly deny calls to certain patterns if the pattern was selected
by the call-routing logic.
Dials
9.0114369918900009
Current Time: 20:00
Current Day: Sat
CSS:
Weekend
Standard
Route Pattern: 9.011!
Partition: Standard
Route to PSTN
Partition Standard: (No Time Schedule)
Dials 9.0114369918900009
Current Time: 10:00
Current Day: Wed
1
2
Route Pattern: 9.011!
Partition: Weekend
Block This Pattern!
Partition Weekend: Time Schedule: TS1
Time Schedule TS1: Time Period: TP1, TP2
TP1: 00:00–24:00 Sat-Sun
TP2: 00:00–24:00 Jan 1
First Partition (Weekend) is
ignored because no time
match. Pattern not blocked.
First Partition (Weekend) is
active, matched, and listed first.
Pattern blocked.
IP
322 Chapter 13: Calling Privileges
Figure 13-14 Recurring Time Period
Figure 13-15 Static Time Period
Figure 13-16 Time Schedule Configuration
TP1 is active Saturday and Sunday from 0:00 to 24:00.
TP2 is active Jan 1 from 0:00 to 24:00.
Add or remove
highlighted time
period to or from
time schedule.
Client Matter Codes and Forced Authorization Codes 323
Time schedules are then assigned to partitions. In Figure 13-17, the time schedule
OfficeHours_TS is applied to the International partition. The International_PT will
only be included in the CSS during office hours.
Partitions and Calling Search Spaces CCSP Bootcamp Training in delhi Gurgaon
Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
A partition is a group of dialable patterns with similar accessibility. Any dialable pattern
can be assigned to a partition. All phone numbers are in the null partition by default, and
all devices have access to the null partition. As soon as a phone number is assigned to a
different partition, the devices in the network will not be able to access that phone number
without the configuration of a calling search space (CSS).
Long Distance Internal
Emergency
Local PSTN
Long-distance PSTN
International Internal
Emergency
Local PSTN
Long-distance PSTN
International PSTN
Table 13-2 Call-Privileges Configuration Elements
Element Characteristic
Partition Group of numbers with similar reachability characteristics (including route
patterns, directory numbers, translation patterns, and so on)
Calling search space Ordered list of accessible partitions applied to device to restrict call privileges
Time periods Static days or recurring time intervals
Time schedules Ordered list of time periods
CMCs Used to track calls to certain destinations
FACs Restrict outgoing calls to certain numbers
Table 13-1 Class of Service Example (Continued)
Class of Service Allowed Destinations
308 Chapter 13: Calling Privileges
A CSS defines which partitions are accessible to a particular device. A device can call only
those call-routing table entries located in partitions that are part of the CSS assigned to the
device.
Partitions are assigned to call-routing targets. Any entry of the call-routing table, including
voice-mail ports, directory numbers (DN), route patterns, translation patterns, meet-me
conference numbers, and so on can be assigned to a partition.
CSSs are assigned to devices, which are the source of a call-routing request (phones, phone
lines, gateways, trunks, voice-mail ports, and computer telephony integration [CTI] ports).
Calls that come into the network from a gateway or trunk inherit the CSS assigned to the
gateway or trunk.
By default, all entities that can be configured with a partition are in partition <None> (null
partition), all entities that can be configured with a CSS are assigned with CSS <None>
(null CSS).
Members of partition <None> are always accessible by sources of a call-routing request,
regardless of the CSS applied to the calling party. Entities that do not have a CSS assigned
can only access numbers that are in partition <None>. Partition <None> is commonly
referred to as the null partition.
In Figure 13-1, various partitions and CSSs have been created. An easier way of understanding
partitions and CSSs is to use an analogy of locks and key rings. If each house on
a block has a different lock (partition), your key ring (CSS) would have to include many
keys (to unlock different doors).
In Figure 13-1, DN 1 of Phone 1 has been configured in the lobby partition, and DN 1 of
Phone 2 is in the employee partition, while Phone 3 and Phone 5 are both in the manager
partition. Phone 4 has not been assigned to a partition. Following the analogy with locks
and keys, there are three different types of locks (lobby, employee, and manager). Phone 4
does not have a lock. Phone 4 is therefore in the null partition, and everyone has access to
call Phone 4.
When approaching CSSs from the perspective of key rings, Phone 1 has a key ring with the
lobby and employee key on it. Phone 2 has a key ring with keys for the lobby, employee,
and manager key ring. Phone 3 has a key ring with the lobby, employee, manager, and
executive keys. The executive key is not seen in the example, but it will be used in the
system for executive management. The key ring of Phone 4 contains only the lobby key.
Phone 5 does not have any keys, which restricts Phone 5 to call only other DNs in the null
partition.
Partitions and Calling Search Spaces 309
As a result of this implementation of locks and keys, the following effective permissions
apply:
■ Phone 1: Like all other phones, this phone has access to all devices that do not have a
lock applied (Phone 4 in this example). Phone 1 can access DN 1 on Phone 2 and Phone
4. Devices cannot access DNs in the same partition unless their CSS gives explicit
permission to that partition.
■ Phone 2: Phone 2 can access Phone 1, Phone 3, Phone 4, and Phone 5.
■ Phone 3: Phone 3 can access Phone 1, Phone 2, Phone 4, and Phone 5.
■ Phone 4: Phone 4 can access Phone 1 only, because the CSS has access only to the
lobby partition.
■ Phone 5: Like all other phones, this phone has access to all devices that do not have a
lock applied (Phone 4 in this example). Phone 5 cannot unlock any locks because it
does not have any keys. That means that Phone 4 can access only Phone 1.
Figure 13-1 Calling Privileges: Partitions and Calling Search Spaces
Figure 13-2 illustrates a phone with a CSS that contains two partitions: Chicago and San
Jose. A third partition, Atlanta, exists in the system but is not included in the CSS of the
phone. Phone DNs are assigned to partitions as follows:
■ DN 3001 (Phone 2-1) is assigned to partition Chicago.
■ DN 2001 (Phone 1-1) is assigned to partition San Jose.
■ DN 4001 (Phone 3-1) is assigned to partition Atlanta.
IP IP IP IP IP
Partitions: Lobby_PT Employee_PT Manager_PT
No Partition
Assigned Manager_PT
Phones Phone 1 Phone 2 Phone 3 Phone 4 Phone 5
CSSs: Lobby_PT
Employee_PT
Lobby_PT
Employee_PT
Manager_PT
Lobby_PT
Employee_PT
Manager_PT
Executive_PT
Lobby_PT No CSS
Assigned
310 Chapter 13: Calling Privileges
The user at the phone dials 3001, which is the DN of Phone 2-1. CUCM performs digit
analysis against the dialed digits of 3001. The call-routing lookup will search only through
the partitions configured in the CSS of the calling phone (Chicago and San Jose). CUCM
finds a match in partition Chicago, because the DN of 3001 of Phone 2-1 is assigned to this
partition. Because no other matches exist, routing is complete, and Phone 2-1 rings.
Figure 13-2 Partition and CSS Example
A CSS is an ordered list of partitions with the highest-priority partitions listed first.
Multiple identical entities can exist in the call-routing table, but they have to be in different
partitions. It is advisable to route emergency calls through a local gateway in multisite
centralized call-processing deployments. If 911 is the emergency number, there will be
many iterations of the 911 route pattern in the system, but they must each be in a separate
partition. Local call routing in a centralized call-processing approach will result in the
creation of site-specific partitions and CSSs to guarantee that local PSTN resources are
used.
CSS
Partition Chicago
3001 Phone 2-1
Partition San Jose
2001 Phone 1-1
Partition Atlanta
4001 Phone 3-1
Phone CSS
contains two
partitions.
Phone 2-1 DN
3001 lies in
partition Chicago.
Phone 3-1 DN
4001 lies in
partition Atlanta.
Not included in
routing decision.
2
Phone 2-1 will ring.
IP 3
User dials 3001.
1
Partitions and Calling Search Spaces 311
Figure 13-3 Multiple Best Matches Example
Figure 13-3 displays a CSS scenario in which the same dialed pattern matches multiple
partitions. The CSS processing is based on the following order:
1. Best match is searched.
2. If multiple equally qualified matches exist (no single best match), the call routes
through the partition in the CSS that is highest in the list. Many sources of call-routing
requests (trunks, gateways, and translation patterns) have only one CSS. On IP phones,
a different CSS can be applied per line and at the device level. If a CSS is specified only
at the device level, each DN inherits the CSS of the device.
If CSSs are configured at both device and line level, the line from which the call is placed
is considered first in the call-processing logic. CUCM concatenates the two CSSs and
processes them in a top-down manner with the line CSS at the top of the list, as shown in
Figure 13-4.
CSS
Partition Chicago
3001 Phone 2-1
Partition San Jose
3001 Phone 1-1
Partition Atlanta
3001 Phone 3-1
Phone CSS
contains two
partitions.
Phone 2-1 DN
3001 lies in
partition Chicago.
Phone 1-1 DN
3001 lies in
partition San Jose.
Phone 3-1 DN
3001 lies in
partition Atlanta.
Not included in
routing decision.
Phone 2-1 and
Phone 1-1 match
equally well. Phone 2-1
is used because its
partition is listed first
in calling phone’s
CSS.
2
IP
User dials 3001.
1
312 Chapter 13: Calling Privileges
Figure 13-4 Device and Line CSS Example
In Figure 13-5, the line CSS of the calling party includes partitions San Jose and Chicago.
The device CSS of the calling phone includes partition Atlanta.
Figure 13-5 CSS Partition Order Example
NOTE On CTI ports, the line and device CSS are processed in reverse order; the
partitions of the device CSS are processed before the partitions of the line CSS.
Line
Line CSS
Partition L1
Partition L2
Partition L3
Device
Device CSS
Partition D1
Partition D2
Partition D3
Resulting CSS
Partition L1
Partition L2
Partition L3
Partition D1
Partition D2
Partition D3
IP
Line CSS
Device CSS
Partition San Jose
300X Route Pattern
Partition Chicago
3001 Phone 2-1
Partition Atlanta
3001 Phone 3-1
Partitions and Calling Search Spaces 313
Route pattern 300X is in the San Jose partition, with DN 3001 assigned to both Phone 2-1
in the Chicago partition and Phone 3-1 in the Atlanta partition.
When the phone dials 3001, the following will happen:
CUCM interprets the dialed digits and searches for the closest match. The two DN entries
in the call-routing table are more specific than the route pattern of 300X. Phone 2-1 is
chosen because its partition is listed first in the concatenated CSS.
Figure 13-5 illustrates the line CSS having higher priority than the device CSS. If the line
CSS and device CSS were reversed, the call would be sent to Phone 3-1. Notice that the
CSS subsequently performs closest-match routing against all partitions in the CSS at the
same time. If the CSS had been strictly processed on the San Jose partition before
considering the Chicago or Atlanta partitions, 300X would have been the match. Instead,
CUCM was aware of the closest match of 3001 in the other partitions. The partition order
is used as a tiebreaker if there are multiple closest matches.
Figure 13-6 is using partitions and CSS to implement four different classes of service:
■ Internal: Allows internal calls only
■ Local: Allows internal and local PSTN calls
■ Long Distance: Allows internal, local PSTN, and long-distance PSTN calls
■ International: Allows internal, local PSTN, long distance, and international PSTN calls
The following partitions are applied as described:
■ Phones: This partition is applied to all phone lines.
■ Local-PSTN: This partition is applied to route pattern 9.[2–9]XXXXXX
■ LD-PSTN: This partition is applied to route pattern 9.1[2–9]XX[2–9]XX XXXX
■ Intl-PSTN: This partition is applied to route pattern 9.011! and 9.011!#.
NOTE It is a common misunderstanding that the first matching pattern (regardless of
the quality of the match) that is found when searching through the partitions in the order
specified in the CSS is used for call routing. If this were true, subsequent partitions of the
CSS would only be looked at, if no match (of any kind) were found in the earlier
partitions. This is not the case. All partitions are immediately considered for the bestmatch
logic, and only if multiple best matches exist does the partition order become
relevant.
314 Chapter 13: Calling Privileges
The following CSSs are configured, each implementing the corresponding service class:
■ CSS-Internal: Containing partition Phones
■ CSS-Local: Containing partitions Phones and Local-PSTN
■ CSS-LD: Containing partitions Phones, Local-PSTN, and LD-PSTN
■ CSS-International: Containing partitions Phones, Local PSTN, LD-PSTN, and
Intl-PSTN
Figure 13-6 CSS Example
NOTE CSSs take on an inverted logical approach when assigned to devices such as
Session Initiation Protocol (SIP) trunks, intercluster trunks, and gateways. Calls that are
routed through a trunk or gateway take on the CSS applied at the device. In a multicluster
distributed call-processing environment, it is not advised to allow emergency call routing
across trunk links. Most organizations locally route emergency calls to the local public
safety answering point (PSAP). It is common practice to restrict emergency call routing
in the CSS applied to trunks.
CSS Internal CSS Local CSS LD CSS
International
Partition Phones
(All Phone DNs)
Partition Local-PSTN
9[2-9]XXXXXX
Partition LD-PSTN
91[2-9]XX[2-9]XXXXXX
Partition
Intl-PSTN
9011!#
X
X
X
X
X X
Internal Calls
Local Calls
Long-Distance
Calls
International
Calls
IP
Assigned CSS determines
calling privilege.
Partitions and Calling Search Spaces 315
Configuration of partitions and CSSs includes the following steps:
Step 1 Create partitions.
Step 2 Assign partitions to the DN, route-translation patterns, CTI ports, voicemail
ports, meet-me conference bridge numbers, call-park ranges, and
any other number in the system.
Step 3 Create CSSs.
Step 4 Add partitions in the desired order into each newly created CSS.
Step 5 Assign CSSs to entities that can request lookups to the call-routing table
to route a call; examples for such entities are phones and phone lines,
trunks, gateways, and translation patterns.
To add partitions in CUCM Administration, navigate to Call Routing > Class of Control
> Partition and click the Add New button. Figure 13-7 shows the Partition Configuration
page in CUCM. You can add up to 75 partitions in one insertion of partitions with a
character limitation of 1475 characters. If more than 75 partitions are required, you may
perform multiple insertions.
Partition names should not be lengthy because the CSS has a maximum length restriction
of 1024 characters. A CSS is a string of partition names. The 1024-character limit includes
separator characters between each partition name. (For example, the string
“partition_1:partition_2:partition_3” contains 35 characters.) The maximum number of
partitions in a CSS varies, depending on the length of the partition names and number of
partitions. If individual CSSs are used on both the device and line level, the maximum
character limit for the individual CSS is 512 (half the combined CSS clause limit of 1024
characters).
Figures 13-8 and 13-9 show the application of partitions, respectively, to a DN and route
pattern.
NOTE A translation pattern is a dialable pattern in the call-routing table. When a
translation pattern is matched, it invokes a new call-routing request for the translated
pattern. Which partition the translation pattern is in limits the devices that can access the
translation pattern. The CSS of the translation pattern specifies the entries of the callrouting
table that the translation pattern is allowed to see for the new call-routing request
when it is trying to find the translated pattern in the call-routing table.
316 Chapter 13: Calling Privileges
Figure 13-7 Partition Configuration
Figure 13-8 Partition Application: Directory Number
Partitions and Calling Search Spaces 317
Figure 13-9 Partition Application: Route Pattern
Figure 13-10 shows the Calling Search Space Configuration page. This page is accessible
by navigating to the following CUCM Administration menu: Call Routing > Class of
Control > Calling Search Space. Click the Add New button to add a new CSS. The CSS
should be given a name that is descriptive of the desired functionality. LD_Calling Search
Space would be descriptive of a CSS that allows long-distance, local, emergency, and
internal dialing. Click a partition in the Available Partitions section of the configuration
page and use the down arrow to move the partition to the Selected Partitions section. You
can use the up and down arrows to the right of the Selected Partitions section to move the
priority of the selected partition. The top of the list is the highest priority. The emergency
partition should normally be at the top of the list.
Figure 13-11 displays the phone configuration page with a CSS applied. CSSs can be
assigned to phones, phone lines, gateways, trunks, voice-mail pilots, voice-mail ports, CTI
route points, CTI ports, translation patterns, and any other source of a call-routing request.
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
A partition is a group of dialable patterns with similar accessibility. Any dialable pattern
can be assigned to a partition. All phone numbers are in the null partition by default, and
all devices have access to the null partition. As soon as a phone number is assigned to a
different partition, the devices in the network will not be able to access that phone number
without the configuration of a calling search space (CSS).
Long Distance Internal
Emergency
Local PSTN
Long-distance PSTN
International Internal
Emergency
Local PSTN
Long-distance PSTN
International PSTN
Table 13-2 Call-Privileges Configuration Elements
Element Characteristic
Partition Group of numbers with similar reachability characteristics (including route
patterns, directory numbers, translation patterns, and so on)
Calling search space Ordered list of accessible partitions applied to device to restrict call privileges
Time periods Static days or recurring time intervals
Time schedules Ordered list of time periods
CMCs Used to track calls to certain destinations
FACs Restrict outgoing calls to certain numbers
Table 13-1 Class of Service Example (Continued)
Class of Service Allowed Destinations
308 Chapter 13: Calling Privileges
A CSS defines which partitions are accessible to a particular device. A device can call only
those call-routing table entries located in partitions that are part of the CSS assigned to the
device.
Partitions are assigned to call-routing targets. Any entry of the call-routing table, including
voice-mail ports, directory numbers (DN), route patterns, translation patterns, meet-me
conference numbers, and so on can be assigned to a partition.
CSSs are assigned to devices, which are the source of a call-routing request (phones, phone
lines, gateways, trunks, voice-mail ports, and computer telephony integration [CTI] ports).
Calls that come into the network from a gateway or trunk inherit the CSS assigned to the
gateway or trunk.
By default, all entities that can be configured with a partition are in partition <None> (null
partition), all entities that can be configured with a CSS are assigned with CSS <None>
(null CSS).
Members of partition <None> are always accessible by sources of a call-routing request,
regardless of the CSS applied to the calling party. Entities that do not have a CSS assigned
can only access numbers that are in partition <None>. Partition <None> is commonly
referred to as the null partition.
In Figure 13-1, various partitions and CSSs have been created. An easier way of understanding
partitions and CSSs is to use an analogy of locks and key rings. If each house on
a block has a different lock (partition), your key ring (CSS) would have to include many
keys (to unlock different doors).
In Figure 13-1, DN 1 of Phone 1 has been configured in the lobby partition, and DN 1 of
Phone 2 is in the employee partition, while Phone 3 and Phone 5 are both in the manager
partition. Phone 4 has not been assigned to a partition. Following the analogy with locks
and keys, there are three different types of locks (lobby, employee, and manager). Phone 4
does not have a lock. Phone 4 is therefore in the null partition, and everyone has access to
call Phone 4.
When approaching CSSs from the perspective of key rings, Phone 1 has a key ring with the
lobby and employee key on it. Phone 2 has a key ring with keys for the lobby, employee,
and manager key ring. Phone 3 has a key ring with the lobby, employee, manager, and
executive keys. The executive key is not seen in the example, but it will be used in the
system for executive management. The key ring of Phone 4 contains only the lobby key.
Phone 5 does not have any keys, which restricts Phone 5 to call only other DNs in the null
partition.
Partitions and Calling Search Spaces 309
As a result of this implementation of locks and keys, the following effective permissions
apply:
■ Phone 1: Like all other phones, this phone has access to all devices that do not have a
lock applied (Phone 4 in this example). Phone 1 can access DN 1 on Phone 2 and Phone
4. Devices cannot access DNs in the same partition unless their CSS gives explicit
permission to that partition.
■ Phone 2: Phone 2 can access Phone 1, Phone 3, Phone 4, and Phone 5.
■ Phone 3: Phone 3 can access Phone 1, Phone 2, Phone 4, and Phone 5.
■ Phone 4: Phone 4 can access Phone 1 only, because the CSS has access only to the
lobby partition.
■ Phone 5: Like all other phones, this phone has access to all devices that do not have a
lock applied (Phone 4 in this example). Phone 5 cannot unlock any locks because it
does not have any keys. That means that Phone 4 can access only Phone 1.
Figure 13-1 Calling Privileges: Partitions and Calling Search Spaces
Figure 13-2 illustrates a phone with a CSS that contains two partitions: Chicago and San
Jose. A third partition, Atlanta, exists in the system but is not included in the CSS of the
phone. Phone DNs are assigned to partitions as follows:
■ DN 3001 (Phone 2-1) is assigned to partition Chicago.
■ DN 2001 (Phone 1-1) is assigned to partition San Jose.
■ DN 4001 (Phone 3-1) is assigned to partition Atlanta.
IP IP IP IP IP
Partitions: Lobby_PT Employee_PT Manager_PT
No Partition
Assigned Manager_PT
Phones Phone 1 Phone 2 Phone 3 Phone 4 Phone 5
CSSs: Lobby_PT
Employee_PT
Lobby_PT
Employee_PT
Manager_PT
Lobby_PT
Employee_PT
Manager_PT
Executive_PT
Lobby_PT No CSS
Assigned
310 Chapter 13: Calling Privileges
The user at the phone dials 3001, which is the DN of Phone 2-1. CUCM performs digit
analysis against the dialed digits of 3001. The call-routing lookup will search only through
the partitions configured in the CSS of the calling phone (Chicago and San Jose). CUCM
finds a match in partition Chicago, because the DN of 3001 of Phone 2-1 is assigned to this
partition. Because no other matches exist, routing is complete, and Phone 2-1 rings.
Figure 13-2 Partition and CSS Example
A CSS is an ordered list of partitions with the highest-priority partitions listed first.
Multiple identical entities can exist in the call-routing table, but they have to be in different
partitions. It is advisable to route emergency calls through a local gateway in multisite
centralized call-processing deployments. If 911 is the emergency number, there will be
many iterations of the 911 route pattern in the system, but they must each be in a separate
partition. Local call routing in a centralized call-processing approach will result in the
creation of site-specific partitions and CSSs to guarantee that local PSTN resources are
used.
CSS
Partition Chicago
3001 Phone 2-1
Partition San Jose
2001 Phone 1-1
Partition Atlanta
4001 Phone 3-1
Phone CSS
contains two
partitions.
Phone 2-1 DN
3001 lies in
partition Chicago.
Phone 3-1 DN
4001 lies in
partition Atlanta.
Not included in
routing decision.
2
Phone 2-1 will ring.
IP 3
User dials 3001.
1
Partitions and Calling Search Spaces 311
Figure 13-3 Multiple Best Matches Example
Figure 13-3 displays a CSS scenario in which the same dialed pattern matches multiple
partitions. The CSS processing is based on the following order:
1. Best match is searched.
2. If multiple equally qualified matches exist (no single best match), the call routes
through the partition in the CSS that is highest in the list. Many sources of call-routing
requests (trunks, gateways, and translation patterns) have only one CSS. On IP phones,
a different CSS can be applied per line and at the device level. If a CSS is specified only
at the device level, each DN inherits the CSS of the device.
If CSSs are configured at both device and line level, the line from which the call is placed
is considered first in the call-processing logic. CUCM concatenates the two CSSs and
processes them in a top-down manner with the line CSS at the top of the list, as shown in
Figure 13-4.
CSS
Partition Chicago
3001 Phone 2-1
Partition San Jose
3001 Phone 1-1
Partition Atlanta
3001 Phone 3-1
Phone CSS
contains two
partitions.
Phone 2-1 DN
3001 lies in
partition Chicago.
Phone 1-1 DN
3001 lies in
partition San Jose.
Phone 3-1 DN
3001 lies in
partition Atlanta.
Not included in
routing decision.
Phone 2-1 and
Phone 1-1 match
equally well. Phone 2-1
is used because its
partition is listed first
in calling phone’s
CSS.
2
IP
User dials 3001.
1
312 Chapter 13: Calling Privileges
Figure 13-4 Device and Line CSS Example
In Figure 13-5, the line CSS of the calling party includes partitions San Jose and Chicago.
The device CSS of the calling phone includes partition Atlanta.
Figure 13-5 CSS Partition Order Example
NOTE On CTI ports, the line and device CSS are processed in reverse order; the
partitions of the device CSS are processed before the partitions of the line CSS.
Line
Line CSS
Partition L1
Partition L2
Partition L3
Device
Device CSS
Partition D1
Partition D2
Partition D3
Resulting CSS
Partition L1
Partition L2
Partition L3
Partition D1
Partition D2
Partition D3
IP
Line CSS
Device CSS
Partition San Jose
300X Route Pattern
Partition Chicago
3001 Phone 2-1
Partition Atlanta
3001 Phone 3-1
Partitions and Calling Search Spaces 313
Route pattern 300X is in the San Jose partition, with DN 3001 assigned to both Phone 2-1
in the Chicago partition and Phone 3-1 in the Atlanta partition.
When the phone dials 3001, the following will happen:
CUCM interprets the dialed digits and searches for the closest match. The two DN entries
in the call-routing table are more specific than the route pattern of 300X. Phone 2-1 is
chosen because its partition is listed first in the concatenated CSS.
Figure 13-5 illustrates the line CSS having higher priority than the device CSS. If the line
CSS and device CSS were reversed, the call would be sent to Phone 3-1. Notice that the
CSS subsequently performs closest-match routing against all partitions in the CSS at the
same time. If the CSS had been strictly processed on the San Jose partition before
considering the Chicago or Atlanta partitions, 300X would have been the match. Instead,
CUCM was aware of the closest match of 3001 in the other partitions. The partition order
is used as a tiebreaker if there are multiple closest matches.
Figure 13-6 is using partitions and CSS to implement four different classes of service:
■ Internal: Allows internal calls only
■ Local: Allows internal and local PSTN calls
■ Long Distance: Allows internal, local PSTN, and long-distance PSTN calls
■ International: Allows internal, local PSTN, long distance, and international PSTN calls
The following partitions are applied as described:
■ Phones: This partition is applied to all phone lines.
■ Local-PSTN: This partition is applied to route pattern 9.[2–9]XXXXXX
■ LD-PSTN: This partition is applied to route pattern 9.1[2–9]XX[2–9]XX XXXX
■ Intl-PSTN: This partition is applied to route pattern 9.011! and 9.011!#.
NOTE It is a common misunderstanding that the first matching pattern (regardless of
the quality of the match) that is found when searching through the partitions in the order
specified in the CSS is used for call routing. If this were true, subsequent partitions of the
CSS would only be looked at, if no match (of any kind) were found in the earlier
partitions. This is not the case. All partitions are immediately considered for the bestmatch
logic, and only if multiple best matches exist does the partition order become
relevant.
314 Chapter 13: Calling Privileges
The following CSSs are configured, each implementing the corresponding service class:
■ CSS-Internal: Containing partition Phones
■ CSS-Local: Containing partitions Phones and Local-PSTN
■ CSS-LD: Containing partitions Phones, Local-PSTN, and LD-PSTN
■ CSS-International: Containing partitions Phones, Local PSTN, LD-PSTN, and
Intl-PSTN
Figure 13-6 CSS Example
NOTE CSSs take on an inverted logical approach when assigned to devices such as
Session Initiation Protocol (SIP) trunks, intercluster trunks, and gateways. Calls that are
routed through a trunk or gateway take on the CSS applied at the device. In a multicluster
distributed call-processing environment, it is not advised to allow emergency call routing
across trunk links. Most organizations locally route emergency calls to the local public
safety answering point (PSAP). It is common practice to restrict emergency call routing
in the CSS applied to trunks.
CSS Internal CSS Local CSS LD CSS
International
Partition Phones
(All Phone DNs)
Partition Local-PSTN
9[2-9]XXXXXX
Partition LD-PSTN
91[2-9]XX[2-9]XXXXXX
Partition
Intl-PSTN
9011!#
X
X
X
X
X X
Internal Calls
Local Calls
Long-Distance
Calls
International
Calls
IP
Assigned CSS determines
calling privilege.
Partitions and Calling Search Spaces 315
Configuration of partitions and CSSs includes the following steps:
Step 1 Create partitions.
Step 2 Assign partitions to the DN, route-translation patterns, CTI ports, voicemail
ports, meet-me conference bridge numbers, call-park ranges, and
any other number in the system.
Step 3 Create CSSs.
Step 4 Add partitions in the desired order into each newly created CSS.
Step 5 Assign CSSs to entities that can request lookups to the call-routing table
to route a call; examples for such entities are phones and phone lines,
trunks, gateways, and translation patterns.
To add partitions in CUCM Administration, navigate to Call Routing > Class of Control
> Partition and click the Add New button. Figure 13-7 shows the Partition Configuration
page in CUCM. You can add up to 75 partitions in one insertion of partitions with a
character limitation of 1475 characters. If more than 75 partitions are required, you may
perform multiple insertions.
Partition names should not be lengthy because the CSS has a maximum length restriction
of 1024 characters. A CSS is a string of partition names. The 1024-character limit includes
separator characters between each partition name. (For example, the string
“partition_1:partition_2:partition_3” contains 35 characters.) The maximum number of
partitions in a CSS varies, depending on the length of the partition names and number of
partitions. If individual CSSs are used on both the device and line level, the maximum
character limit for the individual CSS is 512 (half the combined CSS clause limit of 1024
characters).
Figures 13-8 and 13-9 show the application of partitions, respectively, to a DN and route
pattern.
NOTE A translation pattern is a dialable pattern in the call-routing table. When a
translation pattern is matched, it invokes a new call-routing request for the translated
pattern. Which partition the translation pattern is in limits the devices that can access the
translation pattern. The CSS of the translation pattern specifies the entries of the callrouting
table that the translation pattern is allowed to see for the new call-routing request
when it is trying to find the translated pattern in the call-routing table.
316 Chapter 13: Calling Privileges
Figure 13-7 Partition Configuration
Figure 13-8 Partition Application: Directory Number
Partitions and Calling Search Spaces 317
Figure 13-9 Partition Application: Route Pattern
Figure 13-10 shows the Calling Search Space Configuration page. This page is accessible
by navigating to the following CUCM Administration menu: Call Routing > Class of
Control > Calling Search Space. Click the Add New button to add a new CSS. The CSS
should be given a name that is descriptive of the desired functionality. LD_Calling Search
Space would be descriptive of a CSS that allows long-distance, local, emergency, and
internal dialing. Click a partition in the Available Partitions section of the configuration
page and use the down arrow to move the partition to the Selected Partitions section. You
can use the up and down arrows to the right of the Selected Partitions section to move the
priority of the selected partition. The top of the list is the highest priority. The emergency
partition should normally be at the top of the list.
Figure 13-11 displays the phone configuration page with a CSS applied. CSSs can be
assigned to phones, phone lines, gateways, trunks, voice-mail pilots, voice-mail ports, CTI
route points, CTI ports, translation patterns, and any other source of a call-routing request.
Subscribe to:
Posts (Atom)