Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F761295D8 for ; Sun, 10 Feb 2019 16:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 XUHr49_XhCO0 for ; Sun, 10 Feb 2019 16:07:49 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 05F04129284 for ; Sun, 10 Feb 2019 16:07:49 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id e27so6354173lfj.8 for ; Sun, 10 Feb 2019 16:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2E98GxPPlsJ392T/gDl835Tox96T1tNHz0AOLzRSzKI=; b=BXGt2+aLxokrY65+pJqExEvIfq+g+CsB8jHxXQs3TnUF+M4Z/EtVwkAaZhKiGVdLCk UGVO7GXwUu++edG61HMEsH7SsCQOpDaZP+p8yF2FyelmCb3b0dJlGkjEpSK0kSNMqun6 HGq6ff5DzFDgKnKToA4ndxLJ4VcSTgjAXVDHWFYOmq3oA48TQjPqRIoHMRQxKvZFEUSW Q0Es8TPH6AB2gNNrbUXq55xppRDXEECqUCV3/vvteS59V7y6hZXfpou7NHt1rQjP06vZ futuoSmUK9zZgF4zjc6aNB28DupaiDOE9VxYbAm6cjeLJKvlcoLulkZnmzrPtZz4Imuj 8fkw== 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=2E98GxPPlsJ392T/gDl835Tox96T1tNHz0AOLzRSzKI=; b=cGSCitUlNTLr1wYK5RE2hhdFXDdJCSQ+j3+PAtnfH8hAB3Waf90SUxh/HU2PzqHJR6 XzFc72bCPBbuDNjUBYT9Vyyem6c+6cCQLHRfDK7UpOVEWPp99zVWCRcWKiXt6Y8gzKm9 pQibvcZSbuInEBR8sUTz8/rYg+IsiAl4LVZUo5i636exzo9l8ee+gYcc4T0owFnDsOu9 9MoU0JMJondzXWRcP7oFKLQ3SeEu7i6HFrGzByHYaSXOMLNU8Ls6TALs6BJLZFWyCCar rEiVtLlPfhQvMUXOJJ0cmEkZOerrMDFL+r7J9gmeHMrzGyHtJODdqsIdjtWvsh1jFPKJ E25Q== X-Gm-Message-State: AHQUAuZwsGb4Xw8wXCd/wwz5l0ns5v7LuH8ROJsnueM1MdJpF8plwJZh Ar2fqZYeZQe07m0tAct4YWOlWXs1LgWYSHTeWJh//p9v X-Google-Smtp-Source: AHgI3IYpZ5S7gOstyeXYLFWEjgWtp/W1snN570HbFRZS4ubY3J1y3sz7AGV17i9I4yWRrGu0ZBrb6xwc08NRpEKRvGQ= X-Received: by 2002:a19:f204:: with SMTP id q4mr21090411lfh.133.1549843667025; Sun, 10 Feb 2019 16:07:47 -0800 (PST) MIME-Version: 1.0 References: <1CBB5877-1CBC-46F8-BD41-9B97EE6FB3F3@ericsson.com> In-Reply-To: <1CBB5877-1CBC-46F8-BD41-9B97EE6FB3F3@ericsson.com> From: Eric Rescorla Date: Sun, 10 Feb 2019 16:07:08 -0800 Message-ID: To: Christer Holmberg Cc: Justin Uberti , Roman Shpount , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000003b13dc0581931918" Archived-At: Subject: Re: [rtcweb] Call for consensus on ICE transport parameter issue (February 15). X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 00:07:52 -0000 --0000000000003b13dc0581931918 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not in favor of this change for the reasons I already laid out. -Ekr On Sat, Feb 9, 2019 at 1:13 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I also support this change. > > > > I share Roman=E2=80=99s issue in this note #1, but since Justin seems to = be fine > removing the associated text it should be solved. > > > > Regards, > > > > Christer > > > > *From: *rtcweb on behalf of Justin Uberti > > *Date: *Friday, 8 February 2019 at 20.21 > *To: *Roman Shpount > *Cc: *"rtcweb@ietf.org" > *Subject: *Re: [rtcweb] Call for consensus on ICE transport parameter > issue (February 15). > > > > > > > > On Fri, Feb 8, 2019 at 11:15 AM Roman Shpount wrote: > > I am, obviously for this change. As far as I know additional complexity i= s > minimal if not completely non-existent. JSEP already requires m=3D and c= =3D > line updates based on the default candidate. I do not think there is a lo= t > of extra effort in updating the same line based on the same input in two > places vs one place. > > > > I would also like to note that: > > > > 1. JSEP requires browsers to update the m=3D line more often then > mmusic-ice-sip-sdp or RFC 5245. For offers sent during ICE nomination > process, JSEP asks to set m=3D and c=3D line to the last used ICE candida= te > pair. RFC 5245 asks in this case to set this to the default candidate pai= r, > which changes a lot less often. It is unclear what is the benefit of > additional JSEP requirement. It looks like some sort of left over logic > from re-nomination. This being said, it should not create any interop > issues and will simply creates additional complexity. > > > > I agree that this should probably be removed from JSEP and codified in > sip-sdp instead; as previously discussed, JSEP doesn't actually use this > info. > > > > 2. JSEP can produce the answer where default candidate protocol does not > match the m=3D line protocol. This is an old RFC 5245 issue and can be fi= xed > in the future specification or mmusic-ice-sip-sdp. > > > > This should probably also be fixed in sip-sdp. > > > > Regards, > > _____________ > Roman Shpount > > > > > > On Fri, Feb 8, 2019 at 1:43 PM Ted Hardie wrote: > > Over the the past few weeks, the working group has discussed whether to > adopt a change to JSEP which would adjust how the ICE proto line transpor= t > parameters are populated in certain mid-session offers where the final > candidate is a TCP candidate. Outside of the extensive working group > discussion on the mailing list, participants may also wish to review the > follow issue: > > > > https://github.com/rtcweb-wg/jsep/issues/854 > > > > and the conversations related to these two pull requests: > > > > https://github.com/rtcweb-wg/jsep/pull/862 > > and > > https://github.com/rtcweb-wg/jsep/pull/863 > > > > The chairs believe that there is technical consensus that this proposed > change would not materially affect JSEP-only exchanges, since this > parameter is ignored in those. > > > > The remaining technical issues are: > > > > * whether making one of these changes would improve interoperability > between WebRTC and non-WebRTC clients which use SIP/SDP. > > > > * whether the additional complexity in tracking the use of UDP vs. TCP an= d > populating the parameter accordingly is onerous or unwarranted for WebRTC > implementations. > > > > After reviewing the discussion to date, the chairs believe that there is > rough consensus for the first point, though there is also broad agreement > that the benefit of this change is currently theoretical, since no existi= ng > WebRTC browser implementation has relevant code. > > > > On the second point, the chairs believe that there is no consensus yet > demonstrated. Because we believe that this is in part because the actual > proposal has not been entirely clear, and the complexity is therefore > somewhat hard to gauge, the chairs wish to make a specific call for > consensus. > > > > Does the working group approve the change in the following PR: > > > > https://github.com/rtcweb-wg/jsep/pull/863 ? > > > > Working group participants who have objections to the change are asked to > specify whether they believe it has a technical fault, whether they objec= t > on the basis of its complexity, or whether they have other issues related > to the change they need to raise. > > > > The chairs are already aware of the objection of Eric Rescorla on the > basis of complexity, and will factor it into the review. > > > > Please send comments by February 15th, 2019. > > > > regards, > > > > Ted Hardie and Sean Turner > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000003b13dc0581931918 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not in favor of this change for the reasons I al= ready laid out.

