Cisco IOS Dial-Peers: Inbound Dial-Peers

The next dial-peer example is an example of an inbound POTS dial-peer. Dial-peer voice 1 pots Incoming called-number .T Direct-inward-dial Port 0/0/0:23 Notice that the destination-pattern command is not being used with dial-peer 1. Dial peer 1 is dedicated to inbound call routing. One of the outbound PSTN dial peers from previous blogs could have been leveraged to provide inbound and outbound call routing, but it is best practice to dedicate a dial-peer to for inbound call routing from the PSTN. A single inbound dial peer allows digit manipulation to be performed on the inbound dial-peer using translation profiles. We’ll cover translation profiles in a future blog. I have included a port identifier in this example, but I would normally not reference a port identifier if the gateway router had multiple PRI interfaces. Dial peer 1 includes two new commands we have not covered yet. The lack of the direct-inward-dial command would result in a secondary dial tone to the calling party. The direct-inward-dial command forces the router to perform digit analysis against the received digits so the call is presented to the final destination. The incoming-called number .T command ensures dial peer 1 will pick up all incoming calls sent from the provider to the primary rate interface (PRI) signaling interface (:23 addresses the Q.931 signaling channel). There is a hierarchy of options to matching inbound call legs which is as follows: 1) Incoming called-number 2) Answer-address 3) Destination-pattern 4) Port The incoming called-number command matches against the called party number (DNIS), while the answer-address command matches on the calling party number (ANI). When matching on inbound dial-peers, I normally use one of these two mechanisms. It is important to use these mechanisms when there is a requirement for complex digit manipulation due to tail end hopoff (TEHO) or overlapping number plan conditions. I normally use the incoming called-number . or .T to match on any values the PSTN routes to the site. The destination-pattern string normally matches against the dialed digits (called party number) for the purpose of outbound call routing. Instead of matching the destination-pattern against the dialed digits (called party), the destination-pattern command is analyzed against the calling party (ANI) for inbound calls. I have never used a destination-pattern to match against ANI on an inbound call, but I have had plenty of troubleshooting scenarios where the wrong inbound VoIP dial-peer is selected because the destination-pattern matches the remote sites calling party information. Debugging inbound call routing dial-peer selection is best done with the “debug voip dialpeer” command. This command will display debug output for both POTS and VoIP dial peers. The port mechanism is only used with POTS dial peers if there is no other mechanism available. Let’s consider an example where Global Knowledge has a 5 digit dial plan at a site and the carrier PRI circuit was ordered to provide only the last 5 digits of the dialed number. Dial peer 1 will match the inbound call leg, but the second call leg will be a VoIP dial-peer that forwards the 5 digits to Cisco Unified Communications Manager. In the next blog, we will begin discussing VoIP dial peers.