Re: [MMUSIC] ice-options attribute: session- and media-level?

Roman Shpount <roman@telurix.com> Mon, 23 April 2018 17:03 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 27C2F12D7F1 for <mmusic@ietfa.amsl.com>; Mon, 23 Apr 2018 10:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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, T_DKIMWL_WL_MED=-0.01, T_SPF_PERMERROR=0.01] autolearn=ham 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 fjsAHnsFSCjy for <mmusic@ietfa.amsl.com>; Mon, 23 Apr 2018 10:03:49 -0700 (PDT)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 0D33912D87A for <mmusic@ietf.org>; Mon, 23 Apr 2018 10:03:49 -0700 (PDT)
Received: by mail-pg0-x22d.google.com with SMTP id a13so4354756pgu.4 for <mmusic@ietf.org>; Mon, 23 Apr 2018 10:03:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LRtWcUNlYxPdG2qTalS9ul3mlrfg9V17VIask71oiuM=; b=BUPrv6Zj5tH+hjhQsTKjxYgEVGYx3UKnDpdXXlQZiUMvmYfrz+Bg4F9Z1pCxabtTcA FQJs3Wk+RZZJYxV/bHgIlROH7DjBUCQpxuDqP4UCYPi5C1yY4UNg+IeMS5YQ7BZcEIfR JFEwclRDFjexTA4sK9j1E5rwBQEWvjMl6KZH7YJnpcH3f69hPQfAhfRXD/TaBXwLZC0U 9L4I4vDhn/b+BH3rV1zM8zKwyUMZfvI1ghQFEwCY4fZp2SWIlOL6M8yMvmGmuF2A4qD0 btLT/u7B+0fGzPfYZeLBxxB7EndbIKaQeDi1yGFVbFu3sKeoP5yFtYs+ETYLJHm4DecQ Gumg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LRtWcUNlYxPdG2qTalS9ul3mlrfg9V17VIask71oiuM=; b=YAWyUhOgHd3zn/4Q9nGGOROLHuK8mO26NPnfSmld6VIeHNTelmsJqICKJjgXVGnxYn ow1aCCFYCsZe6PGtO2GhCrFRQIzwseKa7wtKI4RDlP5WMTXGzIZEefEYy+G3hINecKii ECPdYbRPxw6x0PylmtMsm+m9C8IaDSFelGFn0zEel6Ag9BRRo9HdwedVDWinpRIJeDV1 ksZbfDNBxf38HexUSe5Y7Y3gAp2bO0mlOCIHmswI2Qso4ZK7EmzIAaSA7SZGd4G3dIKx JTQgA9GAwTIG4UuqB4GJs8hw4O1ok1vaj/zF+xBnlbI5MMHvQqIlv+2XUzmDxYnw7Lg4 WY1A==
X-Gm-Message-State: ALQs6tDpcb2KmDhJUrlSxfSSb1k38Er+FhvFFz+04AKqUzp38fSSrc/U 95yKCVXwSpC1aNv69Oay6B6L8ajS
X-Google-Smtp-Source: AIpwx4/Z91Zz836GAwbYiFNGmErbYRiM7F6WjbftS36d0SPV7oYgXdYW/SHgUDy8vxUe/DOEEHg78g==
X-Received: by 10.99.94.197 with SMTP id s188mr17592403pgb.21.1524503028232; Mon, 23 Apr 2018 10:03:48 -0700 (PDT)
Received: from mail-pg0-f46.google.com (mail-pg0-f46.google.com. [74.125.83.46]) by smtp.gmail.com with ESMTPSA id s65sm34657961pfj.124.2018.04.23.10.03.47 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 10:03:47 -0700 (PDT)
Received: by mail-pg0-f46.google.com with SMTP id f132so8800070pgc.10 for <mmusic@ietf.org>; Mon, 23 Apr 2018 10:03:47 -0700 (PDT)
X-Received: by 2002:a17:902:4003:: with SMTP id b3-v6mr21165636pld.15.1524503027192; Mon, 23 Apr 2018 10:03:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.149.74 with HTTP; Mon, 23 Apr 2018 10:03:46 -0700 (PDT)
In-Reply-To: <9865a04c-312c-1a81-7f96-5baa237f3d55@petit-huguenin.org>
References: <D6FF6FE7.2E7A2%christer.holmberg@ericsson.com> <CAD5OKxuiaQEd=vpU=W65kGGi8wWUvuQq0X=_=x_4w6TOu_qFOw@mail.gmail.com> <2a27e3fb-528a-92a9-bdfc-e4f303d34221@mozilla.com> <CAMRcRGT=KvEyafM=bNwfmF0B5A70BrHXUBSoFFrEDPKY=fSMmg@mail.gmail.com> <9865a04c-312c-1a81-7f96-5baa237f3d55@petit-huguenin.org>
From: Roman Shpount <roman@telurix.com>
Date: Mon, 23 Apr 2018 13:03:46 -0400
X-Gmail-Original-Message-ID: <CAD5OKxt+1OspnDEOx9LvmPOZDsAUP+neypPWbuc0cA0ECx_tow@mail.gmail.com>
Message-ID: <CAD5OKxt+1OspnDEOx9LvmPOZDsAUP+neypPWbuc0cA0ECx_tow@mail.gmail.com>
To: Marc Petit-Huguenin <marc@petit-huguenin.org>
Cc: Suhas Nandakumar <suhasietf@gmail.com>, Peter Saint-Andre <stpeter@mozilla.com>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000065184b056a870535"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/7qRMb0RJlW7tdBncJ_sh7rASrBU>
Subject: Re: [MMUSIC] ice-options attribute: session- and media-level?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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, 23 Apr 2018 17:03:53 -0000

