New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 4165 link

Starred by 28 users

Issue metadata

Status: Fixed
Last visit 16 days ago
Closed: Aug 27
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment

ICE candidates doesn't support domain name

Reported by, Jan 9 2015

Issue description

What steps will reproduce the problem?
1. Use an ice-candidate with hostname instead of IP address like this: 
a=candidate:1 1 udp 2130706431 your.hostname 11365 typ host generation 0
2. Try to make the connection

What is the expected result?
The hostname is resolved and connection is successfully created.

Described here:

<connection-address>:  is taken from RFC 4566 [RFC4566].  It is the
      IP address of the candidate, allowing for IPv4 addresses, IPv6
      addresses, and fully qualified domain names (FQDNs).  <----------

What do you see instead?
No connection.

What version of the product are you using? On what operating system?
Tested on Windows and OSX

Patch attached.

1.3 KB Download
Project Member

Comment 1 by, Jan 12 2015

Labels: Area-Network
@guoweis, PTAL!
I've never seen this supported, and it doesn't seem like it fits well with the design of ICE.

Can you mention more about why this is important?
Project Member

Comment 3 by, Jan 12 2015

Labels: EngTriaged IceBox
I would like to use an IP route optimization service which needs domain names.
Can you explain more about how your scenario works, end-to-end?
We use SFU (Selective Forwarding Unit) so the peers connect to a centralized streaming server not p2p each other. Using FQDN enables us to find the optimal route between SFU and the peers.
I don't understand why FQDN doesn't fit the design of ICE since the RFC contains this possibility as a "MAY" requirement:

      "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."

Yeah, I read up more on that part of 5245 and I understand how it should work now. But I don't quite understand how the route optimization service fits into your design.
We use a kind of technology which is based on DNS lookup, that's why we need FQDN in SDP. But I don't see the correlation between our purpose of the request and the feasibility of implementation.
Project Member

Comment 9 by, Jan 15 2015

Well, I'm trying to determine the priority of this, and said priority is largely based on how general the problem is (which I don't understand yet).

The proposed patch isn't a fix we can take since it does a blocking DNS request on the media thread, so some work would be needed to figure out how to incorporate an AsyncResolver.
We use a central media relay unit instead of p2p connection. The clients connect to this server. If we use IP addresses the packets will travel through the public internet.
We want to use a traffic optimization service for a better user experience. This service has local DNS servers which resolves the domain names to their nearest server's IP address so we can send our traffic through their network which is faster than the public internet.
That's why we need the domain name.
Project Member

Comment 11 by, Jan 16 2015

Status: Available
Makes sense. 

I think the right approach for this patch is to use an AsyncResolver inside Transport::OnRemoteCandidate_w to convert the DNS name to an IP asynchronously (and then pass the result to the TransportChannel, as OnRemoteCandidate_w does for IP candidates)
I have created an another patch which uses AsyncResolver.
4.0 KB Download
Project Member

Comment 13 by, Jan 20 2015

Could you upload your patch at It will be easier to review it there.

I took a quick look and it's going in the right direction. You won't need to post a message when the resolve is done though, since you'll already be on the right thread (i.e., the worker)
You were right. I will try to upload to
3.2 KB Download
I have the same issue 
But I don't know how to patch 
can you tell me more information

Thank you very much
I have the same issue, hope this patch can be adopted.

Comment 18 Deleted

The route optimisation is not the only use-case where FQDN in the candidates is mandatory.
Apple already requires you to only submit apps to AppStore which have NAT64 support.
This means that if your iOS device is behind a NAT64 network (like a lot of mobile network operators in the US do) your app is forced to operate in a NAT64 environment.

If you are behind a NAT64 network you can only access IPv4 address via the Domain Name Resolution. 
So either the SFU must be on an IPV6/IPV4 dual stack network or the SFU is in IPV4 and it reports FQDN candidates in its offer.

You can reproduce this use-case in 5 minutes:

