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

[sungtae kim (JIRA)]

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

sungtae kim edited comment on ASTERISK-28285 at 2/14/19 3:00 PM:
-----------------------------------------------------------------

I was wrong. No need to fix this. 

It's kind of bit operation. Which is correct.


was (Author: pchero):
I was wrong. No need to fix this. 

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