[MMUSIC] Fwd: [dispatch] New version of the proposed charter

Flemming Andreasen <fandreas@cisco.com> Fri, 04 September 2015 12:18 UTC

Return-Path: <fandreas@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821001A909C for <mmusic@ietfa.amsl.com>; Fri, 4 Sep 2015 05:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3hW2gIpnj-V for <mmusic@ietfa.amsl.com>; Fri, 4 Sep 2015 05:18:13 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452401A1B1B for <mmusic@ietf.org>; Fri, 4 Sep 2015 05:16:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11387; q=dns/txt; s=iport; t=1441368998; x=1442578598; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=6ayagKkZSL2EaCmnJsRFh7yUQsUdxbqc+Kxs2UsovEM=; b=IunTGeKUhPjtrS5poaUI5Fcqcs6A2zJCTQdipbfUGR1XyfRun2Mtfza8 4fn7wfFX6N5b04vQ4/8sRGPpr9oYQ9Biw0qO7P3ZW9XVLzXyzItkj6s7R dasjQwT6qbrwRwImZHDfX5SfTNrukFoyerc1zWvPxQhhUuqwGMkrzKHGg k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B3AgBKi+lV/49dJa1dgyFUabRUiQgBCYFtAQmFMUoCgTs4FAEBAQEBAQGBCoQjAQEBBAEBAWsKERwDAQIKDAoPCQMCAQIBFSYCCAYNBgIBAYgqDcpXAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4ZzhHuCQIFoCgYCAT8YBgSEIgWHMYsAgyCFB4dwgUpGg2yCfIlDiDUmgg8dgXAiMwGIAoFIAQEB
X-IronPort-AV: E=Sophos; i="5.17,469,1437436800"; d="scan'208,217"; a="26226504"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP; 04 Sep 2015 12:16:06 +0000
Received: from [10.98.149.195] (bxb-fandreas-8812.cisco.com [10.98.149.195]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t84CG5Ub015046 for <mmusic@ietf.org>; Fri, 4 Sep 2015 12:16:06 GMT
References: <55E6E9AE.7080400@acm.org>
To: mmusic <mmusic@ietf.org>
From: Flemming Andreasen <fandreas@cisco.com>
X-Forwarded-Message-Id: <55E6E9AE.7080400@acm.org>
Message-ID: <55E98BA5.9070005@cisco.com>
Date: Fri, 04 Sep 2015 08:16:37 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55E6E9AE.7080400@acm.org>
Content-Type: multipart/alternative; boundary="------------000402070406040309060609"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/puMBWnmCtPWXSIVypyFoW2G2O0U>
Subject: [MMUSIC] Fwd: [dispatch] New version of the proposed charter
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2015 12:18:16 -0000

[Forwarding just to MMUSIC to account for mail filters]


-------- Forwarded Message --------
Subject: 	[dispatch] New version of the proposed charter
Date: 	Wed, 2 Sep 2015 06:21:02 -0600
From: 	Marc Petit-Huguenin <petithug@acm.org>
To: 	ice@ietf.org
CC: 	DISPATCH list <dispatch@ietf.org>, mmusic@ietf.org <mmusic@ietf.org>
Followup-To: 	ice@ietf.org



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Please find below a new version of the proposed charter, trying to take in account all the comments so far.

The discussions are taking place in the ice mailing-list, please do not cross-post.

Thanks.

- ---------------------------------------------------------------------------------

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. 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 synchronised with the work in this working group. Synching with other network related working groups to make sure existing mechanisms like QoS, congestion control and other networking mechanisms still work would be essential if we want to improve how ICE works (MIF, TAPS, TSWG, HOMENET, etc...). 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 essential (RTCWEB, HIP, MMUSIC, P2PSIP).

Milestones

     Jun 2016 Submit Dual-stack Fairness with ICE as Proposed Standard
     Apr 2016 Submit a revision of ICE (RFC 5245) as Proposed Standard
     Jan 2016 Submit Trickle ICE as Proposed Standard

- -- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV5umuAAoJECnERZXWan7Ec9AQANIImmE2JC98QoBfq5MEGa01
w8gfLivIXT/Vx5BW3sGHQTv24dznMbwhMGKGwlizGYU0olgxGqc2VasogmvNrD5J
9PwMOHPzPxJe5rIVHMseiN8mk8DtPKVPmDoBZZt1T9ehP2yajYjRys9uFKwZiqhx
+WJF6rxl/eRxmV6oF41m4VSs/UiN7inTMc8mnKvfi6TLdpInELiKHgnb6VxeW1N+
N6JU7TnG4MVYzUVTLPh5Di8BTCWVthOTqFEwJaGw8gcNA8ATDtx+XbTR2dAv3u0x
WLzNep25LRcukn7UyPQaCZWaptIlqJJzzPit3w+oCuJlc5KTRv/SoODJuR1j4pS9
Lxj0ShAMwSCSfFg3MWIUP19+iE7QZcibh9WWHCY3LZWzOMD2uqLiIuH/OcJbwoIE
c7kcd/m9oOxU0NWYNUYBIhFWbX5fg/bIeW+D3uQN9P9HDscs2XpWlwsL1M6ad2mC
YtA0Mzd4E7PT18Q37eRcVcVeUBF+AF1gpqkUoBXKnZUTiUxIs8nORP9cLpywFaBz
JhjganbYvvgDbPS6gnCSlQbMDlofpTWygfA8FT1FJ94wolv2pcPIH09ofDRYO8zM
5fqZuDkD9BFCKCuFzm/hxyeZTaHDB0pfe+wLN5Eccll06G7pOcMjR/8Q4SiR1l3Q
LCNPefFKYJgT/SFpbL6k
=3YsX
-----END PGP SIGNATURE-----

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
.