If you do an “end-to-end” call simulation to a remote IP address, it is sending ICMP ECHO packets (ping packets) to the end destination. The end destination will then send packets back to the client so the latency, jitter, and loss can be measured.

There are two different methods that end destination systems (routers, switches, firewalls, desktops, servers, and IP phones) can reply to an ICMP ECHO (ping) packet:

  1. Take the inbound packet as-is and swap the transmit and receive IP address and re-queue the packet to be sent back.
  2. Destroy the inbound packet and create a brand-new packet to be sent back to the sender.

As far as efficiency goes, method #1 is far more efficient, as no memory allocation or de-allocation has to be performed, and it takes less CPU attention to perform. Method #1 also has the benefit of having all of the IP flags preserved, thus the QoS tag is maintained and is included in the returned packet.

Method #2 does not preserve the QoS tag since a brand-new return packet is built from scratch, and the QoS tag is typically not copied from the source packet to the destination packet.

What this means is that SOME devices may preserve the QoS tag, whereas other devices may not preserve it. The device you are bouncing the call off of may or may not preserve it.

If you test to a particular device and the warning sign does not show up, then you can be assured that the remote device does preserve and return the QoS tag (and it is not being stripped along the way).

If you test to a device and the warning sign shows up, then the QoS tag may not be returned by the end device, or it may be stripped along the way (uncertain of which).

In this case, it may be best to set up a Call Simulator agent in the remote location (email the call simulator located in the “Tools Tab”) on a computer and run it in “RTP Receive” mode and run the local computer in “RTP Transmit” mode and enter the remote computer’s IP address. That will guarantee that the remote end is tagging the packets and you can validate that QoS is making it through successfully.

The other option is to set up a sniffer in front of the remote device to see if the QoS is coming into the remote device, and the QoS that is being sent out is also enabled. That will validate that the remote device is receiving and returning the QoS tag successfully, and it is being stripped somewhere on the return path.

Note: If a Cisco layer-2 switch is involved in the communications path, and is NOT configured for "trust dscp" on the ports where traffic passes, the DSCP tag may also be stripped when passing through this layer-2 device.