Series preface: We generally lean toward long posts here at webrtcHacks, but not all interesting topics warrant a lot of new text. Sometimes briefer is better. So to better address the many topics that fit into this category, we are starting a new Minimum Duration series. Here is our first post under this set covering Perfect Negotiation.
What is Perfect Negotiation and why do we need it?
Long ago the WebRTC specification designers settled on leaving the signaling communication mechanism between two WebRTC peers up to the application. This means your code needs to handle passing Session Description Protocol (SDP) back and forth and giving that to the peerConnection API. Today WebRTC implementations also almost universally use Trickle-ICE, a form of Interactive Connectivity Establishment (ICE), which passes potential network paths between those peers asynchronously so a connection can be established as soon as possible. The asynchronous but time sensitive nature of all this means it is possible for glare conditions to occur – situations where both sides are making updates at the same time causing their state machines to get out of sync. Differences in how developers implement their code and browsers variances make this worse.
Perfect Negotiation is an effort to fix these issues.
How do we get Perfect Negotiation?
The fix takes on several forms:
1. Spec updates
See the official spec to see the recommended code pattern. Jan-Ivar Bruaroey reviews this in more depth in the great Perfect Negotiation blog post that kicked this effort off.
2. API updates
There are some updates to the RTCPeerConnection API in the works. For example, Mozilla has been working on:
- restartIce()
- setRemoteDescription with “rollback” support
- setLocalDescription() without arguments
- Stopping and stopped transceivers
As noted in their intent to ship statement, these were mostly rolled in Firefox 70 with the setLocalDescription updates scheduled for in Firefox 74. Chrome has a similar set of updates for parameterless setLocalDescription(), restartIce() and “rollback”.
3. Bug fixes and testing
Henrik Boström at Google cites several open issues, such as a rollback bug, events possibly not firing exactly at the right time and implementing transceiver.stop(). Chrome has a tracking issue for their updates and related bugs here.
The new Edgium is helping here too. Bernard Aboba, Principal Architect at Microsoft for Skype/Teams commented on my Edgium review last month:
Microsoft’s contributions on screen sharing and perfect negotiation, are being contributed directly to Chromium, so this shouldn’t result in any differences between Chrome and Edge. The perfect negotiation work (which includes support for rollback) is not yet complete, which is why some tests are currently failing.
What does this mean for my WebRTC code?
If you are handling RTCPeerConnection code yourself, at a minimum you should check the Perfect Negotiation code pattern in the spec. When this effort is done, it should make for a simpler and more reliable implementation.
Thanks to Jan-Ivar Bruaroey at Mozilla and Henrik Bostöm of Google for sharing the current status of Perfect Negotiation with many links provided above.
{“author”: “chad hart“}
Leave a Reply