- From: Sean DuBois via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Apr 2020 19:46:43 +0000
- To: public-webrtc-logs@w3.org
@jan-ivar This isn't a bug I am having personally. I have an Open Source project [Pion](https://github.com/pion/webrtc) and I see lots of developers struggling with this. Many of the people coming to the project are using WebRTC for the first time. > Does your signaling guarantee order? This is going to bite people. I don't think I have seen a WebRTC tutorial that calls this out explicitly. I think we are asking too much of new developers to deal with this. > covers up signs of browser and/or application bugs (go ★ it) IMO not a bug. You are making WebRTC implementations more complicated with this requirement. If the ICE agent can just emit candidates when ready things would be better. You are now forcing more logic for the agent to be aware of the PeerConnection state. > defeats Trickle ICE in some cases, slowing down connection From reading the issue it sounds like this assert is the actual thing causing the issue. If we didn't have this requirement people could emit candidates at any time. The slowing down of trickle ICE (and extra logic) has happened because of the SetRemoteDescription requirement. > most queuing I've seen only works on initial negotiation This is all I am looking for! I think after the initial negotiation all the logic stays the same. ----- I would just love to see this sharp edge removed (and I am still not convinced it is going to cost anything). If every user has to go look up this detail that is a lot of man hours wasted. -- GitHub Notification of comment by Sean-Der Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2519#issuecomment-622067869 using your GitHub account
Received on Thursday, 30 April 2020 19:46:44 UTC