[ortc] RTPReceiver encoding parameters are useless

murillo128 has just created a new issue for 

== 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 

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

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:

dictionary RTCRtpReceivingParameters {
             DOMString                                 muxId = "";
             sequence<RTCRtpCodecParameters>           codecs;
             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