Open Bug 1243487 Opened 4 years ago Updated 4 years ago

Document potential causes of WebRTC ICE renegotiation

Categories

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

All
Other
defect

Tracking

(Not tracked)

People

(Reporter: sheppy, Unassigned)

References

(Blocks 1 open bug)

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
You need to log in before you can comment on or make changes to this bug.