Re: [MMUSIC] ICE-SIP-SDP: Concluding ICE statement

Roman Shpount <roman@telurix.com> Mon, 22 July 2019 22:59 UTC

Return-Path: <roman@telurix.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 B79481200BA for <mmusic@ietfa.amsl.com>; Mon, 22 Jul 2019 15:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
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 fXp8EDycwAGB for <mmusic@ietfa.amsl.com>; Mon, 22 Jul 2019 15:59:10 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC50A1200DE for <mmusic@ietf.org>; Mon, 22 Jul 2019 15:59:10 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id ay6so19803661plb.9 for <mmusic@ietf.org>; Mon, 22 Jul 2019 15:59:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5dXY3agYlUX7E3O0f4l+k6Y/ZiEWgZ5QpNB0jhP9+K4=; b=uNwA/3KtyFiqr1Ltd3Xx/BIxf8zKyofvh3x1LVTnNghiNtcUE85e+FkPYnBOc7+i+u X33MFByU6wEgN0emfpW4TCzsE3ZSVb4Ae/oWQObrEvN2PWKMUY3NiZz8vixcsfwBh21u 1IurLFHVeZp2Jodx9Bg7etW9MWRDoNZkzoYJM2nWAT5YL9OgsN6ZIAImY26fignxZhii m3UDTK82rrmf98q9LqtloT6Oo94q2NN1yJfjiH7K0/wF960sF4vP9f111L75mqGcWivx 5xUvUhnF0ekVZXwvrLgqU2fzp/X9eizbJ6ndcsml01DeW8qeS8Nw6mc14V0zsxFsBBgE Zcug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5dXY3agYlUX7E3O0f4l+k6Y/ZiEWgZ5QpNB0jhP9+K4=; b=A3UmX5T13WiJH9WvR3ogF566+fC79hlPE2MzTxV9NbRn3ERFJzQ26vK1X82NeA3c8m pHwfvZTcGZe+tu2pX7hJt614lYi+sR67vlu1XJrKB66vchfkK0wp8oDssBlbL1QZeO3w xrV3bxNVWd1UIEeeAh4yVpZxeIozE2OwfctIr8CWY3fa2U9oSik4AlJ2RdK3VFBejZb8 G7WnxXvZTJwXcNTPPY8KEZVgqJzczBDUgY9BJ/V11Qd3fAzIb7cTGMde0GNMHc0USr3Z qqrydR8yiXWnTwL1428aVIJQ64GOxH4TTU0g3lC+sYPOGyguKICYWQAklvgYT6T7Zm57 eB2A==
X-Gm-Message-State: APjAAAUwCebts13XCT0HrxhjwiYYI6WqU8aTauyJRNAtx6uO2DvaYo30 N/c2JTtS3+k/m1oSgI7ZkcPy+5Fv
X-Google-Smtp-Source: APXvYqxrEP6lj4IjY9mJYwJK89k8ea5Y6y2ETgi2g08i4f67A2tEJM8nbw40ZYgXKouSx/I+6iRo1A==
X-Received: by 2002:a17:902:e613:: with SMTP id cm19mr72699106plb.299.1563836350100; Mon, 22 Jul 2019 15:59:10 -0700 (PDT)
Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com. [209.85.210.177]) by smtp.gmail.com with ESMTPSA id h12sm45939833pje.12.2019.07.22.15.59.08 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 15:59:08 -0700 (PDT)
Received: by mail-pf1-f177.google.com with SMTP id f17so14085898pfn.6; Mon, 22 Jul 2019 15:59:08 -0700 (PDT)
X-Received: by 2002:a63:7a06:: with SMTP id v6mr74365672pgc.115.1563836348202; Mon, 22 Jul 2019 15:59:08 -0700 (PDT)
MIME-Version: 1.0
References: <804B6CBB-3614-4CD5-82FC-0E475F716E18@ericsson.com> <CAD5OKxvYQZz_6RpMf9FvSFx+Mz1=cTUC5-cw3o6jVgKqMKLxSQ@mail.gmail.com> <HE1PR07MB316103A8253F36D03E718AB793C90@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAD5OKxv4kSM3xbqB7Kag3=qdV_4W3T9RbB4D-DLXeNJVqqzOwA@mail.gmail.com> <HE1PR07MB31611980F5E438EFA620329C93C80@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAD5OKxsoRrvzvnc4uSwmbJgMzv7Y4bmjPc4fYv4iGhogtyJTzQ@mail.gmail.com> <HE1PR07MB316164B3D661E223F7F892BA93C80@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAD5OKxuA-Kt_NONWorafn1XPNgKJGvR6XLb2f5sx+_WkW4hz-A@mail.gmail.com> <41178B75-AB52-4CD0-A157-3E8EA6778DE2@ericsson.com>
In-Reply-To: <41178B75-AB52-4CD0-A157-3E8EA6778DE2@ericsson.com>
From: Roman Shpount <roman@telurix.com>
Date: Mon, 22 Jul 2019 18:58:55 -0400
X-Gmail-Original-Message-ID: <CAD5OKxsHGK6gpz3rM42BAK4vpwV3RHK=F5QZBPViXGF4quNuJw@mail.gmail.com>
Message-ID: <CAD5OKxsHGK6gpz3rM42BAK4vpwV3RHK=F5QZBPViXGF4quNuJw@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000058420058e4d06a1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/kAVE46NnVZgWZyhsqUzVlGpoLDc>
Subject: Re: [MMUSIC] ICE-SIP-SDP: Concluding ICE statement
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 22 Jul 2019 22:59:14 -0000

