Re: [rtcweb] ICE-Mismatch and WebRTC

Well, it should either be MUST ignore, or MUST fail. I can go either way, I
just want deterministic API behavior.
On Jul 11, 2014 1:44 PM, "Emil Ivov" <emcho@jitsi.org> wrote:

> On 11.07.14, 18:07, Justin Uberti wrote:
>
>> The fact that WebRTC implementations MUST ignore the address and port in
>> the c=/m= lines will be written into JSEP, S 5.6/5.7.
>>
>
> MUST sounds unnecessarily strong here. Imagine Alice's WebRTC client sends
> offer:
>
>        ...
>        c=IN IP4 *192.168.0.1*
>        t=0 0
>        a=ice-pwd:asd88fgpdd777uzjYhagZg
>        a=ice-ufrag:8hhY
>        a=ice-options:trickle
>        m=audio 5000 RTP/AVP 0
>        a=candidate:1 1 UDP 2130706431 *192.168.0.1* 5000 typ host
>        ...
>
> and then Bob's browser gets
>
>        ...
>        c=IN IP4 *87.65.43.21*
>        t=0 0
>        a=ice-pwd:asd88fgpdd777uzjYhagZg
>        a=ice-ufrag:8hhY
>        a=ice-options:trickle
>        m=audio 2626 RTP/AVP 0
>        a=candidate:1 1 UDP 2130706431 *192.168.0.1* 5000 typ host
>        ...
>
> Don't you think Bob's browser has a pretty good reason to reject the offer
> because chances are the call would fail anyway?
>
> Emil
>
>
>> On Tue, Jul 8, 2014 at 1:04 PM, Emil Ivov <emcho@jitsi.org
>> <mailto:emcho@jitsi.org>> wrote:
>>
>>     On Tue, Jul 8, 2014 at 9:04 PM, Roman Shpount <roman@telurix.com
>>     <mailto:roman@telurix.com>> wrote:
>>      > On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov <emcho@jitsi.org
>>     <mailto:emcho@jitsi.org>> 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
>>
>>     _______________________________________________
>>     rtcweb mailing list
>>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
> --
> https://jitsi.org
>