From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Eric Rescorla <ekr@rtfm.com>, Adam Roach <adam@nostrum.com>
CC: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Proposal to break the ICE impasse
Thread-Index: AQHUtCoOCID4ifgvbk+6P/h8fwfLKaXBz0cAgAEnOzc=
Date: Sun, 27 Jan 2019 11:21:56 +0000
Message-ID: <HE1PR07MB3161B0F1D2B5AC9DA72DDFAD93950@HE1PR07MB3161.eurprd07.prod.outlook.com>
References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com>,
 <CABcZeBP9t0SgsHAuENo99D6ffKd7Mw0Xs1vzUCOzSS=WJN5z8A@mail.gmail.com>
In-Reply-To: <CABcZeBP9t0SgsHAuENo99D6ffKd7Mw0Xs1vzUCOzSS=WJN5z8A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: ericsson.com does not designate
 permitted sender hosts)
Content-Type: multipart/alternative;
 boundary="_000_HE1PR07MB3161B0F1D2B5AC9DA72DDFAD93950HE1PR07MB3161eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 80e7946d-85c7-4048-2ee4-08d68449a5f0
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2019 11:21:56.9172 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4171
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA03SfUiTQRwH8G7Ps+1xNTqX5g/NPxr0ps3SIpeJbyANbL4UhMYgh3uYpk7b
 szSDQNJSZjDRWWqZZUvETE0Ds4x0+IImLi3LrD9MTRExBMMyc+W8Bf73uft97353xzGUpInv
 yaToDKxep06TCkR0RXxbtuysWak63NwslXes1QjldfNDQvkTe4EwjFJYLCs8RWX7NK0onbpB
 xVLnRMEaNi0li9UfCkkUJReU9PAz74ZdfllSLMxFt48ZEcMAPgp5nawRuTAS3I2g9XeqEYnW
 vYygcfEDRQYWHky/mUOOFI2LKRgvFJBCKQ9aOkYRGUwi6MnvQ45tBVgORXZfxwI3HAqDvXm0
 wxTeB18eDgkdkR04EEaaDpKIHJbfG2niIHhR1U2RXnugYeGW0GExVkFfRaezVR6CqdG1jYIL
 jgPT05kNI7wTfg408EgvDxifrt4wYAyWDhtF7A5zU3Y+yavhdf2Ec14Oi4XlNLE3jFQXIeJr
 QjB/jCaWwWJZmTOvBFvrlNOfECy3BxL7wKPCEQFxKix1D/CJd0F57gzfcQHAc3x4ZWngFyNZ
 5aazVq6/C4UzwDieXblxZ1for5imScQPxsrMAmJfqH0wTxHLoNxupTfP30fCeuTOsRyXrg04
 4sfqU5I4LkPnp2MNLWj9G3U9W5U9R4/nw60IM0i6TTxcolRJ+OosLifdioChpG5iFxylkog1
 6pwrrD7jvP5SGstZkRdDSz3EfySuKgnWqg1sKstmsvr/VR7j4pmLUpVb5hNaZ0MGo30MzOl8
 /35z7QIXytkm7mka94fXxdSITMGK1cDIO3Gm2JakGPkF5d64ya/+5d674xcuXv38wxO9+/sr
 3nQ9OTHgTMJNVVvrUoR/fbOtSiM6EdV76nsQ4xU1PNsSWbAycdx0Uqsd2+rp1RVZtV2xVGh7
 e0D7LUJKc8lqfx9Kz6n/AZIhEqpCAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/Exlknq5s1BB40_KQ7XYT3HS5ZJ8>
Subject: Re: [rtcweb] Proposal to break the ICE impasse
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list
 <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>,
 <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>,
 <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Jan 2019 11:22:04 -0000

--_000_HE1PR07MB3161B0F1D2B5AC9DA72DDFAD93950HE1PR07MB3161eurp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,



> I'm not yet persuaded this is needed. The alleged need here is that there=
 are some ICE-implementing endpoints which will choke if
> they see a profile that doesn't match any actual candidate. I recognize t=
hat this is required by 5245, but that doesn't mean anyone
> ever did it. Can you please point me to a client which would interoperate=
 with a WebRTC endpoint with this change that would not
> if you just always sent the same profile as JSEP currently requires.

I don't think it is ok to *specify* that discarding a MUST is ok as long as=
 nobody can show an implementation that would break by doing so.

Having said that, in order to prevent an RTCWEB shutdown I am generally ok =
with Adam's approach. I would like my pull request comments to be addressed=
, though, that is related to separation between the JSEP API and an applica=
tion using it: an application should be allowed to act according to 5245/dr=
aft-ice-sdp and update the c/m line if it wishes to, but due to the way the=
 JSEP API works such applications might sometimes always include the same v=
alue in the c/m- line.

I also think it shall be explicitly written that JSEP does not update 5245/=
draft-ice-sdp, but rather deviates when it comes to the c/m- line.

Regards,

Christer




On Thu, Jan 24, 2019 at 11:12 AM Adam Roach <adam@nostrum.com<mailto:adam@n=
ostrum.com>> wrote:
Based on conversations in MMUSIC, as well as several offline
conversations with interested parties, I've put together a proposed
change to JSEP that, if accepted, will allow publication of the Cluster
238 documents to move forward.

Note that this new text has no impact on existing implementations (at
least, as far as I am able to discern), which do not currently have the
capability of producing media sections consisting of exclusively TCP
candidates. From that perspective, the change makes existing
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future
compatibility between WebRTC implementations once they finalize TCP
candidate handling (and candidate handling in general for mid-session
offers).

   https://github.com/rtcweb-wg/jsep/pull/862/files

