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

How to identify RTP delay

0

Hello Forum,

Assume following workflow, Client1 made a SIP call -> (network) -> clien2

We have encountered a delay in hearing the voice in client2. I have captured the RTP packets from Client1 and Client2. However I am not able to find a way to identify the delay by compering the RTP packets. May be I do not know how to do it. Please help me, how can I identify the delay by studying the packets.

Regards Rajib Siemens India.

asked 06 Sep '13, 05:07

Rajib's gravatar image

Rajib
1●1●1●2
accept rate: 0%

What does (network) constitute of? A layer 2/3 network? WAN connections? VoIP gateways?

(06 Sep '13, 09:07) Jaap ♦

One Answer:

1

We have encountered a delay in hearing the voice in client2. I have captured the RTP packets from Client1 and Client2. However I am not able to find a way to identify the delay by compering the RTP packets.

This could be caused by the use of jitter buffers (at the receiver) and some problems in the network (packet reodering, packet loss, varying latency). Jitter buffers are used to compensate those network problems.

The advantage: You will hear the full stream, even if there is varying delay and/or out of order packets (at least to some extent)
The disadvantage: The receiving device will have to delay the audio/video output for a while, until the jitter buffer fills with enough data.

If the jitter buffer is to large (buffering more than ~ 100-150 ms), you may/will hear that.

Unfortunately, you cannot see anything in the capture files, as the jitter buffer is just an internal mechanism within the receiving VoIP client.

What you might see are 'increased' values for: jitter and/or skew and/or delay and/or lost packets in the RTP statistics.

Please open the capture file taken at the receiver side (jitter can only be calculated correctly at the receiver side!) and run the following stats.

Telephony -> RTP -> Show all Streams

What are the values for Lost, Max. Delta, Mean Jitter", Max. Jitter**?

Regards
Kurt

answered 09 Sep '13, 08:58

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

edited 09 Sep '13, 08:58

Thanks Kurt for your inputs. I can see the following,

Max delta = 155.55 ms at packet no. 6989 
Max jitter = 15.60 ms. Mean jitter = 1.29 ms.
Max skew = 142.47 ms.
Total RTP packets = 3938   (expected 3938)   Lost RTP packets = 7 (0.18%)   Sequence errors = 7 
Duration 78.60 s (158 ms clock drift, corresponding to 8016 Hz (+0.20%)

Can the delay be occurred in our audio processor? We use to write the streams into six different devices after receiving it from the RTP stack.

Regards Rajib

(09 Sep '13, 23:51) Rajib

Can the delay be occurred in our audio processor?

sure and I guess, the problem is more likely a software/hardware problem than a network problem.

(09 Sep '13, 23:57) Kurt Knochner ♦

Thanks Kurt, Looks like the delay does not occur if we reduce the number of devices attached to our application. So we are sure, the problem is in our code. Regards Rajib

(10 Sep '13, 00:49) Rajib

Good.

Hint: If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions.

(10 Sep '13, 01:03) Kurt Knochner ♦