This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Test Voip delay. Application time calculation

0

Hello, I have a network that run voip application between two different locations. Basically, several voip devices connected to the switch and then to the router network at one location. Same exactly setup is at the different location. (east coast /west coast) I can use ping to calculate network delay between any device. How do i calculate total delay? (network delay plus application delay) By application delay i mean buffer time, decode/encode time, software processing time. I am interested in calculating voice delay from time i speak to the microphone to the time i hear voice at the other end. I am not sure if this is possible using wireshark..If not, what kind of test sets that will do this? thank you alex

asked 02 Mar '15, 12:48

alexg1485's gravatar image

alexg1485
6112
accept rate: 0%


One Answer:

0

For that you'll need an audio test. Make an impulse at the mic, and time the arrival at the speaker. The trick is to have synchronized clocks at both ends.

answered 03 Mar '15, 07:42

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

This technique is common for the analog audio lines. Unfortunately, i am not familiar with any of the voip tests that will do this. Do you have a name of the audio test that you use?

(03 Mar '15, 12:29) alexg1485

Well, as you describe it, it is very much like testing analog audio lines. The mic and speaker are analog devices after all.

If you want to remain in the digital domain and stick to your requirements, you'll have to hook up at the ADC near the mic and the DAC at the speaker. Otherwise you'll miss the application delay. Not easy when you have no access to the internals of the devices.

You could break up the measurements in blocks, measure the delay from audio input to network output (encoding delayt), network input to audio output (decoding delay) and then the end-to-end network delay. The first two are tricky to get the correlation right, but it's all local. The end-to-end network delay can be derived from synchronized captures, or using the RTCP info (if present). All is left is the possible variable packet buffer in the receiving terminal. That will depend on (variations in) end-to-end network conditions.

(04 Mar '15, 05:36) Jaap ♦