The key insight here is that JSEP's use of ICE completely discards any
meaning associated with the transport parameter, while SIP's use of ICE
does not. The trivial change that I propose, which bears only on future
WebRTC implementations -- that is, which has no as-built specification
to point to -- allows JSEP to continue to ignore the value of the
transport parameter, while specifying that it says the right thing for
SIP implementations to function properly.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb

--_000_HE1PR07MB3161B0F1D2B5AC9DA72DDFAD93950HE1PR07MB3161eurp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"color: rgb(0, 0, 0); font-family:=
 Calibri,Helvetica,sans-serif,&quot;EmojiFont&quot;,&quot;Apple Color Emoji=
&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji,&quot;Segoe UI Symbol&quot=
;,&quot;Android Emoji&quot;,EmojiSymbols; font-size: 12pt;" dir=3D"ltr">
<p style=3D"margin-top:0; margin-bottom:0">Hi,</p>
<p style=3D"margin-top:0; margin-bottom:0">&nbsp;</p>
<div style=3D"color:rgb(0,0,0)">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"></div>
<div>
<div dir=3D"ltr">
<div>&gt; I'm not yet persuaded this is needed. The alleged need here is th=
at there are some ICE-implementing endpoints which will choke if&nbsp;<br>
&gt; they see a profile that doesn't match any actual candidate. I recogniz=
e that this is required by 5245, but that doesn't mean anyone&nbsp;<br>
&gt; ever did it. Can you please point me to a client which would interoper=
ate with a WebRTC endpoint with this change that would not&nbsp;</div>
<div>&gt; if you just always sent the same profile as JSEP currently requir=
es.<br>
</div>
<div><br>
</div>
<div>I don't think it is ok to *specify* that discarding a MUST is ok as lo=
ng as nobody can show an implementation that would break by doing so.</div>
<div><br>
</div>
<div>Having said that, in order to prevent an RTCWEB shutdown I am generall=
y ok with Adam's approach. I would like my pull request comments to be addr=
essed, though, that is related to separation between the JSEP API and an ap=
plication using it: an application
 should be allowed to act according to 5245/draft-ice-sdp and update the c/=
m line if it wishes to, but due to the way the JSEP API works such applicat=
ions might sometimes always include the same value in the c/m- line.&nbsp;<=
/div>
<div><br>
</div>
<div>I also think it shall be explicitly written that JSEP does not update =
5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line.</di=
v>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>Christer</div>
<div><br>
</div>
<div><br>
</div>
<div></div>
<div><br>
</div>
</div>
<br>
<div class=3D"x_gmail_quote">
<div class=3D"x_gmail_attr" dir=3D"ltr">On Thu, Jan 24, 2019 at 11:12 AM Ad=
am Roach &lt;<a class=3D"OWAAutoLink" id=3D"LPlnk567034" href=3D"mailto:ada=
m@nostrum.com" previewremoved=3D"true">adam@nostrum.com</a>&gt; wrote:<br>
</div>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; bord=
er-left:1px solid rgb(204,204,204); padding-left:1ex">
Based on conversations in MMUSIC, as well as several offline <br>
conversations with interested parties, I've put together a proposed <br>
change to JSEP that, if accepted, will allow publication of the Cluster <br=
>
238 documents to move forward.<br>
<br>
Note that this new text has no impact on existing implementations (at <br>
least, as far as I am able to discern), which do not currently have the <br=
>
capability of producing media sections consisting of exclusively TCP <br>
candidates. From that perspective, the change makes existing <br>
implementations no less compliant with JSEP than they were before.<br>
<br>
What this change does provide is both on-paper and in-the-future <br>
compatibility between WebRTC implementations once they finalize TCP <br>
candidate handling (and candidate handling in general for mid-session <br>
offers).<br>
<br>
&nbsp;&nbsp; <a class=3D"OWAAutoLink" id=3D"LPlnk939220" href=3D"https://gi=
thub.com/rtcweb-wg/jsep/pull/862/files" target=3D"_blank" rel=3D"noreferrer=
" previewremoved=3D"true">
https://github.com/rtcweb-wg/jsep/pull/862/files</a><br>
<br>
The key insight here is that JSEP's use of ICE completely discards any <br>
meaning associated with the transport parameter, while SIP's use of ICE <br=
>
does not. The trivial change that I propose, which bears only on future <br=
>
WebRTC implementations -- that is, which has no as-built specification <br>
to point to -- allows JSEP to continue to ignore the value of the <br>
transport parameter, while specifying that it says the right thing for <br>
SIP implementations to function properly.<br>
<br>
/a<br>
<br>
_______________________________________________<br>
rtcweb mailing list<br>
<a class=3D"OWAAutoLink" id=3D"LPlnk115834" href=3D"mailto:rtcweb@ietf.org"=
 target=3D"_blank" previewremoved=3D"true">rtcweb@ietf.org</a><br>
<a class=3D"OWAAutoLink" id=3D"LPlnk329273" href=3D"https://www.ietf.org/ma=
ilman/listinfo/rtcweb" target=3D"_blank" rel=3D"noreferrer" previewremoved=
=3D"true">https://www.ietf.org/mailman/listinfo/rtcweb</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_HE1PR07MB3161B0F1D2B5AC9DA72DDFAD93950HE1PR07MB3161eurp_--