RTCDtlsTransport.getRemoteParameters / DTCIceTransport.getRemoteParameters but not on sender / receiver?

[robin-raymond]

We "store" remote parameters passed into start() for the ICE + DTLS transport for [convenience?], but we don't do it for other things like the parameters passed into send() / receive() for RTCRtpSenderor RTCRtpReceiver.

We dismissed retrieving the previously passed parameters from the sender/receiver.

Seems these decisions are fairly inconsistent.

[aboba]

In the case of DTLS and ICE, the remote parameters are passed to start(), so the browser can store them and allow them to be retrieved later. In the case of send() and receive() however, only the local parameters are passed as arguments. So it is possible to add getParameters(), but not getRemoteParameters().

[robin-raymond]

I agree, one is local vs the other being remote from the origin. So there is a slight difference. I was more questioning the rational for either agreeing to store information on behalf of the developer or not storing at all. Certainly object references need to be stored and retrieved later (because object life time issues are at stake), but we are a bit inconsistent on dictionary based parameters.

The reason for exclusion of the local parameters was two reasons:

1. don't expand the API to include stuff that the upper layer can easily track themselves (but we actually do this now);
2. the local parameters may have "auto-filled" information, and we couldn't agree if getParameters() would return the original data or the post-filled data;

So I'm not going to comment on 2, but I think the rational behind 1 is inconsistent right now. We do store and allow retrieval for some dictionary information but not for others. So we should either agree that parameters should be stored and fetched to be consistent (and then independently answer part 2 depending on the answer of part 1).

[ibc]

As I already commented in other issues, retrieving "auto-filled" RTP parameters is useless because at the time we can retrieve them we are already sending media. So option 2 above has no sense IMHO unless we change the API to something like:

rtpSender.setParameters(params);

rtpSender.send();

var fullParams = rtpSender.getParameters();

[robin-raymond]

@ibc Correct, but option 2 is more about the receiver than the sender;

[ibc]

Why? Why is more useful to get auto-filled params in the receiver than in the sender?

[robin-raymond]

@ibc I don't think either use case is particularly strong IMHO; But the sender you always have the option to specify SSRCs if you care; on the receiver, if you don't know the information in advance you have no way to discover what was found on the wire after the fact and getParameters on the receiver would be the only way to obtain that information.

[ibc]

The API assumes that the human knows how exactly the browser behaves given specific parameters to the RtpSender. So the same for the RtpReceiver: The human should be able to anticipate how the browser will behave given specific parameters (let them be complete parameters or not).

[robin-raymond]

@ibc if signaling contains all the sender parameters then there's no reason for the receiver to have getParameters because you know what the sender will do. However, if the receiver is setup based upon routing rules (e.g. mux/mid) then the actually SSRCs used are not discoverable via the API and thus receiver reports / contributing sources will not be known by the developer. The sender always has the option to force particular settings in advanced locally, but that's not true of a non-signalled receiver.

[ibc]

Fine. But may I know why is it so hard to provide auto-filled parameters in the sender?

[robin-raymond]

@ibc technically not hard. There was push back against it because of its implications on the receiver to have "matching" functionality between them. For a receiver the information is filled over time so it's a changing value (and thus would also imply an event is needed too). So the complexity grew. Thus it was decided we wouldn't do it and if we did at most it would return the same values that were passed in originally (and thus would not give auto-filled values). Plus since the programmer can specify the values prior to calling send the use case to get the auto-filled values out was considered very low value and thus unworthy of expanding the API surface. That's the history behind the decision.

[ibc]

Fine. But don't forget our bet ;)