- From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jan 2018 07:00:57 +0000
- To: public-webrtc-logs@w3.org
> Then that code would need to send a half trickle initial offer, and use canTrickleIceCandidates on subsequent offers/answers. Right? With bundle the peers opinion about support can apparently change. But trickle-ice-sip says this is determined ((here, last paragraph)[https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-08#section-5.4]) so yes. > I'd assume canTrickleIceCandidates goes back to null. I don't see how the candidate changes things. The candidate would be trickled. *hopefully* the peer would ignore it and use it when it later comes in the full description so there might be no harm. > You mean if a PR answer lacked support for trickle ICE but the final answer did, for example? Then I'd expect canTrickleIceCandidates to change from false to true. That is the more likely case but the less interesting one. In the other case you go null->true->false. You will end up trickling some candidates (its not quite clear to me to which peer but that is a question about pranswer). > Sure, it could be done pretty easily by parsing the SDP in JS, but I don't think it adds much complexity. Parsing it is easy. But the complexity of the application enabled by this is pretty high. Arguably so is the cost of removing it at this stage... > I'm not following; what would createOffer do if you specify canTrickleIceCandidates=false? Not resolve the promise until all candidates are gathered? No, it would set canTrickleIceCandidates after SLD (?). Pondering whether that would be specified as a legacy constraint... ;-) > I don't think that's a good idea; what if STUN requests to gather a specific candidate are timing out? The current MDN code is also affected by that. Ironically, non-trickle is much more complicated than trickle. -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1721#issuecomment-356517103 using your GitHub account
Received on Wednesday, 10 January 2018 07:00:59 UTC