Steps to reproduce:
# Create a NAT64 network with a recent MacOS based device. This will be your NAT64 gw/hub, like a mobile network operator.
# Join that network with your another machine (called desktop_#1).
# Open a Chrome in desktop_#1 and navigate to[random_room_name] where "[random_room_name]" is of your choice.
# Join a simple IPv4 network with your third machine (called desktop_#2).
# Open a Chrome in desktop_#2 and navigate to the same room as you did before.

Actual result:
# The browsers can access to the website (because the website address is resolved by its FQDN -
# The browsers cannot join the SFU (Jitsi in this case), because the SDP from the SFU contains IPV4 only candidates. So no streaming is created between the two browsers. See chrome:://webrtc-internals 
# The two Chrome browsers cannot see each other's camera.

Expected result:
# The two Chrome browsers can join the SFU and can see each other's camera.

I don't really see any reason why not to handle FQDN candidates by WebRTC.
The RFC supports it.
There is already a patch, which works in production environment.
The lack of this feature makes impossible to use SFU conference networks.
The lack of this feature makes the connection slower since no routing optimisation can be performed by a third party DNS/routing optimiser.

Project Member

Comment 20 by, Nov 8 2016

Labels: Pri-3
Project Member

Comment 21 by, Dec 14 2016

Owner: ----
Any update on this feature?  As it was explained in #comment19 this is very useful in NAT64 environments.

Would an updated patch be considered and welcomed in this case?  I can try if doesn't have time for it.

Comment 23 by, Mar 22 2017

IMHO the NAT64 scenario justifies the need for this feature.

Comment 24 by, Mar 22 2017

BTW: shouldn't the patch take the first AAAA record (rather than the first A or AAAA record)? that's what RFC 5245 says, and I'm not sure whether the AsyncResolver does that...
Project Member

Comment 25 by, Mar 23 2017

> Would an updated patch be considered and welcomed in this case?

Sure, patches are always welcome. You can add me as a reviewer.

Comment 26 Deleted


Please update the patch because I do not have enough time for it.

Project Member

Comment 28 by, Apr 13 2018

Labels: -Pri-3 -IceBox Pri-2
deadbeef: you might want to re-evalute wrt to Safari's proposal to use mdns for host candidates.
Project Member

Comment 30 by, Apr 13 2018

That's why we're bumping up the priority; we thought it would make sense to add support for normal hostname candidates first.
Project Member

Comment 31 by, Jun 25 2018

Status: Started (was: Available)
Project Member

Comment 32 by, Aug 2

The following revision refers to this bug:

commit e20867ff6d92da8901eefc918a68c8b97cb65293
Author: Zach Stein <>
Date: Thu Aug 02 21:20:15 2018

Add AsyncResolverFactory interface and basic implementation.

The factory is plumbed down to P2PTransportChannel and will eventually
be used to resolve hostnames. Uses of PacketSocketFacotry::CreateAsyncResolver
will eventually be migrated to use this factory instead.

Bug:  webrtc:4165 
Change-Id: I1c48b2ffb8649609a831eba291f67ce544bb10eb
Commit-Queue: Zach Stein <>
Reviewed-by: Emad Omara <>
Reviewed-by: Steve Anton <>
Reviewed-by: Qingsi Wang <>
Cr-Commit-Position: refs/heads/master@{#24176}

Project Member

Comment 33 by, Aug 13

The following revision refers to this bug:

commit b336c2784f5e1e6e2f59e62a18b2d0e21a555b41
Author: Zach Stein <>
Date: Mon Aug 13 17:39:58 2018

Implement serialization for ICE candidates with hostname addresses.

Bug:  webrtc:4165 
Change-Id: I5ba0f25e458013ac3982648fc33d92d2a00e8fdd
Reviewed-by: Steve Anton <>
Reviewed-by: Seth Hampson <>
Commit-Queue: Zach Stein <>
Cr-Commit-Position: refs/heads/master@{#24275}

Project Member

Comment 35 by, Aug 27

Status: Fixed (was: Started)

Sign in to add a comment