[Home]

Summary:ASTERISK-07335: bad logical operation when manipulating least significant word from ntp timestamp
Reporter:Andre Abrantes (andre_abrantes)Labels:
Date Opened:2007-02-06 09:47:47.000-0600Date Closed:2007-06-30 09:19:58
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/RTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:In line 969 of rtp.c, when manipulating the ntp timestamp field from the received SR (sender report), the wrong half of the seconds fraction is selected with the and operation.
Instead of using 0xffff0000 to select the most significant bits of the LSW, it's used 0xffff, which is the same as 0x0000ffff. So the least significant bits are selected and the fraction part of the new LSR is always null due the the shift (>>16) operation done just after this and.

****** ADDITIONAL INFORMATION ******

This was confirmed after I used ethereal to get the rtcp messages exchanged between asterisk and a sip client with rtcp support (pjsua from pjproject). Asterisk always looses information about the fraction part of the ntp timestamp when returning the LSR.
Comments:By: Russell Bryant (russell) 2007-02-07 11:47:11.000-0600

This has been fixed in 1.4 and trunk in revisions 43429 and 53431.  Thanks!