Re: [webrtc-pc] canTrickleIceCandidiates question

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 using your GitHub account

Received on Friday, 12 January 2018 22:40:28 UTC