On Thu, Sep 8, 2016 at 12:29 PM, Adam Roach <[email protected]> wrote:
> Second, looking past PeerConnection, what other things might we want to > expose to extension authors? In the description for bug 1281833, Adam > suggests "The ability to add, remove, or change IP addresses exposed by > PeerConnections". This sound like a useful thing but I'm unfamiliar with > the webrtc implementation, is this even feasible? What other things > can/should we expose? > > > 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. -Andrew _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
