IP call: my VS4000 can be called but cannot call

Occasional Visitor

IP call: my VS4000 can be called but cannot call

I can call my VS4000 from a scopia desktop application.


When I try to call an IP address, I get the message that could not connect ISDN!!!


Checked the setting... preference are ISDN first and IP call second. no gatekeeper set.

Firewall setting :- open port TCP 3230-3235 and UDP 4000-4023 that have been fixed in VS4000.


Is there something else I need to do to allow IP call from my VS4000?



Message 1 of 2
Polycom Employee

Re: IP call: my VS4000 can be called but cannot call

The first question is has this ever worked over IP?

If not then the system is trying IP then ISDN as a last resort.


Is there a firewall between the VS and scopia? If yes then the firewall needs to be properly configured?

Another thought - is there a firewall on the desktop PC - or laptop?


Looking at IP settings you mention ports but I need to ask if port 1720 is opened bidirectionally for the duration of the call with no timers. 1720 is call setup and without it a call cannot be placed

- The next part is the NAT


Here’s how I explain the function:


If the NAT is 323 compatible is checked, the unit is putting the ‘real’ (internal) 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.




Sr. Product Support Technician
Message 2 of 2