[asterisk-users] Meaning of RTT in channelstats

[Joshua C. Colp]

On Sun, May 17, 2020 at 5:36 AM Michael Maier <m1278468 at mailbox.org> wrote:

> 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?
>

Roughly speaking, yes. It'd likely be more because of the aspects that
aren't represented here but yes.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200517/b03edca1/attachment.html>