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

> @fippo Could it be added to the spec that WebRTC only supports ordered/lossless signaling?

Actually this is coming from [JSEP here](https://www.rfc-editor.org/rfc/rfc8829.html#section-3.1):
> These issues are left entirely up to the application; the application has complete control over which offers and answers get handed to the implementation, and when.

Can you give examples of standardized protocols that do *not* preserve message order? [XMPP](https://www.rfc-editor.org/rfc/rfc6120#section-10.1) does (but notably only at a stream level, not between endpoints which is a known problem), [SIP has CSeq](https://www.rfc-editor.org/rfc/rfc3261#section-12.2.1.1).
If you think that your signaling protocol doesn't require order, how do you deal with a subsequent offer with 5 m-lines being processed ahead of the original one with 2 m-lines? That may work but applying the two m-line offer will fail since it looks (from an API PoV) like you are removing m-lines which is a no-no.

-- 
GitHub Notification of comment by fippo
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2519#issuecomment-1532608762 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 08:04:34 UTC