CScan is a network readiness tool designed to pre-qualify a customer’s network for Calling services. Cisco customers can run this tool to test the network connection in order to ensure a high-quality experience for their Calling service.
Before you begin
Understanding the CScan Tool and its requirements is key to running it successfully. Please note the following requirements:
- A correctly configured firewall is essential for a successful calling deployment. Outbound ports are required to be open for signaling, media and network connectivity. Consult the Port Reference Information for Cisco Calling Service to ensure that all required firewall rules are in place when running CScan.
- Run your CScan test from the same network that you will use your Calling services.
- It is not possible to test every requirement from a web-based tool. Please note the below items which CScan cannot detect.
- Whether user is using a wired or wireless network
- Availability of a DHCP and DNS server
- SRV support
- NTP port for date/time synchronization
Launching and Running a CScan Test
- Log in to https://cscan.webex.com/carrier
- Select Location and your Home region
- Select Language, then click Pick Server
- Choose the type of test you’d like to run between
- Advanced Diagnostic test
- Basic test
- Select the option box (by checking or unchecking) if you would like to share your public IP address information with your provider, then click Start Test.
- Click Continue to Advanced Test.
Note: Choose a location closest to you. This would be the data center that your Calling service connects to. If you are unsure which selection to choose, leave it as the default selection.
Note: More detailed information about the advanced diagnostic test is available in the “CScan report information” section.
Note: When running the Advanced Diagnostic test, CScan must open a WebRTC connection to your computer, which requires access to your computer’s camera and microphone. This permission is used for measuring packet loss and jitter. Audio and video portions are not stored or shared. CScan will never access your camera or microphone outside of running a test and permissions can be revoked at any time.
CScan Report Information
CScan runs a series of Basic & Advanced tests on port & bandwidth requirements to ensure a customer’s network is ready to deploy Calling services.
The Basic test analyzes the following between your computer and the Calling services data center:
- Concurrent calls estimate
- Download and upload bandwidth
- Latency (RTT)
- Traceroute reports
- TCP ports
- TCP ports required for Calling service
Advanced Diagnostic Test
The Advanced Diagnostic test collects the same information as the Basic test but adds the following:
- Packet loss (download and upload)
- Jitter (download and upload)
Note: If access is not granted for either of the camera or microphone, it falls back and runs only the “Basic Test”. This permission is required for an “Advanced Diagnostics Test” for measuring packet loss and jitter.
CScan doesn’t test a wider UDP port range using WebRTC because of browser limitations, it picks a random port range between 19560-65535 and then runs the test.
Reverse Traceroute Report
A traceroute report is provided any time you run a CScan test. To generate this report CScan initiates a reverse traceroute from a Calling service data center to the public IP address of your computer.
This can provide insight to where issues might be occurring along the path between the Calling service data center to the client’s computer.
Note: The reason for using the reverse traceroute option is that we can’t initiate a ‘normal’ traceroute from the client browser to the calling service DC.
Reverse traceroute reports can take a while to generate and the link is greyed out until the report finishes generating.
Interpret Test Results
- The CScan tool estimates potential concurrent calls that could traverse your network. This is a conservative estimate based on the bandwidth that is required for audio calls, allowing for a buffer of extra internet traffic. Since the CScan test is taken at a single point in time, this is an estimate and not a guarantee of performance during peak traffic times.
- Call concurrency is calculated assuming 50% overhead of other traffic on the customer network and by assuming all audio calls require two legs of approximately 100kbps for each leg.
- If the CScan report indicates that ports are blocked, check your firewall configuration and refer to Port Reference Information for Cisco Calling Service. If ports are blocked, you may have issues registering devices or making calls. It’s not possible to test all ports listed in the Port Requirements document, so if all ports on CScan are listed as open, there may still be other ports not possible to test that could be causing issues.
- If latency or bandwidth figures are low, you may have a lower quality Calling Service experience. Ensure you have enough bandwidth from your ISP, and that your device has a strong connection to the internet. If you’re using Wi-Fi, ensure that your signal is strong.
- CScan test results can be viewed in two different ways
- Downloadable in PDF formats. Once the test execution is complete click on the “Download this report” and “Download traceroute report” links.
- For Partners/SPs, login to your SP Portal and at your left pane, under CScan tab, click on the “View requests”. More details are available at CScan SP guide
The figure below indicates that the CScan tool was unable to establish a UDP connection from the customer location to the Calling service. This may be due to a NAT/firewall blocking the UDP traffic for ports 5004,19560-65535
The figure below indicates that the CScan test failed to establish SIP over TCP connectivity to the Calling service. This may cause phone registration failures.
The figure below indicates that the CScan test identified high latency and outbound packet loss. This may be due to possible traffic congestion or bandwidth limitations at the customer location.
If your connection meets requirements, then you are ready to use your Calling service. Below is an example of what a successful test interpretation would look like.