Re: [MMUSIC] Please Read and Comment: Re: ICE SDP/JSEP peace accords

Roman Shpount <roman@telurix.com> Tue, 29 January 2019 21:31 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 235C21310A7 for <mmusic@ietfa.amsl.com>; Tue, 29 Jan 2019 13:31:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.031
X-Spam-Level:
X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8gIHALJy8CtR for <mmusic@ietfa.amsl.com>; Tue, 29 Jan 2019 13:31:43 -0800 (PST)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 53BDE13105F for <mmusic@ietf.org>; Tue, 29 Jan 2019 13:31:42 -0800 (PST)
Received: by mail-pg1-x533.google.com with SMTP id s198so9329935pgs.2 for <mmusic@ietf.org>; Tue, 29 Jan 2019 13:31:42 -0800 (PST)
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=zQmR4SR7kP218WJhzGE8KY0WCEAbJY8WsZ7AIuSongw=; b=Ihmwkt6me2kLC7yBpLN31+VRB6MJtnx1xNdk0bt9n02DRQSy1ttScxwe+KyHOTSTwT DBrcds0H4HFdGhcfHhH4oQva9bEqkKTbdIh7SAl7YuE5YKJn9GuPrfcqwr18Aql04/Wd sQEuVQy3rKo4ZepzauCqohbZjNIbBZ35TUZt+dw8co8yiBMiUYb/otFTF9OLN+w7z8DI TCSsJWh8PpepbAatAB5tMeZbQJ/2C7jKF2286QDf7uzCT8ArDj5BvagQD9p/GbESGZ1E yrBORio8HzGAYeJWCXqhgS5MXPbYUeEIWhJurk30+IyMacHWr+LWPU+hpkyz/CV5nbT2 xSrg==
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=zQmR4SR7kP218WJhzGE8KY0WCEAbJY8WsZ7AIuSongw=; b=ssHpBRhNKChCsmulpM75ggk0q+O3JzbkzQsI0AimvwQGldn5OV2XSbSQAsmFy4RUsY Ib48cflvomebW5rCA79reIIsI+7Pq7HmSDZqzvUUqBaRo0oAB7NB/peGRNIbGWK7xW4V VXEYkP13rvwB6PEn8MRP2s1p+bhNRCv+0MR1e99Dhf1EfqeNIvOCaTG6SjqPYAQNRdax /EX0BYkU0DoXv87M8DGuzlzXaBYo10hoz5l8fT9ne6W1VaQwWP3ShzkcBQv9bX5Xm7Zs rmyYPYCDC+/bEauhmTGXwHG+bwJL/GW49coYPOWxrf3AOvemxKBgSXIwrxw4uPzGB67V X7nQ==
X-Gm-Message-State: AJcUukfKaRy0Y+zY1ssHYsxisgG/EsixEZ3/5ZubtayRWK2k99aEvq2D K4a+3P1VKzDVImv07QQw8zRyIGdQ3ZA=
X-Google-Smtp-Source: ALg8bN5hbQ6nEttEniANM+zHXn41+66YVkXIpExlcUyrqY80USJO5oeJH/xrdxd48wlzxcHLU/D3xw==
X-Received: by 2002:a62:cf02:: with SMTP id b2mr28844656pfg.183.1548797501312; Tue, 29 Jan 2019 13:31:41 -0800 (PST)
Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com. [209.85.214.176]) by smtp.gmail.com with ESMTPSA id z62sm63375594pfl.33.2019.01.29.13.31.40 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 13:31:40 -0800 (PST)
Received: by mail-pl1-f176.google.com with SMTP id p8so9957847plo.2 for <mmusic@ietf.org>; Tue, 29 Jan 2019 13:31:40 -0800 (PST)
X-Received: by 2002:a17:902:6909:: with SMTP id j9mr26832297plk.196.1548797499927; Tue, 29 Jan 2019 13:31:39 -0800 (PST)
MIME-Version: 1.0
References: <0454609c-ce69-80d4-93d8-f89bc8ba897e@nostrum.com> <CAD5OKxu1bPDU_snQ=H7RwVgPKW_hKJY1Nj7g82vTpJ+gorPrYQ@mail.gmail.com> <f279e997-0236-b78c-e555-5189d9818ef2@nostrum.com> <9B6124BE-E369-4327-B759-77DB0ED8A484@ericsson.com> <6f42b5c5-72f0-8d6a-c68d-d19da7d94353@cisco.com> <HE1PR07MB3161189A6405D403F433F17293980@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAD5OKxvNYnARbw5yvSHCeQUiSMRxQdMj9h5zUeXj+o3Nd8Kh-g@mail.gmail.com> <3e17ec5d-e6b2-5d38-e206-2ed7b8b9c690@nostrum.com> <CAD5OKxtzxOfE9O-G5tQ1C_sg8LHQBxpNATJi_ee-UVcp0gdb2w@mail.gmail.com> <ab0940dd-9ad0-d012-5530-a6a35dd659e9@nostrum.com> <CAD5OKxtgRZErxSfPOQd1xts4zg+1RWuYFOZSey=HgG-Y9g0Dhw@mail.gmail.com> <b7c0eb29-d11b-1a54-5325-d8fccb1c778d@nostrum.com> <CAD5OKxthX_GVNCchMvovAac9Q_hwLVP2VHudp3QUEZxfzBj5HA@mail.gmail.com> <b5cd275a-1dc7-9729-fea0-e8e2b432f171@nostrum.com>
In-Reply-To: <b5cd275a-1dc7-9729-fea0-e8e2b432f171@nostrum.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 29 Jan 2019 16:31:28 -0500
X-Gmail-Original-Message-ID: <CAD5OKxtbVYc+o3Lu2ekHztDbw=HdovPd4OJx2OQ_HzfdDC9y0A@mail.gmail.com>
Message-ID: <CAD5OKxtbVYc+o3Lu2ekHztDbw=HdovPd4OJx2OQ_HzfdDC9y0A@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Flemming Andreasen <fandreas@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>, Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary="000000000000cff39a05809f849b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/AQ-AKflhhV2UFXQwARCPinSoUhs>
Subject: Re: [MMUSIC] Please Read and Comment: Re: ICE SDP/JSEP peace accords
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: Tue, 29 Jan 2019 21:31:50 -0000

