@queengooborg NOTE that I only intend to do this case because the values in RTCRtpParameters are not otherwise in BCD (and I will have to also do this for RTCRtpReceiver.getParameters() too.

Each one of these keys is also a set of objects - so for example return_object_has_encodings references an array of
encodings RTCRtpEncodingParameters objects. It all gets pretty messy at this point so my intent is to stop after doing this one and not nest deeper.

Unless you think this is a cunning plan?

Thanks @queengooborg Please merge this.

I didn't see a response to the question below, so I'll just do it the way I want and see what you say :-)

Assuming I am correct, what is the naming pattern to represent each of the values of a returned object? Something like return_object-has_Xxxx?

@queengooborg Updated significantly - needs checking.

So we have a dict RTCRtpSendParameters which extends RTCRtpParameters. I've pulled the information from the dicts into the methods that use them as return values and as parameter options:

• RTCRtpSender.getParameters() sets RTCRtpSendParameters
• RTCRtpSender.setParameters() set RTCRtpSendParameters
• RTCRtpReceiver.getParameters() - returns RTCRtpParameters

This copies the values for RTCRtpSendParameters in BCD - so those should be right.
RTCRtpParameters was not in BCD, but this is what "came first" so should more closely match the original implementation of method that calls it. Where possible I have tested - so for example I know that the values for safari should be correct.

1. Is this naming convention/structure OK? In particular note the return value option names

2. Note that FF110 brought FF "up to spec". However it is hard to clarify exactly what that means in terms of changes. Until we have concrete information about what changed, my intent is just to not mention FF110 at all.

3. Next step would be to delete RTCRtpSendParameters and RTCRtpParameters (follow on PR)