IETF Logo Mail Archive

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

Emil Ivov <emcho@jitsi.org> Sat, 01 March 2014 10:08 UTC

Return-Path: <emcho@sip-communicator.org>
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 36D0F1A0901 for <mmusic@ietfa.amsl.com>; Sat, 1 Mar 2014 02:08:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 m9FKzgqXMfl0 for <mmusic@ietfa.amsl.com>; Sat, 1 Mar 2014 02:08:46 -0800 (PST)
Received: from mail-ea0-f175.google.com (mail-ea0-f175.google.com [209.85.215.175]) by ietfa.amsl.com (Postfix) with ESMTP id 699B81A08FD for <mmusic@ietf.org>; Sat, 1 Mar 2014 02:08:46 -0800 (PST)
Received: by mail-ea0-f175.google.com with SMTP id d10so99695eaj.20 for <mmusic@ietf.org>; Sat, 01 Mar 2014 02:08:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=sW4zs1KvtOxvgY19ZNhbgMjYczgWhzKkTyQVpOEVHzI=; b=AervhzTvHR6Q+shzYTEK140/h+GEqQvydvdM3Ifg+P03VyD4LnIX3OqpYD4Y8meAhU mToVEBv/SA/H6hKiibdOLv3egFU+NlTbTdmiSO+OShQvRzKozS5r06bpjSWnmlmcfqQK A1w1DCbb1KWxHvJbo1sjGsQ0DqgQs/Qg0E3g5PYSihl6tCGElgOaHzfvmbWy3V2XcI5m G2Oe69sIZhY7WSzpQlue2Wuhp2GZ6H8dhcRBw0Inou3VXWhk57iFrbZKNbWYhmUCi2N4 CSbtMcv06q1tGQO+Lk815RZrx2EJf5Zp3mjxWl/Hv4rm3U/TZ1FYJ/CWg53iskzU3wQy yucw==
X-Gm-Message-State: ALoCoQm8EE2cagHoergWT3orj/UGCXO0ZFxUKV/XEHMYIcMQfcxVflnZOqGgC5HdlrIJOt0LYV4W
X-Received: by 10.15.56.130 with SMTP id y2mr27355720eew.17.1393668523786; Sat, 01 Mar 2014 02:08:43 -0800 (PST)
Received: from [192.168.43.67] ([212.5.158.93]) by mx.google.com with ESMTPSA id 46sm21598970ees.4.2014.03.01.02.08.39 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Mar 2014 02:08:40 -0800 (PST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Emil Ivov <emcho@jitsi.org>
In-Reply-To: <5310B236.7050108@ericsson.com>
Date: Sat, 01 Mar 2014 12:08:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <25289CDD-23B0-4060-A12B-EE9F7CCD64F3@jitsi.org>
References: <5310B236.7050108@ericsson.com>
To: Ari Keränen <ari.keranen@ericsson.com>
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/NFvzZ5mFJOuSv0fQXkfxS6t8K0k
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [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: Sat, 01 Mar 2014 10:08:48 -0000

On 28.02.2014, at 17:58, Ari Keränen <ari.keranen@ericsson.com> wrote:

> 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

I don't have a strong opinion on this but the latter seems to be the only one offering consistency with existing implementations.

Emil

> 
> Opinions?
> 
> 
> Cheers,
> Ari
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
https://jitsi.org

v2.23.0 | Report a Bug | By Email