Re: [rtcweb] Proposal to break the ICE impasse

[Roman Shpount <[e-mail]>]

On Tue, Jan 29, 2019 at 4:53 PM Eric Rescorla <[e-mail]> wrote:

>
> On Tue, Jan 29, 2019 at 11:28 AM Roman Shpount <[e-mail]> wrote:
>
>> On Tue, Jan 29, 2019 at 2:05 PM Iñaki Baz Castillo <[e-mail]> wrote:
>>
>>> I understand your point. But still I don't understand the purpose of the
>>> new draft (set TCP/DTLS/etc in proto line if there are just TCP candidates
>>> in the offer).
>>>
>>
>> The purpose is standard compliance. If nominated candidate is UDP, proto
>> line should be UDP. If nominated candidate is TCP, proto line should be
>> TCP. If you do not care about the c= and m= line, put the dummy values and
>> UDP there, but this breaks legacy interop by causing ICE mismatch.
>>
>
> This is two separate statements that don't necessarily follow form each
> other
>
> 1. This is a matter of standards compliance.
> 2. It breaks legacy interop
>
> I agree on point (1). I'm still waiting for someone to demonstrate point
> (2)
>
>>
>>
Unfortunately 2 is impossible to demonstrate to your satisfaction since:

a. Browsers currently do something different from the spec (once again is
being debated) and include additional candidates even after ICE nomination
was completed

b. Using UDP based proto when TCP based candidate is nominated only affects
server provider SBC or media servers. These components are typically easier
to patch when dealing with non-compliant implementations similar to current
JSEP clients. What you are arguing is to keep the "special" profile for
SBC/Media Servers indefinitely instead of making browsers and VoIP end
points do the same thing. This is simply moving the complexity from one
place to another.

As an observation, since JSEP currently mandates that c= and m= lines are
already updated (address and port) based on the ICE candidate which is
nominated, I am not sure if additional complexity of updating the proto
line at the same time is all that great.

Regards,
_____________
Roman Shpount