IETF Logo Mail Archive

Re: [MMUSIC] Empty candidate lists in ice-sip-sdp offers and answers

Roman Shpount <rshpount@turbobridge.com> Mon, 29 April 2019 21:27 UTC

Return-Path: <rshpount@turbobridge.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 99D30120195 for <mmusic@ietfa.amsl.com>; Mon, 29 Apr 2019 14:27:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=turbobridge.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 8niPVjwd20a7 for <mmusic@ietfa.amsl.com>; Mon, 29 Apr 2019 14:27:23 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 282CE1200B1 for <mmusic@ietf.org>; Mon, 29 Apr 2019 14:27:23 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id k19so5789321pgh.0 for <mmusic@ietf.org>; Mon, 29 Apr 2019 14:27:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=turbobridge.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u2k8+1zR1tGgxVMjvKLnCsm4qjgHNHfP5WH72DRswHg=; b=CbNGcvD34bbns8VYRKeAsBOQ6NmBVd/dvQvHwmSjewne33Gci8MrsJf01+r68y4Ew3 JYsDOXlZYgXp4e4YGgGjbAb4qHHOEKc3nGKDt4G0HEm2FA3uqM8+zQaMO/cXv8CSbWXY 7rnaVS5V4x8Oj1QOBTs9qdPOEFpqdP6XkyRdo=
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=u2k8+1zR1tGgxVMjvKLnCsm4qjgHNHfP5WH72DRswHg=; b=Ph6N9QOsnr71blH9U7fyY/E0L5X+v23LuT0T2JFNLqB79T/yuIknKqIvZc1LrRFpt7 p3LNB+nlA0zDwSIeUws0lAUIwGSyV8v/z9ikXafhJYL9/CTGWckPYaCzso0WxJtadihF +BRccqpzsYx/RiUK7pqK8uhlORNwShsti8U2gjaUAdO+12RT5H251AU5UtfA8pM/wVKJ mwiXyMGukeuudH2tTY13duk2icD/bhx0FgZJT91faBw5x3M95ItZ2Vs3Z5MgS3pHeVIL j9cHlxHJ1AUDnmZEAhaz/spoEUjypDSA+Kv7M6d4ml/TEM3CyrJPxsMrqioqVfMueb+h NA6w==
X-Gm-Message-State: APjAAAUnVYFdlvlmK1jNb1CGwqNDK4tbfkgI7Xj/l9MiQXHPE51thF9u LlPTGULfHAZBV1PuoKovXkCviVPoptw=
X-Google-Smtp-Source: APXvYqzExMk390ZRXkq0d83gag3Wc1fvLJrlfOe/VyC9K14hdCbwSbEQ24/E3zrHxRg6xATPnCAZrw==
X-Received: by 2002:a63:c54d:: with SMTP id g13mr59222408pgd.376.1556573242365; Mon, 29 Apr 2019 14:27:22 -0700 (PDT)
Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com. [209.85.214.173]) by smtp.gmail.com with ESMTPSA id t5sm44243068pfh.141.2019.04.29.14.27.21 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2019 14:27:21 -0700 (PDT)
Received: by mail-pl1-f173.google.com with SMTP id bi2so893802plb.13 for <mmusic@ietf.org>; Mon, 29 Apr 2019 14:27:21 -0700 (PDT)
X-Received: by 2002:a17:902:5a8f:: with SMTP id r15mr30382894pli.196.1556573241119; Mon, 29 Apr 2019 14:27:21 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5OKxu=tqdoqBBL=qyT0KywAnzzxSEOc_f47TCBt9Qg63FB4A@mail.gmail.com> <HE1PR07MB3161C69040BF2BB9E518C2AF933F0@HE1PR07MB3161.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB3161C69040BF2BB9E518C2AF933F0@HE1PR07MB3161.eurprd07.prod.outlook.com>
From: Roman Shpount <rshpount@turbobridge.com>
Date: Mon, 29 Apr 2019 17:27:10 -0400
X-Gmail-Original-Message-ID: <CAD5OKxvMhFVju-UKttNb+3Bb2rxCJW=eVpaxaBRT_LC6khMabw@mail.gmail.com>
Message-ID: <CAD5OKxvMhFVju-UKttNb+3Bb2rxCJW=eVpaxaBRT_LC6khMabw@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001a9c7c0587b1f364"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/4UjorylzqYJ-ZoqEVo2UJJUD9T8>
Subject: Re: [MMUSIC] Empty candidate lists in ice-sip-sdp offers and answers
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, 29 Apr 2019 21:27:26 -0000

On Sat, Apr 27, 2019 at 2:02 PM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> ...
>
> >NOTE: Since it is possible that no candidates were provided in the
> offer,  or that all candidates in the offer
> >where skipped due to unsupported address type or FQDN name resolution
> failure, ICE nomination process
> >can start with no remote candidates. This,  however, does not indicate an
> immediate ICE nomination failure.
> >See <<draft-holmberg-ice-pac>> for more details.
> >
> >In the Receiving the Initial Answer section I have added the following:
> >
> >NOTE: Since it is possible that no candidates were provided in the
> answer, or that all candidates in the answer
> >where skipped due to unsupported address type or FQDN name resolution
> failure, ICE nomination process can
> >start with no remote candidates. This,  however, does not indicate an
> immediate ICE nomination failure.
> >See <<draft-holmberg-ice-pac>> for more details.
>
> I think the text is confusing, because it starts talking about the ICE
> nomination process. There are other things that happen before, including
> the creation of candidate pairs.
>
> So, I think the text should say that the agent will not be able to create
> candidate pairs, and it will not be able to start sending connectivity
> checks. Instead it will wait for the peer agent to start sending
> connectivity checks, that the agent will then process as peer reflexive
> candidates.
>

I will try to come up with some text that uses the same terminology as RFC
8445.

>I wanted to get the group's opinion regarding:
> >
> >1. Allowing offers and answers with no candidates
>
> I am ok with the principle. There seem to be use-cases for it, so...
>
> >2. Adding a reference to draft-holmberg-ice-pac regarding how such
> session descriptions or session descriptions where all candidates were
> rejected are handled.
>
> The reference in the text above is misleading, because to me it sounds
> like PAC describes how to process offers/answers without candidates. PAC is
> only about a timer.
>
>
Maybe this draft should cover the situation when session description
processing did not generate any candidates. The fact that ICE has some
minimal run timer is not enough. We still need something that explicitly
states that it is acceptable to run ICE nomination process without
candidates since, as far as I know, nothing in RFC 8445 specifies if this
is allowed or not.

Regards,
___________________________________________
Roman Shpount | CTO | Cell: +1(202) 262-8672
4905 Del Ray Ave, Suite 300 | Bethesda, MD 20814
TurboBridge

v2.23.0 | Report a Bug | By Email