How to ask browser not to offer ICE candidates of specific kinds?

[davidsw...@gmail.com]

Is there a browser api to request that IPv6 and local-only IPv4 ICE candidates be excluded from the offer SDP?

I believe that some browsers might stop gathering candidates after reaching a threshold, which can result in offering only unusable candidates. If true, that would mean that even SDP-munging couldn't fix this problem.

[Alexander Abagian]

As to Chromium IPv6, there's an undocumented option for RTCPeerConnection constrants :

peerConnectionConstraints:
    optional: [
        { googIPv6: false }

    ];

For local-only candidates, you could filter them in onicecandidate(). Their gathering shouldn't add any sensitive delay.

среда, 5 января 2022 г. в 03:10:37 UTC+3, davidsw...@gmail.com:

[Yuan Ho]

I have similar problem. For some users, the local candidates only contain useless local host candidates. Neither srflx nor relay candidates are seen. I have no clue.

[David P]

On Wed, Jan 12, 2022 at 4:16 PM Yuan Ho <tian...@gmail.com> wrote:

I have similar problem. For some users, the local candidates only contain useless local host candidates. Neither srflx nor relay candidates are seen. I have no clue.

We have used both self-hosted coturn and a major vendor's managed TURN service, and we found that neither provides a way to review in the TURN server whether it received a request from our test page, or if it did, what it did in response.

Two bits of advice that have been helpful:

1) If you can arrange to use a Linux device at the client side, set its OS-level TTL property above 70. This determines how many router hops you are asking routers to permit enroute to the TURN server. We found this needs to be higher in the EU than the US, but it's not controllable from the browser's js api and merely helps reveal if the problem is due to hop count. If this is the problem, try to put one of your service endpoints nearer to the users in this location.

2) Some TURN servers seem to ignore options in your iceServers beyond a certain number, seemingly beyond four. So be sure that your preferred options are among the first four. It might even help to delete all but 1-4.

[Henrik Boström]

With regards to using googIPv6 for this, this flag was added when we were rolling this feature out and we never intended to keep it around - it's non-standard.

I was just about to remove it actually: https://crbug.com/1315576

[Harald Alvestrand]

Note that https://www.iana.org/assignments/ip-parameters/ip-parameters.xhtml#ip-parameters-2 says that the recommended TTL for IP is 64.

Needing a TTL above this number is a strong sign that your network is significantly misconfigured. (Longer TTLs simply mean that your packets will spend more time in routing loops before being discarded.)

If you really want to sharply limit # of candidates, use a relay-only mode. Only candidates gathered from your TURN server will be exposed.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAE23trszcx7WVBH%2BO9yfyhHcFjtcLbcYdM_p89OhAiToCUZw_Q%40mail.gmail.com.

[Neil Young]

Maybe not what you need, but why not intercepting the ICE candidates enumerated and just forwarding, what you want to be forwarded? I recall to have had a function in my code, which used some regexp in order to decide, if this is something I would like to let know the other side. Works of course for trickle-ice only

[David P]

Thanks. However, our webrtc server doesn't support trickle-ice.

What we chose to do is use regexes in onicecandidate to identify non-private IPv4s and keep those in an array. And when ice-gathering begins, we set a one-second timer. When the timer expires, if our array is non-empty, we send the offer (without bothering to munge the SDP to remove unusable candidates). But if the array is empty, we allow gathering to continue for the full ~4 seconds, which almost never is needed.

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/e_ZUXi8sEfM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8cc21abf-2c2e-4ec5-8ea0-30d7edf67e92n%40googlegroups.com.

[David P]

Thank you, Harald.

We learned about TTL from tech support at our TURN service (a major provider), because some of our users were not getting srflx nor relay candidates from that service (and had only unusable IPv6 and private IPv4s).

We could only ask our engineers in the same EU country to check TTL; it's far too complicated for most users. So we still don't know why the affected users don't get relays.

You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/e_ZUXi8sEfM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVGknyK14thi%3DpJHG0xbC1O_-Y1De0_FOSdpgTxK9%2B2riA%40mail.gmail.com.