Dial Peer Matching

You can match a call to a dial peer in many ways, including on called or calling number, physical port, and type of call. Because the matching process can vary for inbound and outbound dial peers, each is described separately.

Inbound Dial Peer Matching

Calls that are coming into a gateway match dial peers based on the source of the call. If a call enters using a voice port, the inbound dial peer is a POTS dial peer. If the call enters using IP, the inbound dial peer is a VoIP dial peer. The steps for matching inbound dial peers are as follows:

Step 1.	Match the called number to the incoming called number that is configured on the dial peers. For voice ports that provide call setup information, this is the more common method of matching the inbound dial peer.
Step 2.	Match the calling number to the answer address that is configured on the dial peers. In most cases, an enterprise is more concerned with where an incoming call is going than with where it originates, but sometimes you might want to route a call differently based on its source. For example, calls to a contact center might be routed to different queues based on where the call originates.
Step 3.	Match the calling number to the destination pattern that is configured on the dial peers. This configuration allows you to use a single dial peer and destination pattern to provide both inbound and outbound matching. Although this can reduce the number of required dial peers, following the call flow can become confusing.   Note If an incoming POTS call has an empty calling number, it matches a dial peer that is configured with any destination pattern. The value of the destination pattern is used as the calling number on the outgoing call leg. Configure a dial peer with the incoming called-number . command to prevent this behavior.
Step 4.	Match the voice port that is associated with the call to the port that is configured on the dial peers. This step applies only to calls that originate on voice ports.
Step 5.	Match the "default" dial peer. The "default" dial peer, or dial peer 0, is matched when no other inbound dial peer is used. It is not possible to modify parameters for these calls, such as codec or voice activity detection (VAD). Therefore, it is advisable to always configure a specific dial peer to match incoming calls.

Note

The AS5xxx family of gateways requires an inbound dial peer match for a call to be processed as a voice call. These gateways support both modem and voice termination. If a call does not match an incoming voice dial peer, it is processed as a modem call.

Eliminating a dial peer at one step of the process does not exclude it from consideration during subsequent steps. Example 9-1 shows a gateway with a single POTS dial peer configured with both an incoming called number and an answer address.

Gateway#show run | begin dial-peer voice
dial-peer voice 1 pots
answer-address 408555....
incoming called-number 82..

 

Assume that port 1/0:23 receives a call setup message with a called number of 8193 and a calling number of 408 555-0123. The called number does not match the configured incoming called number on dial peer 1, so the gateway proceeds to Step 2. At this step, all dial peers are considered again. The calling number matches the answer address, so dial peer 1 is used as the inbound dial peer even though it failed Step 1.

At each step, the most specific dial peer is matched. Example 9-2 has added a dial peer to the previous example.

Gateway#show run | begin dial-peer voice
dial-peer voice 1 pots
answer-address 408555....
incoming called-number 82..
!
dial-peer voice 2 pots
answer-address 919555....
incoming called-number 820.

 

A call setup message arrives on port 1/0:23 with a called number of 8200 and a calling number of 4085550123. At this point, both dial peer 1 and dial peer 2 are potential matches for the call. Because the incoming called number for dial peer 2 is more specific, it is used as the inbound dial peer.

Note

Even though the calling number does not match the answer address, the dial peer is used. After a match is found for a step, no further matching analysis is performed.

 

Outbound Dial Peer Matching

Before discussing destination pattern matching, it is necessary to understand how digit strings are built. Wildcards are used in digit strings to allow a single digit string to match multiple numbers. Table 9-3 lists the wildcards that can be used in digit string arguments.

Table 9-3. Digit String Wildcards

Wildcard	Function	Examples
.	This matches any single digit.
[]	This indicates a range of digits. Continuous ranges are separated by a hyphen. A comma separates individual numbers.	[24] matches 2, 3, or 4 [2,4] matches 2 or 4 [24,7] matches 2, 3, 4, or 7
+	The previous digit or pattern occurred one or more times.	4085+ matches 4085 followed by any number of 5s
?	The previous digit or pattern occurred zero or one time.	4085? matches 408 or 4085
%	The previous digit or pattern occurred zero or more times.	4085% matches 408 or 408 followed by any number of 5s
()	This is used to designate a pattern.	408(555)? matches 408 or 408555

Note

Only the period (.) wildcard is allowed with the incoming called-number and answer-address commands.

