Do NOT follow the document https://live.paloaltonetworks.com/docs/DOC-3194 (H323 Polycom Video Conf Drops), as if you notice, that document references Port 5060 (SIP), but SIP is certainly NOT H.323 traffic. (2 totally diff protocols).
I worked at Polycom for 4 years, so this is a common problem that needs to be resolved by the Firewall, checking ports, etc. The H225 call setup is probably working, but the negotiation of what TCP/UDP ports is not being allowed by the firewall. I have seen this many many times. Many times. :smileysilly:
Your best friend in troubleshooting this will be to use Wireshark traces to see what is and is not going in your network.
Please confirm what settings you have enabled on your codec from the WebUI:
Fixed Ports: (what if anything do you have here)
Enable H.460 (on or off)
NAT configuration (what is this setting) <---- Very important, and could be the reason why the call fails.
First thing I would do, is to create a rule allowing ONLY the specific IP address from the source network, inbound to your network, with ANY application, ANY service. Put this rule at the top of your rulebase. (Please confirm this for me)
We do this, just to see if the H225 call setup and negotiation work correctly. If the call sets up and works correctly, then you know we have some firewall rules and dynamic NAT policies in the FW that are not working.
What I would definitely do, is to contact Palo Alto T2 support, and get the ticket opened with them. I would then (with Palo T2 on the phone), called into Polycom T2 support (they have codecs on the public internet with no firewalls between them. Best test scenario).
Have Polycom call into your FW, and let PA T2 support look at your logs and see what is going on.
I will be glad to assist you, just send me a PM and I can work with you on this.
I think you need to get a wireshark trace ready to see what is happening when inbound traffic from the Internet is processed by the FW.
I would go back to original suggestion. Contact Palo Alto T2 support, get a ticket opened, and then get on a conference call with Polycom T2 support and when Polycom attempts to call you, the Palo Alto techs can perform the associated traces.
To answer your question, YES, I think this definitely a PA issue, and they need to do the troubleshooting.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!