--- title: Communication Test Script slug: cybergate-communication-test-script docTags: createdAt: 2026-03-17T10:51:14.192Z --- # Failing tests in CyberGate Communication Test Script The CyberGate Communication Test Script is a helpful tool to diagnose the connection from the network of your device\* to CyberGate. It will test all relevant communication paths to CyberGate and provide output that will help you find the cause in case of failures. This document provides more info on each test of the Communication Test Script. *\*SIP intercom / IP pager / IP speaker / SIP camera* ## Downloading the script The Communication Test Script can be downloaded from the [CyberGate Management Portal](docId\:JR5OLBHYaZDoO08pJkbkw): 1. Go to **Global settings**. 2. Open the **Tools** tab. 3. Under **Communication test script**, click **Download**. ::Image[]{src="https://api.archbee.com/api/optimize/9udbSbjbe1Qxd-sSYHAdw/VvYM4p00McEZDLnVCHLu4-20260317-112243.jpg" size="20" width="654" height="817" position="center" darkWidth="654" darkHeight="817" showCaption="false"} After downloading, right-click the file and **unblock** the script before running it. Otherwise it will not be possible to run the script in PowerShell. Run the downloaded PowerShell script (`.ps1`) from a Windows PC on the same network as the device. ## How the script works The script runs from a Windows PC on the same network as the device and simulates the SIP and RTP traffic that the device would send to CyberGate. It performs the following groups of tests, in order: - **WAN connection** — DNS resolution and local network check - **UDP connection to CyberGate** — SIP signaling on UDP port 5060 - **TCP connection to CyberGate** — SIP signaling on TCP port 5060 - **TLS connection to CyberGate** — Secure SIP signaling on TCP port 5061 - **Public SIP server fallback** — runs per protocol (UDP, TCP or TLS) when CyberGate does not respond over that protocol - **Audio/Video connections** — RTP media streams on UDP 30000 – UDP 30190 - **MTU size** — only runs when the Audio/Video test succeeds Before the tests start, the script shows the Microsoft Tenant Id it was downloaded for and asks for the IP address of the device. Each individual check is printed as a line ending with either a green check (passed) or a red cross (failed). :::hint{type="info"} **One working protocol is enough.** The script tests SIP signaling over all three protocols (UDP, TCP and TLS) for completeness, but the device only needs **one** of them to work in order to connect to CyberGate. If, for example, UDP and TCP fail but TLS succeeds, the device can still register and place calls without any issues. ::: ## Testing WAN connection - CyberGate DNS resolve Failed: The configured DNS server can't resolve the cybergate.cybertwice.com address. This will prevent the device from connecting to CyberGate. Possible solution : Make sure the device is able to reach the DNS servers. - Local IP address xxx.xxx.xxx.xxx : Shows the IP address of your PC. - Local IP mask xxx.xxx.xxx.xxx : Shows the subnet mask of your PC. - Intercom in same subnet Failed: The PC you're using to run this test is not on the same network as the device. The outcome of this Communication Test Script won't be useful for diagnosing communication issues. ## Testing UDP connection... - **UDP OPTIONS **response received Failed: The UDP options message sent by the script is not replied by CyberGate. Possible reason : a Firewall rule blocks outgoing UDP traffic to the internet. Make sure UDP port 5060 (outbound) is opened from the device LAN IP to cybergate.cybertwice.com - **UDP OPTIONS** response SIP 200 OK Failed: The 200 OK message sent by CyberGate is not received (correctly). Possible reason : a Firewall rule blocks outgoing UDP traffic to the internet. Make sure UDP port 5060 (outbound) is opened from the device LAN IP to cybergate.cybertwice.com - **UDP INVITE **response received Failed: A SIP invite sent via UDP (test call) could not be established. Possible reason : a Firewall rule blocks outgoing UDP traffic to the internet. Make sure UDP port 5060 (outbound) is opened from the device LAN IP to cybergate.cybertwice.com - **UDP INVITE **request unmodified Failed: The invite sent by the device to CyberGate is modified by the Firewall. Possible reason : a Firewall SIP helper feature is active on the Firewall (such as SIP ALG). Disable all SIP helper features in the Firewall. - **UDP INVITE **response unmodified Failed: The invite response sent by CyberGate to the device is modified by the Firewall. Possible reason : a Firewall SIP helper feature is active on the Firewall (such as SIP ALG). Disable all SIP helper features in the Firewall. - **UDP WAN IP** xxx.xxx.xxx.xxx : This is the public WAN IP address your device uses to connect to CyberGate over UDP. Make sure you've configured this IP address in the [CyberGate Management Portal](docId\:JR5OLBHYaZDoO08pJkbkw) under Network - Add WAN IP Address or Range (see [CyberGate Network Requirements](docId\:CD1t-cWMPwaNfn25aq5eX)). - **UDP WAN IP not received** Failed: CyberGate answered the invite, but the response did not contain the public WAN IP address. ## Testing TCP connection... - **TCP** connection Failed: TCP connection could not be set up. Possible reason : a Firewall rule blocks outgoing TCP traffic to the internet. Make sure TCP port 5060 (outbound) is opened from the device LAN IP to cybergate.cybertwice.com - **TCP OPTIONS **response received Failed: The TCP options message sent by the script is not replied by CyberGate. Possible reason : a Firewall rule blocks outgoing TCP traffic to the internet. Make sure TCP port 5060 (outbound) is opened from the device LAN IP to cybergate.cybertwice.com - **TCP OPTIONS **response SIP 200 OK Failed: The 200 OK message sent by CyberGate is not received (correctly). Possible reason : a Firewall rule blocks outgoing TCP traffic to the internet. Make sure TCP port 5060 (outbound) is opened from the device LAN IP to cybergate.cybertwice.com - **TCP INVITE **response received Failed: A SIP invite sent over TCP (test call) could not be established. Possible reason : a Firewall rule blocks outgoing TCP traffic to the internet. Make sure TCP port 5060 (outbound) is opened from the device LAN IP to cybergate.cybertwice.com - **TCP INVITE **request unmodified Failed: The invite sent by the device to CyberGate is modified by the Firewall. Possible reason : a Firewall SIP helper feature is active on the Firewall (such as SIP ALG). Disable all SIP helper features in the Firewall. - **TCP INVITE **response unmodified Failed: The invite response sent by CyberGate to the device is modified by the Firewall. Possible reason : a Firewall SIP helper feature is active on the Firewall (such as SIP ALG). Disable all SIP helper features in the Firewall. - **TCP WAN IP** xxx.xxx.xxx.xxx : This is the public WAN IP address your device uses to connect to CyberGate over TCP. Make sure you've configured this IP address in the [CyberGate Management Portal](docId\:JR5OLBHYaZDoO08pJkbkw) under Network - Add WAN IP Address or Range. - **TCP WAN IP not received** Failed: CyberGate answered the invite, but the response did not contain the public WAN IP address. ## Testing TLS connection... - **TLS **connection Failed: TLS connection could not be set up. Possible reason : a Firewall rule blocks outgoing TCP traffic to the internet. Make sure TCP port 5061 (outbound) is opened from the device LAN IP to cybergate.cybertwice.com - **TLS **authentication Failed: The TLS handshake completed, but TLS authentication (certificate validation) failed. Possible reason : a network device, firewall, or TLS-inspecting proxy is intercepting the secure connection and presenting its own certificate. Make sure end-to-end TLS traffic between the device and cybergate.cybertwice.com on port 5061 is not inspected or terminated by any intermediate device. - **TLS OPTIONS** response received Failed: The options message sent by the script over TLS is not replied by CyberGate. Possible reason : a Firewall rule blocks outgoing TCP traffic to the internet. Make sure TCP port 5061 (outbound) is opened from the device LAN IP to cybergate.cybertwice.com - **TLS OPTIONS** response SIP 200 OK Failed: The 200 OK message sent by CyberGate is not received (correctly). Possible reason : a Firewall rule blocks outgoing TCP traffic to the internet. Make sure TCP port 5061 (outbound) is opened from the device LAN IP to cybergate.cybertwice.com - **TLS INVITE** response received Failed: A SIP invite sent over TLS (test call) could not be established. Possible reason : a Firewall rule blocks outgoing TCP traffic to the internet. Make sure TCP port 5061 (outbound) is opened from the device LAN IP to cybergate.cybertwice.com - **TLS INVITE** request unmodified Failed: The invite sent by the device to CyberGate is modified by the Firewall. Possible reason : a Firewall SIP helper feature is active on the Firewall (such as SIP ALG). Disable all SIP helper features in the Firewall. - **TLS INVITE** response unmodified Failed: The invite response sent by CyberGate to the device is modified by the Firewall. Possible reason : a Firewall SIP helper feature is active on the Firewall (such as SIP ALG). Disable all SIP helper features in the Firewall. - **TLS WAN IP** xxx.xxx.xxx.xxx : This is the public WAN IP address your device uses to connect to CyberGate over TLS. Make sure you've configured this IP address in the [CyberGate Management Portal](docId\:JR5OLBHYaZDoO08pJkbkw) under Network - Add WAN IP Address or Range. - **TLS WAN IP not received** Failed: CyberGate answered the invite, but the response did not contain the public WAN IP address. ## Testing UDP/TCP/TLS connection to public SIP server :::hint{type="info"} This block only appears in the script output when CyberGate does not respond over a protocol. For each protocol that fails (UDP, TCP or TLS), the script prints *CyberGate did not respond over \ - trying the public SIP server as a fallback...* and repeats the test against the CyberTwice public SIP server (siptest.cybergate.cybertwice.com). This shows whether the problem is specific to CyberGate or whether SIP traffic over that protocol is blocked altogether. ::: - **UDP OPTIONS** response received Failed (public SIP server): SIP traffic over UDP can't reach the public SIP server. Conclusion : outgoing SIP traffic over UDP is blocked at the Firewall in general, not only towards CyberGate. Make sure UDP port 5060 (outbound) is opened from the device LAN IP. - **TCP **connection / TCP OPTIONS response received Failed (public SIP server): SIP traffic over TCP can't reach the public SIP server. Conclusion : outgoing SIP traffic over TCP is blocked at the Firewall in general, not only towards CyberGate. Make sure TCP port 5060 (outbound) is opened from the device LAN IP. - **TLS **connection / TLS OPTIONS response received Failed (public SIP server): SIP traffic over TLS can't reach the public SIP server. Conclusion : outgoing SIP traffic over TLS is blocked at the Firewall in general, not only towards CyberGate. Make sure TCP port 5061 (outbound) is opened from the device LAN IP. - **UDP / TCP / TLS WAN IP** xxx.xxx.xxx.xxx : When the public SIP server answers, the script shows the public WAN IP address the request came from. Make sure this IP address is configured in the [CyberGate Management Portal](docId\:JR5OLBHYaZDoO08pJkbkw) under Network - Add WAN IP Address or Range. - **UDP / TCP / TLS WAN IP not received** Failed: The public SIP server answered, but the response did not contain the public WAN IP address. ## Multiple WAN IP addresses - **Warning: multiple different WAN IP addresses were observed: xxx.xxx.xxx.xxx, yyy.yyy.yyy.yyy** : The UDP, TCP and TLS tests reached the internet via different public IP addresses. This typically happens on networks with multiple WAN connections or load balancing between internet connections. Possible solution : make sure all listed WAN IP addresses are configured in the [CyberGate Management Portal](docId\:JR5OLBHYaZDoO08pJkbkw) under Network - Add WAN IP Address or Range, or configure your network so that all traffic to CyberGate egresses via the same WAN interface. :::hint{type="warning"} If the public SIP server answers but CyberGate does not, the script will print: *Could not connect to CyberGate directly, but reached it via the public SIP server fallback over \. Please verify the WAN IP addresses in CyberGate under Network settings to enable a direct connection* (see [CyberGate Network Requirements](docId\:CD1t-cWMPwaNfn25aq5eX)). ::: ## Testing Audio/Video connections.............................. The script sends RTP packets to both CyberGate media instances, spread over the RTP port range, to verify that media traffic can leave the network. - Audio/Video connections Failed: Audio / video can't be transmitted to CyberGate. Possible reason : the IP ports necessary for the audio and video streams between the device and CyberGate are not opened on the Firewall. Make sure the following outbound ports are open : UDP 30000 – UDP 30199 - Public WAN IP address (by RTP Echo) xxx.xxx.xxx.xxx Failed: The public WAN IP address detected via the RTP echo response does not match any of the WAN IP addresses detected during the UDP, TCP and TLS tests. Possible reason : RTP traffic is leaving the network via a different public IP address than SIP signaling traffic. This typically happens on networks with multiple WAN connections or asymmetric routing, and can prevent media from being correlated to the SIP session in CyberGate. Possible solution : make sure both detected WAN IP addresses are configured in the [CyberGate Management Portal](docId\:JR5OLBHYaZDoO08pJkbkw) under Network - Add WAN IP Address or Range, or configure your network so that SIP and RTP traffic to CyberGate always egress via the same WAN interface. *** ## Testing MTU size :::hint{type="info"} This test only runs when the Audio/Video connections test succeeded. It sends RTP packets of increasing size (1300 → 1500 bytes) to determine the largest packet that traverses the network without fragmentation. ::: The script reports the result in one of three ways: - **Green check (**passed**)** — MTU size 1490 or higher. The full standard MTU (or close enough to it) is supported end-to-end. - **Yellow warning** — MTU size between 1400 and 1489. Lower than ideal, but in most cases acceptable for audio. May still cause issues with video. - **Red cross (**failed**)** — MTU size below 1400. Likely to cause call quality problems. ### Why this matters The **CyberGate service load balancers do not accept fragmented IP packets**. Any RTP packet that gets fragmented somewhere on the path to CyberGate will be dropped at the load balancer instead of being reassembled and forwarded to the service. Fragmentation happens when a packet is larger than the smallest MTU on the path between the device and CyberGate. A reduced MTU is common on links such as MPLS, VPN, GRE or PPPoE connections. When the intercom sends an audio or video frame that exceeds this MTU, the network fragments the packet and CyberGate then discards it. The result is dropped media, even when all the connectivity tests pass: choppy audio, video glitches, missing frames, or no video at all. Video traffic is especially sensitive to this because **video key frames are much larger than audio packets** and are far more likely to be fragmented. On networks with a reduced MTU, audio may still work reasonably well while video stutters, freezes or doesn't come through at all. ### Possible solutions The goal is to prevent fragmentation from occurring on the path to CyberGate. This can be done by either making sure the full path supports a standard 1500-byte MTU, or by making sure the intercom never sends packets larger than the lowest MTU on the path. - **Verify the MTU configuration** on each network device in the path between the device and the internet. Where possible, ensure the full path supports the standard 1500-byte MTU so that no fragmentation is needed in the first place. - **Disable codecs in the intercom** if SIP is using UDP. Reducing the number of enabled codecs (especially the larger ones) can lower the SIP packet size and avoid fragmentation on the SIP signaling traffic. This only applies to SIP over UDP — for TCP and TLS, fragmentation is handled by the transport layer. - **Configure a maximum MTU size in the intercom**, if the device supports this. Setting the intercom's MTU equal to (or just below) the lowest MTU in the network path prevents the device from sending packets that would get fragmented and dropped by CyberGate. Intercoms that support this are 2N, Robin and Commend. ## Final result and summary messages After all tests, the script prints one of the following final messages: - **All connectivity tests have passed!** No further action needed — the network is correctly configured for CyberGate. - **Note: Could not connect on UDP and TCP, but only on TLS.** This might indicate that the *Secure only* feature has been enabled in the [CyberGate Management Portal](docId\:JR5OLBHYaZDoO08pJkbkw) under Global settings. In that case, UDP and TCP being blocked is expected behavior. Verify the setting before troubleshooting further. - **Could not connect to CyberGate directly, but reached it via the public SIP server fallback over \.** SIP traffic can leave the network over the listed protocols, but does not reach CyberGate directly. Verify that the WAN IP addresses are configured in the [CyberGate Management Portal](docId\:JR5OLBHYaZDoO08pJkbkw) under Network settings (see [CyberGate Network Requirements](docId\:CD1t-cWMPwaNfn25aq5eX)). - **Could not connect to the CyberGate service, and could not connect to the public SIP server over UDP, TCP or TLS.** SIP traffic is blocked at the Firewall. Verify your SIP-related firewall rules, and verify that the WAN IP addresses are configured in the [CyberGate Management Portal](docId\:JR5OLBHYaZDoO08pJkbkw) under Network settings. - **Total performed retries: n** — If the script had to retry one or more SIP messages before getting a response, the total number of retries is shown. A non-zero value indicates packet loss or latency on the network path — even when the tests eventually pass, this is worth investigating for stable call quality. ## Required firewall rules — summary For reference, these are the outbound firewall rules required from the device LAN IP to cybergate.cybertwice.com: | Protocol | Port(s) | Purpose | | -------- | ------------- | ----------------------- | | UDP | 5060 | SIP signaling (UDP) | | TCP | 5060 | SIP signaling (TCP) | | TCP | 5061 | SIP signaling over TLS | | UDP | 30000 – 30199 | RTP audio/video streams | :::hint{type="warning"} In addition to opening the ports above: - Disable SIP ALG and all other SIP helper features on the Firewall. - Do not apply TLS inspection to traffic destined for cybergate.cybertwice.com on port 5061. - Configure the public WAN IP address(es) of the device's network in the [CyberGate Management Portal](docId\:JR5OLBHYaZDoO08pJkbkw) under Network - Add WAN IP Address or Range. For the full list of network requirements, see [CyberGate Network Requirements](docId\:CD1t-cWMPwaNfn25aq5eX). ::: ## Sharing the test result When you run the script as part of a support request, copy the full output of the Communication Test Script and send it back to CyberTwice support (paste the result into your support ticket). This allows us to diagnose the cause in case of failures.