H323

H323 IOS Configuration And Packet Analysis

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

h323--2016-03-06 19_10_41

h323--2016-03-06 19_10_35

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:

h323--2016-03-06 19_15_22

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.

h323-2016-02-28 16_33_47

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.

h323-2016-02-28 16_20_59

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.

h323-2016-02-28 16_40_06

The user at x4002 ended the commmunication fist. So the terminating gateway is the one who sends the releaseComplete message first.

h323-2016-02-28 16_42_19

The originating gateway replies with a releaseComplete message:

h323-2016-02-28 16_43_55

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:

h323-2016-02-28 16_46_31
H.323 counters on the Originating gateway

On the terminating gateway:

h323-2016-02-28 16_46_39
H.323 counters 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:

h323-2016-02-28 16_57_53

One TCP session is negotiated first. This is for the H.225 session:

h323-2016-02-28 16_58_56

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.

h323-2016-02-28 17_00_35

Then comes the H.245 signaling where we have :

  • Terminal Capabilities packet exchange
  • Master/Slave determination
  • Open Logical Channel

h323-2016-02-28 17_04_18

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.

h323-2016-02-28 17_06_29

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).

h323-2016-02-28 17_09_49

And the other gateway follows with a releaseComplete too, and a TCP FIN segment to end the H.245 TCP session

h323-2016-02-28 17_14_51

 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:

h323-2016-02-28 20_35_54

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:

h323-2016-02-28 20_32_33
Although the “h323-gateway voip bind srcaddr” command is set under the loopback interface, the H.323 traffic goes on and off the WAN interface. The loopback address is only used for RTP.

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.

h323-2016-02-28 20_41_25

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:

inbound-pstn-call-problem-h323-gateways-2016-05-28 19_23_38
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).

inbound-pstn-call-problem-h323-gateways-2016-05-28 19_24_28
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.

inbound-pstn-call-problem-h323-gateways-2016-05-28 19_30_07

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.

inbound-pstn-call-problem-h323-gateways-2016-05-28 19_31_42

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).

inbound-pstn-call-problem-h323-gateways-2016-05-28 19_32_16

inbound-pstn-call-problem-h323-gateways-2016-05-28 19_32_27
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.
inbound-pstn-call-problem-h323-gateways-2016-05-28 19_34_47And 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.

inbound-pstn-call-problem-h323-gateways-2016-05-28 19_38_09
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.

inbound-pstn-call-problem-h323-gateways-2016-05-28 19_42_24

So I changed the source interface of H.323 traffic, on the branch router, from the loopback interface to the Frame relay subinterface.

inbound-pstn-call-problem-h323-gateways-2016-05-28 19_45_23

inbound-pstn-call-problem-h323-gateways-2016-05-28 19_46_32

I deleted the gateway on UCM and created a new one, with IP address of 156.100.26.2.

inbound-pstn-call-problem-h323-gateways-2016-05-28 19_48_11

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.

inbound-pstn-call-problem-h323-gateways-2016-05-28 19_59_01
Then I tried once again to call from PSTN into the branch 1 phone, and now it rings.

inbound-pstn-call-problem-h323-gateways-2016-05-28 20_00_42

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:

inbound-pstn-call-problem-h323-gateways-2016-06-02 19_37_56

And I removed the gateway and recreated one with the IP address 12.1.65.254.

inbound-pstn-call-problem-h323-gateways-2016-06-02 19_39_43

After a shut/no shut, the gateway registers, and I’m able to receive inbound PSTN calls into Branch1.

Leave a Comment