[MMUSIC] Comments on draft-ietf-mmusic-trickle-ice-01
Rajmohan Banavi <rajmohanbanavi@gmail.com> Thu, 18 September 2014 06:33 UTC
Return-Path: <rajmohanbanavi@gmail.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 3E1A41A701F for <mmusic@ietfa.amsl.com>; Wed, 17 Sep 2014 23:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 xokaQgVRrtcW for <mmusic@ietfa.amsl.com>; Wed, 17 Sep 2014 23:33:27 -0700 (PDT)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA701A701B for <mmusic@ietf.org>; Wed, 17 Sep 2014 23:33:25 -0700 (PDT)
Received: by mail-lb0-f178.google.com with SMTP id c11so499426lbj.9 for <mmusic@ietf.org>; Wed, 17 Sep 2014 23:33:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=rkt3SVwbtYvTiFy0TT2ZC94iCKGV9sDaFxq6FyF1xEg=; b=t3TgkHbFhLCaABjzyCPvgp1H2dKJlJcM49tOVJacT0O+z2tl4l3zBVIdlTTE2R3gFD 9h3xlXauql2fiCJDfmjEVVMnnAI010Ut537gwIzEsK8j7p/HXp1LxysFrZSi4SZDM77i l/b1hxMWnEb4xRikI0dkRCkhtgG+gd1RQHXOquTcrmOjQYEwl2hE46glCKC6Vue9LTNL Zub+b0hxUT834YimvAdPmnBwz7TrHpOaX6N70/EhzKBCPUdVulqv+DPZhsw2PoouOA6q j05IXH//VJlKcdIfrKFBj7/DF0QZFmbkMDAFBULA+iL/HDo62c1KQqJ2PQqGb4pvQ2dZ 5iKg==
MIME-Version: 1.0
X-Received: by 10.112.62.200 with SMTP id a8mr2073522lbs.34.1411022003599; Wed, 17 Sep 2014 23:33:23 -0700 (PDT)
Received: by 10.152.210.103 with HTTP; Wed, 17 Sep 2014 23:33:23 -0700 (PDT)
Date: Thu, 18 Sep 2014 12:03:23 +0530
Message-ID: <CAJWm+fGZtZDyQ1bDiSrvdnez7_hJh28d6r5nW+uORrnJu6018Q@mail.gmail.com>
From: Rajmohan Banavi <rajmohanbanavi@gmail.com>
To: mmusic@ietf.org
Content-Type: multipart/alternative; boundary="001a11c3c5a04b7d770503512978"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/DxHkUlsE7lRwz45IljTGcwE9NDs
Cc: draft-ietf-mmusic-trickle-ice@tools.ietf.org
Subject: [MMUSIC] Comments on draft-ietf-mmusic-trickle-ice-01
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: <http://www.ietf.org/mail-archive/web/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: Thu, 18 Sep 2014 06:33:29 -0000
Comments on draft-ietf-mmusic-trickle-ice-01 - "Sec 4 Determining Support for Trickle ICE" - "According to [RFC5245] every time an agent supporting trickle ICE generates an offer or an answer,". Need to be reworded as RFC 5245 has no idea of trickle "According to [RFC5245] every time an agent supporting an extension generates an offer or answer, it must include an identification token in the ice-options attribute. Accordingly, an agent supporting trickle ICE must include the "trickle" token in the ice-options attribute." - Trivial typo in sec 1 Introduction. "gathering, candidates" ---> "gathering candidates". - Sec 5 Paragraph 5: Fallback must be to Half Trickle rather than vanilla ICE Prior to actually sending an initial offer, agents MAY verify if the remote party supports trickle ICE, where such mechanisms actually exist. If absence of such support is confirmed agents MUST fall back to using vanilla ICE or abandon the entire session. If it is not possible to determine if the remote party support trickle ice, then the agent must make use of Half Trickle mechanism described in sec 4.1. - Sec 8.1 "Check List and Timer State Updates" - there is something wrong here in this paragraph. Why would a vanilla ICE agent set the state of a check list to Failed if the pairs in the check list are in succeeded state (bullet 1)? Further, it says that "if the following two conditions are satisfied". Is it either one of the two conditions? Good idea to provide a reference to RFC 5245 (sec 7.1.3.3), since we are describing the operation of vanilla ICE. - Trivial type. Sec 9.3 - "Announcing End of Candidates". Duplication of sentence - During implementation, one of the issues that surfaced was regarding the check list timer. RFC 5245 Sec 5.8 "Scheduling Checks" mentions that if there is no such pair, "Terminate the timer for that check list". This is obviously not going to work with trickled ice candidates as the candidate pairs list will keep filling up incrementally. So for trickled ice, the conditions for stopping of the check list timer must be changed. Probably the checklist timer must not be stopped until the checklist moves to completed or Failed state. Cheers, Rajmohan
- [MMUSIC] Comments on draft-ietf-mmusic-trickle-ic… Rajmohan Banavi
- Re: [MMUSIC] Comments on draft-ietf-mmusic-trickl… Rajmohan Banavi