-Ekr

On Sat, F= eb 9, 2019 at 1:13 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Hi,

=C2=A0

I also support this change.<= /u>

=C2=A0

I share Roman=E2=80=99s issue i= n this note #1, but since Justin seems to be fine removing the associated t= ext it should be solved.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = rtcweb <rtcweb-bounces@ietf.org<= /a>> on behalf of Justin Uberti <juberti=3D40google.com@dmarc.ietf.org><= br> Date: Friday, 8 February 2019 at 20.21
To: Roman Shpount <roman@telurix.com>
Cc: "rtcwe= b@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Call for consensus on ICE transport parameter = issue (February 15).

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 8, 2019 at 11:15 AM Roman Shpount <roman@telurix.com&= gt; wrote:

I am, obviously for this change. As far as I know ad= ditional complexity is minimal if not completely non-existent. JSEP already= requires m=3D and c=3D line updates based on the default candidate. I do n= ot think there is a lot of extra effort in updating the same line based on the same input in two places vs one pla= ce.

=C2=A0

I would also like to note that:

=C2=A0

1.=C2=A0 JSEP requires browsers to update the m=3D l= ine more often then mmusic-ice-sip-sdp or RFC 5245. For offers sent during = ICE nomination process, JSEP asks to set m=3D and c=3D line to the last use= d ICE candidate pair. RFC 5245 asks in this case to set this to the default candidate pair, which changes a lot less often.= It is unclear what is the benefit of additional JSEP requirement. It looks= like some sort of left over logic from re-nomination. This being said, it = should not create any interop issues and will simply creates additional complexity.

