The Call Simulator is a very powerful utility that makes use of advanced features of ICMP (Internet Control Message Protocol) to easily simulate calls across networks, without having to set up application specific tools or agents in multiple locations.
It can be downloaded from the Path Insight Tools Tab, VoIP Tools Sub Tab, and installed on any Windows computer from where you would like to test a VoIP call. The basic use case is to perform an End-to End test, which sends VoIP formatted ICMP packets to any device that can respond to a PING/ICMP ECHO. This permits a simulated VoIP phone call to a remote site, without having to set up software or even control hardware in the remote site.
Usage:
When the Call Simulator is initially run on a computer, it will ask for the IP address and port number for the IR Path Insight server. This is done for licensing, as well as to seed the program with the server and port for performing call path mappings. Once a validation check is performed, the Call Simulator is ready to run.
Test calls can be made, and an interactive graph generated in realtime. Additional details about any point in time can be seen by hovering the mouse over the graph element. But after a test is run, a complete report can be saved as well, with details for the entire test, as well as great high-level summaries.
If the graphs don’t populate, the most common issue is firewall settings. You may need to disable local firewalls, or get modifications/exemptions for ICMP echo to successfully use many features, but there are features that specifically use UDP packets that help test/validate for just these conditions
The number of calls that can be simulated as well as the number of call simulator instances running on the same computer is limited by the resources of the computer. An average admin laptop might be able to ~25 calls before running into hardware limitations, while a more powerful administrative desktop PC might handle ~50 calls simultaneously. Servers can often support many more simulated calls, potentially in the hundreds.
Finally, please note that these simulations are NOT designed (and won’t necessarily provide accurate results) when run from VMs. VM access to the network interface and other hardware is time-sliced in ways that can easily interfere with the call simulator. So the results are rarely the same as when running against physical hardware. In many cases, call simulations run from VMs show high latencies and jitter that are related to the VM environment, and the actual network behavior is completely different.
End-to-End Testing:
Enter an IP address of a remote device to with which to simulate a call, and choose a codec to simulate. Click “Start” to start the simulation. This will perform an end-to-end test to the remote device.
The remote device does NOT need to be an IP phone, SBC or network component. It can be any device or system that can be reached, and is capable of responding to ICMP echo messages.
If you DO use an IP phone as a destination, you should simulate only one call at a time. IP phones tend to have very small CPUs and generally can’t handle more than 2 calls worth of traffic before they start to discard packets.
DSCP tagging:
One of the options for simulated calls is to tag the packets with DSCP settings.
Your network configuration may strip this DSCP tagging and apply a different tag to the packets. You may need to deploy a packet analyzer to validate the exact places where network configuration is stripping DSCP tagging, but you can often get quite far with just the Call Simulator, in particular with running multiple instances, one with DSCP tagging set, and one with no DSCP set, with the codec “Bulk Data”. This will simulate an FTP transfer. During the testing, the QoS enabled simulation should not show any degradation when ramping up bulk data testing, but bulk data testing SHOULD show impacts when QoS volumes are raised high enough.
By changing the destination to various network elements along a call path, you can often identify which devices will strip the DSCP tagging on their responses. During a call test, the number of calls with DSCP tags set can be ramped up to load the network, while monitoring the behavior of a simulated call to the same destination, set WITHOUT DSCP tags. When packet loss starts to climb, that’s a great test to determine objectively network based Call Admission Control levels, and/or how many calls can reliably be handled to a destination.
If you DO load a network to saturation, for instance, to test WAN stability, it’s best practice to use a router, switch, SBC, or server as the destination, rather than an individual PC, Laptop, or IP phone. Those devices tend to have enough spare CPU cycles to process large volumes of traffic. But be sure to understand the normal workload on those systems, and monitor the impact via Prognosis as you ramp up testing, to ensure the impact is not unacceptable.
And of course, NEVER perform load tests across a network or to endpoints for which you don’t have authorization or responsibility.
Other advanced features:
Link Troubleshooting:
The Link Troubleshooting mode can be used to test packet stability over a number of router hops, and is typically used to test stability outside of a VPN tunnel to determine where packets are being lost or delayed.
Enter the IP address of the destination to test and click “Start.” The program will trace the route to the destination and then start testing:
If at any point there is a spike in latency, jitter, or loss, the graph point can be clicked on to view additional information of inter-link information between all involved devices along the path.
Path results are displayed with Latency, Jitter, and loss to each hop along the path. Specific devices can be identified contributing to latency, jitter, or loss along the way.
RTP Receiver/Transmitter:
RTP mode uses UDP packets and is particularly useful when remote devices block ICMP packets. Unlike the ICMP modes, this requires both endpoints to run the call simulator.
To use the RTP Mode, send a link to download the call simulator to a remote user, and have the remote user run a copy of the Call Simulator on the network. Set the remote computer up as RTC Receiver and click on Start.
On the local machine, run the RTP as Transmitter and enter the remote computer’s IP address.
Simulated traffic will then run between the two systems.
Ports and Protocols for Call Simulator scenarios:
License check: The call simulator executable will need to communicate with the Prognosis Path Insight service (via the default TCP port 8084) for license verification.
ICMP ping: The call simulator executable uses ICMP ping for most tests. ICMP needs to be enabled to and from end devices for testing purposes. This includes the devices themselves, and of course firewalls, routers, etc, need to allow for ICMP traffic between the call simulator installation and the target endpoints.
VoIP Simulation: The call simulator executable uses RTP ports (UDP 5060, 5061, and 16384 – 32767) to test between call simulator clients for RTP Mode tests.
