CCIE-V "I Shoulda' Checked That" Tip #5: Dial-Peer Zero is Bad Like Vad

This is the fifth installment in what I am calling the "I Shoulda' Checked That" series. The inspiration for this series is covered in the first installment. To save readers some time, I am going to jump right into things. On this go around, I am going to discuss the fifth tip of the series: Don't Forget Dial-Peer 0. 

The Scenario...

As with the other installments in this series, we are going to discuss how one little oversight can undermine an otherwise perfect configuration.  Let's take the following scenario as an example.

We have a basic two-site topology. Gateway GWA has a PRI that is down and we have provisioned CUCM to roll calls over to Gateway GWB. GWB is a H.323 gateway that has the following VoIP dial-peers:

!
voice class codec 1
 codec preference 1 g711ulaw
 codec preference 2 g729r8
!
voice class h323 1
 h225 timeout tcp establish 2
!
dial-peer voice 81990 voip
 destination-pattern 3...$
 voice-class codec 1
 voice-class h323 1
 session target ipv4:10.3.120.12
 dtmf-relay h245-alphanumeric
 ip qos dscp cs3 signaling
 no vad
!
dial-peer voice 81991 voip
 preference 2
 destination-pattern 3...$
 voice-class codec 1
 voice-class h323 1
 session target ipv4:10.3.120.11
 dtmf-relay h245-alphanumeric
 ip qos dscp cs3 signaling
 no vad

The extension range for Site A is 2000 - 2999 and for Site B it is 3000 - 3999. Assume that the POTS dial-peers on GWB are provisioned correctly and calls to PSTN PhoneC from PhoneA or PhoneB route OK. You are able to complete the call, your calling/called presentation is solid and you are satisfied all is well in the kingdom of PRI-failover. But, there is a miss here.

What's Working...

There is something missing from the config, but calls from Site B phones are operating the way they should. We can look at the output of  "show voice call status" and we see the following:

R2#show voice call stat
CallID     CID  ccVdb      Port             DSP/Ch  Called #   Codec    Dial-peers
0x4F       A11  0x68947600 0/1/0:23.1       0/3:1  *98397263   g711ulaw 81990/91020
1 active call found

We are hitting the right voip dial-peer on ingress (81990) and we have selected the appropriate POTS dial-peer for egress (91020). Our codec preferences are working A-OK as we want G711u for media paths between devices in the same site.

What's Not...

We route the media path across the WAN when placing a call from SiteA to the same destination. On the surface, everything appears to work as desired. However, we spot a problem when we look at "show voice call status":

R2#show voice call stat
CallID     CID  ccVdb      Port             DSP/Ch  Called #   Codec    Dial-peers
0x51       B11  0x68947600 0/1/0:23.1       0/3:1  *98397263   g729br8   0/91020
1 active call found

In this call we are hitting that sneaky bastard of a dial-peer: dial-peer 0. Is this bad? I believe it is. To illustrate why I feel this way, let's talk about what dial-peer 0 does and doesn't do. 

Dial-Peer 0: Codec

I have heard people say that dial-peer 0 only supports the G.729 codec. This is simply inaccurate. On a voip call leg, dial-peer 0 will support any codec that is offered during the TCS exchange. Using debug h245 asn1 on the voice gateway in a scenario where dial-peer 0 is selected shows that the H323 gateway send a TCS message with a capability table that includes every codec supported by the gateway. 

What is true is that if you had a desire to force a specific "flavor" of G729 (for example) throughout your environment that you may not be able to achieve that. You can see in the above output I am getting g729b. However, my approach to the lab tries to use g729 wherever possible. Whether my preference is right or wrong doesn't matter. What matters is I am not seeing exactly what I want to see for this call.

Dial-Peer 0: VAD

On a voip call leg, dial-peer 0 will enable VAD. Which is most likely not what you want to do. You can most readily see the effects dial-peer 0 has on media streams by forcing the use of dial-peer 0 on a voip leg and then "mute" the PSTN phone in the call. You can then look at call statistics on your IP phone. You will see Receiver Packets stand still. On a dial-peer where vad is disabled, the receiver packet counter keeps truckin' along. On the gateway, "show call active voice brief" will give you counters like the following:

