Ah, unlike comment 8 which said `pc2.onicecandidate in have-remote-offer null BOOOH!`, comment 9 actually says `pc2.onicecandidate null in have-local-offer BOOOH!` which is quite normal. I'll remove the `BOOOH!` there. But one problem remains with the comment 9 fiddle [updated with onicegatheringstatechange](https://jsfiddle.net/jib1/gjcms01p/55/): It looks like we're firing `"complete"` without ever having fired `"gathering"`, which the [spec](https://w3c.github.io/webrtc-pc/#rtcicetransport) indicates we should have done *"When the ICE Agent indicates that it began gathering"* which sans a state diagram clearly has to have happened before *"When the ICE Agent is finished gathering"*. That seems wrong. > Yeah, webrtc-pc says that whenever gathering transitions to complete for all ice transports, we fire this null candidate. I wonder if this should apply when we're rolling back to a state where there are no ICE transports at all? The ICE gathering state should be "new" in that case, probably? I think it's a stretch to say ice gathering is `"complete"` when it got aborted by its transport being rolled back and vaporized. After all, the [spec](https://w3c.github.io/webrtc-pc/#rtcicetransport) says: *"When the ICE Agent is finished gathering a generation of candidates for an RTCIceTransport, and those candidates have been surfaced to the application"*. I'd argue it wasn't allowed to finish in this case. [ICE](https://tools.ietf.org/html/rfc5245#section-5.7.4) seems supportive of this interpretation: *"ICE processing across all media streams also has a state associated with it. This state is equal to Running while ICE processing is under way. The state is Completed when ICE processing is complete and Failed if it failed without success."* But regardless of interpretation, I see no support anywhere for the behavior in comment 8 (without any SLD on pc2) and earlier, because the phrase *"and those candidates have been surfaced to the application"* above is a reference to [`[[EarlyCandidates]]`](https://w3c.github.io/webrtc-pc/#dfn-release-early-candidates), which means we must not ever fire `"complete"` before SLD(answer).
Bug 1629565 Comment 12 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Ah, unlike comment 8 which said `pc2.onicecandidate in have-remote-offer null BOOOH!`, comment 9 actually says `pc2.onicecandidate null in have-local-offer BOOOH!` which is quite normal. I'll remove the `BOOOH!` there. But one problem remains with the comment 9 fiddle [updated with onicegatheringstatechange](https://jsfiddle.net/jib1/gjcms01p/55/): It looks like we're firing `"complete"` without ever having fired `"gathering"`, which the [spec](https://w3c.github.io/webrtc-pc/#rtcicetransport) indicates we should have done *"When the ICE Agent indicates that it began gathering"* which sans a state diagram clearly has to have happened before *"When the ICE Agent is finished gathering"*. That seems wrong (in Firefox). > Yeah, webrtc-pc says that whenever gathering transitions to complete for all ice transports, we fire this null candidate. I wonder if this should apply when we're rolling back to a state where there are no ICE transports at all? The ICE gathering state should be "new" in that case, probably? I think it's a stretch to say ice gathering is `"complete"` when it got aborted by its transport being rolled back and vaporized. After all, the [spec](https://w3c.github.io/webrtc-pc/#rtcicetransport) says: *"When the ICE Agent is finished gathering a generation of candidates for an RTCIceTransport, and those candidates have been surfaced to the application"*. I'd argue it wasn't allowed to finish in this case. [ICE](https://tools.ietf.org/html/rfc5245#section-5.7.4) seems supportive of this interpretation: *"ICE processing across all media streams also has a state associated with it. This state is equal to Running while ICE processing is under way. The state is Completed when ICE processing is complete and Failed if it failed without success."* But regardless of interpretation, I see no support anywhere for the behavior in comment 8 (without any SLD on pc2) and earlier, because the phrase *"and those candidates have been surfaced to the application"* above is a reference to [`[[EarlyCandidates]]`](https://w3c.github.io/webrtc-pc/#dfn-release-early-candidates), which means we must not ever fire `"complete"` before SLD(answer).