Changed loopback transport in RtxNackTest to not store sequence numbers for retransmitted packets.

Changed loopback transport in RtxNackTest to not store sequence numbers for retransmitted packets.

The unit test currently works as follows:

RtxLoopBackTransport logs the sequence numbers for all sent packets in expected_sequence_numbers_. Since the transport is configured to drop some of the packets there will be requests for retransmissions and the RTX sequence numbers will also be stored in the same list.

The (non-rtx) packets are received by VerifyingRtxReceiver which also stores the sequence numbers in a list sequence_numbers_. Both lists are then sorted and sequence_numbers_ is compared to whatever is in the start of expected_sequence_numbers_.

This works assuming that the RTX sequence numbers are greater than the regular RTP sequence numbers. In the RTP sender, both RTP and RTX are set to start at "random" 15-bit sequence numbers. The RTP sequence number is then changed to 2345 in the unit test, which would imply that the RTX sequence number is lower than the ones for RTP with probability ~1%. The reason why the test works anyway is that the test sets up a fake clock, which is used to initialize the random number generator in RTPSender, and the fixed starting point for the clock happens to result in RTX sequence numbers greater than 2345. However, any change to the initialization of the sequence numbers, the seeding of the PRNG or the fake clock causes a test failure with probability ~1%.

The new code omits the RTX sequence numbers from expected_sequence_numbers_, thus avoiding the problem with low RTX sequence numbers. The initialization of the sequence numbers in RTPSender is also bad, but I'll fix that in another CL.

Committed: https://crrev.com/e64fbce0d92949b2928a1a7427b24f37ba90f526
Cr-Commit-Position: refs/heads/master@{#9967}

[terelius, 2015-08-03 18:09:46]

terelius@webrtc.org changed reviewers:
+ mflodman@webrtc.org, stefan@webrtc.org

[stefan-webrtc, 2015-09-07 10:00:19]

lgtm

[mflodman, 2015-09-08 12:21:29]

lgtm

[terelius, 2015-09-16 14:38:18]

The CQ bit was checked by terelius@webrtc.org

[terelius, 2015-09-16 14:38:18]

The patchset sent to the CQ was uploaded after l-g-t-m from stefan@webrtc.org,
mflodman@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1263383002/#ps20001 (title:
"Rebase")

[commit-bot: I haz the power, 2015-09-16 14:38:32]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1263383002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1263383002/20001

[commit-bot: I haz the power, 2015-09-16 14:55:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-16 14:55:02]

Try jobs failed on following builders:
  linux_asan on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_asan/builds/9348)

[terelius, 2015-09-17 10:17:53]

The CQ bit was checked by terelius@webrtc.org

[commit-bot: I haz the power, 2015-09-17 10:18:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1263383002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1263383002/20001

[commit-bot: I haz the power, 2015-09-17 10:19:48]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-09-17 10:20:01]

Patchset 2 (id:??) landed as
https://crrev.com/e64fbce0d92949b2928a1a7427b24f37ba90f526
Cr-Commit-Position: refs/heads/master@{#9967}