CCNP Training in Delhi: 2010

Friday, December 17, 2010

SRST Dial Plan Voice Translation-Profile Commands for Digit Manipulation Best Cisco CCIE Training Institute 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

The combination of voice translation-profiles and voice translation-rules creates a very
powerful tool for modifying numbers so that they match dial plan needs. Example 6-12
shows the configuration commands for voice translation profiles.
Example 6-12 Voice Translation-Profile Commands
RemoteSite#configure terminal
R e m o t e S i t e ( c o n f i g ) # v o i c e t r a n s l a t i o n - p r o f i l e name
R e m o t e S i t e ( c f g - t r a n s l a t i o n - p r o f i l e ) # t r a n s l a t e { c a l l e d I c a l l i n g I
r e d i r e c t - c a l l e d I r e d i r e c t - t a r g e t } translation-rule-number
You define a translation profile for voice calls using the voice translation-profile command
in global configuration mode. The name parameter of this command defines the name of
the translation profile. The maximum length of the voice translation-profile name is 31
alphanumeric characters.
You associate a translation rule with a voice translation profile using the translate command
in voice translation-profile configuration mode. The following list defines the
keywords and parameter for the translate command:
• called associates the translation rule with called numbers.
• calling associates the translation rule with calling numbers.
• redirect-called associates the translation rule with redirected called numbers.
• redirect-target associates the translation rule with transfer-to numbers and callforwarding
final destination numbers.
• translation-rule-number is the number of the translation rule to use for the call
translation. The valid range is from 1 to 2147483647. There is no default value.
NOTE The prior IOS digit manipulation tool translation rule has been replaced by
voice translation-rule. The commands are similar but are incompatible with each other.
SRST Dial Plan Voice Translation-Profile Commands for Digit Manipulation 143
SRST Dial Plan Voice Translation-Rule Commands for
Number Modification
Example 6-13 shows the configuration commands for voice translation-rules.
Example 6-13 Voice Translation-Rule Commands
RemoteSite#configure terminal I
RemoteSite(config)#voice translation-rule number
r o u t e r ( c f g - t r a n s l a t i o n - r u l e ) # r u l e precedence /match-pattern/
/replace-pattern/[type {match-type replace-type} [plan
{match-type replace-type}))
You define a translation rule for voice calls using the voice translation-rule command in
global configuration mode. The number parameter identifies the translation rule. The range
of the number is from 1 to 2147483647. The choice of the number does not affect usage
priority.
You define a translation rule using the rule command in voice translation-rule configuration
mode. The following list defines the keywords and parameters for the rule command, as
shown in Example 6-13:
• The parameter precedence defines the priority of the translation rule. The range is from
1 to 15.
• The parameter /match-pattern/ is a stream editor (SED) expression used to match
incoming call information. The slash (/) is a delimiter in the pattern.
• The parameter/replace-pattern/ is a SED expression used to replace the match pattern
in the call information. The slash is a delimiter in the pattern.
• The optional construct type match-type replace-type lets you modify the call's number
type. Valid values for the match-type argument are abbreviated, any, international,
national, network, reserved, subscriber, and unknown. Valid values for the replacetype
argument are abbreviated, international, national, network, reserved,
subscriber, and unknown.
• The optional construct plan match-type replace-type lets you modify the call's
numbering plan. Valid values for the match-type argument are any, data, ermes, isdn,
national, private, reserved, telex, and unknown. Valid values for the replace-type
argument are data, ermes, isdn, national, private, reserved, telex, and unknown.
144 Chapter 6: Implementing Cisco Unified SRST and MGCP Fallback
SRST Dial Plan Profile Activation Commands for Number Modification
Voice translation profiles can be bound to dial peers, source groups, trunk groups, voice
ports, and the voice service POTS.
Example 6-14 shows the configuration commands for voice translation profile activation.
Example 6-14 Voice Translation Rule Activation Commands
RemoteSite#configure terminal
RemoteSite(config)#voice-port 0/1/0:23
RemoteSite(config-voiceport) # t r a n s l a t i o n - p r o f i l e {incoming I outgoing} name
R e m o t e S i t e ( c o n f i g - v o i c e p o r t ) # e x i t
RemoteSite(config)#call-manager-fallback
r o u t e r ( c o n f i g - c m - f a l l b a c k ) # t r a n s l a t i o n - p r o f i l e {incoming I outgoing} name
In this example, the voice translationprofile is bound to a voice port. The voice
translationprofile can also be bound to all the dial peers, but the voice port needs to
be done only once.
You assign a translation profile to a voice port using the translation-profile command in
voice-port configuration mode. The following list defines the keywords and parameter for
the translation-profile command:
• The keyword incoming specifies that this translation profile handles incoming calls.
• The keyword outgoing specifies that this translation profile handles outgoing calls.
• The parameter name is the name of the translation profile.
In addition to the configuration shown in Example 6-14, the voice translation profiles can
be bound to the call-manager-fallback Cisco IOS service. The structure of the command
is identical.
NOTE The incoming direction of the voice translation-profile bound to the callmanager-
fallback Cisco IOS service handles the calls coming from IP Phones that are
registered with the router.
For more information about voice translation profiles, refer to the following documents at
Cisco.com, which you should be able to locate by searching by title:
• TechNotes Number Translation Using Voice Translation Profiles
• TechNotes Voice Translation Rules
SRST Dial Plan Class of Restriction Commands 145
SRST Dial Plan Class of Restriction Commands
Calling privileges can be assigned to IP Phones when they are in SRST mode using COR
commands. In the absence of COR in SRST dial peers, all phones can dial all numbers.
Example 6-15 shows the dial plan configuration commands for COR as they apply to SRST.
Example 6-15 Class of Restriction Commands
RemoteSite#configure terminal
RemoteSite(config)#call-manager-fallback
RemoteSite(config-cm-fallback)#cor {incoming I outgoing} cor-list-name
[cor-list-number starting-number - ending-number I default]
The command cor configures a COR on dial peers that are associated with directory
numbers. The following list defines the keywords and parameters for the cor command:
• The keyword incoming defines that a COR list is to be used by incoming dial peers.
• The keyword outgoing defines that a COR list is to be used by outgoing dial peers.
• The parameter cor-list-name is the COR list name.
• The parameter cor-list-number is a COR list identifier. The maximum number of COR
lists that can be created is 20, composed of incoming or outgoing dial peers. The first
six COR lists are applied to a range of directory numbers. The directory numbers that
do not have a COR configuration are assigned to the default COR list, as long as a
default COR list has been defined.
• The parameters starting-number - ending-number define the directory number range,
such as 2000 to 2025.
• The keyword default instructs the router to use an existing default COR list.
Table 6-2 summarizes the functions of COR dialed calls.
146 Chapter 6: Implementing Cisco Unified SRST and MGCP Fallback
Table 6-2 COR Dialing Possibilities
COR List on Incoming Dial
Peer
COR List on Outgoing Dial
Peer Result
No COR No COR The call succeeds.
No COR A COR list is applied for
outgoing calls.
The call succeeds. By default,
the incoming dial peer has the
highest COR priority when no
COR is applied. If you apply no
COR for an incoming call leg
to a dial peer, the dial peer can
make a call out of any other dial
peer, regardless of the COR
configuration on the outgoing
dial peer.
A COR list is applied for
incoming calls.
No COR The call succeeds. By default,
the outgoing dial peer has the
lowest priority. Because some
COR configurations exist for
incoming calls on the incoming
or originating dial peer, it is a
superset of the outgoing-call
COR configuration for the
outgoing or terminating dial
peer.
A COR list is applied for
incoming calls (a superset of
the COR list applied for outgoing
calls on the outgoing dial
peer).
A COR list is applied for
outgoing calls (subsets of the
COR list applied for incoming
calls on the incoming dial peer).
The call succeeds. The COR
list for incoming calls on the
incoming dial peer is a superset
of the COR list for outgoing
calls on the outgoing dial peer.
A COR list is applied for
incoming calls (a subset of the
COR list applied for outgoing
calls on the outgoing dial peer).
A COR list is applied for
outgoing calls (supersets of the
COR list applied for incoming
calls on the incoming dial peer).
The call does not succeed. The
COR list for incoming calls on
the incoming dial peer is not a
superset of the COR list for
outgoing calls on the outgoing
dial peer.
NOTE The complete configuration of COR is handled in the Cisco Voice over IP
course. Table 6-2 presents an overview only.
SRST Dial Plan Example
Figure 6-8 shows a multisite topology with a Cisco Unified SRST-enabled Cisco IOS router
in the remote site.
SRST Dial Plan Class of Restriction Commands 147
Figure 6-8 SRST Dial Plan Topology
Main Site
Cisco Unified
Communications
Manager
Phonel Phone2 Phone3
This figure shows a main site with a PSTN number of 51 l-555-2xxx and a remote site with
a PSTN number of 521-555-3xxx. Four digits are used for all internal calls, including calls
between the main site and remote site. The remote-site gateway has a single ISDN PRI
connection to the PSTN configured on port 0/1/0:23.
For the SRST remote-site configuration shown in Example 6-16, assume that the remote
site has only three phones, with one DN each. During SRST fallback, Phone 1 is configured
with directory number 3001 and has unlimited PSTN dialing access. Phone 2 is configured
with directory number 3002 and is not be allowed to place international calls. Phone 3 is
configured with directory number 3003 and is allowed to place only internal calls. Fourdigit
dialing to headquarters is configured, and calls should be sent to the main site over the
PSTN when in SRST mode.
The remote-site router also requires MGCP configurations, as discussed previously, but
they are not included in Example 6-16 for simplicity.
Example 6-16 Remote-Site SRST Dial Plan Configuration Example
a p p l i c a t i on
g l o b a l
s e r v i c e a l t e r n a t e d e f a u lt
i
•
c a l l - m a n a g e r - f a l l b a ck
ip source-address 10.1.250.101 port 2000
max-ephones 3
max-dn 3
cor incoming phonel 1 3001
cor incoming phone2 2 3002
continues
148 Chapter 6: Implementing Cisco Unified SRST and MGCP Fallback
Example 6-16 Remote-Site SRST Dial Plan Configuration Example (Continued)
cor incoming phone3 3 3003
d i a l p l a n - p a t t e r n 1 5215553...
e x t e n s i o n - l e n g t h 4
I
d i a l - p e e r cor custom
name i n t e r n al
name pstn
name p s t n - i n tl
I
d i a l - p e e r cor l i s t i n t e r n al
member i n t e r n al
!
d i a l - p e e r cor l i s t pstn
member pstn
I
d i a l - p e e r cor l i s t p s t n - i n tl
member p s t n - i n tl
I
d i a l - p e e r cor l i s t phonel
member i n t e r n al
member pstn
member p s t n - i n tl
I
d i a l - p e e r cor l i s t phone2
member i n t e r n al
member pstn
I
d i a l - p e e r cor l i s t phone3
member i n t e r n al
I
d i a l - p e e r voice 1 pots
d e s c r i p t i o n I n t e r n a l d i a l i n g from the PSTN
incoming called-number .
d i r e c t - i n w a r d - d i a l
p o r t 0/1/0:23
!
d i a l - p e e r voice 9 pots
d e s c r i p t i o n PSTN d i a l 9 f i r s t
c o r l i s t outgoing pstn
d e s t i n a t i o n - p a t t e r n 9T
port 0/1/0:23
!
d i a l - p e e r voice 9011 pots
d e s c r i p t i o n I n t e r n a t i o n a l d i a l 9 f i r s t
c o r l i s t outgoing p s t n - i n tl
SRST Dial Plan Class of Restriction Comman ds 149
Example 6-16 Remote-Site SRST Dial Plan Configuration Example (Continued)
d e s t i n a t i o n - p a t t e r n 9011T
p o r t 0/1/0:23
p r e f i x 011
I
•
d i a l - p e e r voice 2000 pots
d e s c r i p t i o n I n t e r n a l 4 d i g i t d i a l i n g to HQ
c o r l i s t outgoing i n t e r n al
t r a n s l a t i o n - p r o f i l e outgoing to-HQ
d e s t i n a t i o n - p a t t e r n 2 . ..
port 0/1/0:23
I
v o i c e t r a n s l a t i o n - r u l e 1
r u l e 1 r2l /15115552/
i
•
v o i c e t r a n s l a t i o n - p r o f i l e to-HQ
t r a n s l a t e c a l l e d 1
The first part of the SRST configuration includes the dialplan-pattern command
configured under call-manager-fallback configuration mode, which maps the internal
four-digit directory numbers to the E.164 PSTN number.
COR lists are configured for internal destinations called internal, for international PSTN
destinations named pstn-intl, and for all other PSTN destinations labeled pstn. These COR
lists are applied to dial peers as outgoing COR lists. Their function is equivalent to partitions
in CUCM.
Additional COR lists are configured, one per phone. These are applied as incoming COR
lists to phone directory numbers using the cor incoming command in call-managerfallback
configuration mode. The configuration shown in Example 6-16 applies the
incoming COR list phonel, which is equivalent to CSSs in CUCM, to phone 1, which
registers with the SRST gateway with a directory number of 3001, incoming COR list
phone2 to the phone with directory number 3002, and incoming COR list phone3 to the
phone with directory number 3003.
Outgoing COR lists are applied to the dial peers that are used as outgoing dial peers: dial
peer 9011 for international PSTN calls, dial peer 9 for PSTN calls, and dial peer 2000 for
calls to headquarters.
150 Chapter 6: Implementing Cisco Unified SRST and MGCP Fallback
NOTE For simplicity, Example 6-16 does not show all the outbound dial peers, as
shown previously in Example 6-9. Using the destination pattern 9T as shown in dial
peer 9 typically is avoided when possible for local or national calls to avoid the interdigit
timeout associated with the T wildcard.
Dial peer 1 is configured for inbound dialing from the PSTN with the incoming callednumber
command to identify all destination phone numbers. Direct inward dialing is enabled,
which turns off the second dial tone at ISDN port 0/1/0:23 for external calls dialing in.
The called E.164 numbers (521-555-3xxx) are mapped to four-digit extensions because of
the dialplan-pattern command that is configured in call-manager-fallback configuration
mode. As a result, incoming PSTN calls are sent to the four-digit extensions.
Outgoing calls to phones located at the main site at extensions 2xxx match a destination
pattern in dial peer 2000. Dial peer 2000 sends calls to port 0/1/0:23 after performing digit
manipulation using the to-HQ voice translation profile. This profile translates the four-digit
called number to an 11-digit E. 164 PSTN number. The result is that during SRST fallback,
users can still dial four-digit extensions to reach phones in headquarters.

