Re: [MMUSIC] BUNDLE TEXT: ICE Procedures (18.6)

Harald Alvestrand <harald@alvestrand.no> Tue, 18 June 2013 08:52 UTC

Return-Path: <harald@alvestrand.no>
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 98AA121F9A84 for <mmusic@ietfa.amsl.com>; Tue, 18 Jun 2013 01:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.498
X-Spam-Level:
X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 ODNL6fbGBeYe for <mmusic@ietfa.amsl.com>; Tue, 18 Jun 2013 01:52:08 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0586521F9A8F for <mmusic@ietf.org>; Tue, 18 Jun 2013 01:52:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 04B3039E0FA for <mmusic@ietf.org>; Tue, 18 Jun 2013 10:52:05 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2bT5TIAm2Ao for <mmusic@ietf.org>; Tue, 18 Jun 2013 10:52:04 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0F3B139E04C for <mmusic@ietf.org>; Tue, 18 Jun 2013 10:52:04 +0200 (CEST)
Message-ID: <51C01FB3.2040808@alvestrand.no>
Date: Tue, 18 Jun 2013 10:52:03 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C3AADE0@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3AADE0@ESESSMB209.ericsson.se>
Content-Type: multipart/alternative; boundary="------------020108030908070202030205"
Subject: Re: [MMUSIC] BUNDLE TEXT: ICE Procedures (18.6)
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: Tue, 18 Jun 2013 08:52:25 -0000

On 06/18/2013 08:56 AM, Christer Holmberg wrote:
>
> Hi,
>
> I did some updates (mostly editorial) to the BUNDLE ICE Procedures 
> section.
>
> So, when reviewing BUNDLE-04, for the ICE parts, please use the text 
> below as base :)
>
> Regards,
>
> Christer
>
> ----------------------------------
>
>
.... snipped stuff I have no issues with ....

> 8.3.  ICE Connectivity Checks
>
>    Once a BUNDLE address has been selected for the Offerer and the
>
>    Answerer, it is RECOMMENDED to perform ICE connectivity checks and
>
>    keep-alives [RFC5245] for the whole BUNDLE group, rather than for
>
>    each individual "m=" line in the BUNDLE group.
>

I have a bit of trouble parsing this last paragraph.

There are two possibilities:

- The offer/answer is incomplete, so we don't know whether BUNDLE will 
be turned on or not. (This can happen only in updates - you can't do ICE 
checks before choosing the BUNDLE address in the initial exchange, since 
you don't know the remote candidates)

- The offer/answer is complete, and both parties know the BUNDLE address

In the last state, it's impossible to do anything BUT check connectivity 
for the whole BUNDLE group; there is nothing else to check for. So 
RECOMMENDED doesn't make sense; it's not even a MUST, it's just the way 
things work.

In the first state, I think it should be RECOMMENDED to delay checking 
until you have completed the exchange, so that you know what the BUNDLE 
address is. But that's not what the words seem to say.

Could you clarify?

            Harald