[asterisk-users] Meaning of RTT in channelstats

Michael Maier m1278468 at mailbox.org
Sun May 17 03:34:55 CDT 2020


On 17.05.20 at 01:28 Joshua C. Colp wrote:
> On Sat, May 16, 2020 at 10:58 AM Michael Maier <m1278468 at mailbox.org> wrote:
> 
>> => How are the RTT values exactly calculated? Which values are actually
>> used for?
>>
> 
> The value is calculated according to the logic in the RFC[1]. Specifically
> using embedded timestamps in the RTCP packets and calculated delays. The
> value is presented in seconds I believe in the output.

Thanks Joshua!

>> => What about the processing time between the inbound leg and the outbound
>> leg (transcoding, ...)?
>>
> 
> That has no impact within this, since it's calculated using the RTCP
> traffic which is not used for media. It's really just for round trip time
> of a UDP packet, not for end to end time of a single audio packet/frame
> through the system.

Let's try to sum it up on base of the given easy example how to get the complete delay between those two speakers:

A calls B:
                                             ...........Receive......... .........Transmit..........

 BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter   RTT....
 ===========================================================================================================

 c8137221 327-00000004       03:22:42 g722      608K      0    0   0.000    608K      0    0   0.000   0.000
 c8137221 providePJSIP-xxx-0 03:22:42 alaw      608K      0    0   0.000    608K      0    0   0.000   0.023

A says something.

1. quantization: 				20 ms
2. processing time on the phone base / DECT: 	?
3. way from phone base to asterisk: 		0 ms
4. processing time on asterisk / transcoding: 	?
5. transport to destination: 			11.5 ms
6. processing time on destination side:		?

Therefore it would take about 35 ms until B can here A. Is this basically a correct estimation or did I miss(understand) something?


Thanks
Michael


> [1] https://tools.ietf.org/html/rfc3550



More information about the asterisk-users mailing list