This issue relates to how ORTC API indicates that there are no more local ICE candidates available "for now".

ORTC API provides a "icegatheringstatechange" event so that a transition of RTCIceGatheringState to "completed" indicates that "The ICE transport has completed gathering and is currently idle." Since "Events such as adding a new interface or a new TURN server will cause the state to go back to gathering", "completed" is not a terminal state.

Note also that in ORTC API, we allow candidate===null. In Section 3.15.1:

"If candidate is null, there are no additional candidates for now."

Just as with RTCIceGatheringState, the "for now" implies that null candidates events can occur more than once (e.g. a null candidate does NOT necessarily imply "end of candidates").

A question has arisen as to whether this is compatible with WebRTC 1.0 (see: https://dev.w3.org/2011/webrtc/editor/webrtc.html) or not.

On the one hand, WebRTC 1.0 Section 4.3.1 says:

"The gathering process is done.

Set connection's ice gathering state to completed and let newCandidate be null."

This would seem to imply that entering the "completed" state and setting newCandidate to null implies "end of candidates".

On the other hand, Section 4.8.2 says:

dictionary RTCPeerConnectionIceEventInit : EventInit {
RTCIceCandidate candidate;
};

[ Constructor (DOMString type, RTCPeerConnectionIceEventInit eventInitDict)]
interface RTCPeerConnectionIceEvent : Event {
readonly attribute RTCIceCandidate candidate;
};

Since candidate is NOT nullable, this would seem to imply that a null candidate cannot be provided.

Other references discussing the behavior in WebRTC 1.0 (actual vs. specified):
versatica/JsSIP#72

Questions:

a. Should ORTC support a null candidate, or should candidate be non-nullable? If ORTC should support a null candidate, how is this to be interpreted?

b. If ORTC does not support a null candidate, are there implications for the shim of relying solely on icegatheringstatechange and RTCIceGatheringState?