For outbound dial peer matching, both POTS and VoIP dial peers are considered together, and the best match is selected. The called number is matched against the configured destination-pattern in the dial peers. The way this comparison is done depends on whether the direct-inward-dial command is configured on the inbound dial peer.

direct-inward-dial Is Not Configured

If the direct-inward-dial command is not configured on the selected inbound POTS dial peer, digit-by-digit analysis is performed. This is the case for all circuit types. After the inbound dial peer is matched, the gateway plays a second dial tone to the caller and waits for him to enter additional digits. Even with ISDN, in which the DNIS is included in the call setup message, a second dial tone is played and the original DNIS is not used to route the call. This is referred to as two-stage dialing. As the caller enters digits, the digits are compared to the configured destination patterns. As soon as a destination pattern is fully matched, the call is routed.

direct-inward-dial Is Configured

If the direct-inward-dial command is configured on the selected inbound POTS dial peer, the entire called number is used to match outbound dial peers. This is referred to as one-stage dialing.

The only case in which the complete called number is not used to match the destination pattern is when overlap receiving is set on an ISDN interface. With overlap receiving, digits are sent after the initial setup message. Because the entire digit string might not be received when the inbound dial peer is matched, digit-by-digit matching is used.

By default, gateways use variable-length matching when selecting outbound dial peers, as shown in Example 9-3.

Gateway#show run | begin dial-peer voice
dial-peer voice 555 pots
destination-pattern 555
forward-digits all
port 1/0:23
!
dial-peer voice 5550123 pots
destination-pattern 555...
forward-digits all
port 1/0:23

 

If the gateway receives a call setup message with a called number of 5550123, both dial peer 555 and dial peer 5550123 match the call.

To disable variable-length matching, you can configure dial peer 555 with a destination pattern of 555$. The $ indicates that extra digits are not allowed.

Verifying Dial Peers

For a complex dial plan that results in multiple dial peers, you can use the show dialplan command to find the matching inbound dial peers based on calling number or voice port and matching outbound dial peers based on inbound dial peer matched and DNIS.

Example 9-4 shows which dial peer is matched for the called number 15015012001. The output shows which dial peer is matched, which port or session target is used to route the call, and which digits are sent in the outgoing setup message.

[View full width]

Gateway#sh dialplan number 15015012001 Macro Exp.: 15015012001 VoiceEncapPeer501 peer type = voice, system default peer = FALSE, information type = voice, description = `', tag = 501, destination-pattern = `1501501....', answer-address = `', preference=0, CLID Restriction = None CLID Network Number = `' CLID Second Number sent CLID Override RDNIS = disabled, source carrier-id = `', target carrier-id = `', source trunk-group-label = `', target trunk-group-label = `', numbering Type = `unknown' group = 501, Admin state is up, Operation state is up, Outbound state is up, incoming called-number = `', connections/maximum = 0/unlimited, DTMF Relay = disabled, URI classes: Destination = huntstop = disabled, in bound application associated: 'DEFAULT' out bound application associated: '' dnis-map = permission :both incoming COR list:maximum capability outgoing COR list:minimum requirement Translation profile (Incoming): Translation profile (Outgoing): incoming call blocking: translation-profile = `' disconnect-cause = `no-service' advertise 0x40 capacity_update_timer 25 addrFamily 4 oldAddrFamily 4 type = pots, prefix = `', forward-digits 10 session-target = `', voice-port = `1/0:1', direct-inward-dial = disabled, digit_strip = enabled, register E.164 number with H323 GK and/or SIP Registrar = TRUE fax rate = system, payload size = 20 bytes supported-language = '' Time elapsed since last clearing of voice call statistics never Connect Time = 0, Charged Units = 0, Successful Calls = 10, Failed Calls = 0, Incomplete Calls = 0 Accepted Calls = 0, Refused Calls = 0, Last Disconnect Cause is "10 ", Last Disconnect Text is "normal call clearing (16)", Last Setup Time = 5526712. Last Disconnect Time = 5527420. Matched: 15015012001 Digits: 7 Target:  

 

Outbound Dial Peer Targets

You must configure outbound dial peers with a target, or path for the call. The target for outbound POTS dial peers is a voice port or trunk group. The target for outbound VoIP dial peers is an IP address.

Trunk Groups

