This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20808 - "Trickle ICE" unspecified
Summary: "Trickle ICE" unspecified
Status: RESOLVED FIXED
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: WebRTC API (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Web RTC Working Group
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-29 18:09 UTC by Matthew Kaufman
Modified: 2014-10-28 18:39 UTC (History)
2 users (show)

See Also:

Attachments

Description Matthew Kaufman 2013-01-29 18:09:33 UTC 
In the WebRTC draft, Section 4.3.2.2, there is a method addIceCandidate() on the RTCPeerConnection object. From the description, is appears to be possible to add ICE candidates “late”, that is, after the initial offer/answer exchange. In addition, it is expected to be possible to start with NO ICE candidates. This concept is known as “trickle ICE”. There is no specification within this document, nor any IETF RFC referenced by this document describing how “trickle ICE” should be implemented within the RFC3264 (SDP offer/answer) offer/answer framework, nor does RFC 5245 (ICE) allow for the addition of ICE candidates after the ICE state machine reaches either the Failed or Succeeded state. It is also clear that starting with no candidates should cause the ICE state machine to immediately reach the Failed state.
Comment 1 Harald Alvestrand 2014-10-28 18:39:57 UTC 
We now have a normative dependency on JSEP, which has a normative dependency on trickle-ice.

Closing as "the rest is the IETF's problem".