[MMUSIC] ICE offer/answer/candidate exchange terminology

Ari Keränen <ari.keranen@ericsson.com> Fri, 25 September 2015 14:59 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 1B45B1A1C02 for <mmusic@ietfa.amsl.com>; Fri, 25 Sep 2015 07:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id S-518JiL_5c8 for <mmusic@ietfa.amsl.com>; Fri, 25 Sep 2015 07:59:17 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BDD1A1B84 for <mmusic@ietf.org>; Fri, 25 Sep 2015 07:59:17 -0700 (PDT)
X-AuditID: c1b4fb3a-f79136d0000071e2-6f-5605614387d6
Received: from ESESSHC020.ericsson.se (Unknown_Domain []) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 23.85.29154.34165065; Fri, 25 Sep 2015 16:59:15 +0200 (CEST)
Received: from o73.nomadiclab.com ( by smtp.internal.ericsson.com ( with Microsoft SMTP Server id; Fri, 25 Sep 2015 16:59:14 +0200
From: =?UTF-8?Q?Ari_Ker=c3=a4nen?= <ari.keranen@ericsson.com>
To: mmusic <mmusic@ietf.org>
Message-ID: <56056142.20608@ericsson.com>
Date: Fri, 25 Sep 2015 17:59:14 +0300
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvja5zImuYwat9WhZTlz9msXh/fSWL xeID91kdmD2m/N7I6rFkyU+mAKYoLpuU1JzMstQifbsEroyDl64xFSzlrdj0roe5gfEKVxcj J4eEgInE2945rBC2mMSFe+vZuhi5OIQEjjJK/Pk5jxHCWccocXfzIXaQKjYBW4nf7XuYQGxh AQuJN2+2M4LYzAKZEnNP3wWLiwjISOzdtJm5i5GDg1dAU6KzWxEkzCKgKnHz802wMaICaRLv rj0CK+cVEJQ4OfMJC8QYC4mZ889DjZSXaN46mxnEFgLqvfrvFeMERv5ZSFpmIWmZhaRlASPz KkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAQDy45bfVDsaDzx0PMQpwMCrx8C5YxRImxJpY VlyZe4hRmoNFSZy3melBqJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGfifHXxOEv7rd2FGb eUoq0qDmqp7CxmbWPbnbf8feyMuMWnf17jyNE20dth0bDW43/Jl30uZ7eadQtF7yuU+GES+a jhwRs9CwdE98dH3G+Q3PXMJ6NC6e+/k07KnWZc3PMm/XceTJyWt/CHA3VN2ZleTxs1tXoOdj 05O6bTME5vPVLRa537hFiaU4I9FQi7moOBEAUaMqiSUCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/yfW3lsuMbKpTGOSR01Xo3aa3f9U>
Cc: "Suhas Nandakumar \(snandaku\)" <snandaku@cisco.com>
Subject: [MMUSIC] ICE offer/answer/candidate exchange terminology
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: <https://mailarchive.ietf.org/arch/browse/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, 25 Sep 2015 14:59:19 -0000

Hi all,

For quite some time now we have had discussions on how could we best get 
rid of the remaining RFC3264 offer/answer language in ICEbis.

Together with Suhas and Pål-Erik we discussed this off-line and came to 
conclusion that we have two reasonable options for the "offer/answer 
part" of the terminology: "ICE offer & ICE answer" and "ICE candidate 

We three can live with either option, but have different preferences 
among them. That's why we'd like to hear from the rest of the group what 
is your preference.

Here's what we think are the main arguments for selecting each.

ICE candidate exchange:
- clear difference from RFC3264 offer/answer; ICE has been heavily 
linked to SDP o/a so far so using any o/a terminology may cause confusion
- many new ICE scenarios are not using offer/answer kind of signaling
- this is more clear on the fact that there can be activity after the 
exchange part of the protocol, like with Trickle ICE

ICE offer/answer:
- smaller change editorially ("just add ICE")
- only SIP/SDP folks would really confuse "ICE offer/answer" with 
RFC3264 offer/answer
- existing ICE implementations use already this terminology
- familiarity is less confusing
- there are some specifics for the "initiating message", for example 
choosing the controlled party; we need to have some terminology to 
address that, and "offer" fits to that purpose
- however, need to specify clearly that there are things happening after 
the offer/answer part

Is some key argument missing?
Is some argument invalid?

Can you live with either option?
What is your preferred option?

Ari (as individual ICEbis editor)