RTCRtpParameter defaults?

[aboba]

From: Robin Raymond robin@hookflash.com
Date: Fri, 13 Jun 2014 18:10:05 -0400
To: "public-ortc@w3.org" public-ortc@w3.org
URL: http://lists.w3.org/Archives/Public/public-ortc/2014Jun/0036.html

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 from the send(..) and the receive(…) methods.

Example:

interface RTCRtpSender {
//...
Promise 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 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

[aboba]

Issues with Promise approach noted by Bernard:
http://lists.w3.org/Archives/Public/public-ortc/2014Jun/0048.html

[aboba]

Proposal is:

partial interface RTCRtpSender : RTCStatsProvider {
Promise send (RTCRtpParameters parameters);
};

The requirement is for the sender object to fill in the RTCRtpParameters by the time the Promise is fulfilled. There is no need for an event on SSRC conflicts; the sender object just changes the sending SSRC and a corresponding RtpUnHandled Event will occur on the Receiver object.

On the RTCRtpReceiver, there doesn't appear to be a good reason to have an event to tell the developer when RTCRtpParameters changes. The only relevant info that could be delivered is latching events and arrival of SDES packets (with CNAME info), etc. but this does not seem critical.

[aboba]

To be somewhat more specific about what is required to be filled in by the time the send Promise is fulfilled, how about this?

"By the time the Promise is fulfilled, RTCRtcpParameters.ssrc, RTCRtpParameters.cname and RTCRtpEncodingParameters.ssrc MUST be set, so that the values (which may be needed for signaling) can be retrieved by calling getParameters()."