08-22-2013 02:52 PM - edited 03-18-2019 01:40 AM
I have re-titled this thread as the conversation moved on from the inital idea of stopping Jabber to access to the Home VCS-E when on site, to actually need to access a VCS-E when at a remote site.
Hi all,
VSC-C and E : x7.2.2
Jabber Video: 4.6
This is an odd question as we have an odd problem. We have a sample deployment as shown in the diagram below:
This all works fine - assuming the roaming users Jabber client registers to the correct VCS. The problem comes when the remote users puts their laptop to sleep, brings it into work, connects it to the dock and wakes the machine up. It seem that the Jabber tries to connect before the Ethernet connection is fully active, therefore the connection to the local VCS-C for provisioning info fails. However, I believe the Ethernet connection then comes up as Jabber then attempts to contact the VCS-E (as it would do when offsite). This mean that the provisioning info fed to Jabber is that for an external connection so Jabber then registers quite happily to the VCS-E :
The problem comes then when attempting to make or receive a call - the Jabber client connects but the user doesn't receive any audio and video. I suspect that the problem lies in the institution firewall as the call is essentially routed to the client via the VCS-E and so the firewall is blocking the UDP traffic to the client.
If there was a way to slow down the Jabber client after a system "wake" (all is Ok from a boot), then this would resolve this problem.
However, after thinking about this - maybe the best way would be to block outbound access to the VCS-E on port 5060 and 5061 at the firewall?
Comments please?
Cheers Chris