Re: Issue 138: Latching in SST-MS

[BA] If the application uses muxId and lets the browser handle the choice of SSRCs,  it would be desirable if the application doesn't need to know whether the codec supports SST-SS or SST-MS.  Here's a potential way this could work:


1.     sender.send() is called on an RTCRtpParameters object that fills in the muxId, but not the SSRCs.  The browser then fills in the unset SSRCs, and places the muxId into an RTP header extension when sending.   If the codec involved supports SST-SS, then only a single SSRC is filled in for each of the SVC layers;  if the codec involved supports SST-MS, then multiple SSRCs will be filled in.  But the developer neither knows nor cares about this.

2.     On the receiver, we want all the RTP packets with a muxId to be routed to a single RTCRtpReceiver object, regardless of whether the layers use the same or different SSRCs.  One way this could work is for receiver.receive() to be called on an RTCRtpParameters object that fills in the muxId, but not the SSRCs.  The assumption would be that if a "match" is found on the muxId that an RTP stream would thereafter be delivered to the matching RTCRtpReceiver object, regardless of whether a previous RTP stream had already been delivered to that RTCRtpReceiver.  So this implies that more than one "SSRC" could be latched to an RTCRtpReceiver object.  One "gotcha" is the case where both simulcast and SST-MS are supported on a receiver.  Here I believe that distinct muxIds may be needed for each simulcast stream, to avoid mixups.  Since there is no RTCRtpEncodingParameters.muxId,  this seems to imply the need for multiple RTCRtpReceiver objects, and therefore multiple tracks.  If the simulcast and SVC layers are dynamically changing, this could make it difficult to render the multiple tracks into a single <video> tag.