On Tue, Jan 22, 2019 at 4:42 PM Adam Roach <adam@nostrum.com> wrote:

> On 1/22/19 3:40 PM, Roman Shpount wrote:
>
> On Tue, Jan 22, 2019 at 4:36 PM Adam Roach <adam@nostrum.com> wrote:
>
>> On 1/22/19 3:33 PM, Roman Shpount wrote:
>>
>> On Tue, Jan 22, 2019 at 4:25 PM Adam Roach <adam@nostrum.com> wrote:
>>
>>> On 1/22/19 3:15 PM, Roman Shpount wrote:
>>> > The issue is the offer generated when ICE restart is not initiated and
>>> > TCP candidate is currently nominated. TCP candidate is the only
>>> > candidate which is present in both offer and answer. It is also the
>>> > default candidate. No UDP candidate will be added it any point during
>>> > the offer/answer exchange.
>>>
>>>
>>> This is what I tried to indicate with the use of an italicized "always"
>>> in my previous reply.
>>>
>>> EVEN IF it is generating an offer when ICE restart is initiated and the
>>> TCP candidate is nominated, Chrome will still always (always, always)
>>> generate an SDP that includes a UDP candidate and use that candidate's
>>> value in the m=/o= lines.
>>>
>>
>> Unless I am mistaken, if ICE restart is not initiated, only the nominated
>> candidate must be included. No other candidates must be present. If Chrome
>> does not follow this, then it is most likely not complaint with either ICE
>> or JSEP specifications.
>>
>>
>> Based on the conversation I had with their engineers, that seems to be
>> the case.
>>
>
> Based on RFC 5245 section 9.1.2.2 (
> https://tools.ietf.org/html/rfc5245#section-9.1.2.2) this is wrong:
>
> The agent MUST include candidate attributes for candidates matching the
> default destination for each component of the media stream, and MUST NOT
> include any other candidates.
>
>
> I'm not disagreeing.
>
I wanted to update this thread that according to Justin in our discussion
regarding https://github.com/rtcweb-wg/jsep/pull/863, JSEP specifies that
even after ICE nomination is complete, offer must include all candidates
collected up to this point. This is not explicitly stated anywhere in JSEP
draft, but it is implied by example in section 7.2 and by the fact that
subsequent offers are generated using the same procedures described in JSEP
section 5.2.2 (
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.2.2),
regardless if ICE nomination is in progress or complete. Specifically,
section 5.2.2 states:

If the m= section is not bundled into another m= section, for each
candidate that has been gathered during the most recent gathering phase
(see Section 3.5.1), an "a=candidate" line MUST be added, as defined in
[I-D.ietf-mmusic-ice-sip-sdp], Section 4.1.

This explicitly contradicts RFC 5245 section 9.1.2.2 (
https://tools.ietf.org/html/rfc5245#section-9.1.2.2) and mmusic-ice-sip-sdp
Section 3.4.1.2.2 (
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.4.1.2.2
).

Regards,
_____________
Roman Shpount