Christer,

On Fri, Jul 19, 2019 at 5:29 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> >>>>>This makes sense, but I am not sure it is precise enough. What we are
> trying to say is that ICE nomination
> >>>>>process is done (completed or failed) for all streams and no new
> candidate pairs are going to be nominated.
> >>>>
> >>>> The text talks about when the nomination starts.
> >>>>
> >>>>>Starts or ends?
> >>>>>
> >>>>>The sentence in 3.3.4 was supposed to mean that when ICE nomination
> process completes and if for any stream non-default
> >>>>>>candidate was nominated and ice2 option was not set, to send a new
> offer.
> >>>>
> >>>> It also says that :)
> >>>>
> >>>> But, the first sentence says:
> >>>>
> >>>>“Once the state of each check list is Completed, and if the agent is
> >>>>the controlling agent, it nominates a candidate pair [RFC8445]…”
> >>>>
> >>>>…which at least to me describes when the nomination starts.
> >>>
> >>> This is actually still about the nomination end. Essentially, what is
> described here is at the end of the nomination process,
> >>> for each stream a candidate pair is nominated (or the stream failed).
> If ice2 option is not set, and pair nominated in the end
> >>> is not the default candidate pair for this stream, then new offer
> should be sent to "true up" default candidates.
> >>>
> >>>What this whole language is missing is that for some streams nomination
> can fail without failure of the entire session. Stream failure
> >>>should also result in a new offer with the failed streams disabled
> (port set to 0). I am not sure this is specified anywhere. Another thing
> >>>which is not specified anywhere if new offer due to stream failure is
> only required if ice2 option is not set or always. I would vote for
> >>>always to make sure this m= line can be reused.
> >>
> >> Not sure what you mean by “nominating process”. My understanding of
> “nomination” is when the agent picks a
> >> Valid Pair and sends a STUN request with the nomination bit set.
> >>
> >> But, in any case the “Once the state of each check list is Completed,”
> statement is wrong.  Of course an implementation might mandate
> >> that each check list must be Completed in order to establish the
> session, but there is no requirement in the ICE standard that each check
> >> list has to be Completed in order to do so
> >
> > The language is about end of ICE process, when all candidate lists are
> in either Completed or Failed state.
> >
> > Nominated pair at the time the list is in the Completed state is the
> final pair used for communications.
>
> Not sure what you mean by "final pair". There might be many valid pairs
> associated with a check list, and the agent picks which it wants to
> nominate. That then becomes the "valid pair".
>
> Maybe we could say:
>
>    "Once the state of *A* check list is Completed, and if the agent is
>    the controlling agent, it nominates a candidate pair [RFC8445] and
>    checks whether the nominated pair matches the
>    default candidate pair associated with the check list."
>
>
Once check list is in Completed state (
https://tools.ietf.org/html/rfc8445#section-8.1.1) only one pair should be
in nominated state. This candidate pair becomes the selected pair for that
agent and is used for sending and receiving data for that component of the
data stream. In cases of aggressive nomination, agents selects the
nominated pair with the highest priority. If this selected pair does not
match the default candidate pair, and "ice2" option was not specified, then
controlling agent MUST send a new offer with default candidate set to the
local candidate in the selected pair for the default component, single
candidate per component set to the local candidate of the selected pair,
and single remote-candidate per component set to the remote candidate in
the selected pair. Answer will contain the same. In other words, the new
offer is sent, when only one pair per data stream component is left,
nomination process was already completed, and single candidate pair per
data stream per component is going to be used until the next ICE restart.
This is, essentially, a default candidate "true up".

Best Regards,
_____________
Roman Shpount