R2#sho call act vo br
((stuff deleted))
Telephony call-legs: 1
SIP call-legs: 0
H323 call-legs: 1
Call agent controlled call-legs: 0
SCCP call-legs: 0
Multicast call-legs: 0
Total call-legs: 2
2912 : 132 233316070ms.1 +1500 pid:0 Answer 2003 active
 dur 00:04:58 tx:115/2066 rx:14921/298420
 IP 142.102.64.130:16764 SRTP: off rtt:0ms pl:292350/0ms lost:0/2/0 delay:60/60/80ms g729br8 TextRelay: off
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a
2912 : 133 233316110ms.1 +1460 pid:91020 Originate 98397263 active
 dur 00:04:58 tx:14921/417788 rx:115/2066
 Tele 0/1/0:23 (133) [0/1/0.1] tx:299780/2040/0ms g729br8 noise:-84 acom:45  i/0:-79/-79 dBm
!
R2#sho call act vo br
((stuff deleted))
Telephony call-legs: 1
SIP call-legs: 0
H323 call-legs: 1
Call agent controlled call-legs: 0
SCCP call-legs: 0
Multicast call-legs: 0
Total call-legs: 2
2912 : 132 233316070ms.1 +1500 pid:0 Answer 2003 active
 dur 00:05:07 tx:115/2066 rx:15355/307100
 IP 142.102.64.130:16764 SRTP: off rtt:0ms pl:303860/0ms lost:0/2/0 delay:60/60/80ms g729br8 TextRelay: off
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a
2912 : 133 233316110ms.1 +1460 pid:91020 Originate 98397263 active
 dur 00:05:07 tx:15355/429940 rx:115/2066
 Tele 0/1/0:23 (133) [0/1/0.1] tx:308450/2040/0ms g729br8 noise:-84 acom:45  i/0:-79/-79 dBm

We ran the show command twice. There is a gap of about 2 seconds or so between each iteration. Notice that the tx: counter for the voip call leg doesn't change. During this test my PSTN phone is muted.  If my voip leg dial-peer had vad disabled (no vad) then you would see the tx: counter incrementing continuously.

So, when using dial-peer 0 for the voip leg we are getting vad and vad is bad. 

Dial-Peer 0: QoS

On a voip call leg, dial-peer 0 will use IP precedence of 0...for everything. The best way to see this happening is to use a service policy on the WAN interface of the gateway. If you have a voip call leg using dial-peer 0 on the gateway, RTP packets heading back across the WAN (or LAN) will have IP Prec/DSCP of 0 or best effort. 

Dial-Peer 0: DTMF Relay

Dial-peer 0 will not negotiate DTMF relay therefore the tones are sent "in-band". Since our call is a G729 call, this is no good. 

Conclusions

As stated above, I believe that you should completely avoid using dial-peer 0 for voip call legs. I believe this to be true for both the lab and production environments. In regards to lab scoring, even if somehow the use of dial-peer 0 isn't directly relevant to any lab questions, there are just too many things it could affect. I'd also bet that there is a check in there somewhere because it is something a candidate could easily overlook in their haste to get a working config.

Wait, why wasn't dial-peer 0 used for Phone B...

You may have noticed that in our call from Phone B to Phone C we were using the correct dial-peer for our voip call leg. We don't have incoming called number specified, so maybe you are asking why was the correct dial-peer selected? 

Well, this gets into the dial-peer matching process and selection order. Voice gateways will match inbound dial-peers using the calling or called number information elements. Matches are made using the following logic (in the order provided):

1. Called number with the incoming call-number command
2. Calling Number with the answer-address command
3. Calling Number with the destination-pattern command
4. Voice-port associated with the incoming call setup request (POTS dial-peer only)
5. Default dial-peer 0

Based on the above logic, the reason dial-peer 81990 was selected in our "good call" example is because the calling number on the phone happened to match the destination-pattern on dial-peer. So, we had a match at step 3.

---

Thanks for reading. If you have time, post a comment!