There was a good question posed by Karla Reyes a few days ago about the use of a voice dial peer that included the string incoming-called-number. I did my best to figure out why one would use such a dial peer in production, and that led me to a search and discovery of all sorts of interesting things about dial peers and what happens when you are forced into defaults.
On a Cisco phone system, whether it be CallManager or CallManager Express, dial peers on your voice gateways route calls to the correct destinations, both inbound and outbound. The outbound dial peers I’m familiar with, having configured them on numerous CUCME systems. The inbound dial peers, not so much. I configure most of my systems to use connection plar opx <extension> to ring analog circuits and send the calls to an operator or an auto attendant (AA). Absent that configuration, you can still configure dial peers to evaluate incoming calls and route them to the proper locations.
Cisco voice gateways will evaluate the dial peers and choose the one the has the longest set of matching digits when deciding where to send a call. So if one dial peer is 8… and the other is 85.., then if you call “8511”, the second dial peer will be used since it has the most matching digits of the two. If you dial “8721”, the first dial peer is matched. This is a simple, straight forward process. When incoming calls are headed into the system, the same process is used. So what happens if there isn’t a perfect match?
This is where Dial Peer 0 comes into play. Dial Peer 0 exists on every voice gateway. It’s a sneaky little default setting that no one pays much attention to until they stumble across it. Part of the reason is that it’s invisible. No reference to Dial Peer 0 pops up in the configuration. Since it’s the default and it’s hard-coded, it’s always there. It’s kind of like the implicit deny statement at the end of every access list. And much like that deny statement, it often produces strange and undesirable results when it gets triggered. That’s because Dial Peer 0 is designed to work with just about anything, so it has some of the silliest settings imaginable:
- It supports any codec you throw at it. The designers figured that rather than waste precious time negotiating whether or not your should use G.711 or G.729, Dial Peer 0 should just accept whatever it’s sent and move on. Not so great when you are trying to keep bandwidth conserved on a slow link and someone sends you big fat voice packets.
- DTMF packets are sent in-band, so if you decide to use G.729 as your signaling protocol, the tones can get mangled by the compression process.
- All the voice signaling and data packets have their IP precedence settings remarked to 0. All that pain and effort you went through getting your perfect Quality of Service (QoS) setup working gets chucked right out the window.
- Resource Reservation Protocol (RSVP) is disabled. That means if you spent even more time and pain setting up an Integrated Services QoS setup, it’s going to fail when the call hits Dial Peer 0.
- IVR applications are disabled. This means that any scripts that would be used for things like auto attendants are going to break.
- Last but not least, Direct Inward Dial (DID) isn’t present. This means your callers will get confused because they’ll hear a secondary dial tone when the call leg completes. This is where they would enter your extension number to speak to you. Instead, they’ll figure the call didn’t work then hang up and try again. Enterprising hackers will hear the dial tone and realize what that means then try and transfer to another number, such as long distance or international calling. That’ll run up your phone bill fast.
Sounds like a whole bunch of bad reasons to never use Dial Peer 0, right? Except you can’t get rid of it. It’s always there, lurking and waiting to screw up your day. The only way to avoid using it is to configure a new default dial peer to match instead of letting the call fall all the way down to Dial Peer 0. In order to understand that, you have to know the order in which Cisco matches incoming dial peers:
- Match the dialed number with incoming-called-address configured in the dial peer.
- Match the calling number with answer-address configured in the dial peer.
- Match the calling number with destination-pattern configured in the dial peer.
- Match an POTS dial peer with a port command configured in the dial peer.
- Take your chances with Dial Peer 0.
The easiest (and by far most popular) method of overriding Dial Peer 0 is to use #1 above like this:
dial-peer voice 1 pots incoming-called-number . direct-inward-dial
This ensures Dial Peer 1 is always matched ahead of Dial Peer 0, but not matched if a longer match exists. It also uses DID to disable two-stage dialing, so those nefarious hackers won’t get a chance to call Cuba on your dime.
Defaults exist so that we don’t have to think about things sometimes. Anyone who’s ever told someone how to install Microsoft Office by saying “Click Next, Next, I Agree, Next, Next” will know what defaults come in very handy. However, if the default settings are baked in and unable to be changed, it makes life difficult if you can’t account for them and find a way to work around them. At the very worst, it just means you get to spend a little more time on the phone with your favorite TAC engineers.