Re: Issue 438: SSRC values should not be entered by the user

If the SSRC is not specified in the parameters passed to sender.send(parameters), the browser will choose.  This occurs in several places:


1.       parameters.encodings[i].ssrc

2.       parameters.encodings[i].fec.ssrc

3.       parameters.encodings[i].rtx.ssrc

If the application does not choose the SSRCs and lets the browser choose them, currently  it is not possible for the sender to determine what these SSRC values have been set to.  This means that to signal SSRCs, the application has to choose them.

This seems like a difficult choice for developers, but there is a way for the developer to let the browser choose SSRCs while avoiding the signaling problems - using muxId (the MID header extension).

In this model, the RtpReceiver can set parameters.muxId in receiver.receive(parameters), and then signal this to the sender which will set parameters.muxId in sender.send(parameters).

If the muxId is used, the matching rules enable both media and RTX/RED/FEC to be routed to the correct receiver without the application needing to choose SSRCs or signal them.

Since ortc-lib is implementing muxId,  Robin can perhaps best comment on his experience with that approach.



Inaki filed the following Issue:
https://github.com/openpeer/ortc/issues/438

Currently, if the user calls RtpSender.send() without setting specific SSRC values, the browser will choose them. This is fine. The problem is that, at that point, RTP negotiation is already supposed to be done so we cannot signal our SSRC. Even worse: RtpSender does not have a getRtpParameters() method that retrieves the effective parameters (including SSRC values chosen by the browser).

This basically means that the user (the JS) is required to manually set a random SSRC which IMHO is not very cool.

NOTE: I do know that, given "RTP Matching Rules" the receiver may be able to somehow correlate received RTP packets, but that is not valid for all the cases (if I send two video tracks over two RtpSendersover the same DtlsTransport and choose the same PT value for both, the receiver won't be able to properly demux RTP packets belonging to both video streams, so SSRC values are required).