RE: RTCRtpParameter defaults?

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?






On Jun 16, 2014, at 5:50 PM, "Peter Thatcher" <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:
I think it would make more sense to have read-only attributes of RtpSender.parameters and RtpReceiver.parameters.  I'm surprised they aren't already there.  Then it's just a question of whether we have an event/promise indicating when send/receive has taken effect.

On Fri, Jun 13, 2014 at 3:10 PM, Robin Raymond <robin@hookflash.com<mailto:robin@hookflash.com>> wrote:

It just occurred to me that we have no way to know the defaults chosen by the browser engine when calling RTCRtpSender.send(...) or RTCRtpReceiver.receive(...) method. You may need that if you intend the browser engine to pick things like SSRC values for you but still signal those on the wire.


I suggest we can solve this by returning a Promise<RTCRtpParameters> from the send(..) and the receive(...) methods.

Example:

interface RTCRtpSender {
    //...
    Promise<RTCRtpParameters> send (RTCRtpParameters parameters);
    //...
};

The "send(...)" method returns a Promise whose "resolve" function will execute when the send parameters have taken effect and be pass back a copy of the RTCRtpParameters previously passed in with any browser chosen defaults appropriately filled as needed.


interface RTCRtpReceiver {
    //...
    Promise<RTCRtpParameters> receive (RTCRtpParameters parameters);
    //...
};

The "receive(...)" method returns a Promise whose "resolve" function will execute when the receive parameters have taken effect and be pass back a copy of the RTCRtpParameters previously passed in with any browser chosen defaults appropriately filled as needed.


In programmer can then do:

var promise = sender.send(params);
promise.then(function(params) { ... success with params filled in.... }, function() {... failure...});


This also gives knowledge of when send/receive are activated should any asynchronous operations be required to fulfill the send/receive requests.

-Robin