Share this page : facebooktwitterlinkedinmailfacebooktwitterlinkedinmail

Path selection is one of the most important aspects of a well-designed VoIP system. High availability is desirable, so there is usually more than one path for a call to take to its final destination. Multiple paths provide several benefits, including redundancy in case of a link failure or insufficient resources on that link and a reduction in toll costs of a call.

Call Routing and Path Selection

The call routing logic on Cisco IOS routers using the H.323 protocol relies on the dial-peer construct. Dial peers are similar to static routes. They define where calls originate and terminate and what path the calls take through the network. Dial peers are used to identify call source and destination endpoints and to define the characteristics applied to each call leg in a call connection.

One of the keys to understanding call routing with dial peers is the concept of incoming versus outgoing call legs and, consequently, of incoming versus outgoing dial peers. Each call passing through a Cisco IOS router is considered to have two call legs, one entering the router and one exiting the router. The call leg entering the router is the incoming call leg, whereas the call leg exiting the router is the outgoing call leg.

Two types of call leg:

■ Traditional Time Division Multiplexing (TDM) telephony call legs that connect a router to the PSTN, analog phones, or PBXs

■ IP call legs that connect a router to other gateways, gatekeepers, or Cisco UCM servers

Dial peers are also of two main types, according to the type of call leg with which they are associated:

POTS dial peers, associated with traditional TDM telephony call legs

VoIP dial peers, associated with IP call legs

Dial Peer Matching

Routers must match the correct inbound and outbound dial peers to successfully complete a call.

It is important to understand that a Cisco IOS gateway performs dial-peer matching every time it receives called-party information. For en bloc signaling, this is straightforward. Specifically, the called-party information is used to find the best dial peer.

For digit-by-digit signaling, such as PSTNs with overlap sending and receiving, Cisco Unified CME and SRST ephones, and FXS ports, the gateway performs dial-peer matching each time a digit is received.

Example:  In the scenario illustrated in Figure below, both dial peers match three digits when 555-1234 is the called number.

Router(config)#dial-peer voice 1 pots
Router(config-dial-peer)#destination-pattern 555
Router(config-dial-peer)#port 0/0/0:23
Router(config-dial-peer)#exit
Router(config)#dial-peer voice 2 pots
Router(config-dial-peer)#destination-pattern 555....
Router(config-dial-peer)#port 0/0/1:23 

The following steps describe what occurs during the call in this example.

1. A user wants to call the international number 90114989123456 and starts to dial.

2. Because the first digit received is a 9, the gateway performs dial-peer matching.

3. Dial-peer 90 is matched, and any further digits are collected by the control character T that indicates the destination-pattern value is a variable-length dial string.

4. The user finishes dialing, and the call is routed using dial-peer 90. Dial-peer 90110 will never be considered.

For en bloc signaling, the DNIS is used, so the process is as follows:

1. A user wants to call the international number 90114989123456 and starts to dial.

2. Because en bloc signaling is enabled, the gateway continues to collect digits until the interdigit timeout value is exceeded.

3. The user finishes dialing, and the call is routed using dial-peer 90110.

When matching the destination pattern, the Cisco IOS gateway performs a left-aligned match (that is, the pattern is matched with the beginning of the received string).

In the scenario illustrated in Figure below both dial peers match three digits when 555-1234 is the called number.

Router(config)#dial-peer voice 1 pots
Router(config-dial-peer)#destination-pattern 555
Router(config-dial-peer)#port 0/0/0:23
Router(config-dial-peer)#exit
Router(config)#dial-peer voice 2 pots
Router(config-dial-peer)#destination-pattern 555....
Router(config-dial-peer)#port 0/0/1:23 

If the first three digits of the called number are 555, dial-peer 1 will be matched because it explicitly matches the called number. The rest of the digits will not be processed, where the problem exists.

Maching to inbound and outbound dial peers

 

Inbound Dial-Peer Matching

Inbound dial-peer matching is prioritized as follows:

1. If the called number (that is, the DNIS) matches with the incoming called-number configuration on a dial peer, this dial peer will be selected as the inbound dial peer. No further matching is performed.

