[MMUSIC] ICE options: need new optional and/or required attributes?

Ari Keränen <ari.keranen@ericsson.com> Fri, 28 February 2014 15:58 UTC

Return-Path: <ari.keranen@ericsson.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 365FA1A083E for <mmusic@ietfa.amsl.com>; Fri, 28 Feb 2014 07:58:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 1nhFctxKyM6Y for <mmusic@ietfa.amsl.com>; Fri, 28 Feb 2014 07:58:50 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACE81A00DE for <mmusic@ietf.org>; Fri, 28 Feb 2014 07:58:49 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-b3-5310b2373fde
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id F7.F2.04249.732B0135; Fri, 28 Feb 2014 16:58:47 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.347.0; Fri, 28 Feb 2014 16:58:46 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id F06301101F3 for <mmusic@ietf.org>; Fri, 28 Feb 2014 17:58:46 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EE65356B2A for <mmusic@ietf.org>; Fri, 28 Feb 2014 17:58:41 +0200 (EET)
Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id ABC5156AEB for <mmusic@ietf.org>; Fri, 28 Feb 2014 17:58:41 +0200 (EET)
Message-ID: <5310B236.7050108@ericsson.com>
Date: Fri, 28 Feb 2014 17:58:46 +0200
From: Ari Keränen <ari.keranen@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: mmusic <mmusic@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupiluLIzCtJLcpLzFFi42KZGfG3Rtd8k0CwwY1vqhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsXpJ5kLdrJVLNw9ka2BsYe1i5GTQ0LARKL7+H92CFtM4sK9 9WxdjFwcQgJHGCUWPv/ABJIQEtjAKPH7qD1E4hKjxM+561khnMOMEm+vvmSBcPYySry+3sAC 0sIroC2xbcYBsB0sAqoSa1e3ge1gE7CXuDnhOpgtKpAs8WlRJyNEvaDEyZlPwHpFBGQk9m7a zAxiCws4S3zYdQMszixgK3FhznUoW15i+9s5zBB3q0lcPbeJGeJUVYmr/14xTmAUmoVk7Cwk 7bOQtC9gZF7FyFGcWpyUm25ksIkRGJ4Ht/y22MF4+a/NIUZpDhYlcd6Pb52DhATSE0tSs1NT C1KL4otKc1KLDzEycXBKNTAeZXuUsPby1VcnXGc/Dv9w52kV24G/c7L2dC96xzYvgv3Xl+hD PGxKWWL2Nz6lWbvfnrtqveSKy67ZFVH2S79z8D++cez72q9nrZiFa+sK5YTe2UXHP/nFds/2 oqNw99WSjgm5FudLE9KsFe9361wO1OC4IZpidWnBessZv488fPS94EctU81pJZbijERDLeai 4kQAaW1TDB0CAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yGClbswISWYeCqen5uBTrJJS0P0
Subject: [MMUSIC] ICE options: need new optional and/or required attributes?
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: Fri, 28 Feb 2014 15:58:51 -0000

Hi all,

One open issue regarding ICE-bis has been the semantics of the 
ice-options attribute. Currently there is no way of saying "do 
aggressive ICE even if you don't understand this option" or "reject my 
offer if you don't understand this option".

One way of solving this would be to introduce a new attribute like:

a=ice-options-required:foo

That is, if "foo" is unknown option to the answerer, the offer is 
rejected. In addition to solving the second case, it could also be used 
to test for the first and if option was not understood, simply leave it 
out of the new offer. Of course this would result in one signaling 
exchange of delay, and hence for the first case (do still aggressive) we 
could also introduce yet another option:

a=ice-options-optional:bar

Opinions?


Cheers,
Ari