You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If start() is called again but the value of remoteParameters has changed, local candidates are kept, remote candidates are flushed, candidate pairs are flushed and state transitions to new.
....
If start() is called again with new values of remoteParameters, local candidates are flushed, remote candidates are flushed, candidate pairs are flushed and state transitions to new.
leaves me scratching my head about what the difference is between "with new values of remoteParameters" and "the value of remoteParameters has changed".
The difference in result is whether or not local candidates are flushed. Should the "remoteParameters" in 9 be "local parameters"?
The text was updated successfully, but these errors were encountered:
I think this is an artifact of the copy-and-paste from ORTC's RTCIceTransport. In ORTC, start also takes an RTCIceGatherer and steps 8 & 9 specify what happens if the gatherer changes (i.e., flush local candidates).
So I think the right course of action is to remove steps 8 & 9 from start.
In ORTC, step 8 has the same RTCIceGatherer, but step 9 has a new one (implying a new generation).
In WebRTC-ICE what are the circumstances in which an ICE restart can occur without creating a new RTCIceTransport? Does calling gather again ever result in a new generation?
The following text:
....
leaves me scratching my head about what the difference is between "with new values of remoteParameters" and "the value of remoteParameters has changed".
The difference in result is whether or not local candidates are flushed. Should the "remoteParameters" in 9 be "local parameters"?
The text was updated successfully, but these errors were encountered: