H323 Dial Peer made simple

H323 dial peers play an important role in Call routing though a H323 gateway.

Understanding dial peers is very crucial for Call routing or any dial plan design. Most of the time people are confused between POTS and VoIP dialpeers and how they should be used. I will try to make the concept as easy as possible to better understand the working of H323 protocol.

There are mainly two types of dial peers. The POTS (Plain old Telephony System) and the VoIP dialpeer (Voice over IP). There are two more VoFr and VoATM but they are not widely used and I will not jump into that.

A POTS dialpeer matches a dialed number to an Outside port. It could be an E1/T1 , FXO port or a PBX link.

A VoIP dialpeer points to a remote network device. It could be a Call manager, Unity Express, SIP Server, Gatekeeper etc.

Outbound Call from CUCM to PSTN:

I will not go into too much technical details as that will make things complex which is not the purpose of this blog. You can always read up on Cisco if you want to dig deep. To make things simple for understanding, this is how a Call flow works.

IP Phone ——–> CUCM  ——–> Switch ——–> Gateway —————-> PSTN Cloud —————-> PSTN Phone

When an IP Phone makes an Outbound call, the call first meets an Inbound VoIP dialpeer and then meets an Outbound POTS dialpeer.

IP Phone ———————> (Inbound Voip) <Gateway> (Outbound POTS) —————— > >> PSTN Phone

Lets say the Caller (01189884443 @ CUCM) dials 901189889999 (A Reading local number), this will be first matched at CUCM with a Route pattern 90118XXXXXXX or 9@ (if using UKNP dialplan). For an MGCP gateway, we can always strip off the leading ‘9’ with predot but for most of the H323 configuration we would need to send that ‘9’ to the gateway. First of all this call will meet an ‘inbound voip dialpeer’:

Inbound VoIP dialpeer:

dialpeer voice 1 voip
incoming called-number .
dtmf-relay h245-alphanumeric
no vad
codec g711ulaw

The ‘ incoming called-number . ‘ is used to match any number coming from CUCM. I could have used ‘incoming called-number 9’ as any call coming from CUCM will have the leading ‘9’. We can also use ‘answer-address’ which is searched if ‘incoming called-number’ is not present. The ‘answer-address’ points to the calling-number which in our case would be ‘01189884443’. The dial-peer can have ‘answer-address 0118988….’, a call coming from CUCM will match this dial-peer. If there is no ‘incoming called-number’ and ‘answer-address’ then the gateway will hunt for dialpeer with destination-pattern of calling party number i.e. 01189884443. So if we have a dialpeer which says ‘ destination-pattern 0118988….’ then this will be matched.

dtmf-relay should always be set to h245-alphanumeric if a Call manager is involved. Other options include h245-signal and cisco-rtp.

If an inbound VoIP dialpeer is not created then each outbound call will match a default IOS inbound VoIP dialpeer. The characteristics of that dialpeer is as follows:

• Any Supported codec
• No DTMF Relay
• IP Precedence 0
• VAD enabled
• No RSVP support
• Fax-rate Voice

Making a call to meet a default VoIP dialpeer is definitely not a good approach. It has VAD enabled and can match any codec. Many times a call may fail because of it matching the default VoIP dialpeer. Always make an Inbound VoIP dialpeer to avoid the default one. In short this is what gateway does to match an inbound VoIP dialpeer:

1. Match the called number (DNIS) with incoming called-number
2. Match the Calling number (ANI) with answer-address
3. Match the Calling number (ANI) with destination-pattern
4. If all fails, match dialpeer ID 0 (default dialpeer)

Outbound POTS dialpeer:

After the call gets its codec, dtmf-relay etc from VoIP dialpeer, it goes to Outbound POTS dialpeer on the gateway. The POTS dialpeer will be similar to this:

dialpeer voice 9 pots
destination-pattern 9T
port 0/0/0:15

This one is a simple POTS dialpeer which will match our dialed digits and will send it to PSTN. Remember a POTS dialpeer makes a match of the dialed digits to the destination pattern and any digit which match explicitly to it will be dropper and the rest will be forwarded to the port towards PSTN. In the above dialpeer the digit ‘9’ will be dropped and ‘ 01189889999’ will be sent to PSTN. I have used the leading ‘9’ as many customers use ‘9’ to make an outside call. There are few others who don’t use ‘9’ and you can make an outside call as if you are dialing from a normal phone. In that case, we will have a dialpeer with destination-pattern .T

