Open jpsantosbh opened 1 week ago
Skeptical. Apart from debugging, this would seem to have little utility. General architectural advice is that simple events are preferred over events carrying "baggage".
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?
There are two views of the world:
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.
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.
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:Example
Benefits: