Re: [MMUSIC] [Ice] Updated charter

"Ben Campbell" <> Thu, 24 September 2015 15:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A1E9F1B29B1; Thu, 24 Sep 2015 08:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 270jI0ZGT9Lj; Thu, 24 Sep 2015 08:12:05 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB5471AD35B; Thu, 24 Sep 2015 08:12:05 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.15.2/8.14.9) with ESMTPSA id t8OFBqFd016058 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 24 Sep 2015 10:12:02 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
To: mmusic <>,,
Date: Thu, 24 Sep 2015 11:11:51 -0400
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.2r5107)
Archived-At: <>
Subject: Re: [MMUSIC] [Ice] Updated charter
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Sep 2015 15:12:07 -0000

[Oops, forgot the ICE list. Sorry for the repeat]

Hi Everyone,

I put the latest charter text and milestones from gitbub into the 
datatracker at . I 
plan to put this into IESG internal review, and on the next IESG 

  I know there's still a conversation going on about where to put the 
SDP bits. Please continue that conversation; hopefully we can close on 
it before the telechat.



On 22 Sep 2015, at 13:51, Pal Martinsen (palmarti) wrote:

>> On 22 Sep 2015, at 19:38, Ben Campbell <> wrote:
>> Hi,
>> If we hope to have ICE approved as a working group in time for 
>> Yokohama, we would need to start the IESG internal review by this 
>> Thursday. IMO, this language is about right. I think there's still an 
>> open issue about where the SDP bit lives. Can we close on that?
> I think the arguments can be summarised as follows.
> - Keeping SDP in MMUSIC helps ICE focus on core ICE things
> - MMUSIC has a lot of SDP knowledge needed to get things right
> I support keeping ICE in ICE and SDP in MMUSIC.
> .-.
> Pål-Erik
>> Thanks!
>> Ben.
>> On 16 Sep 2015, at 7:17, Pal Martinsen (palmarti) wrote:
>>> Hi,
>>> Based on list discussion the charter is now updated.
>>> For the github draft enthusiasts out there the pull request can be 
>>> found at:
>>> —————— Start —————-
>>> Charter for Working Group
>>> Interactive Connectivity Establishment was published as RFC 5245 in 
>>> April 2010. Until recently the protocol had seen rather limited 
>>> deployment. ICE was slow to achieve widespread adoption, as other 
>>> mechanisms were already being used by the VoIP industry. 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.
>>> 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 
>>> a multiplicity of IP addresses and ports in both the request and 
>>> response messages of a connectivity establishment transaction.  The 
>>> IP addresses and ports provided by each side are paired and tested 
>>> by peer-to-peer connectivity checks until one of these pair is 
>>> selected to transport data. ICE follows the end to end principle 
>>> where the clients themselves discovers, test and choose the network 
>>> path to use. It makes no assumptions regarding network topology on 
>>> the local or remote side.
>>> 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 protocol 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 ICE to make it more suitable for the WebRTC 
>>> environment but also to all the current usages of ICE. Current work 
>>> in this area includes an updated version of the ICE RFC (ICEbis), 
>>> Trickle ICE and dualstack/multihomed fairness. It is worth noticing 
>>> that 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.
>>> 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).
>>> Milestones
>>> - Jan 2016 Submit Dual-stack Fairness with ICE as Proposed Standard
>>> draft-ietf-mmusic-ice-dualstack-fairness
>>> - Apr 2016 Submit a revision of ICE (RFC 5245) as Proposed Standard
>>> draft-ietf-mmusic-rfc5245bis
>>> (draft-ietf-mmusic-ice-sip-sdp remains in MMUSIC)
>>> - Jan 2016 Submit Trickle ICE as Proposed Standard
>>> draft-ietf-mmusic-trickle-ice
>>> (draft-ietf-mmusic-trickle-ice-sip remains in MMUSIC)
>>> ————— STOP ———————
>>> .-.
>>> Pål-Erik
>>> _______________________________________________
>>> Ice mailing list
> _______________________________________________
> mmusic mailing list