The Evil of Dial-Peer 0 (pid:0)

Certification Focus: CCNA Voice, CCNP Voice, CCIE Voice 

I remember sitting in my first Cisco voice class many years ago when the subject of dial peers was first discussed.  I also remember how absolutely lost I felt trying to get my head around the Cisco IOS voice gateway concepts of call legs, inbound and outbound dial peer matching, and the now infamous, "Dial Peer 0".

My goal with this post isn't to write a book on the subject - those exist already.  I'm going to instead summarize into (hopefully) easily digestible parts for Cisco voice students of all levels.  For the seasoned voice engineers out there, make sure you see the section below on the new Toll-Fraud Prevention Feature that is now included in IOS, starting with IOS 15.1(2).

Call Leg Concept Overview

Voice calls that traverse packet networks can be described by distinct sections or "call legs".  A call leg is a logical connection between the IOS gateway and another IOS gateway (or another IP telephony device).   Each call leg is associated with a dial peer that describes many parameters about that specific to that call leg.

There are two basic types of dial peers.

1. POTS (plain old telephone system) dial peers are mapped to specific voice ports.  Often these voice ports are connected to the PSTN (public switched telephone network), a local PBX (private automatic branch exchange), or analog phone or fax machine.
2. Voice network dial peers define the attributes of a connection to a packet voice network device(H.323 gateways and gatekeepers, SIP peers, Unified Call Managers, etc.).

In simple terms, each call that goes through a gateway will have two call legs on that gateway; one inbound and one outbound.  Each call leg will (typically) be defined by a different dial-peer on the gateway. 

Inbound Dial Peer Matching Process

The router or gateway matches the information elements in the setup message with the dial peer attributes to select an inbound dial peer. The router or gateway matches these items in this order:

1. Called number (DNIS) with the incoming called-number command
   First, the router or gateway attempts to match the called number of the call setup request with the configured incoming called-number of each dial peer. Because call setups always include DNIS information, it is recommended to use the incoming called-number command for inbound dial peer matching. This attribute has matching priority over the answer-address and destination-pattern commands.
   
2. Calling Number (ANI) with the answer-address command
   If no match is found in step 1, the router or gateway attempts to match the calling number of the call setup request with the answer-address of each dial peer. This attribute can be useful in situations where you want to match calls based on the calling number (originating).
   
3. Calling Number (ANI) with the destination-pattern command
   If no match is found in step 2, the router or gateway attempts to match the calling number of the call setup request to the destination-pattern of each dial peer. For more information about this, see the first bullet in the Dial Peer Additional Information section of this document.
   
4. Voice-port (associated with the incoming call setup request) with configured dial peer port (applicable for inbound POTS call legs)
   If no match is found in the step 3, the router or gateway attempts to match the configured dial peer port to the voice-port associated with the incoming call. If multiple dial peers have the same port configured, the dial peer first added in the configuration is matched.
   
5. If no match is found in the first four steps, then the default dial peer 0 (pid:0) command is used. <--  This does not come without a significant downside.
   

The Evil of Dial Peer 0

Dial-peer 0 (pid:0) has a default configuration that cannot be changed.

The default dial-peer 0 fails to negotiate non-default capabilities, services, and applications such as:

• Non-default Voice-Network capabilities: dtmf-relay, no vad, and so forth.
  
• Direct Inward Dial (DID)
  
• TCL Applications
  

Dial-peer 0 for inbound VoIP peers has this configuration:

• any codec
  
• marks traffic as IP precedence 0
  
• vad enabled
  
• no rsvp support
  
• fax-rate voice
  

Dial-peer 0 (pid:0) for inbound POTS peers has this configuration:

• no ivr application

These limitations can and will cause unexpected results if you do not take care to ensure that all inbound calls match a properly configured dial-peer.

Detecting Dial-Peer 0

Use the following commands to check to see if calls are using pid:0 or dial-peer 0:

1. debug voip ccapi inout
2. show call active voice brief 
3. show dialplan incall 
4. debug voip dialpeer

(thanks to @th1nkdifferent for the suggestions)

Avoiding Dial-Peer 0

If you can't define more specific dial-peers to avoid the use of pid:0 (dial-peer 0), you can use a "catch-all" dial-peer like this one:

dial-peer voice 1 pots
incoming called-number .
port 0/0/1:23

Toll-Fraud Prevention Feature in IOS 15.1(2)

Starting with 15.1(2)T, the router’s default behavior is to not trust a call setup from a VoIP source. This feature adds an internal application named TOLLFRAUD_APP to the default call control stack, which checks the source IP of the call setup before routing the call. If the source IP does not match an explicit entry in the configuration as a trusted VoIP source, the call is rejected. 

Read all about it here.

Additional Information

1. Understanding Dial Peers and Call Legs on Cisco IOS Platforms
2. Cisco IOS Voice Troubleshooting and Monitoring
3. Understanding Inbound and Outbound Dial Peers Matching on IOS Platforms
4. Toll-Fraud Prevention Feature in IOS 15.1(2)