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

Roman Shpount <roman@telurix.com> Fri, 25 January 2019 19:35 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 4EDC6131051 for <mmusic@ietfa.amsl.com>; Fri, 25 Jan 2019 11:35:20 -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 W0-6Qn8WT4ES for <mmusic@ietfa.amsl.com>; Fri, 25 Jan 2019 11:35:18 -0800 (PST)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 2243813104D for <mmusic@ietf.org>; Fri, 25 Jan 2019 11:35:18 -0800 (PST)
Received: by mail-pg1-x531.google.com with SMTP id y4so4587032pgc.12 for <mmusic@ietf.org>; Fri, 25 Jan 2019 11:35:18 -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=bN6QMLXmZBXsgj8ouKkjZ4lRBAW284qZgpspOVQtyEw=; b=UnJ9u95zSAPMg58EPOVv7/4mA1XTgSjdTgLdIMxZpTHBXOMp4RXrQY3j1IhtIDET0S ZT352qrSQu06/+lz1/4d2F0ByTVbv6h5dtKqIFwzLoxbSlF0R3DC9piHE9tcTaskXz94 pe7YoAgDDPUc33tkOiH7Ty/D9U+/mDjz2cpZPuFdpByrdC9Yq+13QaUWhgUWZYfTZVlz ewAYEQQVuiV7Y127fy31DK4RcCgxJGmvcn4lsln0mzwVnE4bnT07ArAlL0bBQWAQ0lAa f4pkw1UpWPIoW6EzEgw/YDK5l8MNYN0MZdKcqJd/2QLwcfccE7KG51vyLvkL3DJaGo7j h39w==
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=bN6QMLXmZBXsgj8ouKkjZ4lRBAW284qZgpspOVQtyEw=; b=iIfpBSfvE3adXZj24AKFO/YemOlJqAcplHTuEWqek5dbS/7DMVBBfVGbmQUbMLmVlU xlKa5xnelaBBIpeSPjjk0mzcy1SNH8PW/LPn9sM7g2+M1Z4/j3A6cxjWR5fncq7j8G/W +faK+2cQNu1Sbfltcb3N6mQJC6F6vFcp0dzy37XMEG+Maf1RO/Oopv42Gz4R5iJMY157 mtEcljgkYK2RtFwGSVKq/FMVm7HaD9/h+x2ZJL06ifaptZ7pm3ZuomwbgtOrUpYoRUi/ VY/ALkiIx6MLSCR59Yr+/pUI2lmhZP5bn2KruwGjg79UQYWfYpdXlDwfIFyPkK9IqZuI io6A==
X-Gm-Message-State: AJcUukcUCxpgxWR3yaKDV1EWw+PgSo7/1oD01y3QR5rIHQcy2UYh4Jsc oXfV9KFTqAYypFbjEKacejTRRcEplRw=
X-Google-Smtp-Source: ALg8bN5tXGe112CxN4GlqEo9WVGuG4aIVblHJpaYAwQeC3sy1svT1VvO/yzD6qnSb4u1Vvm/0tY7Rg==
X-Received: by 2002:a62:7a8b:: with SMTP id v133mr12406232pfc.159.1548444917544; Fri, 25 Jan 2019 11:35:17 -0800 (PST)
Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com. [209.85.210.172]) by smtp.gmail.com with ESMTPSA id 15sm46731321pfr.55.2019.01.25.11.35.16 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jan 2019 11:35:16 -0800 (PST)
Received: by mail-pf1-f172.google.com with SMTP id y126so5198978pfb.4 for <mmusic@ietf.org>; Fri, 25 Jan 2019 11:35:16 -0800 (PST)
X-Received: by 2002:a65:590b:: with SMTP id f11mr11198976pgu.60.1548444916046; Fri, 25 Jan 2019 11:35:16 -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> <f54c5932-7254-151f-a04a-07cb86809fe7@cisco.com> <CAD5OKxv_Xge=g0wtyADF3QO6qjp9iwu4sKMmYvC6zdVw5kg4tw@mail.gmail.com> <CAMRcRGStO+WjTBxETS4usOFS7NZSYgRP0ciWXZ8Sw8FBfge=5g@mail.gmail.com>
In-Reply-To: <CAMRcRGStO+WjTBxETS4usOFS7NZSYgRP0ciWXZ8Sw8FBfge=5g@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Fri, 25 Jan 2019 14:35:06 -0500
X-Gmail-Original-Message-ID: <CAD5OKxt76SVqcKCP_bsWyPEe8sXe2+Kmq4WqDgmcK9EqrJLw+g@mail.gmail.com>
Message-ID: <CAD5OKxt76SVqcKCP_bsWyPEe8sXe2+Kmq4WqDgmcK9EqrJLw+g@mail.gmail.com>
To: Suhas Nandakumar <suhasietf@gmail.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Flemming Andreasen <fandreas@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002cdfbc05804d6d34"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/2Dvl_sYmN9fkmOEUSnUtEwT1U3A>
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: Fri, 25 Jan 2019 19:35:20 -0000

I have provided my comments on pull request. I think this is a reasonable
way forward but the language requires clarification.

We will also need to update ice-sip-sdp to deal with some of the
ambiguities:

1. We need to specify that protocol in the answer must match protocol in
the offer, even if none of the ICE candidates in the answer match. For
instance, if an offer is received with TCP/DTLS/RTP/SAVPF , but the answer
contains only UDP candidates, answer MUST sill use  TCP/DTLS/RTP/SAVPF

2. We need to specify what address and port must be used if protocol in the
m= line does not match any of the candidates. I think using IN IP4 0.0.0.0
and port 9 is a safe option which avoids ICE mismatch.

Regards,
_____________
Roman Shpount


On Fri, Jan 25, 2019 at 1:58 PM Suhas Nandakumar <suhasietf@gmail.com>;
wrote:

> I think Adam’s Pr on this topic is reasonable way forward.
>
> Thanks
> Suhas
>
> On Fri, Jan 25, 2019 at 10:50 AM Roman Shpount <roman@telurix.com>; wrote:
>
>> On Fri, Jan 25, 2019 at 9:05 AM Flemming Andreasen <fandreas@cisco.com>;
>> wrote:
>>
>>>
>>>
>>> On 1/22/19 4:42 PM, Adam Roach 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.
>>>
>>>
>>> So where does this leave us ?
>>>
>>>
>> I think JSEP sections 5.1.2 (
>> https://tools.ietf..org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2
>> <https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2>)
>> and potentially 5.2.2 (
>> https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.2.2)
>> would need to be updated to be consistent with each other and mmusic drafts.
>>
>> There is currently a discussion on RTCWEB of pull request
>> https://github.com/rtcweb-wg/jsep/pull/862/files which attempts to fix
>> this.
>>
>> Regards,
>> _____________
>>
>> Roman Shpount
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>