Blocked ports are one of the most common and hardest-to-diagnose causes of application failure. MCS tests whether the specific TCP and UDP ports your applications need are open and responding across every firewall, NAT device, and network boundary in the path.
Every cloud application, VoIP system, and network service depends on specific ports being open for communication. These ports act as gateways for data to flow between the application and the rest of the network. When a firewall, NAT device, or ISP blocks one of these ports, the application breaks silently.
The user sees "connection failed" or "call dropped" or nothing at all. IT gets a vague ticket. Nobody suspects a blocked port because there's no error message that says "port 5060 is blocked by your firewall." You have to test for it.
MCS tests specific TCP and UDP ports between any combination of test points on your network. Not a generic scan, but a targeted check of the exact ports your applications need.
Verify that specific TCP ports are open and accepting connections across the full network path, including firewalls, NAT, and cloud security groups.
Test whether UDP ports are reachable. Critical for VoIP (RTP media), video conferencing, and capacity testing where UDP is the transport.
Define any port or range of ports in the test specification. Test the exact ports your application uses, not a generic set.
Test port availability in both directions. A port may be open outbound but blocked inbound, or vice versa. MCS tests both.
Test between any two MCS test points: headquarters to branch, data center to cloud, office to remote worker, or any combination.
Schedule port availability tests to run continuously from any satellite. Get alerted when a port that was open becomes blocked.
These are the ports most commonly tested by MCS customers. Each blocked port has a specific, often silent, impact on the application it serves.
| Application / Service | Ports | Protocol | If Blocked |
|---|---|---|---|
| Microsoft Teams | 3478-3481, 49152-65535 | UDP | Media falls back to TCP relay with degraded quality, or fails entirely |
| Zoom | 8801-8810 | UDP | Video and audio quality drops significantly, screen sharing may fail |
| RingCentral | 8000-8200, 19302-19309 | UDP | Voice calls and meetings fall back to TCP, causing latency and poor quality |
| Webex | 9000, 5004, 33434-33598 | UDP / TCP | Media streams fail, meetings may connect without audio or video |
| SIP Signaling (VoIP) | 5060, 5061 | TCP / UDP | Calls fail to register, connect, or tear down. No error visible to user |
| RTP Media (VoIP) | 10000-20000+ | UDP | One-way audio, no audio, or call drops mid-conversation |
| Five9 / Genesys Cloud | 8000-65535 (varies) | UDP | Agent calls drop, audio quality degrades, softphone fails to register |
| HTTPS / Web Services | 443 | TCP | Cloud applications, APIs, and dashboards become unreachable |
| STUN / TURN (NAT Traversal) | 3478, 5349 | UDP / TCP | WebRTC and media behind NAT cannot establish connections |
Port testing in MCS works differently depending on the protocol and where the endpoint is. Understanding the differences ensures you get accurate, meaningful results.
MCS can test TCP port availability against any remote host. For example, you can test whether port 443 is reachable on google.com, or whether port 5060 is open on your SIP trunk provider's server. TCP is connection-oriented, so if the port is open and the host is listening, MCS gets a definitive answer.
TCP port tests also run between MCS management servers and NCS satellite devices, making it easy to validate port access across your own infrastructure.
For UDP, the most straightforward approach is testing between MCS servers and NCS satellites. Both ends are under your control, so the satellite can confirm whether the UDP packet arrived and respond. This is the recommended method for VoIP port validation, capacity port checks, and general UDP reachability.
MCS does support testing UDP ports against remote endpoints that are not MCS or NCS technology. However, because UDP is connectionless (there is no handshake like TCP), the remote host has no built-in reason to respond. To make this work, you must configure a send packet string and an expected receive packet string in the test specification. The remote service must be set up to respond to that specific packet. This is common with services that have a known challenge-response pattern, but it requires specific configuration on both sides.
Deploy a customized self-service portal that lets end-users, customers, or remote workers test port availability from their browser using the BCS utility. Results feed directly to your MCS dashboard.
Deploy MCS satellites (hardware or software) at every location that matters. Schedule continuous automated port availability tests between any and all endpoints, 24/7.
Learn about automated testingVerify that SIP and RTP ports are open at every customer site before deployment. Prevent the "calls don't work" support calls that always turn out to be a blocked port.
Validate firewall rules across multi-site networks. Confirm that ports opened for a deployment remain open, and that ports that should be closed stay closed.
HIPAA, PCI-DSS, and GDPR require active monitoring of network port access. MCS provides the evidence trail that ports are controlled and monitored continuously.
Home routers and consumer ISPs block ports unpredictably. Test each remote worker's connection to confirm the ports their tools need are accessible.
