Meaning Of RTT In Channelstats

Home » Asterisk Users » Meaning Of RTT In Channelstats
Asterisk Users 6 Comments

Hello!

I’m just wondering what the RTT exactly means. Where are the exact measuring points located?

………..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

Thanks Michael

—

6 thoughts on - Meaning Of RTT In Channelstats

  • That doesn’t answer my question (I know the abbreviation RTT). Therefore I’m trying again:

    I’m just wondering what the RTT *exactly* means. Where are the exact measuring points located?

    => How are the RTT values exactly calculated? Which values are actually used for?

    => What about the processing time between the inbound leg and the outbound leg (transcoding, …)?

    Thanks Michael

    —

  • Somebody else more knowledgeable then me will have to chime in here, but my guess would be, that since TCP is stateful, it’s the amount of time that a RTCP packet taken to be acknowledged the recipient.

    The measure points located would probably be each hop in the path, which typically can be visualized with traceroute.

    Similar to ping; the math behind it I would have no clue.

    And again, just a guess.

    Doug

    —

  • 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.

    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.

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

  • Thanks Joshua!

    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

    —

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