In this article we will examine the configuration of H323 and dig into Wireshark to see which packets are exchanged. We will read about H323 Fast Connect and Slow Start features.
Home lab setting
Let’s examine the packets between two H323 nodes. The network setting is as follows:
x5002 — Mongi Shop router — PSTN router — x4001 and x4002.
H323 dial peer configuration
The signaling protocol for these dial peers is left to the default value, which is H323. Actually, when you do a “show dial-peer voice 4000” for example, you’ll see “cisco” as the protocol:
It’s not a new protocol. This is just the Cisco version of H323.
In the rest of the article, user at x5002 calls user at x4001.
H.323 Fast Connect: Call Setup And Teardown
In the H323 Fast Connect mode, the media channel capabilities are negotiated in the same TCP protocol session as the H.225 call establishment. So we have only one TCP session, over which there will be a Call Setup message and Open Logical Channel (OLC) exchange messages.
Let us examine how h323 packets are exchanged in Wireshark. You can get a sample capture too on this website.
First, the originating gateway sends a TCP Open request on port 1720, which is the H323 default port on which a gateway listens for incoming H323 Call Setup messages. If the TCP Three-way handshake is made successfully, we can proceed to H.225 operations.
We use the filter h225 to see H225 messages in Wireshark. The originating gateway sends a H225 Call Setup message that contains also a Open Logical Channel packet. The terminating gateway replies with Call Proceeding that also contains an Open Logical Channel packet. This demonstrates that H.323 is operating in Fast Connect mode. This is the default operation mode for H.323 on Cisco voice gateways.
The terminating gateway replies with the Call Alerting message, which is translated into a ringback tone.
Once the called party phone is off hook, the terminating gateway sends a Connect message. At this point, RTP packets are exchanged.
The user at x4002 ended the commmunication fist. So the terminating gateway is the one who sends the releaseComplete message first.
The originating gateway replies with a releaseComplete message:
To examine H.323 statistics on a voice gateway: show h323 gateway. Initially the counters were null on both voice gateways. Then, we made the call and here is how the counters went:
On the originating gateway:
On the terminating gateway:
H.323 Slow Start: Call Setup and Teardown
I’m going to change the H.323 operating mode on one voice gateway to slow start, and leave the default on the other gateway:
One TCP session is negotiated first. This is for the H.225 session:
After sending Call Setup and Call Proceeding messages, a second TCP session is negotiated; this is the transport channel for the H.245 Terminal Capabilities negotiation.
Then comes the H.245 signaling where we have :
- Terminal Capabilities packet exchange
- Master/Slave determination
- Open Logical Channel
Once H.245 signaling is agreed, both gateways are ready for the Connect message. Once the called party phone is hooked off, RTP streams are exchanged.
Like in H.323 Fast Connect, when a phone is hooked on, its attached gateway sends a releaseComplete. This triggers a TCP FIN message to the other party, to signal the end of the TCP session (remember the second TCP session established for H.245 signaling).
And the other gateway follows with a releaseComplete too, and a TCP FIN segment to end the H.245 TCP session
H.323 Source Interface
The command that sets a source interface for H.323 traffic is “h323-gateway voip bind srcaddr …”. However, unlike what it is said in the Cisco CIPT1 Foundation Learning Guide, this command does not set all H.323 traffic to be sourced from the specified interface. And I tried that in Wireshark.
On my PSTN router, I set the H323 interface to the loopback interface:
I then make a call from an attached phone (x4001) to the other phone extension x5002.
What I notice is: when a call is initiated from the attached phone, the source IP address of H.225 signaling and H.245 signaling is the egress interface and NOT the loopback interface. The loopback interface is only used for RTP traffic:
However, when the call is initiated from the other gateway (the one not with the H323 interface binding command), the loopback interface is indeed used for both signaling and media streams.
Notice below that Call Setup, CallProceeding, Alerting, Notify and Connect use the WAN IP addresses and not the H323 bound interface. I still don’t know why but I may need to figure it out.
Inbound PSTN Call Problem On H.323 Gateways
Here is a problem that I saw in my home lab since more than a week, with inbound PSTN calls, to branch office. Inbound PSTN calls to HQ are successful though.
In my home lab diagram below, I only left the relevant parts:
Here is the technical challenge:
From any PSTN line, I could not call into the DID number of the branch office, which is 4048812100. The branch office gateway is registered through its loopback interface to CUCM (the loopback interface is set as the H.323 source interface).
The gateway is a H.323 gateway. Its dial-peers seem correct. I have two matches for the inbound PSTN call, one for the inbound call leg (dial peer 111) and one for the outbound (dial peer 404), towards CUCM.
The branch gateway is registered correctly to UCM.
Outbound calls are OK. The gateway configuration on UCM seems correct, when compared to HQ gateway. I set up Significant digits to 4, set up the gateway CSS for incoming calls.
The DID number of the branch office does not directly map to the internal numbering plan. So I created a Translation Pattern that matches the four digits and transforms them to an internal DN (the branch phone).
Unfortunately, every time I call from PSTN to Branch1, I get a fast busy tone.
I launched Wireshark on the Branch router and filtered with IP address of the UCM: 192.168.2.250. I strangely saw that the Frame Relay interface of the branch router is initiating a TCP connection, for H.323 traffic, to UCM. It’s weird because I’ve configured the loopback interface to be the source of H.323 traffic towards UCM, not the frame relay subinterface.
And the CUCM is refusing the connection (TCP Reset segment), logically because it has no gateway registered to it with IP address of 156.100.26.2.
I compared this behaviour with HQ router. I launched Wireshark on the HQ router. The HQ router is sending H.323 traffic to CUCM from its F0/0 interface and is receiving a successful H.323 Call Proceeding message.
So I changed the source interface of H.323 traffic, on the branch router, from the loopback interface to the Frame relay subinterface.
I deleted the gateway on UCM and created a new one, with IP address of 156.100.26.2.
I modified the firewall security rules on my Comodo firewall to allow for IP traffic between the UCM subnet 192.168.2.0/24 and the Frame relay subnet 156.100.26.0/30 (See how to modify global security rules on Comodo firewall)
After a couple of refreshes on the UCM gateway page, I got the gateway registered again.
Then I tried once again to call from PSTN into the branch 1 phone, and now it rings.
Yes the called party is not properly displayed. I need to throw in some digit manipulation techniques.
At this point the config mislead me to think that the command “h323-gateway voip interface” defines the source of H.323 traffic towards CUCM. I was wrong.
I found out the correct command that does that is “h323-gateway voip bind srcaddr X.X.X.X}. I tried it on the Branch1 router:
And I removed the gateway and recreated one with the IP address 12.1.65.254.
After a shut/no shut, the gateway registers, and I’m able to receive inbound PSTN calls into Branch1.
