negotiationneeded event payload should be more descriptive about what is triggering the event

[jpsantosbh]

Summary

The negotiationneeded event currently lacks detailed information about what specifically triggers it. This limitation makes it challenging for developers to handle signaling efficiently, especially in complex applications where multiple actions can cause renegotiation.

Detailed Description:

When the negotiationneeded event is fired on an RTCPeerConnection, it does not provide any context about the underlying reason. For instance, the event could be triggered by:

Adding a new track via addTrack() or addTransceiver()
Removing a track with removeTrack()
Changing the parameters of an RTCRtpSender
Modifications to data channels
Other internal state changes that require renegotiation
Without knowing the specific cause, developers might:

Perform unnecessary or redundant signaling operations
Face difficulties in optimizing the negotiation process
Encounter challenges in debugging and maintaining code

Proposed Solution:

Enhance the negotiationneeded event by including additional information in its payload that describes the reason(s) for the event. This could be achieved by:

• Introducing a reason property in the event object, possibly as an array if multiple actions triggered the event.
• Defining a set of enumerated values or constants that represent different triggering actions.

Example

pc.addEventListener('negotiationneeded', (event) => {
  console.log('Negotiation needed due to:', event.reason);
  // event.reason could be something like ['addTrack', 'modifySender']
});

Benefits:

• Improved Clarity: Developers can tailor their signaling logic based on the specific cause.
• Optimization: Potential to avoid full renegotiations when only minor adjustments are needed.
• Debugging: Easier to trace and resolve issues related to peer connection state changes.

[alvestrand]

Skeptical. Apart from debugging, this would seem to have little utility.
General architectural advice is that simple events are preferred over events carrying "baggage".

[jpsantosbh]

Apart from debugging, the main utility would be that depending on the "negotiation cost" in given scenarios, a developer could safely opt not to renegotiate.

Is there another way to evaluate what triggers the event?

[fippo]

There are two views of the world:

• developers know what they are doing, do not rely on ONN at all and negotiate when they think they triggered an action that requires negotiation.
• browsers provide perfect implementations of ONN that developers can just rely on and negotiate without waiting for years to get issues with ONN fixed.

There is not much middle ground left for "kinda interested in ONN but wants to know more".

chrome's webrtc-internals page has "transceiverAdded" and similar events but those turned out to be more confusing than helpful.

[jpsantosbh]

developers know what they are doing, do not rely on ONN at all and negotiate when they think they triggered an action that requires negotiation.

The problem with this view is that only some developers control both sides of the communication.
So even when the developer knows what they are doing on their side, they are still susceptible to receiving an incompatible remote SDP that fires ONN events.