[ortc] RTPReceiver encoding parameters are useless

murillo128 has just created a new issue for 
https://github.com/openpeer/ortc:

== RTPReceiver encoding parameters are useless ==
Correct me if I am wrong.

On chapter `8.3 RTP matching rules` the rtp packets are routed to the 
correct RTPReceiver based on the following parameters:

- parameters.muxId
- parameters.encodings[i].ssrc
- parameters.encodings[i].fec.ssrc
- parameters.encodings[i].fec.ssrc
- parameters.codecs[j].payloadType
- parameters.encodings[i].rtx.payloadType

First weird case, we check the payloadType on the codecs, but the rtx 
payloadType on the encodings (???). Luckily this will be solved by 
#444

We only use encodings for looking for the ssrc, but we then don't do 
anything with it (is it relevant at all that a packet is received by a
 particular encoding? i don't think so, we know the ssrc and the codec
 already).

So my question is what are encodings really used for in receving side?
 We just need a sequence of <ssrc,fecssrc> at most.

Moreover, as discussed in #439, if we just allow one incoming stream 
for simulcast, we just need one ssrc and one fecssrc, don't we?

So if we do #440 we could simplify to:

```javscript
dictionary RTCRtpReceivingParameters {
             DOMString                                 muxId = "";
             sequence<RTCRtpCodecParameters>           codecs;
             sequence<RTCRtpHeaderExtensionParameters> 
headerExtensions;
             unsigned long                             ssrc;
             unsigned long                             fecSsrc;
             RTCRtcpParameters                         rtcp;
};
``` 

As usual, am I missing anything?

Please view or discuss this issue at 
https://github.com/openpeer/ortc/issues/445 using your GitHub account

Received on Thursday, 31 March 2016 21:56:58 UTC