|
Resolution:
When trying to use vPoint to communicate over the public Internet, the most common connectivity issue relates to firewalls and network address translation (NAT). Many times these functions are combined in the same device, including commonly used broadband access devices (Linksys, DLink, Netgear, etc). The security aspects of these network devices create a list of connectivity challenges for real time communication applications like videoconferencing. For a more detailed explanation of the issues and challenges, see the Emblaze-VCON white paper titled "Traversing Firewalls and Proxies with Video over IP: Issues and Solutions."
For customers using the no-charge vPoint trial version for demonstration and evaluation purposes, the best network environment to use is the local area network (LAN) or some other network environment that does not have firewalls and NATs between the users that need to communicate. There are some features built into vPoint that can help serve as a partial workaround for the firewall/NAT connectivity issue, but it should not be considered a comprehensive solution. Users that have vPoint HD in a production environment and need a secure firewall/NAT traversal solution should consider Emblaze-VCON's SecureConnect family of products.
If basic firewall services are creating a problem, there is one possible workaround. The user behind the firewall should initiate the videoconference to the other user. When doing so, typically the firewall will allow return communication through the same ports that were used for the outbound communication. If video is only seen in one direction, then it's almost certain the firewall is blocking the return video streams (and usually audio too). If the remote user is also behind a firewall, then this solution will not typically work.
If the firewall device is also performing network address translation (NAT), the workaround solution is more complicated and doesn't work as often. With NAT, the IP address of the user is private, which means it is not a routable IP address. This makes the user "invisible" to the outside world. For security purposes, this is ideal. But for realtime communications, it is not. If the vPoint HD application passes its private IP address to the remote vPoint HD application, the return streams will not be routable by the network devices.
The possible workaround is to use vPoint's HD NAT IP Address Mask feature. vPoint HD has a setting on the Settings / Network / Advanced page for this. First, you must determine the real public IP address on the Internet side of the NAT server that is used for your PC. Entering this IP address into the "Enable NAT" field will instruct the vPoint application to pass this IP address to the remote videoconferencing endpoints. If you are using a broadband access device, it is possible that browsing into the administration page of the device will tell you the public IP it has been assigned. If you in a corporate or enterprise environment, you should speak to your network administrator.
The NAT IP Address Mask feature will not work well if the public IP address gets assigned dynamically with each communication session or if it changes on a regular basis for some other reason (some broadband carriers do this). It also does not solve the "invisibility" problem. In other words, the user behind the NAT would still need to initiate the call to the "public" user.
The other possible workaround for a NAT situation is to logically place the PC in the DMZ of the firewall/NAT. Doing so typically assigns the PC the public IP address on the Internet side of the firewall/NAT. If you are using a broadband access device, it is possible that browsing into the administration page of the device will show the settings for this. If you in a corporate or enterprise environment, you should speak to your network administrator.
As mentioned earlier, the suggestions in this note are mostly workarounds that can be tested to see if they resolve the connectivity issues presented by firewalls and NAT servers. A comprehensive solution is offered by Emblaze-VCON, called SecureConnect. SecureConnect may not be practical to include in an evaluation deployment, but certainly should be considered for any production deployment that needs firewall/NAT traversal.
| 
