Communication Test Script

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 go to global settings open the tools tab under communication test script , click download 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 public ip detection 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 — only runs if all cybergate sip tests fail audio/video connections — rtp media streams on udp 30000 – udp 30190 mtu size — only runs when the audio/video test succeeds each individual check is printed as a line ending with either a green check ( \passed\ ) or a red cross ( \failed\ ) 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 public wan ip address xxx xxx xxx xxx this is the public wan ip address your device uses to connect to cybergate make sure you've configured this ip address in the cybergate management portal under network add wan ip address or range (see cybergate network requirements ) 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 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 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 testing udp/tcp connection to public sip server this block only appears in the script output when all cybergate sip tests fail (udp, tcp and tls) it tests connectivity to a public sip server (iptel org) to determine whether the problem is specific to cybergate or whether sip traffic is blocked altogether udp options response received failed (public sip server) sip traffic over udp can't reach a public sip server conclusion outgoing sip traffic is blocked at the firewall in general, not only towards cybergate verify the sip related firewall rules on your network tcp connection / tcp options response received failed (public sip server) sip traffic over tcp can't reach a public sip server conclusion outgoing sip traffic is blocked at the firewall in general, not only towards cybergate verify the sip related firewall rules on your network if the public sip server tests pass but the cybergate tests fail, the script will print could not connect to the cybergate service, but could connect to public sip server please verify that the wan ip addresses are configured in cybergate under network settings (see cybergate network requirements ) testing audio/video connections the script sends rtp packets to cybergate on udp ports 30000, 30010, 30020 … 30190 (steps of 10) 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 the wan ip address detected at the start of the script 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 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 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 under global settings in that case, udp and tcp being blocked is expected behavior verify the setting before troubleshooting further could not connect to the cybergate service, but could connect to public sip server sip traffic can leave the network, but does not reach cybergate verify that the wan ip addresses are configured in the cybergate management portal under network settings (see cybergate network requirements ) could not connect to any sip server sip traffic is blocked at the firewall verify your sip related firewall rules 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 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 under network add wan ip address or range for the full list of network requirements, see cybergate network requirements