The number of issues that could arise in your VoIP deployment
involving voice gateways are too numerous to capture in one blog. The
issues and variants are probably too numerous to capture in one blog
series. So, my intention with this series is to simply touch on methods
I use for testing some (not all) issues I have come across with voice
gateways. Part 1 of this series will focus on how an admin can
configure the dial plan in such a way that allows them to "seize" or
force calls out any individual T1/E1 voice circuit in their
Cisco Unified Communications Manager solution.
Background
It could be that you don't know what I mean by "seizing" a channel
or that you wonder why I keep putting "seize" in quotes. On many PBX
systems there is a way for the admin of the system to force an
individual call out any voice circuit attached to the system. It is a
way for the admin to test physical circuits and validate call path.
Different admins and PBX vendors use different terms for this but
"seizing" the trunk seems to be a common colloquialism. I use quotes
when referring to "seizing" a trunk with Cisco Unified Communication
Manager (CUCM) simply because the concept doesn't inherently exist in
the product. If you want to implement a feature which allows admins to
selectively send calls out a particular voice circuit, you will have to
design and build it into your dial plan.
Example Dial Plan Scenario
While CUCM dial plan configurations vary from environment to environment, there are common elements across all designs:
- Devices (phones) are configured with Calling Search Spaces (CSS)
- Calling Search Spaces contain one or more partitions
- Partitions contain one or more route patterns
- Route patterns are configured (most of the time) to use route lists
- Route lists contain one or more route groups
- Route groups contain one or more gateways or trunks
Gateways basically bridge call legs between administratively
separated domains (in the case of IP-IP gateway) or domains separated by
signal methodology (i.e. MGCP and TDM). The gateway or trunk
destination is not an important consideration for the method discussed.
A sample dial plan scenario is provided in the following figure:
There is nothing extraordinary in the example above, a user in
Washington, D.C. dials the directory information line for the District
of Columbia and assuming it isnt a blocked pattern the call will use a
geographically designated route list. The route list may contain
gateways in other geographic areas for redundancy purposes or not. In
Chicago, a separate user tries to reach the same directory number may
use a separate route list (assuming least cost routing is not
implemented).
The Problem Scenario
Assume that the CUCM administrator is located in Chicago and wants to
test call routing behavior using the gateways located in D.C. There are
several solutions to this question, assuming that the dial plan design
isnt that robust the answer most commonly used would be to reconfigure a
test phone in Chicago with the D.C. calling search space and place the
test call.
Now, assume that the Chicago administrator wants to test an outbound
call through a D.C. PRI on the second gateway in Route Group 2 (which is
the 4th gateway in the outbound selection list). In many cases this is
more difficult and one may juggle route group priority orders to
accomplish this.
Administrators may need to selectively test new PRIs added to the
system, PRIs that may have voice quality issues, PRIs that may be
rejecting long distance calls, or PRIs that have just undergone
maintenance. Expanding on this care and feeding concept, an
administrator may want to test individual analog circuits, or inter-PBX
connections, analog termination on a video MCU, or any other critical
system resource.
Using the standard approach the change needed to make a single test
is overly cumbersome, may require coordination (i.e. Change Control
window), and may introduce unexpected consequences.
A Possible Solution
The NetCraftsmen solution to this administrative
burden is to build an overlay dial plan where specific patterns are used
that allow a single phone to directly dial a remote party using any
gateway configured in the Cisco IP telephony environment.
The basics:
- Create trunk test route groups
- Assign trunk test route groups to trunk test route lists
- Assign one gateway to one trunk test group
- Create pattern designations to uniquely identify trunk test codes
- Place trunk test codes in a partition visible from all IP phone calling stations
- Assign Forced Authorization Codes to provide a level of authorization
To illustrate, look at the following figure which illustrates the overlay concept using the previous example.
Building the Route List - MGCP Environments
With CUCM 4.1 and later an administrator can assign
a single gateway to more than one route group so this allows for two
optional configurations when building a route list to work with the
Trunk Access methodology.
First, all route groups can be configured in a 1:1 relationship with
gateways. So, gateway1 will be part of Route Group1 and Route Group1 can
be part of any Route List including the Trunk Testing Route List. The
net benefit in the end game is fewer Route Groups which isnt usually a
major issue in most environments.
The second option is to assign a gateway to normal call route groups
in whatever way makes sense for the existing design and then assign the
gateway to a separate Trunk Test route group specifically for use with
trunk access testing. With the introduction of Standard Local Route
Groups (SLRG) in CUCM 7.x, placing multiple gateways in a single route
group is the option many folks will prefer.
In our example it doesn't matter which method an admin uses for their
standard call path selection. We are going to create route groups with a
single Gateway membership (note we assume two PRIs on each IOS
gateway):
- DC PSTN-localgw1 RG1: DC Gateway 1 is the only member
- DC PSTN-localgw1 RG2: DC Gateway 2 is the only member
- DC PSTN-localgw2 RG1: DC Gateway 3 is the only member
- DC PSTN-localgw2 RG2: DC Gateway 4 is the only member
- DC PSTN-localgw3 RG1: DC Gateway 5 is the only member
- DC PSTN-localgw3 RG2: DC Gateway 6 is the only member
Once assigned to route groups, these gateways can be placed in any
production route list. In addition the same route groups can be assigned
to route lists specifically used for trunk access testing:
- DC Test-PRI01 RL: DC PSTN-localgw1 RG1 is the only member
- DC Test-PRI02 RL: DC PSTN-localgw1 RG2 is the only member
- DC Test-PRI03 RL: DC PSTN-localgw2 RG1 is the only member
- DC Test-PRI04 RL: DC PSTN-localgw2 RG2 is the only member
- DC Test-PRI05 RL: DC PSTN-localgw3 RG1 is the only member
- DC Test-PRI06 RL: DC PSTN-localgw3 RG2 is the only member
Building the Route List - H323/SIP Environments
With MGCP, each individual T1/E1 is registered to
the CUCM cluster as a MGCP end-point. This is not the case with H.323
and SIP. You could have 16 T1-PRIs terminated on a H.323 gateway and the
CUCM references the gateway by a single entry. In other words, the
trunks connected to a H.323 gateway are transparent from a CUCM
perspective.
This is not a problem, you just need to incorporate that known fact
into your dial plan. You can do this on individual test patterns
(discussed later) or you can accomplish this by configuring multiple
route groups that contain the same H.323 gateway. Then, when you assign
the route groups to a route list, modify the called party
transformations to prefix digits that the remote H.323/SIP dial-peers
will handle in a deterministic way.
For our purposes, we suggest creating a single route group for the
H.323/SIP gateway that will be tested and then assign this route group
as the only member of a route list used for testing. If you have
multiple circuits on the H.323/SIP gateway then you'll use the test
pattern to accommodate your dial-peer pattern matching needs. We'll get
into this shortly.
Building the Dial Plan
All call routing starts with a digit pattern and
the approach outlined in this blog is no different. As such it requires
design consideration with respect to the existing dial plan solution.
The first question that must be addressed is what partition should be
used.
NetCraftsmen typically builds a partition that is dedicated to
services which are only visible to IP phones on the CUCM cluster. For
optimum flexibility it is recommended that the administrator use a
partition that is visible from all IP phone calling search spaces, is
not part of any ToD routing solution, and is not visible from any non-IP
phone calling search space (i.e. gateway CSS or voicemail port CSS).
For the purpose of continuing the example, the CL Svcs-Priv PT is used.
- CL is used to designate scope, in this case cluster wide.
- Svcs-Priv identifies this partition as a partition that provides special services that are only available to the local cluster.
After choosing the partition the next step is to identify a digit
pattern which is scalable, flexible, and non-overlapping. The asterisk *
is a useful digit in to avoid overlapping conditions (keeping in mind
that using the asterisk in this way is not an original idea!).
Since scalability is critical and it is possible we may want to
extend the usage of asterisk, a digit sequence could be added to
designate a feature request. If two digits are used then the
administrator can have 100 such features which should be sufficient in
most cases. For this example we will reserve 0x for any
telecommunication special service codes and assuming this is the first
such application we will use *07.
Next a digit pattern is needed to uniquely assign to each gateway in
the environment. Another consideration is possibly using a digit flag
which identifies geographic location, cluster identification, or some
other convention that makes sense to the organization or existing
standard. Keep in mind that the future may bring changes that quickly
introduce a numbering standard to obsolescence (e.g. using private IP
address schemes that try to use octets as site designations).In this
example we will use two digits which allows for 100 such configurations.
So, given our standard:
- *0701 will use DC Test-PRI01 RL
- *0702 will use DC Test-PRI02 RL
- *0703 will use DC Test-PRI03 RL
- *0704 will use DC Test-PRI04 RL
- *0705 will use DC Test-PRI05 RL
- *0706 will use DC Test-PRI06 RL
The patterns as they are listed above are not sufficient to satisfy
the needs of the CUCM digit analysis subsystem. To make these patterns
functional we will actually define a pre-dot digit truncation method,
allow any number of digits following the pattern, and define a
termination string. With these new configuration changes the pattern for
DC Test-PRI01 RL is
*0701.!#, the pattern for DC Test-PRI02 RL is
*0702.!#, and so on.
The idea is that the administrator will supply all digits needed by
the PSTN to route the call. So, if the administrator was going to call
toll free information on DC PRI 01, the test pattern is:
*070118005551212#
So, the above would match the route pattern: *0701.!# and the route
pattern is configured to strip pre-dot, the gateway receives
18005551212.
Some other examples:
| Test Pattern |
Usage Example |
| *0703411# |
Sending information calls (411) out PRI number 3 |
| *0705914105551212# |
Sending calls to directory information service
line for Maryland to a PBX or Centrex Intercomm switch that requires an
offnet code of 9. |
| *070410100333015551212# |
Use the Sprint long distance PIC code to dial information in California using PRI number 4. |
| *07012025551212# |
Dial information in Washington D.C. as a local 10-digit number using PRI number 1. |
Going back to our problem scenario: The administrator in Chicago
wants to test a call to the D.C. information line using the fourth PRI
in the trunk group they would go off hook and dial *07042025551212#.
Note that the administrator does not need to specify a leading digit of 1
for long distance since the call is not long distance from the DC trunk
group.
Building the Dial Plan - H.323/SIP Considerations
The previous section assumes that you are using
MGCP gateways. For the most part, the examples laid out in the previous
section are applicable to call agent controlled (e.g. MGCP) and gateway
controlled (e.g. H.323) protocols. However, there are a few other things
to consider with call signaling scenarios that use gateway controlled
protocols.
You can still use the route pattern conventions as defined. The only
thing you need to work out is what digit patterns would you like to
prefix to the pattern so that the remote H.323 gateway knows which trunk
it should use? Basically, come up with a pattern prefix that the CUCM
sends to the gateway which aligns with a POTS dial-peer pointing to the
trunk you wish to test.
An example dial-peer configuration on one of the D.C. voice gateways in our example could be:
dial-peer voice 79000 pots
description Trunk Testing circuit 1
destination-pattern 1990T
port 0/0/0:23
!
dial-peer voice 79001 pots
description Trunk Testing circuit 2
destination-pattern 1991T
port 0/0/1:23
!
If an admin wishes to test the T1-PRI connected to port 0/0/1 on the
example voice gateway, they could use the digit string: *0702
7035551212#. This would match route pattern:
*0702.!#. In this route pattern you would use the called party transformation section to strip the pre-dot and prefix
1991. When the gateway receives the call setup, it will strip the 1991 and send the remaining digits to the PSTN for processing.
Note that you will want to keep your gateway's Class of Restriction
(COR) configuration in mind for SRST-enabled gateways. If you don't
assign a COR to the test pattern dial-peers but use a corlist
configuration for your attached ephones, then you will introduce an
opening to toll-fraud scenarios. So, if you use COR on your H.323
gateway, then configure a special COR for these test patterns (e.g.
corlist specialTelecomm) and make sure that the COR isn't a member of
any SRST ephone corlist.
Authorization Codes
Our solution uses a dial-plan overlay that the
operations team can use for testing. Our objective is to minimize
unnecessary reconfiguration of phones (i.e. CSS) or route list/route
group membership. At the same time, we don't want just any user being
able to learn about the trunk access codes and use them to bypass any
COR configurations you have in your production dial-plan. Is this
likely? Who knows. It is a possible toll-fraud scenario and in my mind,
that means it can't be ignored.
The solution is actually quite simple. For all route patterns
configured for trunk testing use Forced Authorization Codes (FAC).
Assign a permissions level like "250". Then create FAC codes for each of
your operations staff or groups of staff members (whatever works best
for you). Make sure the FAC permission level used is "higher" or "more
restrictive" then what you may already have in place for local, long
distance, interlata, international, etc..
If you use FAC and a user was clever enough to figure out the test
pattern they would be blocked. Unless, of course, the user also figured
out the FAC code. That would reinforce an operational recommendation to
review CDRs periodically and to enable storing FAC codes in CDRs.
However, this is definitely a topic for another day!
