Re: [webrtc-pc] canTrickleIceCandidiates question

@cdh4u, I was responding to @henbos. I agree with you that `canTrickleIceCandidates` can't be used when creating the initial offer.

> I assume that this property is designed for library code that needs to deal with both trickle peers and non-trickle peers (and also peers that may support trickle and where discovery is needed).

Then that code would need to send a half trickle initial offer, and use `canTrickleIceCandidates` on subsequent offers/answers. Right?

> What if you call SRD, onicecandidate fires, you rollback?

I'd assume `canTrickleIceCandidates` goes back to `null`. I don't see how the candidate changes things.

> or what happens with pranswer?

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`.

> This property seem add much complexity for very little gain.

As far as I understand, it's basically:

if (!remoteDescription)
    return null;
    return remoteDescription.sdp.includes("a=ice-options:trickle");

Sure, it could be done pretty easily by parsing the SDP in JS, but I don't think it adds much complexity.

> If this makes sense, it makes sense as a parameter to CreateOffer, not as a modified PC state.

I'm not following; what would `createOffer` do if you specify `canTrickleIceCandidates=false`? Not resolve the promise until all candidates are gathered? I don't think that's a good idea; what if STUN requests to gather a specific candidate are timing out? Then the entire offer will be delayed. I think it's better to let the application decide the cutoff point for sending the offer.

GitHub Notification of comment by taylor-b
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 9 January 2018 22:27:43 UTC