- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Fri, 12 Jan 2018 22:40:15 +0000
- To: public-webrtc-logs@w3.org
If I understand correctly, the rollback/PR-answer cases you're talking about are when a "trickle" remote description is applied, candidates are trickled, and then later a non-trickle remote description is applied. But this would indicate that the remote endpoint is actually changing. So what happens to the candidates trickled? I'd assume the signaling server would have sent them to the first endpoint, or ignored them. I don't see how this relates to `canTrickleIceCandidates` though; sorry if I'm missing your point. Anyway, getting back to the main topic: My general feeling is that adding complexity to the spec so that JS code can stick a value in the PeerConnection just to read it back later seems pointless. Can't this behavior be shimmed easily in JS if desired? -- GitHub Notification of comment by taylor-b Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1721#issuecomment-357374271 using your GitHub account
Received on Friday, 12 January 2018 22:40:28 UTC