• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
webrtcHacks

webrtcHacks

Guides and information for WebRTC developers

  • Home
  • About
    • Chad Hart
    • Philipp Hancke
  • Subscribe
  • Contact
  • Show Search
Hide Search

Standards Chad Hart · February 5, 2020

Perfect Negotiation

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“}

Standards

Related Posts

  • Introducing the WebRTC Event DirectoryIntroducing the WebRTC Event Directory
  • What is a WebRTC Gateway anyway? (Lorenzo Miniero)What is a WebRTC Gateway anyway? (Lorenzo Miniero)
  • Am I behind a Symmetric NAT?Am I behind a Symmetric NAT?
  • Trunking WebRTC: the user authentication challenge (Torrey Searle)Trunking WebRTC: the user authentication challenge (Torrey Searle)

RSS Feed

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

  • Sponsored. Become a webtcHacks sponsor

Email Subscription

Subscribe to our mailing list

* indicates required

Twittering

Tweets by @webRTChacks
webrtcHacksguides and information for WebRTC developers

Footer

SITE

  • Post List
  • About
  • Contact

Categories

  • Guide
  • Other
  • Reverse-Engineering
  • Standards
  • Technology

Tags

apple Blackbox Exploration Brief camera Chrome code computer vision DataChannel debug e2ee Edge extension gateway getUserMedia ICE ims insertable streams ios ip leakage janus jitsi MCU Microsoft NAT opensource Opus ORTC Promo Q&A raspberry pi Safari SDES SDP sfu signaling simulcast standards TURN video vp8 w3c Walkthrough Web Audio webrtc-internals wireshark

Follow

  • Twitter
  • YouTube
  • GitHub
  • RSS

webrtcHacks · copyright © 2023