Hi All,

I would prefer disaggregated media to be handled separately and keep
ice-options a session level attribute. Dealing with disaggregated media is
a much bigger issue then just adjusting ice-options. For instance, why
ice-options are handled there and ice-lite is excluded? I think ice-lite is
potentially as big of the problem when aggregating media from several
sources. Also, I we sure that making singe ICE agent dealing with two
independent ICE agents does not have any issues? I do not think this was
examined in sufficient detail.

Furthermore, it is possible to define per ICE candidate specific parameters
using ICE candidate extension attributes. I think it would be cleaner to
define things which are specific to only some candidates using this
mechanism vs medial level ice-options.

Regards,

_____________
Roman Shpount

On Mon, Apr 23, 2018 at 12:45 PM, Marc Petit-Huguenin <
marc@petit-huguenin.org> wrote:

> This was done as a consequence of merging this draft in ice-bis:
>
> https://www.ietf.org/archive/id/draft-petithuguenin-mmusic-
> ice-attributes-level-04.txt
>
> There is probably discussions that can be found in the minutes of IETF
> meetings around that time when the WG agreed to that modification.
>
> On 04/20/2018 11:09 PM, Suhas Nandakumar wrote:
> > I am fine with considering ice-options has session level too. I wonder if
> > Marc can chime in on considering it as  media level in the ice-sip-sdp.
> >
> > On Fri, Apr 20, 2018 at 12:07 PM, Peter Saint-Andre <stpeter@mozilla.com
> >
> > wrote:
> >
> >> On 4/20/18 12:37 PM, Roman Shpount wrote:
> >>> Hi All,
> >>>
> >>> I do not think ice-options was ever used as a media level attribute.
> >>> Only two ice-options defined in IANA registry
> >>> (https://www.iana.org/assignments/ice/ice.xhtml) are ice2 and
> rtp+ecn,
> >>> which are both session level.
> >>>
> >>> Furthermore, RFC 5245 section 15.5
> >>> (https://tools.ietf.org/html/rfc5245#section-15.5,) defined that
> >>> ice-options attribute is session level only. Thus, ice-options should
> be
> >>> kept session level for backwards compatibility.
> >>>
> >>> If something more granular then session is needed, I think it should go
> >>> into candidate extension attribute, not into media level ice-options.
> >>>
> >>> Bottom line, I think ice-options should be a a session level only
> >> attribute.
> >>
> >> Agreed.
> >>
> >> In the Trickle ICE spec, we also limited the `trickle` option to session
> >> level only.
> >>
> >> Peter
> >>
> >>
>
>
> --
> Marc Petit-Huguenin
> Email: marc@petit-huguenin.org
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>