-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RTCRtpParameter defaults? #106
Comments
Issues with Promise approach noted by Bernard: |
Proposal is: partial interface RTCRtpSender : RTCStatsProvider { 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. |
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()." |
…3c#66 Added Identity support, as described in Issue w3c#78 Reworked getStats method, as described in Issue w3c#85 Removed ICE restart method described in Issue w3c#93 Addressed CNAME and synchronization context issues described in Issue w3c#94 Fixed WebIDL issues noted in Issue w3c#97 Addressed NITs described in Issue w3c#99 DTLS transport issues fixed as described in Issue w3c#100 ICE transport issues fixed as described in Issue w3c#101 ICE transport controller fixes made as described in Issue w3c#102 Sender and Receiver object fixes made as described in Issue w3c#103 Fixed RTCRtpEncodingParameter default issues described in Issue w3c#104 Fixed 'Big Picture' issues descibed in Issue w3c#105 Fixed RTCRtpParameter default issues described in Issue w3c#106 Added a multi-stream capability, as noted in Issue w3c#108 Removed quality scalability capabilities and parameters, as described in Issue w3c#109 Added scalability examples as requested in Issue w3c#110 Addressed WebRTC 1.0 Data Channel compatibility issue described in Issue w3c#111 Removed header extensions from RTCRtpCodecParameters as described in Issue w3c#113 Addressed RTP/RTCP non-mux issues with IdP as described in Issue w3c#114 Added getParameter methods to RTCRtpSender and RTCRtpReceiver objects, as described in Issue w3c#116 Added layering diagrams as requested in Issue w3c#117 Added a typedef for payload type, as described in Issue w3c#118 Moved onerror from the RTCIceTransport object to the RTCIceListener object as described in Issue w3c#121 Added explanation of Voice Activity Detection (VAD), responding to Issue w3c#129 Clarified the meaning of maxTemporalLayers and maxSpatialLayers, as noted in Issue w3c#130 Added RFC 6051 to the list of header extensions and removed RFC 5450, as noted in Issue w3c#131 Addressed ICE terminology issues, as described in Issue w3c#132 Separated references into Normative and Informative, as noted in Issue w3c#133
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
The text was updated successfully, but these errors were encountered: