Here's additional information the intent template asks for:
Standard:
restartIce()
https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-restartice
setRemoteDescription() with "rollback"
https://w3c.github.io/webrtc-pc/#dom-peerconnection-setremotedescription
This refers to the implicit rollback that happens at step 3.1.
setLocalDescription() that implicitly creates the offer or answer
https://github.com/w3c/webrtc-pc/pull/2234
The changes have already been discussed, reviewed and have consensus,
the PR will be merged at the editor's meeting this week.
Stopping and stopped transceivers
https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver-stop
Especially, see the [[Stopping]] and [[Stopped]] internal slots.
Platform coverage: all platforms
Preference: on by default
DevTools bug: no plans
Other browsers:
Chrome: In development [1]
Edge: In development
Safari: No signals
Web / Framework developers: No signals
web-platform-tests:
1.
https://wpt.fyi/results/webrtc/RTCPeerConnection-restartIce.https.html?label=master&label=experimental
2.
https://wpt.fyi/results/webrtc/RTCPeerConnection-setRemoteDescription-offer.html?label=master&label=experimental
3. Forthcoming in http://bugzil.la/1568292
4. Forthcoming in http://bugzil.la/1568296
Secure contexts: No. These are fixes to an existing API.
Example:
const pc = new RTCPeerConnection(config);
mediaButton.onclick = () => {
if (mediaButton.checked) {
this.transceiver = pc.addTransceiver(this.track); // Some media
} else {
this.transceiver.stop(); // Safe now
}
}
// Write-once "perfect negotiation" handles glare. One peer is polite:
io.onmessage = async ({data: {description, candidate}}) => {
if (description) {
const {type} = description;
if (!polite && type == "offer" && pc.signalingState != "stable") {
return; // The impolite peer ignores glare
}
await pc.setRemoteDescription(description); // Rolls back on glare
if (type == "offer") {
await pc.setLocalDescription(await pc.createAnswer());
io.send({description: pc.localDescription});
}
} else if (candidate) await pc.addIceCandidate(candidate);
};
pc.onnegotiationneeded = async () => {
await pc.setLocalDescription(); // Glare-proof
io.send({desc: pc.localDescription});
}
pc.onicecandidate = ({candidate}) => io.send({candidate});
pc.oniceconnectionstatechange = () => {
if (pc.iceConnectionState == “failed”) {
pc.restartIce();
}
}
To understand why this is race-free requires knowledge that
RTCPeerConnection internally chains asynchronous negotiation methods
called on it, so they never run concurrently with each other.
There's a working example in the blog [3]. It works in Firefox today,
modulo some bugs, thanks to some Promise.all() kludges to guard against
races that can be removed once the new APIs are all done. I hope to
write a follow-up blog once we can demo the new APIs.
Cheers!
.: Jan-Ivar :.
On 7/23/19 9:10 PM, Jan-Ivar Bruaroey wrote:
"Perfect Negotiation" refers to four API improvements to WebRTC that
together make signaling non-racy and more ergonomic. They are (with FF
target and bug #):
1. 70 http://bugzil.la/1551316 restartIce()
2. 70 http://bugzil.la/1567951 setRemoteDescription() with "rollback"
3. 70 http://bugzil.la/1568292 setLocalDescription() without arguments
4. 71 http://bugzil.la/1568296 Stopping and stopped transceivers
Their shared intent is avoiding races and glare in WebRTC's signaling
APIs. See the Chrome's intent to implement [1] for more details.
The first is already in Nightly. The second should land today, and be in
tomorrow's Nightly. The plan is to have all four in Firefox 70 (though
the last one may slip to 71 for more testing).
On the last one, Firefox will likely continue to expose the
transceiver.stopped property for a release or two for backwards
compatibility until we have telemetry numbers for it that justify
removing it.
[1]
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/OqPfCpC5RYU/SjapegYYAgAJ
[2]
https://docs.google.com/presentation/d/1xcvf0udNeSH7s1FOY7RRqr1dEFvokZjn-MZPjwy3iXQ/edit#slide=id.g5c2f3df65b_11_261
[3] https://blog.mozilla.org/webrtc/perfect-negotiation-in-webrtc/
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
