[asterisk-bugs] [JIRA] (ASTERISK-28285) Fixed wrong RTT calculation

[Asterisk Team (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=246207#comment-246207 ] 

Asterisk Team commented on ASTERISK-28285:
------------------------------------------

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.

> Fixed wrong RTT calculation
> ---------------------------
>
>                 Key: ASTERISK-28285
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28285
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 16.1.1
>            Reporter: sungtae kim
>            Severity: Minor
>
> 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



--
This message was sent by Atlassian JIRA
(v6.2#6252)