On 15.05.20 at 14:31 Doug Lytle wrote:> Google says Round Trip Time > > https://www.voip-info.org/asterisk-rtcp/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
On 5/16/20 9:57 AM, Michael Maier wrote:> On 15.05.20 at 14:31 Doug Lytle wrote: >> Google says Round Trip Time >> >> https://www.voip-info.org/asterisk-rtcp/ > 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, ...)? >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
On Sat, May 16, 2020 at 10:58 AM Michael Maier <m1278468 at mailbox.org> wrote:> On 15.05.20 at 14:31 Doug Lytle wrote: > > Google says Round Trip Time > > > > https://www.voip-info.org/asterisk-rtcp/ > > 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? >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.> => 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. [1] https://tools.ietf.org/html/rfc3550 -- 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/20200516/b6b1f84f/attachment.html>
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