Trunk groups are used to group multiple voice ports or ISDN channels into a single logical target for an outbound dial peer, reducing the number of peers required. Each trunk group is configured with a "hunting scheme" that determines the order in which channels are selected. The following are the hunt schemes that are available:

• least-idle The interface with the timeslot that has been idle the least is selected.
• least-used The interface with maximum free timeslots is selected.
• longest-idle The interface with the timeslot that has been idle the longest is selected.
• random The timeslot is selected randomly.
• round-robin The next interface with free timeslots is selected.
• sequential The interface with the highest preference is selected.

You can apply attributes, such as priority level or translations, to the trunk group. A voice port that is assigned to a trunk group can still be the target of a POTS dial peer. In this situation, the attributes of the trunk group are not applied to the call. You can also configure a dial peer with multiple trunk groups by assigning a preference to each. The dial peer attempts to extend the call over the highest priority trunk group. If this is unsuccessful, the next trunk group is attempted.

A useful feature of trunk groups is their ability to dedicate some channels of an ISDN circuit to particular dial peers. For example, you might want to reserve two channels of a PRI for emergency calls and route all other PSTN calls over the remaining channels.

Note

Trunk groups apply only to outbound calls. The gateway cannot control channel assignment of incoming calls.

Example 9-5 illustrates the configuration steps for each of the possible outbound dial peer targets.

[View full width]

Gateway#config t ! ! VoIP dial peer ! Gateway(config)#dial-peer voice 4 voip Gateway(config-dial-peer)#destination-pattern 4... Gateway(config-dial-peer)#session target ipv4:10.1.1.100 ! ! POTS dial peer single voice port ! Gateway(config)#dial-peer voice 7 pots Gateway(config-dial-peer)#destination-pattern 9[29]...... Gateway(config-dial-peer)#port 1/0:23 ! ! POTS dial peer trunk groups ! Create trunk groups ! Gateway(config)#trunk group Emergency Gateway(config-trunk-group)#description B Channels reserved for Emergency Calls Gateway(config-trunk-group)#hunt-scheme round-robin Gateway(config)#trunk group Standard Gateway(config-trunk-group)#hunt-scheme least-used ! ! Controller config to select channels ! Gateway(config)#controller t1 2/0 Gateway(config-controller)#framing esf Gateway(config-controller)#linecode b8zs Gateway(config-controller)#pri-group timeslots 1-24 Gateway(config-controller)#trunk-group Emergency timeslots 1-2 Gateway(config-controller)#trunk-group Standard timeslots 3-23 ! ! Set additional voice ports into standard trunk group ! Gateway(config)#voice-port 1/0/0 Gateway(config-voice-port)#trunk-group Standard Gateway(config-voice-port)#interface s1/0:23 Gateway(config-if)#trunk-group standard ! ! Apply trunk groups to dial peers ! Gateway(config)#dial-peer voice 911 pots Gateway(config-dial-peer)#destination-pattern 911 Gateway(config-dial-peer)#trunkgroup Emergency 1 Gateway(config-dial-peer)#trunkgroup Standard 2 ! Gateway(config)#dial-peer voice 11 pots Gateway(config-dial-peer)#destination-pattern 91[29]..[29]...... Gateway(config-dial-peer)#trunkgroup Standard !  

 

Dial Peer Hunting

If a call matches more than one outbound dial peer, the router hunts through the dial peers trying them in order. If the call setup is unsuccessful, the next matching dial peer is attempted. The following factors determine the hunt order:

• Longest match
• Preference
• Random selection

The longest match dial peer is always attempted first. If the call cannot be completed using this dial peer, the next longest match is attempted.

If you configure multiple dial peers with the same destination pattern but different voice ports, you can determine the dial peer selected using the preference command. You typically do this when you want a call to be extended first over the IP network and alternately over the PSTN. This scenario is discussed in more detail in Chapter 11. If you have multiple dial peers with the same destination pattern and do not specify a preference, the dial peer match is random.

You can modify the default hunt order logic using the dial-peer hunt command, as shown in Example 9-6.

[View full width]

BR2(config)#dial-peer hunt ? <0-7> Dial-peer hunting choices, listed in hunting order within each choice: 0 - Longest match in phone number, explicit preference, random selection. 1 - Longest match in phone number, explicit preference, least recent use. 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.  

 

POTS Versus VoIP Outbound Dial Peers

