RE: RTCRtpParameter defaults?

Few of points to add:

- (minor nit) I think it can’t be just a read-only attribute / property named RtpSender.parameters and RtpReceiver.parameters and must be a getter method for the same reason we had to do that for other dictionaries, the read-only applies to the pointer the dictionary, not to the properties within the dictionary.

- the reason I made it a Promise because I wasn’t 100% sure the moment the “send(…)" was called the parameter defaults would be completely ready to go so having an event indicate when parameters are fully ready would be needed.

- I also wasn’t thinking about the auto-filling of receiver information based on auto-latching and the default values change as a result (which is definitely an asynchronous operation and definitely can event more than once)


So we do need to get the defaults for the send (no question), the only question I have is that an asynchronous operation with the “sender"? I don’t think it inherently needs to be but I could see some implementations requiring it to be asynchronous to get their state machine ready to fill in the default information. If it’s asynchronous, a Promise would suffice.

However, if we want it to “receiver" information as it is filled as it latches then a Promise would not work and it would need to be an “on parameters changed” event of some kind whenever more information became known / available (which I believe is what Bernard is suggesting).

-Robin

On June 18, 2014 at 5:10:53 PM, Bernard Aboba (bernard.aboba@microsoft.com) wrote:

With RTCRtpSender.send, the SSRC fields in  RTCRtcpParameters and RTCRtpEncodingParameters will typically not be filled in when the method is called, so the browser will fill them in.   If a promise is used, we are assuming that when the success callback is invoked, the complete RTCRtpParameters dictionary is filled in and the SSRCs are always available.  I am wondering whether this is always true – for example, is it possible that the success callback could be called after starting to send one stream, but additional streams (and SSRC allocations) could happen later? 

This problem definitely seems like it could occur for RTCRtpReceiver.receive because the SSRCs in RTCRtpEncodingParameters might not be known yet (e.g. the answer hasn’t been received) but the receiverId is set so that RTP packets can be received and processed without firing an RtpUnhandled event.  So even with a promise, the receive method could return with only some of the SSRCs in RTCRtpParameters filled in. For example, the SFU might not start out sending all the layers, only the base temporal layer or a lower resolution simulcast stream, so that the other SSRCs might not be filled in until *way* after the success callback.

If that is true, then if we go down the event route, we need to be careful to understand what the event means.  Is it an event to signify that *one* of the missing fields has been filled in?  Or is it only fired when *all* of them are filled in?  What happens if a layer is never received (e.g. the SFU figures out that it is talking to a mobile device with insufficient bandwidth to handle HD)?  Is the event never fired?