I have used port 0/0/0:15 for an E1. The same will be 0/0/0:23 for a T1.

If the call is for ‘999’ then the dialpeer configuration will be slightly different.

dialpeer voice 9 pots
destination-pattern 999
Prefix 999
port 0/0/0:15

Here I used the keyword prefix to force the dialpeer to send ‘999’ to the PSTN otherwise it will drop all the digits due to explicit match. You can also use ‘no digit-strip‘ or ‘foward-digits all’ to send all digits to PSTN.

For an International call from UK, we can use the following dialpeer:

dialpeer voice 900 pots
destination-pattern 900T
Prefix 00
port 0/0/0:15

Here we cannot use ‘no digit-strip’ as it will send the leading ‘9’ as well. After matching explicitly ‘900’ will be dropped and the rest of the digits will be sent to PSTN. It depends what are PSTN requirements. If PSTN needs leading ’00’ to signal an International call then we will have to prefix ’00’ forcing the dialpeer to send ’00’ to the PSTN.

Note: We can use the first dialpeer ‘9T’ for an International call as well. I created the ‘900’ one to make things more understandable.

Inbound call from PSTN to CUCM:

An Inbound call from Outside world over PSTN to the Voice gateway will first meet an Inbound POTS dialpeer and then an Outbound VoIP dialpeer.

PSTN Phone —————-> PSTN Cloud —————-> Gateway —————->Switch ——–>CUCM  ——–> IP Phone

This is how the dialpeers are matched:

PSTN Phone —————->> (Inbound POTS) <Gateway> (Outbound VoIP) —————— > >> IP Phone

Lets say a caller from PSTN dials 01189884443 which hits our gateway. The company is using a DDI range of 98844XX (100 numbers). This call will first meet an Inbound POTS dialpeer and then a Outbound VoIP dialpeer.

Inbound POTS dialpeer:

dialpeer voice 2 pots
incoming called-number .
direct-inward-dial

This will match any inbound call coming to this gateway. The ‘direct-inward-dial’ is used to route the called-party number (01189884443) immediately instead of providing a dial tone an waiting for digits. It’s always a good practice to use ‘direct-inward-dial’ to avoid toll fraud. A caller can dial in and after reaching the gateway can make an outside call to anywhere.

If an inbound dialpeer is not created then an incoming call will meet the default IOS inbound POTS dialpeer. The characteristics of this dialpeer are as follows:

• No Application support (like IVR etc)
• No direct-inward-dial

This is why it’s very important to have a POTS dialpeer for all incoming calls. This is what a gateway does to match an inbound POTS dialpeer:

1. Match the called number (DNIS) with incoming called-number
2. Match the Calling number (ANI) with answer-address
3. Match the Calling number (ANI) with destination-pattern
4. If all fails, match dialpeer ID 0 (default dialpeer)

Outbound VoIP dialpeer:

This dialpeer will send the call to Call manager. If there are any translation patterns/Num-exp etc then they will do their work before reaching to this dialpeer. A typical Outbound VoIP dialpeer will be like this:

dial-peer voice 4000 voip
destination-pattern 44..$
voice-class codec 1
voice-class h323 1
session target ipv4:10.10.200.11
dtmf-relay h245-alphanumeric
no vad
!
dial-peer voice 4001 voip
preference 1
destination-pattern 44..$
voice-class codec 1
voice-class h323 1
session target ipv4:10.10.200.10
dtmf-relay h245-alphanumeric
no vad
!
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8

voice class h323 1
h225 timeout tcp establish 3
h225 timeout setup 3

Last four digits of the inbound call will be matched against destination-pattern 44.. which will then send the call to Subscriber first (10.10.200.11) and then to Publisher (10.10.200.10) due to preference command. If there is just one call manager then there is no need for the second dialpeer. The two dialpeers are there for redundancy and backup. If subscriber goes down then call will reach the Publisher. The codec class is there to match possible codec for inbound call while the h323 class is there to route between the two dialpeers.

This is how a call is completed. I have just given a basic breakdown of an inbound and outbound call flow. There is a lot involved if we start using translation patterns and translation profiles etc which I will discuss in some other entry.