MIME-Version: 1.0
References: <CA+9kkMADnZJBaV0hfLuwGU0bGBEP5tCPZ=8Zd_85Dgzi37ghAQ@mail.gmail.com>
 <CAD5OKxsNFFmER__H0+5Mzts58yn9cWLMEADhSnLR4nreKD9WAQ@mail.gmail.com>
 <CALiegfkHXv6f8P3C-C=2RKCyxWfzCAzkzOqxBXmmsNCPrZzFfg@mail.gmail.com>
In-Reply-To: <CALiegfkHXv6f8P3C-C=2RKCyxWfzCAzkzOqxBXmmsNCPrZzFfg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Mon, 19 Nov 2018 15:02:08 -0500
Message-ID: <CAD5OKxswZdGm1CYvy=NoyEtN-eFFp7Sc8mmGT7jAJ-q3msJYXA@mail.gmail.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Cc: RTCWeb IETF <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008ef335057b09fe19"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/k-CD-zFA2iBu5DCXO2w-o_QdM8A>
Subject: Re: [rtcweb] Default proto transport in JSEP
Precedence: list

--0000000000008ef335057b09fe19
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 19, 2018 at 2:36 PM I=C3=B1aki Baz Castillo <ibc@aliax.net> wro=
te:

> On Mon, 19 Nov 2018 at 19:28, Roman Shpount <roman@telurix.com> wrote:
> > The problem is that JSEP proposes to use UDP protocol in the m=3D line =
and
> at the same time update address and port to the currently selected
> candidate. Based on ice-sip-sdp, if protocol of the current selected
> candidate does not match protocol in the m=3D line, this will mean either=
 ICE
> mismatch or additional candidate with protocol, address, and port form m=
=3D
> and c=3D line.
>
> We could just assume that no WebRTC capable endpoint will (absolutely
> never) rely on the content of the c=3D line or the proto indicated in
> the m=3D line (no matter it indicates "CHICKEN" as proto).
>

This is incorrect. Only the transport part of the proto line does not
matter since it is overwritten by the ICE candidate. The rest of the proto
is needed to know if this m=3D line is audio, video, or data channel.

In any case, this is about interop with existing (and already WebRTC
compatible) implementations. At this point, I would be happy, if either c=
=3D
and m=3D line were populated by some constant data or modified based on rul=
es
which serve some purpose like legacy interop. I would actually greatly
prefer former, but if someone still cares about RFC 5245 interop will be
fine with the later. Right now JSEP requires to change the c=3D and m=3D li=
ne
but does not achieve the interop.

Regards,
_____________
Roman Shpount

--0000000000008ef335057b09fe19
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div dir=3D"ltr" class=3D"gmail_signature" data-smart=
mail=3D"gmail_signature">On Mon, Nov 19, 2018 at 2:36 PM I=C3=B1aki Baz Cas=
tillo &lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.net</a>&gt; wrote:<br>=
</div></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mo=
n, 19 Nov 2018 at 19:28, Roman Shpount &lt;<a href=3D"mailto:roman@telurix.=
com" target=3D"_blank">roman@telurix.com</a>&gt; wrote:<br>
&gt; The problem is that JSEP proposes to use UDP protocol in the m=3D line=
 and at the same time update address and port to the currently selected can=
didate. Based on ice-sip-sdp, if protocol of the current selected candidate=
 does not match protocol in the m=3D line, this will mean either ICE mismat=
ch or additional candidate with protocol, address, and port form m=3D and c=
=3D line.<br>
<br>
We could just assume that no WebRTC capable endpoint will (absolutely<br>
never) rely on the content of the c=3D line or the proto indicated in<br>
the m=3D line (no matter it indicates &quot;CHICKEN&quot; as proto).<br></b=
lockquote><div><br></div><div>This is incorrect. Only the transport part of=
 the proto line does not matter since it is overwritten by the ICE candidat=
e. The rest of the proto is needed to know if this m=3D line is audio, vide=
o, or data channel.=C2=A0</div><div><br></div><div>In any case, this is abo=
ut interop with existing (and already WebRTC compatible) implementations. A=
t this point, I would be happy, if either c=3D and m=3D line were populated=
 by some constant data or modified based on rules which serve some purpose =
like legacy interop. I would actually greatly prefer former, but if someone=
 still cares about RFC 5245 interop will be fine with the later. Right now =
JSEP requires to change the c=3D and m=3D line but does not achieve the int=
erop.</div><div><br></div><div>Regards,</div>_____________<br>Roman Shpount=
<br class=3D"gmail-Apple-interchange-newline"><div>=C2=A0</div></div></div>

--0000000000008ef335057b09fe19--