Webrtc-pc: canTrickleIceCandidiates question

[fippo]

spawned by this question

Is there a way to set an initial value for canTrickleIceCandidiates? Basically a "I know what I am doing" which will make the code shown on mdn signal a trickle-offer.

Arguably such code could simply ignore canTrickleIceCandidiates so I am not sure if not being able to set an initial value is a serious concern.

[alvestrand]

It would seem to kind of break the model of "all information about the remote partner is carried in the remote offer". My immediate reaction is that such piecemeal knowledge of the other party's capabilities should be a WebRTC-NG feature, not something we shoehorn in as an exception to the offer/answer model.

[alvestrand]

(you can get the same effect - a full-trickle offer - by munging the SDP before sending it to the remote side)

[cdh4u]

When you call createOffer(), the returned SDP will not contain any candidates. They will come later. So, as said above, you can wait for the candidates before you send the offer to the remote side.

But, the way the text in the JSEP draft is written is that you can read the canTrickleIceCandidiates property in order to find out whether the remote party supports trickle also when creating an initial offer - before you have received any SDP from the remote party. But, the text says that the canTrickleIceCandidiates property value is NULL before you call setRemoteDescription(), so even if the browser somehow knows whether the remote peer supports trickle the canTrickleIceCandidiates property will not indicate that (as the value is NULL).

[taylor-b]

Is there a way to set an initial value for canTrickleIceCandidiates? Basically a "I know what I am doing" which will make the code shown on mdn signal a trickle-offer.

I don't understand, why can't you just modify the code slightly?

if (pc.canTrickleIceCandidates || iKnowWhatImDoing) {
  return pc.localDescription;
}

Making the value settable seems pointless to me, and will just create a bunch of additional complexity (What if it's set to true but the remote answer indicates otherwise? How do the application-set values interact with rollbacks? etc.).

[cdh4u]

Taylor, my question is how canTrickleIceCandidates can be used when creating the initial offer. According to JSEP, the value is NULL until the remote SDP has been received and setRemoteDescription() has been called.

[fippo]

@taylor-b sure you can modify your code. But if you know your peer does not support trickle you don't need canTrickleIceCandidates at all. So 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).

(What if it's set to true but the remote answer indicates otherwise? How do the application-set values interact with rollbacks? etc.).

What if you call SRD, onicecandidate fires, you rollback? Now you sent the ice candidate already... or what happens with pranswer?
This property seem add much complexity for very little gain.

[alvestrand]

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

[taylor-b]

@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;
else
    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.

[fippo]

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.

[cdh4u]

I have created a JSEP issue for this:

https://github.com/rtcweb-wg/jsep/issues/848

[taylor-b]

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 (if the first endpoint already disconnected by the time they're received). 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?

[alvestrand]

Remaining issue is in JSEP. We'd like to avoid complexifying API surface for corner case, so closing.