Suspected H323 Issues - Help!

[mattipler]

Hey guys,

I've very little in the way of networking telephony experience and zero exposure to (and little understanding of) H323. I believe I may have a H323 issue that is causing problems with the function of softphones connected to a particular VPN client when attempting to make "external calls". Let me try my best to explain what is happening. 

We have 3 softphone users... user A, user B and user C. In order to make an external / public telephony call, each users calls must traverse as follows...

USER A (CONNECTED TO CLIENT VPN PROFILE A)

VPN HEADEND FIREWALL ZULU > FIREWALL ALPHA > FIREWALL CHARLIE > TELEPHONY INSTRUCTURE

USER B (CONNECTED TO CLIENT VPN PROFILE B)

VPN HEADEND FIREWALL ZULU > FIREWALL ALPHA > FIREWALL BRAVO > FIREWALL CHARLIE > TELEPHONY INSTRUCTURE

USER C (LAN CONNECTED)

FIREWALL ECHO > FIREWALL BRAVO > FIREWALL CHARLIE > TELEPHONY INSTRUCTURE

When users A and C make external calls they function perfectly. Logging upon last hop FIREWALL CHARLIE shows that when users A and C make external calls, a H323 UDP back-connection is allocated over dynamic UDP 39601 between the users system and the telephony infrastructure. Then, when the external call is then answered a connection over the H323 dynamic UDP 39601 port is established between the users system and the telephony infrastructure and the call functions correctly!

However, when user B makes external calls the calls establish but no voice can be heard at either end. Logging upon FIREWALL CHARLIE shows that the behaviour is the same as users A and C when they make external calls up until the point the call is answered. As with A and C, a H323 UDP back-connection is allocated over dynamic UDP 35213 between the user B's system and the telephony infrastructure, BUT when the call is answered we do not see the H323 UDP back-connection establish over the pre-allocated dynamic UDP 35213 port as we do for users A and C, nor can the callers be heard in either direction.

For some reason the H323 UDP back-connection between user B > Telephony Infrastructure does not establish and I suspect this is why we can hear no voice between calling parties. Firewalls ZULU, ALPHA and BRAVO all appear to have H323 inspection enabled in the global policies.

Unfortunately, I’ve had no previous exposure or dealings with H323 and I’m a little tapped-out with this issue. Does anybody have any hands-on experience with H323 and / or might be able to provide some insight as to what the issue might be here?

Any assistance greatly appreciated.

Matt

[Adam Pawlowski · Accepted solution]

I can try and reply generically, I guess, as I'm not an H323 pro either but this is not necessarily a problem specific to it. I'm not sure why H.323 is being used here but let's pretend it is legacy VTC clients or something.

There's some basic information out there on the call flow and signaling that could be taking place such as:

https://www.cisco.com/c/en/us/support/docs/voice/h323/5244-understand-gatekeepers.html

There could be an interaction between the ALG/Inspection/Helper/whatever and the way that media traffic is being pinholed through one firewall or another.

I would take the approach, if this happened to me, of collecting a packet capture at both ends if possible, during call setup. Figure out which message during the flow is saying "Here is where I am, and here is how we're going to communicate, on these ports". If there's a helper somewhere that is doing pinhole roles or traffic re-writing, perhaps it is either re-writing it incorrectly and putting in the wrong ports, or it is not recognizing the message format and is not allowing return traffic.

Once you can see what both sides of the transaction want to do with each other, you can try and track down on the network end of it the part that is not cooperating. This could be as simple as having user B on a subnet that the telephony gateway doesn't know how to reach, and thus a routing issue, more so than an ALG issue.

Just figure I'd share that approach not having a better answer.

[mattipler]

Hey Adam,

I ran captures upon all firewalls before creating the post. I then ran them again afterwards and i'm a little embarrassed to say that a L4 / access issue upon the Alpha firewall turned out to be the issue. Don't know how I missed this first time around. 

Thank you very much for taking the time to read my post (as vague as it was) and for taking the time to respond. 

Matt