Re: [rtcweb] Default proto transport in JSEP

[Roman Shpount <[e-mail]>]

On Mon, Nov 19, 2018 at 2:36 PM Iñaki Baz Castillo <[e-mail]> wrote:

> On Mon, 19 Nov 2018 at 19:28, Roman Shpount <[e-mail]> wrote:
> > The problem is that JSEP proposes to use UDP protocol in the m= 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= line, this will mean either ICE
> mismatch or additional candidate with protocol, address, and port form m=
> and c= line.
>
> We could just assume that no WebRTC capable endpoint will (absolutely
> never) rely on the content of the c= line or the proto indicated in
> the m= 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= 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=
and m= 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= and m= line
but does not achieve the interop.

Regards,
_____________
Roman Shpount