RTCRtpParameter defaults? #106

Closed
aboba opened this Issue Jun 23, 2014 · 3 comments

Projects

None yet

2 participants

@aboba
Contributor
aboba commented Jun 23, 2014

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
Contributor
aboba commented Jun 25, 2014

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

@robin-raymond robin-raymond added the 1.1 label Jun 28, 2014
@aboba
Contributor
aboba commented Jul 8, 2014

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
Contributor
aboba commented Jul 14, 2014

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()."

@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Jul 16, 2014
Robin Raymond Added section on WebRTC 1.0 compatibility issues, responding to Issue #…
…66

Added Identity support, as described in Issue #78
Reworked getStats method, as described in Issue #85
Removed ICE restart method described in Issue #93
Addressed CNAME and synchronization context issues described in Issue #94
Fixed WebIDL issues noted in Issue #97
Addressed NITs described in Issue #99
DTLS transport issues fixed as described in Issue #100
ICE transport issues fixed as described in Issue #101
ICE transport controller fixes made as described in Issue #102
Sender and Receiver object fixes made as described in Issue #103
Fixed RTCRtpEncodingParameter default issues described in Issue #104
Fixed 'Big Picture' issues descibed in Issue #105
Fixed RTCRtpParameter default issues described in Issue #106
Added a multi-stream capability, as noted in Issue #108
Removed quality scalability capabilities and parameters, as described in Issue #109
Added scalability examples as requested in Issue #110
Addressed WebRTC 1.0 Data Channel compatibility issue described in Issue #111
Removed header extensions from RTCRtpCodecParameters as described in Issue #113
Addressed RTP/RTCP non-mux issues with IdP as described in Issue #114
Added getParameter methods to RTCRtpSender and RTCRtpReceiver objects, as described in Issue #116
Added layering diagrams as requested in Issue #117
Added a typedef for payload type, as described in Issue #118
Moved onerror from the RTCIceTransport object to the RTCIceListener object as described in Issue #121
Added explanation of Voice Activity Detection (VAD), responding to Issue #129
Clarified the meaning of maxTemporalLayers and maxSpatialLayers, as noted in Issue #130
Added RFC 6051 to the list of header extensions and removed RFC 5450, as noted in Issue #131
Addressed ICE terminology issues, as described in Issue #132
Separated references into Normative and Informative, as noted in Issue #133
6f8216a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment