On 9/8/16 4:53 PM, Andrew Swan wrote:
On Thu, Sep 8, 2016 at 12:29 PM, Adam Roach <[email protected]> wrote:
What I'd expect here is the means to register a callback that is hit
whenever a new ICE candidate is generated. The callback receives the
candidate, and returns a Promise<void>. Once it reaches a verdict on
whether the candidate is allowed to be presented to the content, it either
resolves or rejects the promise. (Or, if people don't like the aesthetics
of a promise reject for normal operation, you can return a
Promise<boolean>).
Right, the concept makes sense and I think its a great one. But I'm
thoroughly unfamiliar with the webrtc implementation. I assume that most
(all?) of the protocol stack runs in the content process. If the
implementation doesn't already communicate with the parent process then
this becomes more complicated and if the implementation isn't written in a
way to handle an asynchronous operation at the moment new candidate
addresses are produced, it becomes significantly more complicated.
Hi Andrew,
That sounds about right. The high-level implementation in
dom/media/PeerConnection.js (getPermission) is the one that talks to the
parent process specifically for the things we wanted permission blocking
for, and would need to be duplicated for ice candidates, which also go
through there, to fire icecandidate events (e.g. for pc.onicecandidate).
The tricky part is I suspect the ice candidates have already been added
to the SDP down in c++ part of the implementation at this point, so we'd
need to change that around, probably by making a trip back down to the
c++ once a candidate is approved, before firing the icecandidate event.
Everything is asynchronous, so that shouldn't be a problem. We'd
definitely take patches and don't hesitate to ask if you need any help.
..: Jan-Ivar :.
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
