Re: [rtcweb] ICE-Mismatch and WebRTC

[Emil Ivov <[e-mail]>]

On Tue, Jul 8, 2014 at 9:04 PM, Roman Shpount <[e-mail]> wrote:
> On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov <[e-mail]> wrote:
>>
>> On 07.07.14, 21:48, Roman Shpount wrote:
>>>
>>> Is it possible to run into ICE-Mismatch with WebRTC? Should we specify
>>> that default candidate (c= and m= line based candidate) should be
>>> ignored and thus mismatch check should not be performed?
>>
>>
>> I guess running into an ICE mismatch with WebRTC is just as possible as
>> with any other ICE implementation. I suppose the only difference would be
>> that rather than falling back to 3264 semantics, WebRTC implementations will
>> rather drop the session because without ICE, they wouldn't be able to do
>> consent checks for it.
>>
>
> My point was that WebRTC would never use 3264 semantics

Indeed. This was also my point.

> and use address from
> c= and m= lines for any purpose, so why does it need to check that this
> address is correct? Would it be more sensible just ignore whatever value
> happen to be there?

With the exception of trickle ICE's use of :: (or 0.0.0.0) an ICE
mismatch indicates that there is an entity on the signalling path that
is overwriting c= line addresses and m= line ports. The idea of
dropping ICE here is that the infrastructure is likely performing
Hosted NAT Traversal and latching so insisting on ICE is likely to
lead to unexpected situations.

> Or, better yet end point can generate an error instead
> of generating a response with ice-mismatch.

Agreed. Sending an answer with ice-mismatch means downgrading to basic
3264 and that doesn't make sense for WebRTC.

Agreed.

Emil

-- 
https://jitsi.org