IETF Logo Mail Archive

Re: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00

worley@ariadne.com (Dale R. Worley) Thu, 18 April 2013 18:33 UTC

Return-Path: <worley@shell01.TheWorld.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC94C21F9356 for <mmusic@ietfa.amsl.com>; Thu, 18 Apr 2013 11:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.605
X-Spam-Level:
X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZdSMgc-uUyl for <mmusic@ietfa.amsl.com>; Thu, 18 Apr 2013 11:33:54 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 910BC21F92E9 for <mmusic@ietf.org>; Thu, 18 Apr 2013 11:33:53 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r3IIXHAg014536 for <mmusic@ietf.org>; Thu, 18 Apr 2013 14:33:20 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r3IIXHhI2952170 for <mmusic@ietf.org>; Thu, 18 Apr 2013 14:33:17 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3IIXHcr2960017; Thu, 18 Apr 2013 14:33:17 -0400 (EDT)
Date: Thu, 18 Apr 2013 14:33:17 -0400
Message-Id: <201304181833.r3IIXHcr2960017@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: mmusic@ietf.org
In-reply-to: <9F33F40F6F2CD847824537F3C4E37DDF0E6B75D5@MCHP04MSX.global-ad.net> (andrew.hutton@siemens-enterprise.com)
References: <516C071B.5050204@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6B227E@MCHP04MSX.global-ad.net> <201304172107.r3HL7Fdt2897721@shell01.TheWorld.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6B75D5@MCHP04MSX.global-ad.net>
Subject: Re: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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 Apr 2013 18:33:55 -0000

> From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
> 
> [AndyH] This is covered in the existing bundle draft which states
> that connectivity checks are performed on the bundle group rather
> than each m= line. 

What I see in draft-ietf-mmusic-sdp-bundle-negotiation-03 is

   8.3.  Candidates

   Once it is known that both endpoints support, and accept to use, the
   "BUNDLE" grouping extension, ICE connectivity checks and keep-alives
   only needs to be performed for the whole "BUNDLE" group, instead of
   for each individual "m=" line associated with the group.

which is more a sketch than a description of the algorithm.

I suppose what is bothering me is that
draft-hutton-mmusic-bundled-ice-candidates modifies the procedures of
draft-ietf-mmusic-sdp-bundle-negotiation, and
draft-ietf-mmusic-sdp-bundle-negotiation modifies the procedures RFC
5245.  Neither modification is large, but stacking two
weakly-specified modifications together makes me worry that nobody has
a clear understanding of what the combined procedure really is, and it
is hard to examine the combined procedure for unintended consequences.

Dale

v2.23.0 | Report a Bug | By Email