Re: [rtcweb] ICE-Mismatch and WebRTC

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