New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Null ICE candidate in WebRTC 1.0 and ORTC API #144

aboba opened this Issue Aug 6, 2014 · 0 comments


None yet
2 participants
Copy link

aboba commented Aug 6, 2014

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: 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):


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?

@robin-raymond robin-raymond added the 1.0 label Aug 8, 2014

robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Aug 19, 2014

Robin Raymond
Clarification of the ICE restart issue, as noted in:

Clarified onerror usage in sender and receiver objects, as noted in:

Clarified SST-MS capability issue noted in:

Clarification of send() and receive() usage as noted in:

Changed ICE state diagram as noted in:

Removed getParameters methods and changed send() method as noted in:

Changed definition of framerateScale and resolutionScale as noted in:

Substituted "muxId" for the "receiverId" as noted in:

Clarified the setting of track.kind as described in:

Added SSRC conflict event to the RTCRtpSender, as described in:

Addressed the "end of candidates" issues noted in:

@aboba aboba closed this Aug 19, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment