VSX7000 NO Video During Call

[Anonymous]

We have a VSX7000 that is at end of life and need help from the forum. We used to connect through ISDN and now we want to connect through IP address only. We have performed a master reset. Yet, when we connect to Polycom for a video test, the image on the screen does not appear. The local picture of ourselves shows up and can be seen on the other end. But, we are left starring a black screen. After working with 3 technical support specialists, we have not solved the problem. Not sure if we need to check or change Firewall settings or configuration, etc. Currently, it is obtaining an auto IP address that is valid and works. We can ping from computers and it can ping under the diagnostic tests to various other IP addresses. We tried connecting to our other Polycom which is a HDX 7000 HD and the call does not even get through. Any help would be greatly appreciated and I can add any details needed.

Thanks for the help!

[Anonymous]

sounds like a firewall issue where the firewall is allowing traffic out but not back in. Also NAT may need to be properly configured. See the Polycom VSX Admin Guide for info on configurining for firewall. 

http://support.polycom.com/PolycomService/support/us/support/video/vsx_series/vsx7000.html

[Anonymous]

Yes, I believe that it is as well. I went through with a tech support agent. We tried having fixed ports enabled for TCP and UDP with the H.323 disabled. We then tried with the fixed ports disabled for TCP and UDP with the H.323 enabled. Then we tried with both enabled. And also both disabled. All of them had the same results. Is tehre anything else that can be looked at?

Thanks for your help!

[Anonymous]

what is your firewall? some are more tricky to setup than others, as firewalls generally don't understand H.323 traffic.

When you say you enabled and disabled H.323 - what do you mean?

If you want to dial to the outside world, you need a 1:1 NAT

Open the appropriate TCP And UDP ports, ensuring TCP 1720 (call setup) is open both ways

Make sure you are forwarding ports to the internal address from the external address

[Anonymous]

We have a Cisco ASA firewall. And by 'enable' and 'disable' I am referring to the check boxes associated with the Firewall options under admin settings -> network -> firewall. The box on the top is for the "Fixed Ports" check box and the one on the bottom refers to "Enable H.323" (im not 100% positive this is the exact wording) check box below the "NAT Confiuration" box. The "NAT Confiuration" is set to "Auto" as well.

[Anonymous]

To clarify...

Admin -> Network -> IP -> Firewall

Fixed Ports                                    (enable/disable)

NAT Configuration                       (Auto/OFF/Manual/UPnp)

Nat is H.323 Compatible           (enable/disable)

Those are the main changes that can be made

[Anonymous]

You mention the config of the pix firewall.

But The VSX also has some settings for firewall traversal.

check "admin settings" => "network" => "ip network"

in the bottom you will find

- fixed ports

- firewall traversal

- nat config.

start with "fixed ports" enabled and "nat config" enabled

[Anonymous]

@pieterh

thank you for the assistance, however it did not work

[Anonymous]

@kendo

I reviewed the documentation provided and attempted the suggestions but it is still not working properly

[Anonymous]

still sounds like a NAT issue.

Here’s how I explain the function:

If the NAT is 323 compatible is checked, the unit is putting the ‘real’ IP address at both layer 3 and layer 7 of the packet.

If it is unchecked, the unit puts the ‘real’ IP address in L3 and the WAN IP in L7 of the packet.

NAT is compatible is extremely close, in real-world function, to having no NAT settings at all. When it is checked, the unit is depending on the firewall to intercept the packets & do the L3 NAT (change internal IP to external IP/vice-versa), as well as open the payload of the packet, determine if there is anything ‘to do’ (such as determine if it is an H245 packet and alter the IP address/port numbers contained therein) & do whatever is necessary.

When not checked, the codec has the simple thought process of: “the firewall here is dumb, so I have to put the WAN IP in the payload part so this call will work”

The layer 3 part of the packet, regardless of the NAT settings, is the same as it would not work otherwise.