The Call Simulator can be found by going to the Tools Tab and then by clicking on the VoIP Tools Sub Tab.
It is a program that is run on a computer where you would like to test a VoIP call. An End-to-End test will send VoIP formatted ICMP ping packets to any IP address endpoint.
This permits you to simulate a VoIP phone call to any remote IP address without having to set up software on the remote IP endpoint.
When the Call Simulator is initially run on a computer, it will ask for the IP address and port number for the PathSolutions’ TotalView server. This is done for licensing as well as to seed the program with the server and port for performing call path mappings:
Enter the IP Server Address (where PathSolutions is installed) and the Port.
Server address: xxx.xxx.xxx.xxx
Server port: 8084
Once a validation check is complete, you should see the program ready to start:
End-to-End Testing You should be able to enter the IP address of the remote device or location that you desire to test to and choose the codec to simulate. Click “Start” to start the simulation. This will perform an end-to-end test to the remote location.
Note: If you choose an IP phone as the destination, you should simulate only one call at a time to that location. IP phones tend to have very small CPUs and cannot handle more than 2 calls worth of traffic before they start to discard packets.
Any remote location that responds to a PING (ICMP ECHO) can be used as a destination for testing. You can choose to optionally tag the packets with a DSCP setting.
Note: Your network configuration may strip this DSCP tagging and apply a different tag to the packets. You may choose to deploy a packet analyzer to validate that the network configuration is not stripping the DSCP tagging.
Note: If you intend to load a network to saturation to test for WAN stability, it is advised to use the IP address of a router, switch, or server as the destination. Those devices tend to have enough spare CPU cycles to handle processing large loads of traffic.
Note: Some devices will strip the DSCP tagging on their responses. Cisco routers have been validated to reserve DSCP tagging on their responses. Other devices may have to be checked to see if they preserve or strip the tagging to insure that the DSCP is preserved bi-directionally.
During a call test, the number of calls can be ramped up to load the network and determine how many calls can reliably be handled to a destination.
Additional details about any point in time can be seen by hovering the mouse over the graph element.
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.
Note: If the graphs do not show up you will need to check your Firewall. You may need to turn off your Firewall for Link Troubleshooting.
Path results are displayed:
Latency, Jitter, and loss are displayed to each hop along the way. As a result, it can be easily determined which device is adding latency, jitter, or loss along the way.
The RTP mode uses UDP packets and is useful when remote devices block PING (ICMP ECHO) packets. To use the RTP Mode, email the link to the 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.