Issue 246: Incoming RTX payload ambiguity

>From Robin Raymond:


It's highly desirable that an unannounced incoming stream where SSRCs are not pre-configured get automatically wired to an RtpReceiver based on a muxid and a codec list.

Scenario where RTX is ambiguous:
1) RtpReceiver is configured with a muxid of "foo", a full codec list of Opus (96), G711-ulaw (0), G711-alaw (8); Isac (99); RTX (102);
2) The RtpSender starts being is configured to use a muxid of "foo", using Opus (96) SSRC 1000; RTX (102) with SSRC 2000
3) The RtpReceiver sends a NACK for Opus; RtpSender sends SSRC 2000 packet ("Packet-1");
4) The RtpSender changes configuration (still using muxid of "foo") but using G711a (8) SSRC 1001; RTX (102) with SSRC 2001
5) The RtpReceiver sends a NACK for G711a; RtpSender sends SSRC 2001 packet ("Packet-2");
6) The RtpSender changes configuration (still using muxid of "foo") but using Isac (99) SSRC 1002; RTX (102) with SSRC 2002
7) The RtpReceiver sends a NACK for Isac; RtpSender sends SSRC 2002 packet ("Packet-3");

Problem: RtpReceiver suddenly receives RTX packets late and in random order ("Packet-1"); ("Packet-2"); ("Packet-3"), i.e. SSRCs 2001, 2002, 2003, all configured with RTX payload type 102. Given that the RtpReceiver processed 3 different SSRCs (where each replaced previous) the incoming RTXs packets are mis-matched to the current configuration and the incoming RTX packets are ambiguous to which original SSRC stream they belong.