H.323 And SIP Dial Peers
In this article we will play with dial peers by setting different combinations between a source and a destination gateway.
Here is the network setting:
x5002 — Mongi Shop router — PSTN router — x4002
Before starting the lab, make sure you know the difference between CUCM wildcards and dial peer wildcards.
In case you need a refresher on H323 configuration or packet analysis, then please read this post.
Playing With Dial Peer Session Protocols
case#1: one outbound call leg is H323 and the remote inbound call leg is SIP
The call succeeds and it is a H.323 call:
case#2: one outbound call leg is SIP and the remote inbound call leg is H.323
The call succeeds and it is a SIP call:
So from both cases, we see that the type of session protocol used for outbound call legs follows what is configured on the outbound call leg, despite the difference with the remote inbound call leg.
But, why does the terminating gateway still accepts inbound call legs whether they are H.323 or SIP? That’s because SIP and H.323 services are up on the router.
So to force the router to stop the H.323 service for example, we can do that as follows:
DTMF Relay
Configuring DTMF support occurs at the voip dial peer level.
Let’s choose which dial peer we will configure DTMF support for.
We examine if any DTMF settings exist already:
Line 390 says DTMF Relay is disabled. We configure it under the dial peer:
and we check again with “show dial-peer” command:
Now we want to examine the negotiated DTMF method between two voice gateways, when a call is established. The network setting is: x5002 — Mongi Shop router — PSTN router — x4002. We call from x5002 to x4002.
- The inbound matched dial peer at PSTN router is voip dial peer 111
- The outbound matched dial peer at Mongi Shop router is voip dial peer 4000
We remove everything related to DTMF relay on both routers.
We make the call and observe the negotiated DTMF relay method with the command “show sip-ua calls”.
Since there is no custom DTMF relay method, both routers fall to inband-voice DTMF relay:
Let’s change the method to H245 alphanumeric on the UAC:
We make the call. The same DTMF method (inband-voice) is agreed upon. That’s because the inbound matched dial peer on the UAS does not support the H245 alphanumeric method.
The following table summarizes what I’ve found from experiencing with different combinations of DTMF relay methods, on the UAC and the UAS.
[table]
UAC DTMF method,UAS DTMF method,negotiated DTMF method
H245-alphanumeric,none,inband-voice
H245-alphanumeric cisco-rtp h245-signal rtp-nte sip-kpml sip-notify,none,inband-voice
sip-kpml,h245-alphanumeric,inband-voice
cisco-rtp,h245-alpha,inband-voice
cisco-rtp,sip-notify,inband-voice
sip-notify,sip-notify,sip-notify
H245-alphanumeric cisco-rtp h245-signal rtp-nte sip-kpml sip-notify,sip-notify,sip-notify
[/table]
Notice that, in the absence of a common DTMF method between the UAC and the UAS, both fall to the default which is Inband-voice.
Dial Peer Matching when Dial Plans overlap in IOS Gateways
Let’s try an overlapping dial plan on gateways that operate in a digit by digit fashion. We will use the following network topology:
Remember that digit by digit operation is performed on these devices:
- CUCME router
- gateways connected to PSTN configured for Overlap Sending and Receiving.
We have one CUCME router on which we configured two dial peers with the same value of precedence. Both dial peers are potential matches for the dial string 5124771551.
Overlapping dial plan in IOS gateways: scenario 1
Dial peer 512 has more explicit digits than dial peer 5122.
We make a call from Mongi shop to Bicycle Sport shop and observe which outbound dial peer is matched on Mongi voice gateway.
Although the full PSTN number is dialed, the voice gateway still waits for more digits. That’s the effect of the terminating character. After no more digits are sent and the interdigit timeout expires, the IOS finds an outbound matching dial peer: dial peer 512 is a match. Dial peer 5122 is a potential match:
I repeated the experiment and had the same results: dial peer 512 is the match and dial peer 5122 is a potential match. So, dial peer 5122 is never matched as long as there is dial peer 512.
This demonstrates that the most specific dial peer (the dial peer with the more explicit digits in the pattern) always wins.
Compare this result with page 457 of the CVOICE Foundation Learning Guide:
According to the author, dial peer 90110 will never be used, although it is the dial peer with the most explicit pattern. This statement contradicts what we just found.
Overlapping dial plan in IOS gateways: scenario 2
We make a call from Mongi phone to PSTN. As soon as I finish dialing “512”, it displays “unknown number” and the call fails.
In the output of the debug, we clearly see the reason: dial peer 5122 was the match and not dial peer 512.
So as soon as the IOS finds a matching dial peer, it uses it and immediately processes the call for routing.
Cisco Dial Peer Hunting
Dial peer hunting is a way to change the default behaviour of outbound dial peer matching.
Dial peer hunt options
Dial peer lab setup
On our Cisco UBE, I’ve set three dial peers for outbound matching. The test pattern will be 911.
Notice the different preference values.
Testing dial peer hunt options
I’ll go through them one by one. To determine which dial peer matched, do a debug voip dialpeer on the CUBE.
Dial-peer hunt 0
this is the default.
Dial-peer hunt 1
Dial-peer hunt 2
Dial-peer hunt 3
Dial-peer hunt 4
Comments
Post a Comment