[asterisk-dev] [Code Review]: Resolve Sequence Number Rollover causing codec increase in res_rtp_multicast

[Alec Davis]

> On Oct. 27, 2011, 1:45 p.m., wdoekes wrote:
> > /branches/1.8/res/res_rtp_multicast.c, lines 231-237
> > <https://reviewboard.asterisk.org/r/1542/diff/3/?file=21429#file21429line231>
> >
> >     I'd rather see something like this:
> >     
> >     put_unaligned_uint32(...(multicast->seqno & 0xFFFF)...
> >     
> >     This clarifies that we're dealing with 16 bits in the 32 bit int.
> >     
> >     And then simply do += 1 below, without any ANDing.
> >     
> >     P.S. The 0 << 23 still looks odd. If you're going to keep it, consider moving it between 30 and 16.
> 
> rmudgett wrote:
>     Doing it the way it is in the patch ensures that the seqno value is never out of range.  If the seqno value is ever used elsewhere in the code, it would need to be masked to 16 bits there as well.
> 
> jrose wrote:
>     I'll go ahead and move 0 << 23 to the left of codec << 16 before committing since the change seems pretty harmless to me and I get where you are coming from with the order of things.
> 
> jrose wrote:
>     Actually, I'm just getting rid of 0 << 23.  Bitwise or on 0 is kind of pointless anyway and it doesn't really serve to document anything as far as I can tell.  It does get optimized out by the compiler (or so I'm told), so it's harmless either way, but no one has rushed to its defense.

After digging deeper, the 0 << 23 is to document the Application Level Marker, although it wasn't doing a good job. Thanks google.


- Alec


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1542/#review4601
-----------------------------------------------------------


On Oct. 27, 2011, 12:44 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1542/
> -----------------------------------------------------------
> 
> (Updated Oct. 27, 2011, 12:44 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Basically what was happening was the sequence number would go above 65535, and rather than rolling back to zero, the extra bits would overflow into the codec bits of the RTP packet.  Because of this, if the sequence number goes above 65535, it'll make the codec value change and this can make calls fail.
> 
> This patch simply checks the value of the sequence number each time it is incremented and sets it back to 0 if it's above 65535.  Shouldn't cause any problems.
> 
> 
> This addresses bug ASTERISK-18291.
>     https://issues.asterisk.org/jira/browse/ASTERISK-18291
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/res/res_rtp_multicast.c 341429 
> 
> Diff: https://reviewboard.asterisk.org/r/1542/diff
> 
> 
> Testing
> -------
> 
> I checked the unpatched version with wireshark to make sure the codec shift was in fact happening and it was.  I checked it again after patching and made sure the problem went away and it did.  I also checked to see whether the values stayed as expected if I forcibly changed the codec value to something other than 0, and in all cases it behaved as expected.
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111027/cb4f2c15/attachment-0001.htm>