Subject: [rtcweb] ICE-Mismatch and WebRTC

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Jul 2014 15:48:40 -0400

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?
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 7 Jul 2014 22:29:29 +0200

Yes please.

--
Iñaki Baz Castillo
<[email-masked]>
On Jul 7, 2014 9:50 PM, "Roman Shpount" <[email-masked]> 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?
> _____________
> Roman Shpount
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 08 Jul 2014 18:33:23 +0200

On 07.07.14, 21:48, Roman Shpount wrote:
> 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.

Emil

-- 
https://jitsi.org

---

From: Roman Shpount <[email-masked]>
Date: Tue, 8 Jul 2014 15:04:21 -0400

On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov <[email-masked]> wrote:

> 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 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? Or, better yet end point can generate an error
instead of generating a response with ice-mismatch.

It would also be nice to define what WebRTC end point is supposed to do if
it gets ice-mismatch attribute in the SDP response. I would assume dropping
the connection is one sensible option. Generating an error would be another
one.

_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 8 Jul 2014 21:16:14 +0200

2014-07-08 21:04 GMT+02:00 Roman Shpount <[email-masked]>:
> My point was that WebRTC would never use 3264 semantics 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?

I assume that is exactly what current WebRTC browsers do.

Yes, we could drop the entire m line and instead use a "media
identifier" (mid), and we could drop the half of the classic content
of a SDP. But that would break interop with future legacy gateways.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 8 Jul 2014 22:04:10 +0200

On Tue, Jul 8, 2014 at 9:04 PM, Roman Shpount <[email-masked]> wrote:
>> 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

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

---

From: Justin Uberti <[email-masked]>
Date: Fri, 11 Jul 2014 09:07:41 -0700

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.

On Tue, Jul 8, 2014 at 1:04 PM, Emil Ivov <[email-masked]> wrote:

> be
> will

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 11 Jul 2014 18:13:34 +0200

I suggest renaming JSEP draft to "SDP made simple".

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 11 Jul 2014 13:42:34 -0400

On Fri, Jul 11, 2014 at 12:07 PM, Justin Uberti <[email-masked]> wrote:

> Is it going to completely ignore these parameters or would it still honor
port 0 to indicate that m line disabled?

What about 0.0.0.0 address to indicate hold? These should not be allowed
per RFC 5245 section 9.1.1.1 but I still do see it used in SIP, especially
with various B2BUA scenarios where this is the only way for a pure
signaling agent to put a call on hold or to resolve collision. There are
other ways to deal with this in WebRTC but this will still come up during
interop with SIP.

Would it also document on what happens when WebRTC implementation receives
an answer SDP with ice-mismatch attribute? An error in such case is
probably the most appropriate action.
_____________
Roman Shpount

---

From: Emil Ivov <[email-masked]>
Date: Fri, 11 Jul 2014 19:44:08 +0200

> 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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Tue, Jul 8, 2014 at 9:04 PM, Roman Shpount <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      > On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >>
>     [email-masked] <mailto:[email-masked]>

-- 
https://jitsi.org

---

From: Justin Uberti <[email-masked]>
Date: Fri, 11 Jul 2014 11:55:46 -0700

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" <[email-masked]> wrote:

> MUST sounds unnecessarily strong here. Imagine Alice's WebRTC client sends
> offer:
>
>        ...
>        c=IN IP4 *192.168.0.1*
>        t=0 0
> 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
>
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 11 Jul 2014 12:03:06 -0700

Yes, port 0 will be understood.
No, 0.0.0.0 will not be handled.
Agree ice-mismatch should result in an error, similar to that if no ICE
info was present.

---

From: Emil Ivov <[email-masked]>
Date: Fri, 11 Jul 2014 22:23:00 +0200

On 11.07.14, 20:55, Justin Uberti wrote:
> Well, it should either be MUST ignore, or MUST fail. I can go either
> way, I just want deterministic API behavior.

I'd completely agree with MUST fail.

> On Jul 11, 2014 1:44 PM, "Emil Ivov" <[email-masked]
>             a=ice-pwd:__asd88fgpdd777uzjYhagZg
>             a=ice-ufrag:8hhY
>             a=ice-options:trickle
>             m=audio 5000 RTP/AVP 0
>             a=ice-pwd:__asd88fgpdd777uzjYhagZg
>             a=ice-ufrag:8hhY
>             a=ice-options:trickle
>             m=audio 2626 RTP/AVP 0
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>              On Tue, Jul 8, 2014 at 9:04 PM, Roman Shpount
>         <[email-masked] <mailto:[email-masked]>
>              <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>               > On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov
>         <[email-masked] <mailto:[email-masked]>
>              <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>               >>
>               >>> Is it possible to run into ICE-Mismatch with WebRTC?
>         Should we
>              specify
>               >> with any other ICE implementation. I suppose the only
>         difference
>              would be
>               >> rather drop the session because without ICE, they
>         wouldn't be
>              able to do
>               >> consent checks for it.
>               >>
>               >
>               > c= and m= lines for any purpose, so why does it need to
>         check
>              that this
>              _________________________________________________
>              rtcweb mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/__listinfo/rtcweb
>         <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>
>
>     --
>     https://jitsi.org
>

-- 
https://jitsi.org

---

From: Roman Shpount <[email-masked]>
Date: Fri, 11 Jul 2014 17:20:46 -0400

I would agree with:

1. Must fail if c=/m= line IP does not match any candidate. Must also fail
if rtcp attribute does not match any RTCP candidates.

2. Must fail if "ice-mismatch" attribute is present same as no ICE

3. Port 0 in m= line to disable the line must be understood

4. c= line with 0.0.0.0 must fail

Does this make sense?
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Sat, 12 Jul 2014 08:28:10 -0700

Agreed, with a special case for the no-candidates trickle ICE situation.

---

From: Kevin Dempsey <[email-masked]>
Date: Mon, 14 Jul 2014 09:06:47 +0100

In Emil's example, Bob might later receive a trickled candidate:
a=candidate:1 1 UDP 1130706431 *87.65.43.21* 5000 typ srflx raddr
192.168.0.1 rport 5000
which, if it was in the initial offer, would mean there was no mismatch.

On 12 July 2014 16:28, Justin Uberti <[email-masked]> wrote:

>> 1. Must fail if c=/m= line IP does not match any candidate. Must also
>> fail if rtcp attribute does not match any RTCP candidates.
>>

---

From: Emil Ivov <[email-masked]>
Date: Mon, 14 Jul 2014 10:56:58 +0200

> which, if it was in the initial offer, would mean there was no mismatch.

How would that happen?

If you are thinking of a trickle ICE capable middle box then it
could/should simply do it all at once. What reason would it have to
delay the extra candidate?

Emil

-- 
https://jitsi.org

---

From: Kevin Dempsey <[email-masked]>
Date: Mon, 14 Jul 2014 10:10:11 +0100

The initial offer is sent with only host candidates and the c= line gets
mangled by Alice's gateway* to match her external IP. Alice's client then
'discovers' the external address using STUN and sends the srflx candidate
which happens to match the mangled c= line.

*an application gateway that claims to be 'SIP aware' and modifies the SDP
to match the externally visible IP address. I suppose it may also modify
the candidate line if it does a simple match/replace.