RE: Issue 246: Incoming RTX payload ambiguity

The question is: prior to receipt of the answer, how to disambiguate RTX packets where the same RTX payload type (but different SSRCs) are used for different codecs?

In terms of setting up the RtpParameters to be passed to receive(), when the answer arrives we will have multiple RTX entries, each with the same PT and muxId, but with different SSRC values, based on the information in the answer.

However, before the answer arrives, all we know is the RTX PT and the APTs (the Payload Types of the codecs that will be used with RTX).

Since all the RTCP SDES packets and RTX packets will contain the same muxId, muxId doesn't provide information to help you out, and neither does PT since the PT value is the same for all RTX packets.

The original sequence number (OSN) in the RTX packets can be matched to the sequence numbers of the lost packets, which could perhaps enable RtpParameters to be revised based on the SSRC values of the received RTX packets as well as the OSNs which can be matched to SSRCs of the original streams to which RTX is applied.  However, the API (e.g. rtpunhandled event) does not currently provide the OSN).

RFC 4588 Section 8.8 gives examples of RTX configuration using SSRC multiplexing when the RTX streams are differentiated by PT.  If the retransmission payloads are distinguished by PT, the RtpReceiver can be set up in advance and the problem you describe does not occur:

   v=0
   o=mascha 2980675221 2980675778 IN IP4 host.example.net
   c=IN IP4 192.0.2.0
   m=audio 49170 RTP/AVPF 96 97
   a=rtpmap:96 OPUS/48000
   a=rtcp-fb:96 nack
   a=rtpmap:102 rtx/48000
   a=fmtp:102 apt=96;rtx-time=3000
   a=rtpmap:99 ISAC/32000
   a=rtcp-fb:99 nack
   a=rtpmap:103 rtx/32000
   a=fmtp:103 apt=99;rtx-time=3000
   a=rtpmap:0 PCMU/8000
   a=rtcp-fb:0 nack
   a=rtpmap:104 rtx/8000
   a=fmtp:104 apt=0;rtx-time=3000
   a=rtpmap:8 PCMA/8000
   a=rtcp-fb:8 nack
   a=rtpmap:105 rtx/8000
   a=fmtp:105 apt=0;rtx-time=3000






>From Robin Raymond:
https://github.com/openpeer/ortc/issues/246

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.