[Home]

Summary:ASTERISK-28285: Fixed wrong RTT calculation
Reporter:sungtae kim (pchero)Labels:
Date Opened:2019-02-12 18:26:57.000-0600Date Closed:2019-02-14 15:01:08.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Resources/res_rtp_asterisk
Versions:16.1.1 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Currently, when the Asterisk calculate the RTT for the RTCPSent/RTCPReceived, it does like the below.
{noformat}
rtt = lsr_a - lsr - dlsr;
{noformat}

the lsr_a and lsr is compact timestamp type, but dlsr is 1 / 65536 sec, which is not matched. So this mismatching type makes huge amount of RTT time.

{noformat}
  last SR timestamp (LSR): 32 bits
     The middle 32 bits out of 64 in the NTP timestamp (as explained in
     Section 4) received as part of the most recent RTCP sender report
     (SR) packet from source SSRC_n.  If no SR has been received yet,
     the field is set to zero.

  delay since last SR (DLSR): 32 bits
     The delay, expressed in units of 1/65536 seconds, between
     receiving the last SR packet from source SSRC_n and sending this
     reception report block.  If no SR packet has been received yet
     from SSRC_n, the DLSR field is set to zero.

4. Byte Order, Alignment, and Time Format

  All integer fields are carried in network byte order, that is, most
  significant byte (octet) first.  This byte order is commonly known as
  big-endian.  The transmission order is described in detail in [3].
  Unless otherwise noted, numeric constants are in decimal (base 10).

  All header data is aligned to its natural length, i.e., 16-bit fields
  are aligned on even offsets, 32-bit fields are aligned at offsets
  divisible by four, etc.  Octets designated as padding have the value
  zero.

  Wallclock time (absolute date and time) is represented using the
  timestamp format of the Network Time Protocol (NTP), which is in
  seconds relative to 0h UTC on 1 January 1900 [4].  The full
  resolution NTP timestamp is a 64-bit unsigned fixed-point number with
  the integer part in the first 32 bits and the fractional part in the
  last 32 bits.  In some fields where a more compact representation is
  appropriate, only the middle 32 bits are used; that is, the low 16
  bits of the integer part and the high 16 bits of the fractional part.
  The high 16 bits of the integer part must be determined
  independently.

  An implementation is not required to run the Network Time Protocol in
  order to use RTP.  Other time sources, or none at all, may be used
  (see the description of the NTP timestamp field in Section 6.4.1).
  However, running NTP may be useful for synchronizing streams
  transmitted from separate hosts.

  The NTP timestamp will wrap around to zero some time in the year
  2036, but for RTP purposes, only differences between pairs of NTP
  timestamps are used.  So long as the pairs of timestamps can be
  assumed to be within 68 years of each other, using modular arithmetic
  for subtractions and comparisons makes the wraparound irrelevant.

{noformat}


But the dlsr has different unit. It's 1/65536 sec. So this ma
Comments:By: Asterisk Team (asteriskteam) 2019-02-12 18:26:57.816-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
By: sungtae kim (pchero) 2019-02-14 14:59:57.716-0600

I was wrong. No need to fix this.

It's kind of bit operation. Which is correct.
By: sungtae kim (pchero) 2019-02-14 15:01:08.871-0600

No need to fix. Nothing was wrong.