SRST Dial Plan of CFUR and CSS Best Cisco CCIE Security Training Center 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

The CFUR feature is a way to reroute calls placed to a temporarily unregistered destination
phone. The configuration of CFUR consists of the two main elements of destination
selection and CSS, as shown in Figure 6-6. Choose Cisco Unified Communications
Manager Administration > Call Routing > Directory Number.
Figure 6-6 SRST Dial Plan Configuration of CFUR and CSS
When the directory number is unregistered, calls can be rerouted to the voice mail that
is associated with the extension or to a directory number that is used to reach the phone
through the PSTN. The latter approach is preferable when a phone is located within a site
whose WAN link is down. If the site is equipped with SRST, the phone (and its co-located
PSTN gateway) reregisters with the co-located SRST router. The phone then can receive
calls placed to its PSTN direct inward dialing (DID) number.
134 Chapter 6: Implementing Cisco Unified SRST and MGCP Fallback
In this case, the appropriate CFUR destination is the corresponding PSTN DID number of
the original destination directory number. Configure this PSTN DID in the destination field,
along with applicable access codes and prefixes. For this example, the number would be
9-1-481-555-0001.
CUCM attempts to route the call to the configured destination number using the CFUR CSS
of the called directory number. The CFUR CSS is configured on the target phone and is
used by all devices that are calling the unregistered phone. This means that all calling
devices use the same combination of route pattern, route list, route group, and gateway to
place the call, and that all CFUR calls to a given unregistered device are routed through the
same unique gateway, regardless of where the calling phone is located. It is recommended
that you select a centralized gateway as the egress point to the PSTN for CFUR calls. You
also should configure the CFUR CSS to route calls that are intended for the CFUR
destination to this centralized gateway.
SRST Dial Plan: Max Forward UnRegistered
Hops to DN
The CUCM service parameter Max Forward UnRegistered Hops to DN reduces the
impact caused by CFUR routing loops, as shown in Figure 6-7. Choose CUCM
Administration > System > Service Parameter > Cisco CallManager.
Figure 6-7 SRST Dial Plan Configuration of Max Forward UnRegistered Hops to DN
This parameter specifies the maximum number of forward unregistered hops that are
allowed for a directory number at one time. It limits the number of times the call can be
forwarded because of the unregistered directory number when a forwarding loop occurs.
Use this count to stop forward loops for external calls that have been forwarded by CFUR,
SRST Dial Plan Components for Normal Mode Analogy 135
such as intercluster IP Phone calls and IP Phone-to-PSTN phone calls that are forwarded to
each other. CUCM terminates the call when the value that is specified in this parameter is
exceeded. The default 0 disables the counter but not the CFUR feature. The allowed range
is from 0 to 60.
MGCP Fallback and SRST Dial Plan Configuration
in the Cisco IOS Gateway
A dial plan in SRST mode, at a minimum, enables the remote-site users to place and receive
calls from the PSTN.
At least one dial peer needs to be configured to enable calls to and from the PSTN. The
destination pattern of that dial peer has to correspond to the PSTN access code (for example,
9T). The more elegant way is to configure several dedicated dial peers with destination
patterns that match the number patterns in a closed numbering plan, such as 91
(91 followed by ten dots).
In countries that have variable dial plans, the only destination pattern that is needed is 9T.
Because of the variable length of dialed numbers, the router waits for the interdigit timeout
(T302) or for a hash (#) sign to indicate the end of the dial string. Cisco Unified SRST
version 4.1 and Cisco Unified Communications Manager Express Release 4.1 do not
support the overlap sending feature to the PSTN. The receiving of ISDN overlap dialing
from PSTN is supported but has to be enabled on the interfaces. To shorten the wait time
for users after they complete the dial string, it is possible to reduce the interdigit timeout
from the SRST default of 10 seconds.
SRST Dial Plan Components for Normal
Mode Analogy
A good SRST dial plan is as close as possible between the dialing functionality in normal
mode and in SRST mode. The telephony service should have the same look and feel for the
user, regardless of the mode the system is in. For example, it would be an unacceptable
failover design if the remote user required an awareness of WAN link connectivity when he
dials his headquarters.
The numbers in the call lists (such as missed calls) must have the correct format (PSTN
access code plus PSTN phone number) to enable users to use the list entries for dialing. The
calling party ID of incoming calls from the PSTN needs to be modified by voice translation
profiles and voice translation rules.
136 Chapter 6: Implementing Cisco Unified SRST and MGCP Fallback
Abbreviated dialing between sites of the site code plus the extension number is possible in
SRST mode. Voice translation profiles have to be used to expand the called numbers to
PSTN format for intersite dialing.
If the calling privileges (which normally are controlled by the CUCM) have to be preserved
in SRST mode, class of restriction (COR) configuration must be used.
SRST Dial Plan Dial Peer Commands
The dial-peer command is the main component for configuring dial plans on Cisco IOS
routers, as shown in Example 6-8.
Example 6-8 Dial Peer Commands for an SRST Dial Plan
RemoteSite#configure terminal
RemoteSite(config)#dial-peer voice tag pots
RemoteSite(config-dial-peer)#destination-pattern [+]string[T]
R e m o t e S i t e ( c o n f i g - d i a l - p e e r )#port slot-number/port
You define a particular dial peer, specify the voice encapsulation method, and enter dial
peer configuration mode using the dial-peer voice command in global configuration mode.
The following list defines the keywords and parameters used in the configuration shown in
Example 6-8:
• The parameter tag specifies digits that define a particular dial peer. The range is from
1 to 2147483647.
• The keyword pots indicates that this is a plain old telephone service (POTS) peer. The
option voip also exists, indicating that this is a VoIP peer, but is not mentioned in
Example 6-8 because POTS dial peers are predominately used for SRST. POTS dial
peers contain a port, whereas VoIP dial peers contain a configured IP address.
• You specify either the prefix or the full E.164 telephone number to be used for a dial
peer using the destination-pattern command in dial peer configuration mode.
• The optional character + indicates that an E. 164 standard number follows.
SRST Dial Plan Dial Peer Commands 137
• The parameter string defines a series of digits that specify a pattern for the E. 164 or
private dialing plan telephone number. Valid entries are the digits 0 through 9, the
letters A through D, and the following special characters:
*
#
+
A
S
\
[]
0
• The optional control character T indicates that the destination-pattern value is a
variable-length dial string. Using this control character enables the router to wait until
all digits are received before routing the call.
• To associate a dial peer with a specific voice port, use the port command in dial peer
configuration mode.
• The parameter slot-number defines the number of the slot in the router in which the
voice interface card (VIC) is installed. Valid entries depend on the number of slots that
the router platform has.
• The parameter port defines the voice port number. Valid entries are 0 and 1.
Table 6-1 lists common classes of PSTN calls in the North American Numbering Plan
(NANP) and lists the pattern that is used for each class. An access code of 9 should be used
to indicate a PSTN call. The exception is 911, which should be configured with and without
the access code 9. The patterns outlined in Table 6-1 must be reachable in SRST mode.
138 Chapter 6: Implementing Cisco Unified SRST and MGCP Fallback
An access code of 9 typically is used to indicate a PSTN call; however, other access codes
such as 8 are also permissible.
The patterns in the table are the minimum number of patterns that need to be reachable in
SRST mode.
Example 6-9 provides a sample configuration of dial peers only, demonstrating outbound
dialing to the PSTN in an SRST router. This example is in the NANP, which also shows
local ten-digit dialing in area code 919. The configuration as written can be directly pasted
into a router.
Example 6-9 Dial Peer Example for an SRST Dial Plan
SRST Dial Plan Dial Peer Comman ds 139
NOTE This example does not contain any class of restriction (COR), which currently
allows all SRST registered phones to dial all numbers, including long-distance, 900, and
international, without any constraint. COR is discussed later in this chapter. In addition,
dial peers 3 and 4 do not require the forward-digits command, and are added only for
clarity.
140 Chapter 6: Implementing Cisco Unified SRST and MGCP Fallback
SRST Dial Plan Commands: Open Numbering Plans
Example 6-10 defines the configuration commands for open numbering plans in an SRST
dial plan.
Example 6-10 SRST Dial Plan Commands for an SRST Dial Plan
RemoteSite#configure terminal
RemoteSite(config)#interface s e r i a l 0 / 1 / 0 : 23
R e m o t e S i t e ( c o n f i g - i f ) # i s d n overlap-receiving [T302 ms]
R e m o t e S i t e ( c o n f i g - i f ) # e x i t
RemoteSite(config)#call-manager-fallback
RemoteSite(config-cm-fallback)#timeouts i n t e r d i g i t sec
RemoteSite(config- cm - f a l l b a c k)#dialplan-pattern tag pattern
extension-length length [extension-pattern extension-pattern] [no-reg]
The following list defines the commands, keywords, and parameters used in the
configuration shown in Example 6-10:
• To activate overlap receiving on ISDN interfaces, you use the isdn overlap-receiving
command in interface configuration mode. This command is applicable on BRI interfaces
or on the ISDN interface of El/Tl controllers in PRI mode.
• The optional parameter T302 defines how many milliseconds the T302 timer should
wait before expiring. Valid values for the ms argument range from 500 to 20000. The
default value is 10000 (10 seconds).
CAUTION Modifying the T302 parameter, when connected to public networks, might
disable the function. The T302 describes the interdigit timeout for all phones in the
CUCM cluster.
• Configure the timeout value to wait between dialed digits for all Cisco IP Phones that
are attached to a router using the timeouts interdigit command in call-managerfallback
configuration mode.
• The parameter sec defines the interdigit timeout duration, in seconds, for all Cisco IP
Phones. Valid entries are integers from 2 to 120.
• Create a global prefix that can be used to expand the extension numbers of inbound and
outbound calls into fully qualified E.164 numbers using the dialplan-pattern
command in call-manager-fallback configuration mode.
• The parameter tag is the unique identifier that is used before the telephone number. The
tag number is from 1 to 5.
SRST Dial Plan Commands: Open Numbering Plans 141
• The parameter pattern is the dial plan pattern, such as the area code, the prefix, and the
first one or two digits of the extension number, plus wildcard markers or dots (.) for the
remainder of the extension-number digits.
• The keyword extension-length sets the number of extension digits that will appear as
a caller ID followed by the parameter length, which is the number of extension digits.
The extension length must match the setting for IP Phones in CUCM mode. The range
is from 1 to 32.
• The optional keyword extension-pattern sets the leading digit pattern of an extension
number when the pattern is different from the leading digits defined in the pattern
variable of the E.164 telephone number. An example is when site codes are used. The
parameter extension-pattern that follows defines the leading digit pattern of the extension
number. It is composed of one or more digits and wildcard markers or dots (.)• For
example, 5,. would include extensions 500 to 599, and 5... would include extensions
5000 to 5999. The extension pattern configuration should match the mapping of internal
to external numbers in CUCM.
• The optional keyword no-reg prevents the E. 164 numbers in the dial peer from registering
with the gatekeeper.
Example 6-11 demonstrates the use of the dialplan-pattern command, which shows how
to create a dial plan pattern for directory numbers 500 to 599 that is mapped to a DID range
of 408-555-5000 to 5099. If the router receives an inbound call to 408-555-5044, the dial
plan pattern command is matched, and the extension of the called E. 164 number, 408-555-
5000, is changed to directory number 544. If an outbound calling party extension number
(544) matches the dial plan pattern, the calling-party extension is converted to the E.164
number 408-555-5044. The E.164 calling-party number appears as the caller ID.
Example 6-11 SRST Dial Plan Example for Mapping Directory Numbers
RemoteSite#configure terminal I
RemoteSite(config)#call-manager-fallback
RemoteSite(config-cm-fallback)#dialplan-pattern 1 40855550..
extension-length 3 extension-pattern 5..

Dial Plan Configuration for SRST Support in CUCM Network bulls Best Networking Training Institute in 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

This section describes the configuration to adjust the CUCM dial plan to work with Cisco
Unified SRST.
The CUCM dial plan has to be adjusted to ensure the reachability of remote-site phones by
their extensions even if the remote site runs in SRST mode. The parameter that enables this
adjustment is the CFUR destination setting, which has to be defined on every line of an
SRST enabled remote-site phone. This parameter was introduced in Cisco Unified Communication
Manager Release 4.2.
The CFUR feature forwards calls to unregistered (disconnected or logged out) directory
numbers for the defined destination. The destination might be the PSTN number of a phone
at a remote site or the voice mail for a user in a CUCM Extension Mobility setting.
SRST Dial Plan of CFUR and CSS 133
To ensure that the feature works even if a major WAN breakdown disconnects all the remote
sites, only voice gateways located at the main site should be used. This can be ensured by
selecting the correct Calling Search Space (CSS) for the CFUR destination.
CFUR causes routing loops whenever there is a single disconnected SRST phone in
which the remote location is not in SRST mode. Internal calls to that directory number
are forwarded to the CFUR (PSTN) destination and are received by the remote-site gateway
in normal mode. This gateway handles the call as usual, sending the signaling to its
CUCM subscriber. CUCM then again forwards the call to the PSTN, causing an inevitable
routing loop.
To limit the impact of these routing loops, Cisco introduced a CUCM service parameter
called Max Forward UnRegistered Hops to DN. When activated, this counter limits the
calls that are forwarded to one CFUR destination.

MGCP-Gateway-Fallback Configuration on the Cisco IOS Gateway ccie training institute in india

SRST Configuration on the Cisco IOS Gateway ccsp training institute in 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

To configure Cisco Unified SRST on a Cisco IOS router to support the Cisco IP Phone
functions, follow these steps:
Step 1 Enter call-manager-fallback configuration mode to activate SRST.
Step 2 Define the IP address and port to which the SRST service binds.
Step 3 Define the maximum number of directory numbers to support.
Step 4 Define the maximum number of IP Phones to support.
Step 5 Define the maximum number of numbers allowed per phone type.
Step 6 Define the phone keepalive interval.
TIP When Cisco Unified SRST is enabled, Cisco IP Phones in call-manager-fallback
configuration mode do not have to be reconfigured, because phones retain the same
configuration that was used with CUCM.
SRST Configuration on the Cisco IOS Gateway 127
SRST Activation Commands
Example 6-1 shows the commands for the first two SRST configuration steps.
Example 6-1 SRST Activation Commands
RemoteSite#configure terminal
RemoteSite(config)#call-manager-fallback
R e m o t e $ i t e ( c o n f i g - c m - f a l l b a c k ) # i p source-address ip-address [port port]
[any-match I strict-match]
The Cisco IOS command call-manager-fallback enters call-manager-fallback configuration
mode.
The Cisco IOS command ip source-address enables the router to receive messages from
the Cisco IP Phones through the specified IP addresses and provides for strict IP address
verification. The default port number is 2000. This IP address will be supplied later as an
SRST reference IP address in CUCM Administration.
The ip source-address command is mandatory. The fallback subsystem does not start if the
IP address of the Ethernet port to which the IP Phones are connected (typically the Ethernet
interface of the local SRST gateway) is not provided. If the port number is not provided,
the default value (2000) is used.
The any-match keyword instructs the router to permit Cisco IP Phone registration even
when the IP server address used by the phone does not match the IP source address. This
option lets you register Cisco IP Phones on different subnets or those with different default
DHCP routers or different TFTP server addresses.
The strict-match keyword instructs the router to reject Cisco IP Phone registration attempts
if the IP server address used by the phone does not exactly match the source address. By
dividing the Cisco IP Phones into groups on different subnets and giving each group different
DHCP default router or TFTP server addresses, this option restricts the number of Cisco
IP Phones allowed to register.
SRST Phone Definition Commands
The commands shown in Example 6-2, max-dn and max-ephones, are mandatory because
the default values for both are defined as 0.
Example 6-2 SRST Phone Definition Commands
RemoteSite#configure terminal I
RemoteSite(config)#call-manager-fallback
RemoteSite(config-cm-fallback)#max-dn max-directory-numbers [dual-line]
[preference preference-order]
RemoteSite(config-cm-fallback)#max-ephones max-phones
128 Chapter 6: Implementing Cisco Unified SRST and MGCP Fallback
The Cisco IOS command max-dn sets the maximum number of directory numbers or
virtual voice ports that can be supported by the router and activates dual-line mode. The
maximum number is platform-dependent. The default is 0.
The dual-line keyword is optional. It allows IP Phones in SRST mode to have a virtual
voice port with two channels.
NOTE The dual-line keyword facilitates call waiting, call transfer, and conference
functions by allowing two calls to occur on one line simultaneously. In dual-line mode,
all IP Phones on the Cisco Unified SRST router support two channels per virtual
voice port.
The optional parameter preference sets the global preference for creating the VoIP dial
peers for all directory numbers that are associated with the primary number. The range
is from 0 to 10. The default is 0, which is the highest preference.
NOTE The router must be rebooted to reduce the limit on the directory numbers or
virtual voice ports after the maximum allowable number is configured.
To configure the maximum number of Cisco IP Phones that an SRST router can support,
use the max-ephones command in call-manager-fallback configuration mode. The default
is 0, and the maximum configurable number is platform-dependent. The only way to
increase the maximum number of Cisco IP Phones supported is to upgrade to a higher
hardware platform.
NOTE The router must be rebooted to reduce the limit on Cisco IP Phones after the
maximum allowable number is configured.
SRST Performance Commands
To optimize performance of the system, best practice dictates that you use the limit-dn and
keepalive commands, as shown in Example 6-3.
Example 6-3 SRST Performance Commands
RemoteSite#configure terminal
RemoteSite(config)#call-manager-fallback
RemoteSite(config-cm-fallback)#limit-dn {7910 I 7935 I 7940 I 7960} max-lines
RemoteSite(config-cm-fallback)#keepalive seconds
SRST Configuration on the Cisco IOS Gateway 129
The optional Cisco IOS command limit-dn limits the directory number lines on Cisco IP
Phones during SRST mode, depending on the Cisco IP Phone model.
NOTE This command must be configured during the initial Cisco Unified SRST router
configuration, before any IP Phone actually registers with the Cisco Unified SRST router.
However, you can change the number of lines later.
The setting for the maximum number of directory lines is from 1 to 6. The default is 6. If
any active phone has the last line number greater than this limit, warning information is
displayed for phone reset.
The optional Cisco IOS command keepalive sets the time interval, in seconds, between
keepalive messages that are sent to the router by Cisco IP Phones. The range is 10 to 65535.
The default is 30.
The keepalive interval is the period of time between keepalive messages that are sent by a
network device. A keepalive message is a message that is sent by one network device to
inform another network device that the virtual circuit between the two is still active.
NOTE If the default time interval between messages of 30 seconds will be used, this
command does not have to be used.
Cisco Unified SRST Configuration Example
Figure 6-4 shows a multisite topology that supports SCCP-controlled IP Phones at the
remote SRST site. The configuration is shown in Example 6-4.
Figure 6-4 Multisite Topology Supporting SCCP-Controlled IP Phones at the Remote SRST Site
Main Site
Linel; 2001 Linel; 2002 Linel: 2003
Line2:3001 Line2:3002 Line2:3003
130 Chapter 6: Implementing Cisco Unified SRST and MGCP Fallback
NOTE More commands might be necessary, depending on the complexity of the
deployment.

MGCP Fallback and SRST Configuration ccnp training institute in 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

Figure 6-1 shows the topology relating to configuring Cisco Unified SRST and MGCP
gateway fallback on Cisco IOS routers.
Figure 6-1 MGCP Fallback and SRST Configuration
The MGCP-gateway-fallback feature is activated and configured on the Cisco IOS router.
Note that Cisco Unified SRST must be configured within CUCM and within the Cisco IOS
router.
Configuration Requirements for MGCP Fallback and Cisco Unified SRST
When configuring MGCP fallback and Cisco Unified SRST, you must follow these steps at
different locations:
• Define the SRST references for phones in CUCM Administration.
• Configure the Call Forward Unregistered (CFUR) feature, and set the CFUR
destination of lines on remote-site phones to the correct public switched telephone
network (PSTN) number in CUCM Administration to enable reachable remote sites
in SRST mode.
• Enable and configure the MGCP fallback and Cisco Unified SRST features on the IOS
gateways.
• Implement a simplified SRST dial plan on the remote-site gateways to ensure
connectivity for remote-site phones in SRST mode.
Cisco Unified SRST Configuration in CUCM 125
Cisco Unified SRST Configuration in CUCM
The SRST feature in CUCM provides IP Phones with the information needed to find the
relative gateway to register with when they lose contact with CUCM servers.
An SRST reference must first be defined. This reference contains information about IP
addresses and ports of SRST gateways for SCCP and session initiation protocol (SIP)
phones. Because the SRST functions are different for SIP and SCCP, the addresses and
ports are also different.
Secondly, provide a group of phones with this information by assigning the SRST reference
to a proper device pool, which is then assigned to the phones.
SRST Reference Definition
An SRST reference, as shown in Figure 6-2, comprises the gateway, which can provide
limited CUCM functionality when all other CUCM servers for IP Phones are unreachable.
Choose Cisco Unified Communications Manager Administration > System > SRST.
Figure 6-2 SRST Reference Definition in CUCM
i— SRST Reference Information
* Name-
PortJ
SRST-Remotel
2 0 0 0
IP Address*
SIP Network/IP Address
SIP Port*
SRST Certificate Provider
Port*
• Is SRST Secure?
172.42.2. l|
5060
2445
SRST references determine which gateways IP Phones will search when they attempt to
complete a call if the CUCM is unavailable.
Administrators must configure CUCM with a unique SRST reference name that specifies
the IP address of the Cisco Unified SRST gateway. The default TCP port number 2000
normally is used.
The SIP network and IP address apply to SIP SRST. If SIP SRST is used, the IP address
and port that are used by the SIP protocol of the Cisco Unified SRST gateway have to be
specified; the default port number is 5060. The configured address and port will be used by
SIP phones to register with the SIP SRST gateway.
126 Chapter 6: Implementing Cisco Unified SRST and MGCP Fallback
CUCM Device Pool
The SRST reference, as shown in Figure 6-3, is assigned to IP Phones using device pools.
Choose Cisco Unified Communications Manager Administration > System > Device
Pool.
Figure 6-3 Device Pool in CUCM
I— Roaming Sensitive Settings
Date/Time Group* CMLocal
Region* Default
Media Resource Group List *~ None >
Location c None >
Network Locale < None >
SRST Reference*
Connection Monitor D u r a t i o n * * * "
Physical Location < None >
Device Mobility Group < None >
Administrators select the configured SRST reference from the drop-down menu in the
device pool configuration.
NOTE If devices are associated with this SRST reference, a message appears, saying
that devices need to be reset for the update to take effect.

Dial Plan Requirements for MGCP Fallback and SRST Scenarios ccna training institute in 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

Figure 5-11 illustrates requirements of standalone dial plans to work with MGCP fallback
and SRST.
SRST failover leaves the remote site independent from the complex dial plan implemented
in CUCM at the main site. The SRST router needs to have a dial plan implemented to allow
all remote-site phones, all main-site phones, and all PSTN destinations to be reached with
the same numbers as in standard mode.
During fallback, users should be able to dial main-site directory numbers as usual. Because
these calls have to be routed over the PSTN during fallback, main-site extensions have to
be translated to E. 164 PSTN numbers at the PSTN gateway.
114 Chapter 5: Examining Remote-Site Redundancy Options
Figure 5-11 SRST Dial Plan Requirements for Calls from the Remote Site
Most enterprises limit the range of destinations that can be reached from specific extensions
by applying class of service to the extensions. This limitation should still be valid during
times in SRST mode by applying IOS class of restriction (COR), as described in the next
chapter.
Ensuring Connectivity for Remote Sites
When SRST is active, you must take several measures to ensure connectivity from remote
sites to PSTN destinations, between different sites, and inside the site itself.
To guarantee PSTN connectivity, dial peers with destination patterns corresponding to the
PSTN access code have to be implemented. In H.323 or SIP gateways, these dial peers must
be present for normal operation. When MGCP gateways are used, dial peers are activated
by the MGCP-gateway-fallback mechanism. Interdigit timeout adopts open numbering
plans that do not have a fixed number of digits.
Voice translation profiles that are applied to dial peers, the voice interface, or the voice port
modify the calling party ID to enable callback from call lists.
For intrasite and intersite connectivity, voice translation profiles are configured to expand
called numbers to PSTN format during fallback.
The Cisco IOS command dialplan-pattern in call-manager-fallback configuration mode
modifies incoming called numbers to match the remote-site extensions. It ensures that
internal extensions can be dialed even though the lines are configured with the site code and
extension. The Line Text Label settings defined in CUCM are not applied to the SRST
phones, so the complete directory number applied to the line is visible to the user.
Dial Plan Requirements for MGCP Fallback and SRST Scenarios 115
Remote Site
Main Site 1001
CUCM considers the remote-site phones unregistered and cannot route calls to the affected
IP Phone directory numbers. Therefore, if main-site users dial internal extensions during
the IP WAN outage, the calls will fail or go to voice mail.
To allow remote IP Phones to be reached from main-site IP Phones, Call Forward Unregistered
(CFUR) can be configured for the remote-site phones. CFUR should be configured with the
PSTN number of the remote-site gateway so that internal calls for remote IP Phones get
forwarded to the appropriate PSTN number.
NOTE In older versions of CCM that did not support CFUR, it was not possible to
allow a main-site phone registered to CCM to call a remote-site phone in SRST mode
over the PSTN during a WAN failure. This was because CCM did not have a mechanism
to route calls to unregistered DNs through the PSTN.
CFUR Considerations
CFUR was first implemented in CCM Release 4.2.
Ensuring Connectivity from the Main Site Using
Call Forward Unregistered
During fallback, main-site users should still be able to call remote-site users using their
extension numbers, as shown in Figure 5-12.
Figure 5-12 Ensure Connectivity from the Main Site Using CFUR
116 Chapter 5: Examining Remote-Site Redundancy Options
As mentioned earlier, the CFUR feature allows calls placed to a temporarily unregistered
IP Phone to be rerouted to a configurable number. The configuration of CFUR has two main
elements:
• Destination selection: When the directory number is unregistered, calls can be rerouted
to voice mail or to the directory number that was used to reach the IP Phone through
the PSTN.
• Calling Search Space (CSS): CUCM attempts to route the call to the configured
destination number using the CFUR CSS of the directory number that was called. The
CFUR CSS is configured on the target IP Phone and is used by all devices that are
calling the unregistered IP Phone. This means that all calling devices use the same
combination of route pattern, route list, route group, and gateway to place the call. In
addition, all CFUR calls to a given unregistered device are routed through the same
unique gateway, regardless of the location of the calling IP Phone. It is recommended
that you select a centralized gateway as the egress point to the PSTN for CFUR calls
and configure the CFUR CSS to route calls to the CFUR destination through this
centralized gateway.
If an IP Phone is unregistered while the gateway that is associated with the direct
inward dialing (DID) number of that phone is still under the control of CUCM, CFUR
functionality can result in telephony routing loops. For example, if an IP Phone is
simply disconnected from the network, the initial call to the phone would prompt
the system to attempt a CFUR call to the DID of the phone through the PSTN. The
resulting incoming PSTN call would in turn trigger another CFUR attempt to reach the
directory number of the same phone, triggering yet another CFUR call from the central
PSTN gateway through the PSTN. This cycle potentially could repeat itself until system
resources are exhausted.
The CUCM service parameter Max Forward UnRegistered Hops To DN in the Clusterwide
Parameters (Feature—Forward) section in CUCM Administration controls the maximum
number of CFUR calls that are allowed for a directory number at one time. The default
value of 0 means that the counter is disabled. If any directory numbers are configured to
reroute CFUR calls through the PSTN, loop prevention is required. Configuring this service
parameter to a value of 1 would stop CFUR attempts as soon as a single call were placed
through the CFUR mechanism. This setting would also allow only one call to be forwarded
to voice mail, if CFUR is so configured. Configuring this service parameter to a value of 2
would allow up to two simultaneous callers to reach the voice mail of a directory number
whose CFUR setting is configured for voice mail. It would also limit potential loops to two
for directory numbers whose CFUR configuration sends calls through the PSTN.
Dial Plan Requirements for MGCP Fallback and SRST Scenarios 117
NOTE CUCM Extension Mobility directory numbers should not be configured to send
CFUR calls to the PSTN DID that is associated with the directory number. The directory
numbers of CUCM Extension Mobility profiles in the logged-out state are deemed to be
unregistered. Therefore, any calls to the PSTN DID number of a logged-out directory
number would trigger a routing loop. To ensure that calls made to CUCM Extension
Mobility directory numbers in the logged-out state are sent to voice mail, their
corresponding CFUR parameters must be configured to send calls to voice mail.
Keeping Calling Privileges Active in SRST Mode
Under normal conditions in multisite deployments with centralized call processing, calling
privileges are implemented using partitions and CSSs within CUCM.
However, when IP WAN connectivity is lost between a branch site and the central site,
Cisco Unified SRST takes control of the branch IP Phones, and the entire configuration that
is related to partitions and CSSs is unavailable until IP WAN connectivity is restored.
Therefore, it is desirable to implement classes of service within the branch router when
running in SRST mode.
For this application, you must define classes of service in Cisco IOS routers using the class
of restriction (COR) functionality. You can adapt the COR functionality to replicate the
CUCM concepts of partitions and CSSs by following these main guidelines:
• Named tags have to be defined for each type of call that you want to distinguish.
• Basic outgoing COR lists containing a single tag each have to be assigned to the
outgoing dial peers that should not be available to all users. These outgoing COR lists
are equivalent to partitions in CUCM.
• Complex incoming COR lists containing one or more tags have to be assigned to the
directory numbers that belong to the various classes of service.
SRST Dial Plan Example
Call-routing components on Cisco IOS routers and CUCM are necessary before a dial plan
will work in SRST mode, as shown in Figure 5-13.
118 Chapter 5: Examining Remote-Site Redundancy Options
Figure 5-13 SRST Dial Plan Example
CFUR must be defined on the CUCM side. Configuring the Cisco IOS router is a little more
complex when you use dial peers, COR, dial plan pattern, and voice translation profiles to
define the simplified SRST dial plan. Note how this example lets you dial 9 to get out to all
numbers on the PSTN from the remote site but limits 900 calls with COR to align with the
same restrictions set in CUCM.

Cisco Unified SRST Versions and Feature Support cisco ccna bootcamp training institute 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

Table 5-4 describes Cisco Unified SRST versions, their protocol support and features, and
the required Cisco IOS Software release.
Table 5-4 Cisco Unified SRST Versions
Feature
CUCM Express
in SRST Mode SRST 4.0 SRST 3.2 SRST 2.1
Minimum Cisco IOS Software
Release
12.4(11)XJ 12.4(4)XC 12.3(11)T 12.2(15)T1
Hunt Group •
B-ACD •
SIP SRST /
Video / /
Voice Security / /
Cisco IP Communicator (CIPC)
Support
/ /
Analog Telephone Adaptor (ATA)
Support
• / •
Local Music On Hold (MOH) • / /
Three-Party Conference / /
The version of the Cisco Unified SRST application depends on which release of the Cisco
IOS Software is running on the router. Each Cisco IOS Software release implements a
particular SRST version. You upgrade to a newer version of SRST through a Cisco IOS
update into router flash. Recent Cisco IOS Software releases often have higher memory
requirements than older ones, so make sure that you look into this before upgrading.
For detailed information on the history of Cisco Unified SRST, refer to the Cisco Unified
SRST Administration Guide or other documents listed in the documentation road map for
Cisco Unified SRST at http://www.cisco.com.
SRST 4,0 Platform Density
The maximum number of IP Phones and directory numbers supported by the Cisco Unified
SRST 4.0 feature depends on which Cisco IOS router platform is used, as shown in Table 5-5.
Dial Plan Requirements for MGCP Fallback and SRST Scenarios 113
Table 5-5 SRST 4.0 Platform Density
Platform Maximum Number of IP Phones Maximum Directory Numbers
1751, 1760, 2801 24 256
2811,26lxXM, 262xXM 36 144
2821,265xXM 48 192
2691 72 288
2851 96 288
3725 144 960
3745 480 960
3825 336 960
3845 720 960
This table shows the maximum number of phones and directory numbers on phones that
a Cisco Unified SRST router can accommodate. For example, a Cisco 3845 Integrated
Services Router can support a maximum of 720 phones and 960 directory numbers on
the phones.
NOTE These maximum numbers of IP Phones are for common SRST configurations
only. Routers with large numbers of IP Phones and complex configurations may not work
on all platforms and can require additional memory or a higher performance platform.

MGCP Fallback Usage ccie course 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 PSTN gateway can use MGCP gateway fallback configured as an individual feature if
H.323 or SIP is configured as a backup service. SRST and MGCP fallback must be configured
on the same gateway with Cisco IOS Software Release 12.2(11)T or later if this single
gateway will provide SRST fallback service to phones and MGCP gateway fallback.
Although MGCP gateway fallback is most often used together with SRST to provide
gateway functions to IP Phones in SRST mode, it can also be used as a standalone feature.
For example, with a fax application server using a PRI ISDN interface controlled by MGCP,
connectivity to the PSTN can be preserved by MGCP gateway fallback. An MGCP-fallback
standalone configuration may also be used to allow analog interfaces that are controlled by
SCCP to stay in service even when the WAN connection to the CUCM is down.
MGCP gateway fallback preserves active calls from remote-site IP Phones to the PSTN
when analog or channel-associated signaling (CAS) protocols are used. For ISDN protocols,
call preservation is impossible, because Layer 3 of the ISDN stack is disconnected
from the MGCP call agent and is restarted on the local Cisco IOS gateway. This means that
for active ISDN calls, all call-state information is lost in cases of switchover to fallback
operation.
MGCP Fallback Operation
MGCP gateway fallback, shown in Figure 5-7, is a feature that improves the reliability
of MGCP branch networks. A WAN link connects the MGCP gateway at a remote site to
the Cisco Communications Manager at a central site, which is the MGCP call agent. If
the WAN link fails, the fallback feature keeps the gateway working as an H.323 or SIP
gateway and rehomes to the MGCP call agent when the WAN link is active again.
MGCP gateway fallback works in conjunction with the SRST feature.
108 Chapter 5: Examining Remote-Site Redundancy Options
Figure 5-7 MGCP Gateway Fallback in a Normal Situation
Main Site Remote Site
Cisco IOS gateways can maintain links to up to two backup CUCM servers in addition to
a primary CUCM. This redundancy enables a voice gateway to switch over to a backup
server if the gateway loses communication with the primary server. The secondary backup
server takes control of the devices that are registered with the primary CUCM. The tertiary
backup takes control of the registered devices if both the primary and secondary backup
CUCM systems fail. The gateway preserves existing connections during a switchover to a
backup CUCM server.
When the primary CUCM server becomes available again, control reverts to that server.
Reverting to the primary server can occur in several ways: immediately, after a configurable
amount of time, or only when all connected sessions are released.
MGCP Gateway Fallback During Switchover
The MGCP gateway performs a switchover to its default technology of H.323 or SIP (as
shown in Figure 5-8) when the keepalives between CUCM and the Cisco MGCP gateway
are missing.
GCP Fallback Usage 109
Figure 5-8 MGCP Gateway Fallback During Switchover
The MGCP gateway fallback feature provides the following functionality:
MGCP gateway fallback support: All active MGCP analog, El CAS, and Tl CAS
calls are maintained during the fallback transition. Callers are unaware of the fallback
transition, and the active MGCP calls are cleared only when the callers hang up. Active
MGCP PRI backhaul calls are released during fallback. Any transient MGCP calls that
are not in the connected state are cleared at the onset of the fallback transition and must
be attempted again later.
Basic connection services in fallback mode: Basic connection services are provided
for IP telephony traffic that passes through the gateway. When the local MGCP gateway
transitions into fallback mode, the default H.323 or SIP session application assumes
responsibility for handling new calls. Only basic two-party voice calls are supported
during the fallback period. When a user completes (hangs up) an active MGCP call, the
MGCP application handles the on-hook event and clears all call resources.
MGCP Gateway Fallback During Switchback
The MGCP-gateway-fallback feature provides the rehome functionality to switch back
to MGCP mode. As shown in Figure 5-9, the switchback or rehome mechanism is triggered
by the reestablishment of the TCP connection between CUCM and the Cisco MGCP
gateway.
110 Chapter 5: Examining Remote-Site Redundancy Options
Figure 5-9 MGCP Gateway Fallback During Switchback
Rehome function in gateway-fallback mode detects the restoration of a WAN TCP connection
to any CUCM server. When the fallback mode is in effect, the affected MGCP gateway
repeatedly tries to open a TCP connection to a CUCM server that is included in the prioritized
list of call agents. This process continues until a CUCM server in the prioritized list
responds. The TCP open request from the MGCP gateway is honored, and the gateway
reverts to MGCP mode. The gateway sends a RestartlnProgress (RSIP) message to begin
registration with the responding CUCM.
All currently active calls that are initiated and set up during the fallback period are
maintained by the default H.323 session application, except ISDN Tl and El PRI calls.
Transient calls are released. After rehome occurs, the new CUCM assumes responsibility
for controlling new IP telephony activity.
MGCP Gateway Fallback Process
The MGCP gateway maintains a remote connection to a centralized CUCM cluster, as
shown in Figure 5-10, by sending MGCP keepalive messages to the CUCM server at
15-second intervals.
MGCP Fallback Usage 111
Figure 5-10 MGCP Gateway Fallback Process
If the active CUCM server fails to acknowledge receipt of the keepalive message within
30 seconds, the gateway attempts to switch over to the next available CUCM server.
If none of the CUCM servers responds, the gateway switches into fallback mode and reverts
to the default H.323 or SIP session application for basic call control.
NOTE H.323 is a standardized communication protocol that enables dissimilar devices
to communicate with each other through the use of a common set of codecs, call setup
and negotiating procedures, and basic data-transport methods.
The gateway processes calls on its own using H.323 until one of the CUCM connections is
restored. The same occurs if SIP is used instead of H.323 on the gateway.

CUCME in SRST Mode Usage ccsp course 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

CUCME in SRST mode enables routers to provide basic call-handling support for Cisco
Unified IP Phones if they lose connection to remote primary, secondary, and tertiary CUCM
installations or if the WAN connection is down.
When Cisco Unified SRST functionality is provided by CUCME, provisioning of phones
is automatic. Most CUCME features are available to the phones during periods of fallback,
including hunt groups, Call Park, and access to Cisco Unity voice messaging services using
SCCP. The benefit is that CUCM users gain access to more features during fallback without
any additional licensing costs.
CUCME in SRST mode offers a limited telephony feature set during fallback mode. If the
following features are required, basic SRST should be used, because these features are not
supported with CUCM in SRST mode:
• More than 240 phones exist during fallback service.
• Cisco VG248 Analog Phone Gateway support is required.
• Secure voice fallback during SRST fallback service.
• Simple, one-time configuration for SRST fallback service.
Cisco Unified SRST Operation
Figure 5-2 illustrates the function of Cisco Unified SRST.
Basic Cisco Unified SRST Usage 103
Figure 5-2 SRST Function in a Normal Situation
Main Site Remote Site
CUCM supports Cisco Unified IP Phones at remote sites attached to Cisco multiservice
routers across the WAN. The remote-site IP Phones register with CUCM. Keepalive
messages are exchanged between IP Phones and the central CUCM server across the WAN.
CUCM at the main site handles the call processing for the branch IP Phones. Note that
Cisco IP Phones cannot register SCCP or SIP through the PSTN to CUCM even if the
PSTN is functional, because SCCP and SIP must run over an IP network.
SRST Function of Switchover Signaling
When Cisco Unified IP Phones lose contact with CUCM (as shown in Figure 5-3) because
of any kind of IP WAN failure, they register with the local Cisco Unified SRST router
to sustain the call-processing capability that is necessary to place and receive calls.
Figure 5-3 SRST Function of Switchover Signaling
Main Site Remote Site
104 Chapter 5: Examining Remote-Site Redundancy Options
Cisco Unified SRST configuration provides the IP Phones with the alternative call control
destination of the Cisco Unified SRST gateway.
When the WAN link fails, the IP Phones lose contact with the central CUCM but then
register with the local Cisco Unified SRST gateway.
The Cisco Unified SRST gateway detects newly registered IP Phones, queries these IP
Phones for their configuration, and then autoconfigures itself. The Cisco Unified SRST
gateway uses SNAP technology to autoconfigure the branch office router to provide call
processing for Cisco Unified IP Phones that are registered with the router.
CAUTION In the event of a WAN failure, when the branch IP Phones register to the
SRST gateway, do not erase the settings on the phone. The phone settings, such as phone
numbers, were added to the phone from CUCM when the WAN was functional, and the
phone then takes its settings and uses them to register to the SRST router. If the phone
has no settings, it cannot register to SRST, and the phone will not be functional.
SRST Function of the Call Flow After Switchover
Cisco Unified SRST ensures that Cisco Unified IP Phones offer continuous service by
providing call-handling support directly from the Cisco Unified SRST router using a basic
set of call-handling features, as shown in Figure 5-4.
Figure 5-4 SRST Function of the Call Flow After Switchover
Main Site Remote Site
The Cisco Unified SRST gateway uses the local PSTN breakout with configured dial peers.
Cisco Unified SRST features such as call preservation, autoprovisioning, and failover are
supported.
Basic Cisco Unified SRST Usage 105
During a WAN connection failure, when Cisco Unified SRST is enabled, Cisco Unified IP
Phones display a message informing users that the phone is operating in CUCM fallback
mode. This message can be adjusted.
While in CUCM fallback mode, Cisco Unified IP Phones continue sending keepalive
messages in an attempt to reestablish a connection with the CUCM server at the main site.
SRST Function of Switchback
Figure 5-5 shows Cisco Unified IP Phones attempting to reestablish a connection over the
WAN link with CUCM at the main site periodically when they are registered with a Cisco
Unified SRST gateway.
Figure 5-5 SRST Function of Switchback
Main Site Remote Site
Cisco IP Phones, by default, wait up to 120 seconds before attempting to reestablish a
connection to a remote CUCM.
When the WAN link or connection to the primary CUCM is restored, the Cisco Unified IP
Phones reregister with their primary CUCM. Three switchback methods are available on
the Cisco IOS router: immediate switchback, graceful switchback (after all outgoing calls
on the gateway are completed), or switchback after a configured delay. When switchback
is completed, call handling reverts to the primary CUCM, and SRST returns to standby
mode. The phones then return to their full functionality provided by CUCM.
SRST Timing
Typically, a phone takes three times the keepalive period to discover that its connection to
CUCM has failed. The default keepalive period, as shown in Figure 5-6, is 30 seconds.
106 Chapter 5: Examining Remote-Site Redundancy Options
Figure 5-6 SRST Timing
IP Phone
If the IP Phone has an active standby connection established with a Cisco Unified SRST
router, the fallback process takes 10 to 20 seconds after the connection with CUCM is lost.
An active standby connection to a Cisco Unified SRST router exists only if the phone has
a single CUCM in its Cisco Unified CM Group. Otherwise, the phone activates a standby
connection to its secondary CUCM.
NOTE The time it takes for an IP Phone to fall back to the SRST router can vary,
depending on the phone type. Phones such as the Cisco Unified IP Phone models 7902,
7905, and 7912 can take approximately 2.5 minutes to fall back to SRST mode.
If a Cisco Unified IP Phone has multiple CUCM systems in its Cisco Unified CM group,
the phone progresses through its list before attempting to connect with its local Cisco
Unified SRST router. Therefore, the time that passes before the Cisco Unified IP Phone
eventually establishes a connection with the Cisco Unified SRST router increases with each
attempt to connect to a CUCM. Assuming that each attempt to connect to a CUCM takes
about one minute, the Cisco Unified IP Phone in question could remain offline for three
minutes or more following a WAN link failure. You can decrease this time by setting the
MGCP Fallback Usage 107
keepalive timer to a smaller value. You can configure the keepalive timer using the CUCM
service parameter Station Keepalive Interval.
While in SRST mode, Cisco Unified IP Phones periodically attempt to reestablish a
connection with CUCM at the main site.
NOTE If you want a Cisco IP Phone to come out of SRST fallback mode faster, you can
manually reboot the phone by pressing "settings" and then **#**, or by going into the
router mode call-manager-fallback and entering reset all.

Basic Cisco Unified SRST Usage best ccnp course training in 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

Cisco Unified SRST provides CUCM with fallback support for Cisco Unified IP Phones
that are attached to a Cisco router on a local network.
Cisco Unified SRST enables routers to provide basic call-handling support for Cisco
Unified IP Phones when they lose connection to remote primary, secondary, and tertiary
CUCM servers or when the WAN connection is down.
Basic SRST supports up to 720 SCCP IP Phones on the highest supported router (3845). In
addition, the VG248 Analog Phone Gateway offers basic SRST support and secure voice
fallback. However, it does not support hunt groups or message waiting indication (MWI)
for voice mail in fallback mode.
Cisco Unified SIP SRST Usage
Cisco Unified SIP SRST provides backup to an external SIP proxy server by providing
basic registrar and redirect server services earlier than Cisco Unified SIP SRST version 3.4
or B2BUA for Cisco Unified SIP SRST version 3.4 and higher services.
A SIP phone uses these services when it is unable to communicate with its primary SIP
proxy of CUCM in the event of a WAN connection outage.
Cisco Unified SIP SRST can support SIP phones with standard RFC 3261 feature support
locally and across SIP WAN networks. With Cisco Unified SIP SRST, SIP phones can place
calls across SIP networks in the same way that SCCP phones do.
Cisco Unified SIP SRST supports the following call combinations: SIP phone to SIP phone,
SIP phone to public switched telephone network (PSTN) or router voice port, SIP phone to
SCCP phone, and SIP phone to WAN VoIP using SIP.
SIP proxy, registrar, and B2BUA servers are key components of a SIP VoIP network. These
servers usually are located in the core of a VoIP network. If SIP phones located at remote
sites at the edge of the VoIP network lose connectivity to the network core (because of
a WAN outage), they may be unable to make or receive calls. Cisco Unified SIP SRST
functionality on a SIP PSTN gateway provides service reliability for SIP-based IP Phones
in the event of a WAN outage. Cisco Unified SIP SRST enables the SIP IP Phones to
continue making and receiving calls to and from the PSTN. They also can continue making
and receiving calls to and from other SIP IP Phones by using the dial peers configured on
the router.
102 Chapter 5: Examining Remote-Site Redundancy Options
When the IP WAN is up, the SIP phone registers with the SIP proxy server and establishes
a connection to the B2BUA SIP registrar (B2BUA router). But any calls from the SIP phone
go to the SIP proxy server through the WAN and out to the PSTN.
When the IP WAN fails or the SIP proxy server goes down, the call from the SIP phone
cannot get to the SIP proxy server. Instead, it goes through the B2BUA router out to the
PSTN.
NOTE The B2BUA acts as a user agent to both ends of a SIP call. The B2BUA is
responsible for handling all SIP signaling between both ends of the call, from call
establishment to termination. Each call is tracked from beginning to end, allowing the
operators of the B2BUA to offer value-added features to the call. To SIP clients, the
B2BUA acts as a user agent server on one side and as a user agent client on the other
(back-to-back) side. The basic implementation of a B2BUA is defined in RFC 3261, as
mentioned earlier in this chapter.

Remote-Site Redundancy Overview ccna course training in delhi

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

Two different technologies are used to provide remote-site redundancy for small and
medium remote sites in a CUCM environment. SRST and MGCP gateway fallback are the
key components of delivering fail-safe communication services, as shown in Figure 5-1.
Figure 5-1 SRST and MGCP Fallback
Main Site
CUCM supports Cisco Unified IP Phones at remote sites that are attached to Cisco multiservice
routers across the WAN. Before Cisco Unified SRST, when the WAN connection
between a router and the CUCM failed, or when connectivity with the CUCM was lost for
any reason, Cisco Unified IP Phones on the network became unusable for the duration of
the failure. The reason is that Cisco IP Phones demand Skinny Client Control Protocol
(SCCP) or session initiation protocol (SIP) connectivity to a call-processing agent such as
CUCM, and in the absence of signaling connectivity, the phones become fully unusable.
Cisco Unified SRST overcomes this problem and ensures that Cisco Unified IP Phones
offer continuous, although reduced, service by providing call-handling support for Cisco
Unified IP Phones directly from the Cisco Unified SRST router. The system automatically
detects a failure and uses Simple Network-Enabled Auto-Provision (SNAP) technology
to autoconfigure the branch office router to provide call processing for Cisco Unified IP
Phones that are registered with the router. When the WAN link or connection to the primary
CUCM subscriber is restored, call handling reverts to the primary CUCM.
MGCP gateway fallback is a mechanism that allows a Cisco IOS router to continue providing
voice gateway functions even when the MGCP call agent is not in control of the media
gateway. These voice gateway functions are implemented through a fallback mechanism
that activates the so-called default technology application. The gateway then works in the
same way as a standalone H.323 or SIP gateway by using its configured dial peers.
Remote-Site Redundancy Technologies
Remote-Site Redundancy Technologies
Table 5-1 lists the capabilities of different remote-site redundancy technologies.
Table 5-1 Remote-Site Redundancy Technologies
SRST
MGCP Fallback
Cisco Unified
SRST
Cisco Unified
SIP SRST
Cisco Unified
Communications
Manager Express
in SRST Mode
Provides
Redundancy For
MGCP-controlled
gateways
SCCP phones SIP phones SCCP phones
Delivered Service Fall back to
Cisco IOS default
technology
Basic telephony
service
Basic SIP
proxy service
Cisco Unified
Communications
Manager Express
Maximum
Number of Phones
720 (C3845) 480 (C3845) 240 (C3845)
ISDN Call
Preservation
No Yes(no
MGCP)
Yes (no
MGCP)
Yes (no MGCP)
Analog/CAS Call
Preservation
Yes Yes Yes Yes
To use SRST as your fallback mode on an MGCP gateway, SRST and MGCP fallback have
to be configured on the same gateway.
NOTE MGCP and SRST have had the capability to be configured on the same gateway
since Cisco IOS Software Release 12.2(11)T.
Cisco Unified SIP SRST provides a basic set of features to SIP-based IP Phones. It has to
be enabled and configured separately on Cisco IOS routers. In Cisco Unified SRST versions
before 3.4, it provides a SIP Redirect Server function; in subsequent versions, it acts as a
back-to-back user agent (B2BUA).
SIP is an Internet standard discussed in many Request for Comments (RFC). If you want
to supplement your knowledge of SIP, here is a good RFC to start with:
http://www.ietf.org/rfc/rfc3261 .txt
100 Chapter 5: Examining Remote-Site Redundancy Options
NOTE Before CUCM version 6, CUCME and SRST contained similar functionality
but existed as separate technologies. SRST always requires Cisco CallManager (CCM)
or CUCM, whereas CUCME can exist as a separate entity. However, with CUCM
version 6, CUCME in SRST mode can add functionality to SRST when configured to
provide survivability with CUCM. However, only SRST or CUCME can be configured
at any one time on an IOS router.
VoIP call preservation, as shown in Tables 5-2 and 5-3, sustains connectivity for topologies
in which signaling is handled by an entity (such as CUCM) that is different from the other
endpoint and brokers signaling between the two connected parties.
Call preservation is useful when a gateway and the other endpoint, which typically is a
Cisco Unified IP Phone, are co-located at the same site, and the call agent is remote and
therefore more likely to experience connectivity failures.
Table 5-2 Call Preservation Capabilities of Different Interfaces
Interface Type I Cisco Analog Interface Cards
Card Type WS-svccmm-24fxs Ws-x6624-fxs
1
VG224
"
VG248 ATA 186 and 188
H.323 Gateway No No No I Yes No
SIP Gateway No No No Yes No
MGCP
Gateway
No No No Yes No
Table 5-3 Call Preservation Capabilities of Different Interfaces, Continued
Interface Type Cisco Time-Division Multiplexing Interface Cards
Card Type T1 CAS | E1 CAS | T1 PRI E1 PRI | BRI
H.323 Gateway Yes Yes Yes Yes Yes
SIP Gateway Yes Yes Yes Yes Yes
MGCP Gateway Yes Yes No No No

Implementing Tail-End Hop-Off cisco ccie training center 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

When you implement TEHO, PSTN breakout occurs at the gateway that is closest to the
dialed PSTN destination. You do this by creating a route pattern for each destination area
that can be reached at different costs. These route patterns are required once per site and
have to be put into different partitions by identifying the site that should use a particular
route pattern.
As illustrated in Figure 4-10, each route pattern points to a route list and route group or
groups and has an ordered list of PSTN gateways that includes the cheapest gateway first,
the local gateway next, and optionally a third gateway for additional backup. IP Phones
have a CSS that selects the route patterns built for their site. This way, per originating site
and per destination number, a different first-choice gateway can be selected, and the local
gateway is the second option.
Figure 4-10 Implementing Tail-End Hop-Off (TEHO)
Chapter 4: Implementing a Dial Plan for Multisite Deployments
NOTE You also must consider call admission control (CAC) when implementing
TEHO. When the primary (TEHO) path is not admitted as a result of reaching the CAC
call limit, calls should be routed through the local gateway. More information about CAC
is provided in Chapter 9, "Implementing Call Admission Control."
Summary
The following key points were discussed in this chapter:
• Multisite dial plans should support selective PSTN breakout with backup gateways,
PSTN backup for on-net calls, TEHO, and intersite calls using access codes and site
codes.
• If you add an access code and site code to directory numbers at each site, directory
numbers do not have to be globally unique anymore.
Considerations When Using TEHO
When using backup TEHO, consider the following potential issues:
• Consider what number you want to use for the ANI of the outgoing call. The factors
you must consider are the same that have been discussed for PSTN backup.
• With TEHO, calls are routed based on the source (physical location) and based on the
dialed number. This can require a huge number of route patterns, resulting in complex
dial plans. Such dial plans are difficult to maintain and troubleshoot.
• CUCM has no automated technique to enter all the remote route patterns for TEHO.
They all must be entered manually based on a specific study of area codes in different
geographic regions and their associated toll charges.
• The primary purpose of TEHO is to reduce operating costs by increasing WAN
utilization and decreasing PSTN toll charges. For example, PSTN long-distance toll
charges within the contiguous 48 United States have dropped considerably in the last
few decades, hence reducing the TEHO cost savings. However, TEHO cost savings for
international calls can be considerable.
CAUTION The use of TEHO might not be permitted in your country or by your
provider. There also can be issues with emergency calls. Therefore, ensure that your
planned deployment complies with legal requirements.

Implementing PSTN Backup for On-Net Intersite Calls cisco ccsp training center 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

Figure 4-8 shows a multisite deployment with two sites. Each site has its own CUCM
cluster. Intersite calls use the intercluster trunk (ICT) or a SIP trunk over the IP WAN to the
other cluster. The route patterns with the site codes point to route lists, which point to route
groups that have the ICT as the first option and the PSTN gateway as the second option. If
the IP WAN link fails for any reason, because both sites have access to the PSTN, the PSTN
is used as a backup for intersite calls. Note that proper digit manipulation must take place
if the calls are routed through the PSTN.
Figure 4-8 Implementing PSTN Backup for On-Net Intersite Calls
Main Site Remote Site
1001-1099 1001-1099
Digit-Manipulation Requirements for PSTN Backup of
On-Net Intersite Calls
PSTN backup for on-net calls can be easily provided by route lists and route groups giving
priority to the intercluster trunk over the PSTN gateway, as shown in Figure 4-9.
When using a PSTN backup for on-net calls, you must address internal versus external
dialing. Although on-net calls usually use site codes and directory numbers, calls that are
sent through the PSTN have to use E.164 numbers. Digit-manipulation requirements vary,
depending on the path that is taken for the call:
• Digit-manipulation requirements when using the ICT, which is the first choice in the
route list and route group:
—At the calling site: The access and site code are removed from DNIS.
—At the receiving site: The access and site code are added to the ANI.
(This can also be done on the calling site.)
Chapter 4: Implementing a Dial Plan for Multisite Deployments
Figure 4-9 Digit-Manipulation Requirements for PSTN Backup of On-Net Intersite Calls
• Digit-manipulation requirements when using the PSTN (secondary choice in the route
list and route group)
—At the calling site: The internal DNIS comprising an access code, site
code, and directory number is transformed into the PSTN number of
the called phone. The ANI is transformed into the PSTN number of the
calling phone.
NOTE If DID is not supported, the site's PSTN number is used in DNIS and ANI
instead of the IP Phone's PSTN number.
mplementing Tail-End Hop-Off
—At the receiving site: The PSTN ANI is recognized as a PSTN number of
an on-net connected site and is transformed into the internal number: access
and site code, followed by the directory number of the calling phone (if
DID is used at the calling site) or of the attendant of the calling site (if DID
is not used at the calling site). The DNIS is transformed into an internal
directory number and is routed to the IP Phone (if DID is used at the
receiving site) or to an attendant (if DID is not used at the receiving site).

Implementing Selective PSTN Breakout cisco ccnp training center 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

A multisite deployment, shown in Figure 4-6, typically has multiple PSTN gateways, usually
one per site. Selective PSTN breakout ensures that local gateways are used to access the
PSTN. From a dial plan perspective, this can be achieved by creating one 9.@ route pattern
if you're using the North American Numbering Plan; otherwise, use 9.! per site. These route
patterns are put into different partitions and point to different PSTN gateways. IP Phones
need to be configured with a CSS that includes only the route patterns that refer to the local
gateway. This way, IP Phones will always use their local PSTN gateway for PSTN breakout.
Figure 4-6 Configure IP Phones to Use a Local PSTN Gateway
Main Site
In this figure, three different calls are received at the main site gateway. The first call is
received from the local area with a subscriber TON and a seven-digit number. This number
only needs to be prefixed with access code 9. The second call, received with national TON
and ten digits, is modified by adding access code 9 and the long-distance 1, both of which
are required for placing calls back to the source of the call. The third call is received from
another country (Germany in this case) with an international TON. For this call, the access
codes 9 and 011 have to be added to the received number, which begins with the country
code of 49. Note that 011 is the NANP international access code, which is different for calls
originating outside the NANP.
The end result benefits an internal user who receives but misses any calls from these sites
and wants to easily call back any of these numbers without editing the number from his or
her missed call list.
Implementing Selective PSTN Breakout
PSTN breakout occurs at the gateway located closest to the PSTN destination:
• Route patterns for each area that can be reached at different costs—one per site, in
different partitions
• Route patterns point to route lists (with different priorities of gateways: cheapest
gateway first, local gateway next, and then another gateway for additional backup if
desired).
• Phone CSS for correct route-pattern selection
NOTE If greater control over restricting outbound dialing is required, more-specific
route patterns should be created instead of those using the generic @ wildcard.
Configure IP Phones to Use Remote Gateways for
Backup PSTN Access
Figure 4-7 shows how a multisite dial plan can feature multiple choices for PSTN access to
provide a backup in case of primary (local) gateway failure.
Figure 4-7 Configure IP Phones to Use Remote Gateways for Backup PSTN Access
Main Site
Primary Path Backup Path
In this figure, both sites have IP Phones and a PSTN gateway. As discussed earlier in this
book, IP Phones should always use their local gateway to access the PSTN, which is critical
for emergency 911 calls. A user dialing 911 in Atlanta certainly wouldn't want to reach the
emergency call center in Chicago. This example of geographic routing can be achieved
by using multiple route patterns in partitions and CSSs at the IP Phones. If the local PSTN
gateway has a failure while the WAN link is functional, you can provide backup PSTN access
by using route lists and route groups with multiple gateways. Because a route list and route
group is a prioritized list of devices, it is simple to specify the primary and backup path.
Chapter 4: Implementing a Dial Plan for Multisite Deployments
• Use the secondary gateway's PSTN number.
When the ANI of the backup gateway is used, the called party may get confused about
the number that should be used when calling back. For instance, the person may update
his address books with the different number and inadvertently end up sending calls
through the backup gateway every time he calls. Further DID ranges would have to
include remote phones or IVR scripts (automated attendants) to be able to route calls
to phones located in any site, regardless of where the PSTN call was received.
CAUTION Using a remote gateway for PSTN access might not be permitted in your
country or by your provider. There can also be issues with emergency calls. Therefore,
ensure that your planned deployment complies with legal requirements.