Re: [webrtc-pc] addIceCandidate may not need to throw an error when no remoteDescription (#2519)

If I understand the issue correctly, there is no ordering violation on the signalling layer but rather an API call ordering violation. Because SLD and SRD are async, candidates will have to be held back even though they may have already been received.

IMO: I don't see how the suggestion (to accept ICE candidates regardless of the state) would make the API more robust. I think it would provide a false sense of simplicity and hide usage errors. That is pretty much the opposite of what I'd want as a developer. The peer connection is already too much of a black box when it comes to its internal state (e.g. ICE dropping candidate pairs), I don't think we should make it even less opaque. Moreover: If we disregard state here, what about other races on the peer connection state machine that are just less apparent? Would we have to address those as well and where do we draw the line?

-- 
GitHub Notification of comment by lgrahl
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2519#issuecomment-1532678514 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 3 May 2023 09:02:14 UTC