[asterisk-dev] [Code Review] 2886: Correct erroneous lost packet information in RTCP reports

Mark Michelson reviewboard at asterisk.org
Fri Sep 27 13:08:03 CDT 2013


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

Ship it!


Ship It!

- Mark Michelson


On Sept. 26, 2013, 3:44 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2886/
> -----------------------------------------------------------
> 
> (Updated Sept. 26, 2013, 3:44 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> RTCP's calculation of the number of lost packets in an RTP stream is based on that stream's sequence number count, the number of received packets, and how many packets we expect to receive. When the SSRC for an RTP stream changes, there can - and almost always will be - a large jump in the next packet's timestamp and sequence number. If we don't reset the number of received packets, sequence number count, and other metrics used by RTCP, the next RR/SR report will use the previous SSRC's values to calculate the lost packet count for the new SSRC - resulting in a very large number of lost packets.
> 
> This patch modifies res_rtp_asterisk such that, if it detects a SSRC change, it will reset the various values used by the RTCP calculations. From the perspective of RTCP, this appears as a new media stream - which is what it is.
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/res/res_rtp_asterisk.c 399886 
> 
> Diff: https://reviewboard.asterisk.org/r/2886/diff/
> 
> 
> Testing
> -------
> 
> Constructed a scenario where the SSRC changes (put a phone on and off hold a few times).
> 
> Previously, Asterisk would count a chunk of lost packets when the SSRC changed. Now it doesn't.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130927/ea8fb495/attachment-0002.html>


More information about the asterisk-dev mailing list