* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ice Status Pages

Interactive Connectivity Establishment (Active WG)
Art Area: Barry Leiba, Adam Roach, Alexey Melnikov | 2015-Oct-06 —  

2020-01-25 charter

Interactive Connectivity Establishment (ice)


 Current Status: Active

     Ari Keränen <ari.keranen@ericsson.com>

 Applications and Real-Time Area Directors:
     Barry Leiba <barryleiba@computer.org>
     Alexey Melnikov <aamelnikov@fastmail.fm>
     Adam Roach <adam@nostrum.com>

 Applications and Real-Time Area Advisor:
     Adam Roach <adam@nostrum.com>

 Tech Advisor:
     Martin Stiemerling <mls.ietf@gmail.com>

 Mailing Lists:
     General Discussion: ice@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/ice
     Archive:            https://mailarchive.ietf.org/arch/browse/ice/

Description of Working Group:

  Interactive Connectivity Establishment (ICE) is at the same time a NAT traversal technique, a multihomed address selection technique, and a dual stack address selection technique that works by including multiple IP addresses and ports in both the request and response messages of a connectivity establishment transaction. It makes no assumptions regarding network topology on the local or remote side.

  Interactive Connectivity Establishment was published as RFC 5245 in April 2010. Until recently the protocol had seen rather limited deployment. This situation has changed drastically as ICE is mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web. ICE was originally defined for the Offer-Answer (RFC 3264) protocol used by SIP (RFC 3261). Later XMPP (XEP-0176), RTSP (draft-ietf-mmusic-rtsp-nat), RTCWeb (draft-ietf-rtcweb-jsep) and other realtime media establishment protocols have used the protocol. ICE is also used by non-realtime media protocols, like HIP (RFC 5770) and RELOAD (RFC 6940).

  The goal of the ICE Working Group is to consolidate the various initiatives to update and improve ICE, and to help ensure suitability and consistency in the environments ICE operates in. Current work in this area includes an updated version of the ICE RFC (ICEbis), Trickle ICE and dualstack/multihomed fairness. This work will make ICE more flexible, robust and more suitable for changing mobile environments without major changes to the original ICE RFC. The ICE workgroup will consider new work items that follow this pattern.  The core ICE work will offer guidance to help minimize the unintentional exposure of IP addresses.

  ICE is an application controlled protocol that leverages a set of network defined protocols. The STUN (RFC 5389), TURN (RFC 5766) and related protocol work done in the TRAM working group must be closely synchronized with the work in this working group. To avoid interoperability issues and unwanted behavior it is desired to increase the interaction with other working groups dealing with network protocols closer to the wire. Example of such work may be, but not limited to: issues regarding multi-homing, multi subnet and prefixes, QoS, transport selection and congestion control. From the application side, the users of ICE, there is a need to make sure what is specified is actually usable. Getting input from the application working groups will be helpful (RTCWEB, HIP, MMUSIC, P2PSIP).

Goals and Milestones:
  May 2019 - Submit ICE Patience as Proposed Standard
  Done     - Submit Dual-stack Fairness with ICE as Proposed Standard
  Done     - Submit a revision of ICE (RFC 5245) as Proposed Standard  (draft-ietf-mmusic-ice-sip-sdp remains in MMUSIC)
  Done     - Submit Trickle ICE as Proposed Standard  (draft-ietf-mmusic-trickle-ice-sip remains in MMUSIC)

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/ice/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -