Using the BCS behind a proxy
The BCS is a client side utility that requires access to the Internet to successfully complete a connection test.
When a proxy is deployed on the client side computer it can interfere with some of the BCS protocols, which may require some exceptions or setting changes.
Below are some specific areas that may need looking into in order to successfully run a test.
Local WebSocket Connection
The BCS binds to the localhost IP address of 127.0.0.1 and listens on ports 32658 (used for HTTP tests) and 32660 (used for HTTPS tests).
When the test page loads the first action is to establish a connection over a WebSocket to the BCS.
When the test is running over HTTP the test will first try to connect on ws://bcs.visualware.com:32658, before then trying ws://127.0.0.1:32658.
As HTTPS uses a secure certificate, which is bound to a domain name, it will only try to connect on wss://bcs.visualware.com:32660. This is important because DNS is needed to resolve bcs.visualware.com to 127.0.0.1.
It's important to note that the BCS > Test connection takes place in the local machine, so localhost must not be routed through a proxy and DNS access will be necessary for HTTPS testing.
Basic diagram depicting the initial BCS connection protocol.
Resource Requests
Once the BCS has established a connection with the test over localhost it makes numerous resource requests to the testing server.
This communication does go out over the Internet.
The test IP/URL used for these requests may NOT be the URL the test is running on, as tests can be hosted anywhere. If you need this information please contact your test provider.
Resources include information such as licensing and test specifications.
Basic diagram depicting the BCS resource request protocol.
Running the Test
The tests themselves will not utilize the proxy as they require a variety of ports to be open.
For example, by default, the Voice over IP test uses UDP ports 20000 and 20001 for testing. If those ports are closed in the local test environment the test will fail.
Troubleshooting the point of failure
Knowing where the failure is occurring can sometimes by tricky.
WebSocket
If the failure is occurring during the initial connection phase then a web socket error should show in the browser console log, like the image below:
Resource error
If there was an error getting resources then a message should appear on the test interface detailing which resouce failed. The messages can vary but if this occurs it's likely the proxy is not allowing the request to complete.
Test error
If the test looks like it's running but the results are appearing as blank or red then it could be due to one of the test ports being closed. If this happens contact the test provider for the required ports.