FQDN instead of IP address for ICE candidate

Hello all,

Is it possible to use an FQDN instead of IP address for org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS in JVB configuration ?

In the RFC of ICE I found this (section-15.1) :

An IP address SHOULD be used, but an FQDN MAY be
used in place of an IP address. In that case, when receiving an
offer or answer containing an FQDN in an a=candidate attribute,
the FQDN is looked up in the DNS first using an AAAA record
(assuming the agent supports IPv6), and if no result is found or
the agent only supports IPv4, using an A. If the DNS query
returns more than one IP address, one is chosen, and then used for
the remainder of ICE processing.

Hi,

Jitsi-videobridge doesn’t support it. I’m not sure that chrome supports it either. There was a patch for it years ago, but I don’t know if it ever got merged.

Regards,

Boris

Hi @Boris_Grozev and thank you for the answer.
I believe that FQDN for ICE candidate in the SFU architecture would solve many technical problems.

In our case for example, within our complex network environment, we have 3 types of clients : internal, partners and others.

  • Internal users browsers should get an internal IP 10.X.X.X for ICE candidate.
  • Partners’ browsers should get 100.X.X.X for ICE candidate.
  • and other users should get a different IP address (a public one)

So instead of broadcasting 3 IP addresses to each of these 3 different clients, I think that it would be more “correct” to use FQDN.

What do you think ?

I don’t know enough about your use-case to express an opinion. But if this is something you want to implement, perhaps you can do so in jicofo (filter the candidates before you send them to the clients) or your focus agent.

Boris

Thanks @Boris_Grozev
Do you have any tips on how to filter candidates before sending them in jicofo ? :pray:

There are two options to filter either udp or tcp candidates, to be able to force the client to use one or another, you can get inspired from that code:

I changed org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS to FQDN and it seems to work even with 3 participants. Why is FQDN is not officially supported?