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
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").
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?
The text was updated successfully, but these errors were encountered:
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#138w3c#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#142w3c#144
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?
The text was updated successfully, but these errors were encountered: