docfaraday
docfaraday
Whoops, bad example. You _can_ end up in this situation when adding a new transceiver (in sLD) that isn't bundled. The old transport would not transition back to new; adding...
Of course, the spec saying "An ICE restart for an existing [RTCRtpTransceiver](https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver) will be represented by an existing [RTCIceTransport](https://w3c.github.io/webrtc-pc/#dom-rtcicetransport)" raises the question "What is the state of that transport while...
> What's the model that forces you to assume two underlying transports? https://datatracker.ietf.org/doc/html/rfc8445#section-9 doesn't seem to assume that the transport is changed - the RTCIceTransport represents "the ICE transport layer...
> I think the gathering state should never be "new" again. You can create an offer with iceRestart but that is only provisional and does not lead to the (re)creation...
I think we might be missing the steps that add an a=end-of-candidates to the local description.
Also, it looks like we'll fire duplicate null candidates here. We should only fire the null candidate if the RTCPeerConnection.iceGatheringState just transitioned to "complete".
> > I think we might be missing the steps that add an a=end-of-candidates to the local description. > > Isn't that covered by JSEP? This spec generally doesn't get...
So, the more I think about this, the more it seems appropriate to defer the updates to RTCPeerConnection.connectionState/iceConnectionState until the answer is set. A local offer that creates a new...
Furthermore, I think maybe we need to ignore RTCDtls/IceTransports in "new". Suppose the following occurs: 1. ICE is in checking from a previous negotiation. 2. We do a sLD(offer) that...
It doesn't make a whole lot of sense to put an ssrc attribute in an inactive m-section, but there isn't much harm in doing so either. If we really want...