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.
- 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.
- 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.).
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:
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.
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).
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.
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.
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.
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)
marks traffic as IP precedence 0
no rsvp support
- no ivr application
Detecting Dial-Peer 0
Use the following commands to check to see if calls are using pid:0 or dial-peer 0:
(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 .
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.