Subject: [rtcweb] STUN tests (ICE candidates) and VPN (session delayed)

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 5 Jun 2012 19:30:54 +0200

Hi, just wondering if there could be some "workaround" for this "issue":

I've a VPN (Cisco vpnc) interface in my host. Using Chrome dev-channel
and setting a public STUN server in my WebRTC application I've
realized that during ICE stuf it also takes the VPN interface (which
makes sense) but when it tries to contact the STUN server from the VPN
interface it will have not response (due to VPN/network routes and
so...) which causes a "STUN timeout" (~2-3 seconds). Of course this
happens for *every* outgoing or incoming media session when the
browser needs to create a SDP.

I don't think there is a solution for this "issue", just wondering.

Regards.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Jun 2012 11:19:02 -0700

On 5 June 2012 10:30, Iñaki Baz Castillo <[email-masked]> wrote:
> [...] but when it tries to contact the STUN server from the VPN

It's not an issue.  Some candidate pairs are always going to fail.
That shouldn't block the testing (and nomination) of other pairs.  If
the ICE implementation struggles or lags as a result, then that's a
fault in the implementation.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 5 Jun 2012 15:30:24 -0400

If you don't have trickle candidates, you can't send the offer until you
have gotten all candidates, or given up on the ones that haven't responded
yet.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Jun 2012 12:57:31 -0700

> have gotten all candidates, or given up on the ones that haven't responded

Right.  If you want to collect a server reflexive address for every
host candidate before moving on to other things, then you end up
waiting for a fairly substantial period of time.

There is no reason to gate media negotiation on transport setup.
Trickle candidates is basically a way of saying that you need this
separation.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 5 Jun 2012 23:41:28 +0200

2012/6/5 Martin Thomson <[email-masked]>:
> That shouldn't block the testing (and nomination) of other pairs.

Perhaps I didn't explaing properly. What I mean is that when the
browser sends the STUN UDP request from the VPN interface, it will NOT
receive a UDP response in that interface. So this is the worst case:
timeout in receiving a STUN response.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Jun 2012 14:50:36 -0700

> timeout in receiving a STUN response.

No misunderstanding.  That's expected behaviour.  And it's not
specific to interfaces that can't reach the specified address.  Some
UDP packets just don't make it.  (Though in this case, there are
several sent, so the odds of all of them getting lost is
astronomically low.)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 6 Jun 2012 01:41:17 +0200

> several sent, so the odds of all of them getting lost is

I hope there will be some way to try ICE candidates in all the
networks addresses/interfaces and, later once we have learned which
interfaces "work", then use just them for ICE/STUN discovery.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 06 Jun 2012 10:02:52 +0200

On 06/06/2012 01:41 AM, Iñaki Baz Castillo wrote:
> 2012/6/5 Martin Thomson<[email-masked]>:
That's what ICE/STUN discovery is for.... and once you yank out your 
cable or reconnect your wireless, it all changes anyway, so caching has 
very limited value.

Better to program apps in such a way that you can live with interfaces 
that don't answer.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 6 Jun 2012 20:54:52 +0200

2012/6/6 Harald Alvestrand <[email-masked]>:
> That's what ICE/STUN discovery is for.... and once you yank out your cable
> or reconnect your wireless, it all changes anyway, so caching has very
> limited value.

Sure, but in my case it means ~3 seconds of delay for every WebRTC
session. Just wondering: it would be "nice" if the SO would notify the
browser when some change in the network settings happen, so the
browser would then invalidate its cache and try again all the
interfaces, and not just those that worked in the previous session.

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

---

From: Tim Panton <[email-masked]>
Date: Thu, 7 Jun 2012 10:42:43 +0100

> interfaces, and not just those that worked in the previous session.

Strikes me that you can get close to that with the current API. 
In your candidate callback, you  wait untill you see what you used last-time and use it, 
then if that fails you have to do a re-invite with the stuff that trickled in later.
(and update the cache).

You are still at the mercy of any upstream network changes (e.g. rotating 
pools of public IPs - mifi switching roaming providers etc) that make your cache 
meaningless.

T.

> 
> 
> -- 
> Iñaki Baz Castillo
> <[email-masked]>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 7 Jun 2012 12:01:54 +0200

> then if that fails you have to do a re-invite with the stuff that trickled in later.

It seems suitable :)

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

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 10 Jun 2012 10:21:42 -0400

> interfaces, and not just those that worked in the previous session.

I get that the VPN takes however long to timeout, but given that other STUN servers do respond, why are you dealing your whole WebRTC session waiting for that stun server. Just ignore it once you get some response from another interface.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 10 Jun 2012 22:20:58 +0200

> I get that the VPN takes however long to timeout, but given that other STUN servers do respond, why are you dealing your whole WebRTC session waiting for that stun server. Just ignore it once you g…

That sounds simple and good :)
Thanks.

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