Null ICE candidate in WebRTC 1.0 and ORTC API #144

Closed
aboba opened this Issue Aug 6, 2014 · 0 comments

Projects

None yet

2 participants

@aboba
Contributor
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: http://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?

@robin-raymond robin-raymond added the 1.0 label Aug 8, 2014
@robin-raymond 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:
w3c#93

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

Clarified SST-MS capability issue noted in:
w3c#108

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

Changed ICE state diagram as noted in:
w3c#122

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

Changed definition of framerateScale and resolutionScale as noted in:
w3c#137

Substituted "muxId" for the "receiverId" as noted in:
w3c#138
w3c#140

Clarified the setting of track.kind as described in:
w3c#141

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

Addressed the "end of candidates" issues noted in:
w3c#142
w3c#144
4916cd5
@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