2. If no dial peer has been found, the calling number (that is, the ANI) is checked. If the answer-address configuration of a dial peer is matched, this dial peer will be selected, and no further matching is performed.

3. If the calling number (the ANI) matches with the destination-pattern configuration of a dial peer, this dial peer will be selected, and no further matching is performed.

4. If none of the previous attempts were successful and the call is inbound on a POTS port, a dial peer with a matching voice-port configuration is searched.

5. If still no match is found, the default dial-peer 0 is used.

Note Default dial-peer matching is not desirable because default call characteristics might not be what you want.

The router needs to match only one of these conditions. It is not necessary for all the attributes to be configured in the dial peer or that every attribute match the call setup information. The router stops searching as soon as one dial peer is matched, and the call is routed according to the configured dial peer attributes. Even if other dial peers exist that would match, only the first match is used.

Note A typical misconception about inbound dial-peer matching is that the session-target of a dial peer is used. This is not true. Instead, use the incoming called-number or answer-address command to ensure that the correct inbound dial peer is selected.

Outbound Dial-Peer Matching

How the router selects an outbound dial peer depends on whether DID is configured in the inbound POTS dial peer:

DID is a service offered by telephone companies that enables callers to dial directly to an extension on a Private Branch Exchange (PBX) or packet voice system without the assistance of an operator or automated call attendant. This service makes use of DID trunks, which forward only the last three to five digits of a phone number to the PBX or router/gateway. If for example, a company has phones extensions 555-1000 to 555-1999, and a caller dials 555-1234, the local central office (CO) would forward 234 to the PBX or packet voice system. The PBX or packet voice system (Cisco CallManager and IOS router/gateway) would then ring extension 234. This entire process is transparent to the caller.

■ If DID is not configured in the inbound POTS dial peer, the router collects the incoming dialed string digit-by-digit and compares these digits to configured destination patterns. After an inbound dial peer is matched, the gateway plays a second dial tone to the caller and waits for them to enter additional digits. This is referred to as two-stage dialing. As soon as a dial peer fully matches the destination pattern, the router immediately routes the call using the configured attributes in the matching dial peer.

■ If DID is configured in the inbound POTS dial peer, the router uses the full incoming dial string to match the destination pattern in the outbound dial peer. This is known as one-stage dialing. With DID, the setup message contains all the digits necessary to route a call, so no additional digit collection is required. If more than one dial peer matches the dial string, all the matching dial peers are used to form a hunt group. The router attempts to place the outbound call leg using all of the dial peers in the hunt group until one is successful.

Outbound dial-peer matching is prioritized as follows by default:

1. The gateway searches through all dial peers and tries to match the called number (the DNIS) with the destination-pattern configuration. The dial peer with the closest match is selected.

2. If multiple equal matches are found, the dial peer with the lowest preference configuration wins.

3. If equal preferences are found, a random dial peer is selected.

Dial peer call routing and Path selection command

 

Table – ANI and DNIS Matching on Dial Peers

Command

Description

Use this command in dial-peer configuration mode to specify either the prefix or the full E.164 telephone number to be used for a dial peer. To disable the configured prefix or telephone number, use the no form of this command. The following characters can be used:

■ The asterisk (*) and pound sign (#) that appear on standard touch-tone dial pads.

■ Comma (,), which inserts a pause between digits.

destination-pattern [+]string[T]  Period (.), which matches any entered digit. (This character is used as a wildcard.)
 Percent sign (%), which indicates that the preceding digit occurred zero or more times, similar to the wildcard usage.
 Plus sign (+), which indicates that the preceding digit occurred one or more times. Note: This plus sign has a different purpose than the plus sign in front of a digit string, which is used to indicate that the string is an E.164 standard number.
 Circumflex (A), which indicates a match to the beginning of the string.
 Dollar sign ($), which matches the null string at the end of the input string.
 Backslash symbol (\), which is followed by a single character and matches that character; can be used with a single character with no other significance (matching that character).
 Question mark (?), which indicates that the preceding digit occurred zero or one times.
 Brackets ( [ ] ), which indicate a range (a sequence of characters enclosed in the brackets); only numeric characters from 0 to 9 are allowed in the range.
 Parentheses ( ( ) ), which indicate a pattern and are the same as the regular expression rule.

 

incoming called-number [+]string[T]

Use this command in dial-peer configuration mode to specify a digit string that can be matched by an incoming call to associate the call with a dial peer. To reset to the default, use the no form of this command.

answer-address [+]string[T]

Use this command in dial-peer configuration mode to specify the full E.164 telephone number to be used to identify the dial peer of an incoming call. To disable the configured telephone number, use the no form of this command.

 

 

Direct-Inward-Dial and Dial-Peer Matching Commands

Command

Description

direct-inward-dial

Use this command in dial-peer configuration mode to enable the DID call treatment for an incoming called number. When this feature is enabled, the incoming call is treated as if the digits were received from the DID trunk. The called number is used to select the outgoing dial peer. No dial tone is presented to the caller.

preference value

Use this command in dial-peer configuration mode to indicate the preferred order of a dial peer within a hunt group. The value variable can be a value in the range of 0 through 10. To remove the preference, use the no form of this command. The default is 0 and is not displayed in a configuration.

no dial-peer outbound status-check pots

Use this command in privileged EXEC mode to check the status of outbound POTS dial peers during call setup and to disallow, for that call, any dial peers whose status is down.

This might be required on some ISDN links where the CO ISDN switch activates the ISDN layer only if activity is detected on the link.

 

Matching Dial Peers in a Hunt Group

By default, dial peers in a hunt group are selected according to the following criteria, in the order listed:

1. Longest match in phone number: This method selects the destination pattern that matches the greatest number of dialed digits. For example, if one dial peer is configured with a dial string of 345…. and a second dial peer is configured with 3456789, the router would first select 3456789 because it has the longest explicit match of the two dial peers.

2. Explicit preference: This method uses the priority configured with the preference dial-peer command. The lower the preference number, the higher the priority. The highest priority is given to the dial peer with preference order 0. If the same preference is defined in multiple dial peers with the same destination pattern, a dial peer is selected randomly.

3. Random selection: In this method, all destination patterns are weighted equally.

You can change this default selection order or choose different methods for hunting dial peers by using the dial-peer hunt global configuration command. Dial-peer hunt options include the following:

■ 0: Longest match in phone number, explicit preference, random selection. This is the default hunt order number.

■ 1: Longest match in phone number, explicit prefer

■ 2: Explicit preference, longest match in phone number, random selection.

■ 3: Explicit preference, longest match in phone number, least recent use.

■ 4: Least recent use, longest match in phone number, explicit preference.

■ 5: Least recent use, explicit preference, longest match in phone number.

■ 6: Random selection.

■ 7: Least recent use.

 

H.323 Dial-Peer Configuration Best Practices

 

To illustrate best practice procedures when configuring H.323 dial peers on a Cisco IOS router, consider Figure below and the corresponding dial-peer configuration shown in config Example . In the example, dial-peer 1 is used to route calls according to their DNIS, and dial peers 100 and 101 are used to route calls to the primary UCM server, unless it has lost connectivity, and then to use the backup, or secondary, UCM server. notice that the dial-peer 100 with high priority ( preference 1) and 101 with low priority ( preference 2).

Router(config)#dial-peer voice 1 pots
Router(config-dial-peer)#incoming called-number .
Router(config-dial-peer)#direct-inward-dial
Router(config-dial-peer)#exit
Router(config)#dial-peer voice 100 voip
Router(config-dial-peer)#preference 1
Router(config-dial-peer)#destination-pattern 1...
Router(config-dial-peer)#session target ipv4:10.10.10.2
Router(config-dial-peer)#exit
Router(config)#dial-peer voice 101 voip
Router(config-dial-peer)#preference 2
Router(config-dial-peer)#destination-pattern 1...
Router(config-dial-peer)#session target ipv4:10.10.10.3

The previous figure and example illustrate the following best practice procedures:

■ To ensure that incoming PSTN calls are directly routed to their destination based on the DNIS information, create a default POTS dial peer with the direct-inward-dial attribute.

Note This should be the first POTS dial peer that you configure on the gateway. It should be the only dial peer that contains a “.” for the destination pattern and direct inward dial. It should not contain a port number.

■ When using the router as an H.323 gateway connected to a Cisco UCM cluster, provide redundancy by configuring at least two VoIP dial peers with the same destination pattern pointing to two different UCM servers. Use the preference attribute to select the priority order between primary and secondary UCM servers.

 

Path Selection Strategies

When remote sites are involved, different path selection strategies are required. Multisite dial plans include all the requirements of a single-site dial plan, as well as the following requirements:

■ Site-code dialing: A typical requirement is the support of site-code dialing. Site-code dialing allows users to place an intersite call by dialing a site code that is typically three to four digits long followed by the actual extension of the remote site user. Call routing and path selection can support this by using digit manipulation to prefix and strip off site codes where necessary.

■ Toll-bypass: Toll-bypass uses the WAN link for call routing to avoid PSTN charges for intersite calls. This includes call routing and path selection for the actual call-routing process, including fallback PSTN routing in case the WAN link fails. Again, digit manipulation is also required to ensure proper number formatting.

■ TEHO: Tail-End Hop-Off (TEHO) is similar to toll-bypass but extends the WAN usage for PSTN calls as well. The PSTN breakout should be as close as possible to the final PSTN destination to decrease phone charges. The same requirements exist as with toll-bypass.

Site-Code Dialing and Toll-Bypass

When you use site-code dialing, each site is assigned with a unique site code. For example, a network with three sites could have the site codes 801, 802, and 803. If a user wants to place a call to a remote site user, the dialed number would be the site code followed by the actual extension. This form of abbreviated dialing greatly improves the end-user experience because of shorter dial-able numbers.

The calling-party number, also referred to as ANI, needs to include the appropriate site code. This allows called users to call back directly using their missed-calls and received-calls directory. You can use digit manipulation to support this as well.

You might also use site-code dialing to solve issues with overlapping numbering plans. Because all extensions of a site are prefixed with a unique site code, an overlapping numbering plan (where extensions in multiple sites overlap) can be turned into a unique numbering plan.

Toll-Bypass Example

The example illustrated in Figure 7-23 and Example 7-21 shows the concepts of call routing and path selection in a toll-bypass scenario.

Toll-Bypass Topology Example

Figure 7-23 Toll-Bypass Topology Example

Example 7-21 Toll-Bypass Configuration Example

Toll-Bypass Configuration Example

Figure 7-23 shows a scenario with two sites, San Jose and Austin. The Austin Cisco Unified CME gateway is configured to route calls to San Jose primarily over the WAN, and if the WAN link fails, the PSTN link should be used.

The first dial-peer configuration is used to route calls that match destination-pattern 2… command to San Jose using the IP WAN. Because the dial peer is configured with a preference of 1, it is preferred over the PSTN dial peer with a preference of 2.

The second dial-peer configuration is used to route calls that match destination-pattern 2… command to San Jose using the PSTN. The preference of 2 makes this dial peer inferior to dial-peer 21 with a preference of 1.

Site-Code Dialing and Toll-Bypass Example

The example illustrated in Figure 7-24 and Examples 7-22 and 7-23 shows a scenario for site-code dialing and toll-bypass.

Example 7-22 Site-Code Dialing and Toll-Bypass Example—R1′s Configuration

Site-Code Dialing and Toll-Bypass Example—R1's Configuration

Example 7-23 Site-Code Dialing and Toll-Bypass Example—R3′s Configuration

Site-Code Dialing and Toll-Bypass Example—R3's Configuration

Site-Code Dialing and Toll-Bypass Topology Example

Figure 7-24 Site-Code Dialing and Toll-Bypass Topology Example

Figure 7-24 shows a sample scenario for site-code dialing combined with toll-bypass. San Jose has the site code 801, and Austin uses the site code 802. Also note that both sites use extensions in the range of 2XXX. This is a typical overlapping numbering plan. Following is the process the call goes through in this example:

1. A user in Austin wants to place a call to Phone1-1. Because Phone1-1 resides in San Jose and has the site code 801, the user dials 801-2001 (that is, the site code 801 followed by the extension 2001).

2. The call is routed over the IP WAN link to San Jose. Phone1-1 rings and displays the calling number 802-2002 (that is, the site code 802 of Austin followed by the extension of Phone2-2, which is 2002).

Tail-End Hop-Off (TEHO)

TEHO extends the concept of toll-bypass. Instead of only routing intersite calls over an IP WAN link, TEHO also uses the IP WAN link for PSTN calls. The goal is to route a call using the IP WAN as close to the final PSTN destination as possible. As with toll-bypass, PSTN fallback should always be possible in case the IP WAN link fails.

Note Some countries do not allow TEHO. When implementing TEHO, ensure that the deployment complies with national legal requirements.

TEHO Example

Figure 7-25 shows the TEHO scenario for this example.

Tail-End Hop-Off Scenario

Figure 7-25 Tail-End Hop-Off Scenario

Here is the process the call goes through:

1. Phone2-1 dials 9 1 408 555-6666 (that is, it places a call to a PSTN phone located in San Jose).

2. The call is routed to San Jose using the IP WAN link.

3. The local San Jose voice gateway is used to route the call as a local call to the San Jose PSTN.

4. The San Jose PSTN phone rings.

 

Implementing Calling Privileges on Cisco IOS Gateways

Calling privileges on Cisco IOS gateways are dial plan components, which define the types of calls that a phone, or group of phones, is able to place.

The COR (Class of Restrictions) feature provides the capability to deny certain call attempts based on the incoming and outgoing CORs provisioned on the dial peers.

COR is used to specify which incoming dial-peer can use which outgoing dial-peer to make a call. Each dial-peer can be provisioned with an incoming and an outgoing corlist. COR functionality provides the capability to deny certain call attempts on the basis of the incoming and outgoing CORs that are provisioned on the dial peers. This functionality provides flexibility in network design, allows users to block calls (for example, calls to 900 numbers), and applies different restrictions to call attempts from different originators.

Understanding COR on Cisco IOS Gateways

The fundamental mechanism at the center of the COR functionality relies on the definition of incoming and outgoing corlists. Each corlist is defined to include a number of members, which are tags previously defined within Cisco IOS. Multiple CORs are defined, and corlists are configured that contain these CORs. Each corlist is then assigned to dial peers as an incoming or outgoing corlist.

When a call goes through the router, an incoming dial peer and an outgoing dial peer are selected based on the Cisco IOS dial-peer routing logic. If corlists are associated with the selected dial peers, the following additional check is performed before extending the call:

■ If the COR applied on an incoming dial-peer (for incoming calls) is a super set or equal to the COR applied to the outgoing dial-peer (for outgoing calls), the call goes through.

■ If the COR applied on an incoming dial-peer (for incoming calls) is NOT a super set or equal to the COR applied to the outgoing dial-peer (for outgoing calls), the call is rejected.

Note Incoming and outgoing are terms used with respect to the voice ports. For example, if you hook up a phone to one of the FXS ports of a router and try to make a call from that phone, it is an incoming call for the router/voice port. Similarly, if you make a call to that FXS phone, it is an outgoing call.

If no corlist statements are applied to some dial peers, the following properties apply:

■ When no incoming corlist is configured on a dial-peer, the default incoming corlist is used. The default incoming corlist has the highest possible priority, and it therefore allows this dial-peer to access all other dial-peers, regardless of their outgoing corlist.

■ When no outgoing corlist is configured on a dial-peer, the default outgoing corlist is used. The default outgoing corlist has the lowest possible priority, and it therefore allows all other dial-peers to access this dial-peer, regardless of their incoming corlist.

To be continued

 

Reference

 

http://what-when-how.com/cisco-voice-over-ip-cvoice/configuring-path-selection-configuring-advanced-dial-plans-cisco-voice-over-ip-cvoice-part-1/