PSA: An old RED/RTX workaround has been removed.

[bra...@webrtc.org]

About a week ago we landed a CL that removed an old workaround related to RED over RTX. This workaround was introduced to deal with some older Chrome versions, which had a bug in how the associated payload types were set in the RTX packet headers. The Chrome versions with this bug are now so old that we can remove the workaround. The full details of what this removal entails can be seen in the linked CL, whose description is pasted at the end of this email.

As a side effect of the workaround removal, the sending of RED over RTX now needs to be explicitly enabled in the UlpfecConfig struct. Prior to the workaround removal, the sending of RED over RTX would implicitly be enabled whenever RTX was enabled. Here is an example CL that shows the small changes needed.

-- Rasmus

==

Remove RED/RTX workaround from sender/receiver and VideoEngine2. In older Chrome versions, the associated payload type in the RTX header of retransmitted packets was always set to be the original media payload type, regardless of the actual payload type of the packet. This meant that packets encapsulated with RED headers had incorrect payload type information in the RTX header. Due to an assumption in the receiver, this incorrect payload type information would effectively be undone, leading to a working system. Albeit working, this behaviour was undesired, and thus removed. In the interim, several workarounds were introduced to not destroy interop between old and new Chrome versions: (1) https://codereview.webrtc.org/1649493004 - If no payload type mapping existed for RED over RTX, the payload type of the underlying media would be used. - If RED had been negotiated, received RTX packets would always be assumed to contain RED. (2) https://codereview.webrtc.org/1964473002 - If RED was removed from the remote description answer, it would be disabled in the local receiver as well. (3) https://codereview.webrtc.org/2033763002 - If RED was negotiated in the SDP, it would always be used, regardless if ULPFEC was negotiated and used, or not. Since the Chrome versions that exhibited the original bug now are very old, this CL removes the workarounds from (1) and (2). In particular, after this change, we will have the following behaviour: - We assume that a payload type mapping for RED over RTX always is set. If this is not the case, the RTX packet is not sent. - The associated payload type of received RTX packets will always be obeyed. - The (non)-existence of RED in the remote description does not affect the local receiver. The workaround in (3) still needs to exist, in order to interop with receivers that did not have the workarounds in (1) and (2) removed. The change in (3) can be removed in a couple of Chrome versions.

TESTED=Using AppRTC between patched Chrome (connected to ethernet) and standard Chrome M54 (connected to lossy internal Google WiFi), with and without FEC turned off using AppRTC flag. Also using "Munge SDP" sample on patched Chrome over loopback interface, with 100ms delay and 5% packet loss simulated using tc. BUG=webrtc:6650 Committed: https://crrev.com/e6f98c7a379aae970e7570ac3cf99e2a21f256c0 Cr-Commit-Position: refs/heads/master@{#15038}