1243487 - Document potential causes of WebRTC ICE renegotiation

Status: RESOLVED WONTFIX

(Developer Documentation Graveyard :: API: WebRTC, defect, P5)

Description

[Eric Shepherd [:sheppy]]

:: Developer Documentation Request

      Request Type: New Documentation
     Gecko Version: unspecified
 Technical Contact: 

:: Details

We need to document in our guide to WebRTC connectivity what can cause renegotiation to occur (that is, a second or later negotiationneeded event to start a new negotiation process).

From email from abr:

So, there are a few different things that can trigger renegotiation.

One of these things is ICE restart, which we don't yet do. ICE restart would happen when we sense a network failure or change in available network interfaces, as a means to either reestablish a broken media path or establish an improved media path.

Another thing that can trigger renegotiation is a change in the number of streams. So, for example: imagine that you've gone through a full call setup and have video flowing in one direction. Then, one side calls "addStream" on the peerconnection to hook up a second camera. At that point, the PC will trigger an "onnegotiationneeded" event. The application is then responsible for doing a new offer/answer exchange.

There are a handful of other things that trigger renegotiation, such as pausing and unpausing streams. But, in all cases, the behavior of the application is the same: it needs to send a new offer to the remote side.

Comment 1

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.