IETF Logo Mail Archive

Re: [rtcweb] Filling in details on "trickle ICE"

Matthew Kaufman <matthew.kaufman@skype.net> Wed, 17 October 2012 20:41 UTC

Return-Path: <matthew.kaufman@skype.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B6921F86F0 for <rtcweb@ietfa.amsl.com>; Wed, 17 Oct 2012 13:41:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5y8dFpCHV02 for <rtcweb@ietfa.amsl.com>; Wed, 17 Oct 2012 13:41:29 -0700 (PDT)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id AEC1821F86F7 for <rtcweb@ietf.org>; Wed, 17 Oct 2012 13:41:28 -0700 (PDT)
Received: from BY2FFO11FD014.protection.gbl (10.1.15.203) by BY2FFO11HUB037.protection.gbl (10.1.14.120) with Microsoft SMTP Server (TLS) id 15.0.516.0; Wed, 17 Oct 2012 20:42:28 +0000
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Wed, 17 Oct 2012 20:42:28 +0000
Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Wed, 17 Oct 2012 20:40:31 +0000
From: Matthew Kaufman <matthew.kaufman@skype.net>
To: Justin Uberti <juberti@google.com>, Emil Ivov <emcho@jitsi.org>
Thread-Topic: [rtcweb] Filling in details on "trickle ICE"
Thread-Index: AQHNggtYU4RJsiahn0ePX6kIvBvYA5eG0euAgAzxmgCAAFJqAIAqM0Zw
Date: Wed, 17 Oct 2012 20:40:30 +0000
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A484160ED5CD@tk5ex14mbxc272.redmond.corp.microsoft.com>
References: <CABcZeBMzgAs=hK38hCjS7t6yLjkTydS2TQUb8R3rBbRKGakVdQ@mail.gmail.com> <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> <CAOJ7v-00BAp8M0_+FJGuXqAdXQ=e=MRN_L_6_CmkQWX-Gy5JAg@mail.gmail.com>
In-Reply-To: <CAOJ7v-00BAp8M0_+FJGuXqAdXQ=e=MRN_L_6_CmkQWX-Gy5JAg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.76]
Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A484160ED5CDtk5ex14mbxc272r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(5343635001)(4396001)(8716001)(16826001)(47446002)(15202345001)(74502001)(4196001)(5343655001)(16696001)(49866001)(47976001)(16406001)(512874001)(3846001)(46102001)(2666001)(31966008)(33656001)(42186003)(20776001)(1076001)(44976002)(47736001)(50986001)(74662001)(51856001)(316001)(3556001)(3746001); DIR:OUT; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0637FCE711
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Filling in details on "trickle ICE"
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Oct 2012 20:41:29 -0000

A few questions raised by this thread:

1)      Did the discussion about “trickle ICE” actually turn into an I-D for (I suppose) MMUSIC to look at?

2)      Are we seriously considering defining the allowed SDP for RTCWEB/WEBRTC by referencing an I-D and not an RFC, or are we going to delay defining the allowed SDP until trickle ICE is in an RFC, or are we going to drop trickle ICE from RTCWEB 1.0?

3)      Is IETF or W3C the right venue for defining the specific SDP that is permitted in the JSEP “setLocalDescription” and “setRemoteDescription” calls (and what errors will be reported when disallowed SDP is passed to those APIs)?

4)      How does trickle ICE work without “relaxing” RFC3264 O/A? It seems like you really want to be able to trickle via updated offers that may be generated prior to the corresponding answer or reject?

Sorry if some of these seem like the answer is obvious, but I think we need to get pretty specific before we start asking major browser vendors to bake some of this logic into mission-critical software.

Matthew Kaufman

v2.23.0 | Report a Bug | By Email