Closed Bug 1243487 Opened 9 years ago Closed 4 years ago

Document potential causes of WebRTC ICE renegotiation

Categories

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

All
Other
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: sheppy, Unassigned)

References

Details

:: 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.
Blocks: 1050930
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/.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.