Outbound POTS dial peers are different from outbound VoIP dial peers in one significant way: With POTS dial peers, digits that explicitly match the destination pattern are stripped from the outgoing call setup. Table 9-4 lists various destination patterns and the corresponding called numbers sent in the setup message.

Table 9-4. POTS Digit Stripping Examples

Destination Pattern	Dialed String	Resulting Called Number
911	911	Empty
91800.......	918005550123	5550123
91[29]..[29]....	918005550123	8005550123

To send the correct called number, you can use the forward-digits or prefix commands.

Outbound VoIP dial peers do not strip explicitly matched digits.

Dial Peer Operational Status

For a dial peer to be included in either inbound or outbound matching, it must be operationally active. It must meet one of the following conditions to be considered operationally active:

• Destination-pattern configured and a target (voice port, trunk group or session target) configured
• Incoming called-number configured
• Answer-address configured

If the dial peer is not operationally active, it will not be considered while doing dial peer matching.

Many people believe they can block calls to certain destinations by configuring an appropriate destination pattern and not including a target. As stated, this results in the dial peer not being included in the searching, so it does not result in call blocking if another dial peer can be matched. Example 9-7 shows how dial peer matching is performed when a dial peer is operationally inactive. Dial peer 11 is used to route NANP long-distance calls. Dial peer 900 has been added in an attempt to block calls to this premium service.

[View full width]

Gateway#show run | begin dial-peer voice dial-peer voice 11 pots destination-pattern 91[2-9]..[2-9]...... port 2/0/0 prefix 1 ! dial-peer voice 900 pots destination-pattern 91900....... ! Gateway#debug voice dialpeer all ! Gateway#csim start 919005550123 csim start 919005550123 csim: called number = 919005550123, loop count = 1 ping count = 0 *Aug 14 11:30:08.526: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore: Calling Number=, Called Number=919005550123, Peer Info Type=DIALPEER_INFO_SPE ECH *Aug 14 11:30:08.526: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore: Match Rule=DP_MATCH_DEST; Called Number=919005550123 *Aug 14 11:30:08.526: //-1/xxxxxxxxxxxx/DPM/dpMatchCore: Dial String=919005550123, Expanded String=919005550123, Calling Number= Timeout=TRUE, Is Incoming=FALSE, Peer Info Type=DIALPEER_INFO_SPEECH *Aug 14 11:30:08.530: //-1/xxxxxxxxxxxx/DPM/MatchNextPeer: Result=Success(0); Outgoing Dial-peer=11 Is Matched *Aug 14 11:30:08.530: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore: Result=Success(0) after DP_MATCH_DEST *Aug 14 11:30:08.530: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers: Result=SUCCESS(0) List of Matched Outgoing Dial-peer(s): 1: Dial-peer Tag=11  

As you can see from the debug, this premium call will match dial peer 11, and call setup will be attempted. Because the outbound dial peer is a POTS dial peer, the gateway will strip the explicitly matched digits91900and will prefix in the 1. This will result in a called number of 15550123 being sent to the service provider, and the call will be rejected because of an invalid format, not because dial peer 900 was added. If dial peer 11 would have been configured with forward-digits 11 instead of the prefix command, the call would have been set up successfully.

The proper method of blocking certain destination patterns depends on your topology. In most cases, the call processing system blocks calls. If the gateway is the call processing system, you can use Class of Restrictions (COR) or, for CallManager Express (CME), time of day routing to block calls. You can also use voice translation rules to block incoming calls to a gateway. Chapter 10 covers voice translation rules in greater detail.

Dial Peers Versus Cisco CallManager

The way that gateways and CallManager perform digit-by-digit matching to determine the correct path for a call is different in one major sense. Table 9-5 illustrates how CallManager matches a dialed string of 1134. CallManager compiles a table consisting of all directory numbers (DNs), route patterns, and translation patterns. As digits are processed, the list of possible matches is narrowed down. Processing continues as long as there is a longer possible match in the table, even if a more specific match has already occurred. It is possible to change this behavior by configuring a route pattern as "Urgent Priority." Translation patterns are always considered to be Urgent Priority.

Table 9-5. CallManager Digit Analysis

Route Plan	Potential Matches
	Dial 1	Dial 1	Dial 3	Dial 4
