Question about STUN pings

[Dirk-Jan C. Binnema]

Dear List,

While testing webrtc over cellular or VPN connections, using M76 on an
embedded Linux device, I noticed that quite often, after 15 minutes or
so (but other times are seen as well), my device no longer receives any
STUN ping responses:

--8<---------------cut here---------------start------------->8---
(connection.cc:635):
Conn[6d5bc938:0:Net[wlan0:192.168.100.x/24:Wifi:id=1]:vbvuDtl9:1:0:relay:udp:xx.xx.xx.x:57484->RTn9d0HE:1:1685921535:stun:udp:xx.xx.xx.x:58518|C-WI|S|0|0|179897693567073790|506]:
Unwritable after 5 ping failures and 5065 ms without a response, ms
since last received ping=6801 ms since last received data=6021
rtt=1012
[...]
(peer_connection.cc:4117): Changing IceConnectionState 3 => 5
--8<---------------cut here---------------end--------------->8---

and my session is dropped (it never recovers). While all of this happens, the
actual streaming works perfectly fine; in fact, when I disable the
error handling (in connection.cc), streaming continues indefinitely. Of
course, a bit _too_ indefinitely, since now my device will continue
streaming even if the other side is no longer there - the STUN pings
seem to be used for that.

Reading the thread at
https://groups.google.com/forum/#!topic/discuss-webrtc/lkycP4XPy9g
and RFC-5245 suggests those STUN pings are not really necessary.

So a few questions:
- Is this a known problem, where the STUN pings no longer work after a
given time? (I'm assuming it's some network thing?). If so, are there
any ways to avoid that?
- Is it possible to turn off these PINGs (after connection has been
established) but still get my ICE state etc. updated when the remote
side vanishes (ie., RTCP etc. should be enough for that, or?)

Thanks in advance,
Dirk.

[Nils Ohlmeier]

While it is correct that the continuous STUN binding requests, called consent requests, are not needed to establish the connection they are meant to allow you to detect that the network connections is broken. Imagine if the remote side machine for example simply kernel panics and doesn't respond to any network traffic at all any more.

RTCP is not enough, because it is not frequent enough and not acknowledged, so you never know if they were received.

I have a hard time to imagine why a network would let the initial STUN packets pass, then let RTP packets through, but start to block the STUN packets. I would try to find out why the network is doing that rather then to turn off a feature.

Best

  Nils Ohlmeier

[Dirk-Jan C. Binnema]

Dear list,

Thanks for the insights.

Haven't been able to find the root-cause of why the network behaves in
the way it does, but as a work-around, it seems using TCP rather than
UDP avoids the problem.

Kind regards,
Dirk.

[vzw.kuna...@gmail.com]

Hey Dirk, can you please elaborate a little more on the details of where you made the change from TCP to UDP ? Where is this setting exactly, how do you change it?

Thanks