<div dir="ltr"><div dir="ltr">On Sun, May 17, 2020 at 5:36 AM Michael Maier <<a href="mailto:m1278468@mailbox.org">m1278468@mailbox.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 17.05.20 at 01:28 Joshua C. Colp wrote:<br>
> On Sat, May 16, 2020 at 10:58 AM Michael Maier <<a href="mailto:m1278468@mailbox.org" target="_blank">m1278468@mailbox.org</a>> wrote:<br>
> <br>
>> => How are the RTT values exactly calculated? Which values are actually<br>
>> used for?<br>
>><br>
> <br>
> The value is calculated according to the logic in the RFC[1]. Specifically<br>
> using embedded timestamps in the RTCP packets and calculated delays. The<br>
> value is presented in seconds I believe in the output.<br>
<br>
Thanks Joshua!<br>
<br>
>> => What about the processing time between the inbound leg and the outbound<br>
>> leg (transcoding, ...)?<br>
>><br>
> <br>
> That has no impact within this, since it's calculated using the RTCP<br>
> traffic which is not used for media. It's really just for round trip time<br>
> of a UDP packet, not for end to end time of a single audio packet/frame<br>
> through the system.<br>
<br>
Let's try to sum it up on base of the given easy example how to get the complete delay between those two speakers:<br>
<br>
A calls B:<br>
                                             ...........Receive......... .........Transmit..........<br>
<br>
 BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter   RTT....<br>
 ===========================================================================================================<br>
<br>
 c8137221 327-00000004       03:22:42 g722      608K      0    0   0.000    608K      0    0   0.000   0.000<br>
 c8137221 providePJSIP-xxx-0 03:22:42 alaw      608K      0    0   0.000    608K      0    0   0.000   0.023<br>
<br>
A says something.<br>
<br>
1. quantization:                                20 ms<br>
2. processing time on the phone base / DECT:    ?<br>
3. way from phone base to asterisk:             0 ms<br>
4. processing time on asterisk / transcoding:   ?<br>
5. transport to destination:                    11.5 ms<br>
6. processing time on destination side:         ?<br>
<br>
Therefore it would take about 35 ms until B can here A. Is this basically a correct estimation or did I miss(understand) something?<br></blockquote><div><br></div><div>Roughly speaking, yes. It'd likely be more because of the aspects that aren't represented here but yes. </div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><font color="#073763">Joshua C. Colp</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Asterisk Technical Lead</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Sangoma Technologies</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Check us out at <a href="http://www.sangoma.com" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a></font><br></div></div></div></div></div></div></div></div></div></div></div>