=C2=A0

I agree that this should probably be removed from JS= EP and codified in sip-sdp instead; as previously discussed, JSEP doesn'= ;t actually use this info.=C2=A0

=C2=A0

2. JSEP can produce the answer where default candida= te protocol does not match the m=3D line protocol. This is an old RFC 5245 = issue and can be fixed in the future specification or mmusic-ice-sip-sdp.

=C2=A0

This should probably also be fixed in sip-sdp.=C2=A0=

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0

=C2=A0

On Fri, Feb 8, 2019 at 1:43 PM Ted Hardie <ted.ietf@gmail.com>= ; wrote:

Over the the past few weeks, the working group has d= iscussed whether to adopt a change to JSEP which would adjust how the ICE p= roto line transport parameters are populated in certain mid-session offers = where the final candidate is a TCP candidate.=C2=A0 Outside of the extensive working group discussion on the = mailing list, participants may also wish to review the follow issue:=

=C2=A0

=C2=A0

and the conversations related to these two pull requ= ests:

=C2=A0

and

=C2=A0

The chairs believe that there is technical consensus= that this proposed change would not materially affect JSEP-only exchanges,= since this parameter is ignored in those.=C2=A0

=C2=A0

The remaining technical issues are:=C2=A0 =

=C2=A0

* whether making one of these changes would improve = interoperability between WebRTC and non-WebRTC clients which use SIP/SDP.

=C2=A0

* whether the additional complexity in tracking the = use of UDP vs. TCP and populating the parameter accordingly is onerous or u= nwarranted for WebRTC implementations.

=C2=A0

After reviewing the discussion to date, the chairs b= elieve that there is rough consensus for the first point, though there is a= lso broad agreement that the benefit of this change is currently theoretica= l, since no existing WebRTC browser implementation has relevant code.

=C2=A0

On the second point, the chairs believe that there i= s no consensus yet demonstrated.=C2=A0 Because we believe that this is in p= art because the actual proposal has not been entirely clear, and the comple= xity is therefore somewhat hard to gauge, the chairs wish to make a specific call for consensus.

=C2=A0

Does the working group approve the change in the fol= lowing PR:

=C2=A0

=C2=A0

Working group participants who have objections to th= e change are asked to specify whether they believe it has a technical fault= , whether they object on the basis of its complexity, or whether they have = other issues related to the change they need to raise.

=C2=A0

The chairs are already aware of the objection of Eri= c Rescorla on the basis of complexity, and will factor it into the review.<= u>

=C2=A0

Please send comments by February 15th, 2019.<= u>

=C2=A0

regards,

=C2=A0

Ted Hardie and Sean Turner

=C2=A0

=C2=A0

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000003b13dc0581931918--