Re: [webrtc-pc] Add pc.restartIce() method. (#2169)

> My question is this: Did we just restart ICE with obsolete credentials or obsolete candidates, or does the relevant candidate gathering happen at 3) and we are happy anyway?

It happens in 3). Does it matter that the credentials predate `restartIce` or are we happy? ๐Ÿ™‚

Also, `createOffer`/`createAnswer` have [special logic]( to rerun to pick up state changes like this. 

But I think what you're touching on is what happens if `restartIce()` is called outside of stable state?

> With restartIce(), are you happy that the ICE credentials are relatively new, even if they are older than the call to restartIce()?

As written, yes: Success = no ICE credentials match those *current* when `restartIce()` was called.ยน

This way, a remote restart = success as well.

> Let's say that the network interface changed and all existing candidates are invalid, so you call [restartIce()]

This would require a different definition: Success = candidates *generated* more recently than when `restartIce` was called. Maybe:

 Success = no ICE credentials match those *current* **or** ***pending*** when `restartIce()` was called?

Does that work? A remote offer would then satisfy the restart ONLY if it comes in *after* the call to `restartIce` (because otherwise it is the *pendingLocalDescription*).

> an enum with value "not-needed", "needed-when-stable" and "needed"

That might work, but I think looking at *pendingDescription* would have the same effect, and handle remote offers more efficiently.

<sub>1) I plan to update the PR to match Firefox as mentioned in to cache *currentLocalDescription* (as well as *pendingLocalDescription* if we decide to go that way) at time of call in [[RestartIce]].</sub>

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

Received on Wednesday, 10 July 2019 20:13:04 UTC