SIP Trunk & H323 on CUCM and Voice Gateway

What are SIP Trunk & H.323?

SIP Trunk and H.323 are both protocols for VoIP communication, facilitating session setup, media negotiation, and interoperability between networks. They enable connections between IP and traditional telephony networks using gateways.
SIP has become more popular due to its simplicity and adaptability, while H.323 is an older protocol with greater complexity and limited modern usage.

Topology

Here is the topology for this deployment, where there will be 1 CUCM sending and receiving both SIP and H323 sessions from 2 Voice Gateways.

1. SIP Trunk

Configure SIP Trunk on CUCM

Go to Device » Trunk » Add new, give it Name, Device Pool and IP Destination. The rest keep leave it as default as we keep this configuration minimal.

Add another one for the second VG

Then go to Call Routing » Route/Hunt » Router Pattern, Create new route pattern with pattern 9xxx going to XE2

Configure SIP Trunk on Voice Gateway

a. XE2

First, we enable the voice voip service

voice service voip
 allow-connections sip to sip 

After that we create a translation rule to translate the incoming call from prefix 9xxx to 1xxx

voice translation-rule 1
 rule 1 /^9/ /1/ 

voice translation-profile NINE_TO_ONE
 translate called 1

Then create a dial-peer for incoming calls from CUCM

dial-peer voice 1 voip
 description FROM CUCM
 translation-profile incoming NINE_TO_ONE
 session protocol sipv2
 incoming called-number .
 dtmf-relay rtp-nte

Next another dial-peer for sending calls to XE3

dial-peer voice 2 voip
 description TO XE3
 destination-pattern 1.
 session protocol sipv2
 session target ipv4:198.18.0.123
 dtmf-relay rtp-nte

Last one, an additional dial-peer with session target of CUCM. This will not be used but it’s needed so the SIP Trunk between CUCM and XE2 goes up

dial-peer voice 99 voip
 description TO CUCM
 destination-pattern 123.
 session protocol sipv2
 session target ipv4:198.18.0.21
 dtmf-relay rtp-nte

b. XE3

Same here, we enable the voice voip service

voice service voip
 allow-connections sip to sip 

Then create some dial-peers with more or less same function as on XE2

dial-peer voice 1 voip
 description FROM XE2
 translation-profile incoming NINE_TO_ONE
 session protocol sipv2
 incoming called-number .
 dtmf-relay rtp-nte

dial-peer voice 2 voip
 description TO CUCM
 destination-pattern 1.
 session protocol sipv2
 session target ipv4:198.18.0.21
 dtmf-relay rtp-nte

dial-peer voice 99 voip
 description TO XE2
 destination-pattern 987.
 session protocol sipv2
 session target ipv4:198.18.0.122
 dtmf-relay rtp-nte

Testing SIP Trunk Call

Now if we try to make a call from 1001 to 9002, the call should be going out to XE2, the called party translated to 1002, and sent to XE3, and then XE3 send it back to CUCM.

Lets try to enable debugging on XE2 to see the SIP Sessions

debug ccsip messages

Then upload the logs to Cisco Cway or use TranslatorX to get a visual representation of the log messages

After adding a bit of explanation of each message, this is pretty much how SIP messages work in handling voice sessions

2. H.323

Configure H323 Gateway on CUCM

Go to Device » Gateway » Add new, select H323 Gateway, give it an IP and Device Pool, the rest we can leave as it is.

And another one for the other VG

Then go to Call Routing » Route/Hunt » Router Pattern, Create new route pattern with pattern 9xxx going to 198.18.0.122

Configure H.323 on Voice Gateway

a. XE2

First, we enable the voice voip service

voice service voip
 ip address trusted list
   ipv4 198.0.0.0 255.0.0.0
 allow-connections h323 to h323 

After that we create a translation rule to translate the incoming call from prefix 9xxx to 1xxx

voice translation-rule 1
 rule 1 /^9/ /1/ 

voice translation-profile NINE_TO_ONE
 translate called 1

Next we set the interface receiving the call to become the H.323 Gateway

interface GigabitEthernet 1
 h323-gateway voip interface
 h323-gateway voip bind srcaddr 198.18.0.122

Lastly we create 2 dial-peers for the 2 facing call legs

dial-peer voice 100 voip
 description FROM CUCM
 translation-profile incoming NINE_TO_ONE
 incoming called-number .
 no vad
 codec g711ulaw

dial-peer voice 200 voip
 description TO XE3
 destination-pattern 1.
 session target ipv4:198.18.0.123
 no vad
 codec g711ulaw

b. XE3

For XE3, its pretty much the same configuration with different facing side for the dial-peers

voice service voip
 ip address trusted list
   ipv4 198.0.0.0 255.0.0.0
 allow-connections h323 to h323

interface GigabitEthernet 1
 h323-gateway voip interface
 h323-gateway voip bind srcaddr 198.18.0.123

dial-peer voice 100 voip
 description FROM XE2
 incoming called-number .
 no vad
 codec g711ulaw

dial-peer voice 201 voip
 description TO CUCM
 destination-pattern 1.
 session target ipv4:198.18.0.21
 no vad
 codec g711ulaw

Testing H.323 Call

If we repeat the testing as before, we’ll get the same result but the difference is this time we’re using H.323 instead of SIP

Running debugging on XE2 shows that the traffic indeed passes through with H.323

debug cch323 h225 
debug cch323 h245

• H.323 is the overall protocol suite that defines how multimedia communication occurs over IP networks.
  
• H.225 is responsible for call signaling and control, managing the establishment and termination of connections.
  
• H.245 is responsible for negotiating the capabilities of the endpoints and controlling the setup, maintenance, and release of media channels used in the session.
  

But unfortunately there’s no tool to help reading H.323 logs easier like there is for SIP, but its okay no one uses H.323 anymore anyway xD