11XXX	11XXX	11XXX	11XXX	11XXX
12XXX	1134	1134	1134	1134
1134	1145	1145
1145
1250

After the caller dials a 4, the digit string still has two potential matches. CallManager waits for the caller to enter an additional digit. If the caller does not enter a digit before the interdigit timer expires, pattern 1134 is matched.

As described previously, gateways also compare digits to dial peer destination patterns, eliminating potential matches as digits are processed. The difference is that as soon as a dial peer matches, it is used even if a longer possible match exists. This is similar to configuring all your CallManager route patterns as Urgent Priority.

To understand how significant this difference is, consider the situation described previously in the NANP. Because of growth, many areas now require more than one area code to cover a "local" calling area. In some areas, both seven-digit and ten-digit dialing is used for local calls, which can lead to issues with interdigit timeout. In the Tampa, Florida area, several area codes are assigned, including 813 and 727. Most calls between these area codes do not incur per-minute charges. Table 9-6 lists some of the CallManager route patterns to support a gateway that is located in the 813 area code.

Table 9-6. CallManager Dial Plan for Seven-Digit and Ten-Digit Local Calling

Route Pattern	Gateway	Description
911	Local T1	EmergencyUrgent Priority
9.911	Local T1	EmergencyUrgent Priority
9.[29]xxxxxx	Local T1	Local seven-digit calls
9.727[29]xxxxxx	Local T1	Local ten-digit calls
9.1[29]xx[29]xxxxxx	LD T1	Long-distance calls

The following dialed digit strings illustrate how CallManager processes the digits and what strings result in the user experiencing interdigit timeout.

• Dialed string 9 555-0123

  The third pattern is the only pattern matched, so the call proceeds immediately.

• Dialed string 9 727 555-0123

  Both the third and fourth patterns match the first eight digits (97275550). When the caller dials a 1, the third pattern is eliminated, and the fourth pattern is used immediately after the caller dials the last digit.

• Dialed string 9 727-0123

  Both the third and fourth patterns match the dialed digits. CallManager must wait for additional digits to determine which pattern to use. When the interdigit timer has expired, the call is processed using the third pattern.

  The only time that a user experiences interdigit timeout is when the prefix, or first three digits of a local seven-digit number, matches a "local" area code. Most service providers would avoid this situation by not assigning the 727xxxx block to a customer in the 813 area code.

  Example 9-8 shows the dial peer configurations to support the same numbering plan taken from a CME gateway.

  Gateway#show run | begin dial-peer voice
  dial-peer voice 911 pots
   destination-pattern 911
   port 1/0:23
   prefix 911
  !
  dial-peer voice 9911 pots
   destination-pattern 9911
   port 1/0:23
   prefix 911
  !
  dial-peer voice 7 pots
   destination-pattern 9[2-9]......
   port 1/0:23
  !
  dial-peer voice 10 pots
   destination-pattern 9727[2-9]......
   port 1/0:23
   prefix 727
  !
  dial-peer voice 11 pots
   destination-pattern 91[2-9]..[2-9]......
   port 2/0:23
   prefix 1
  !
  

   

  The same dialed digit strings are used to illustrate how the gateway will process the digits.

• Dialed string 9 555-0123

  Dial peer 7 is the only pattern matched, so the call proceeds immediately.

• Dialed string 9 727 555-0123

  Both dial peer 7 and dial peer 10 match the first eight digits (97275550). Dial peer 7 is used immediately after the caller presses 0, sending the incorrect digits to the service provider.

• Dialed string 9 727-0123

  Both dial peer 7 and dial peer 10 match the dialed digits. Dial peer 7 is used immediately after the caller presses 3, sending the correct digits to the service provider.

As you can see, the user cannot dial 10-digit local numbers using these dial peers. You must modify dial peer 7 to instruct it to wait to determine whether it should consider additional digits. Example 9-9 shows the correct configuration for dial peer 7.

dial-peer voice 7 pots
 destination-pattern 9[2-9]......T
 port 1/0:23
!

 

The "T" added to the end of the destination pattern instructs the gateway to wait until the interdigit timer expires before matching the string. The result of this configuration change is that all seven-digit local calls must wait for the interdigit timer to expire before the call is placed, even though there are no other possible dial peer matches. You can adjust the interdigit timeout to minimize the wait of the end user, but delay will still be noticeable.

Case Study Configuring PSTN Access