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

Issue metadata

Status: Started
Owner:
Cc:
Components:
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

ICE candidates doesn't support domain name

Reported by luczo.la...@gmail.com, 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:
https://tools.ietf.org/html/rfc5245

<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?
http://webrtc.googlecode.com/svn/branches/38/@7822
Tested on Windows and OSX

Patch attached.


 
ice-dns-resolver.patch
1.3 KB Download
Project Member

Comment 1 by braveyao@webrtc.org, Jan 12 2015

Cc: pthatcher@webrtc.org juberti@webrtc.org braveyao@webrtc.org
Labels: Area-Network
Owner: guoweis@webrtc.org
@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 pthatcher@webrtc.org, Jan 12 2015

Labels: EngTriaged IceBox
Owner: juberti@webrtc.org
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:

https://tools.ietf.org/html/rfc5245

      "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 juberti@webrtc.org, 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 juberti@webrtc.org, 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.
ice-dns-resolver-2.patch
4.0 KB Download
Project Member

Comment 13 by juberti@webrtc.org, Jan 20 2015

Could you upload your patch at review.webrtc.org? 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 review.webrtc.org.
ice-dns-resolver-3.patch
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 https://meet.jit.si/[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 - meet.jit.si).
# 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 pthatcher@webrtc.org, Nov 8 2016

Labels: Pri-3
Project Member

Comment 21 by anatolid@webrtc.org, 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 luczo.la...@gmail.com doesn't have time for it.

Comment 23 by ibc@aliax.net, Mar 22 2017

IMHO the NAT64 scenario justifies the need for this feature.

Comment 24 by ibc@aliax.net, 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 deadbeef@chromium.org, 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

Hi gustav...@gmail.com,

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

Thanks.
Project Member

Comment 28 by deadbeef@chromium.org, Apr 13

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 deadbeef@chromium.org, Apr 13

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 zstein@webrtc.org, Jun 25

Owner: zstein@webrtc.org
Status: Started (was: Available)
Project Member

Comment 32 by bugdroid1@chromium.org, Aug 2

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/e20867ff6d92da8901eefc918a68c8b97cb65293

commit e20867ff6d92da8901eefc918a68c8b97cb65293
Author: Zach Stein <zstein@webrtc.org>
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
Reviewed-on: https://webrtc-review.googlesource.com/91300
Commit-Queue: Zach Stein <zstein@webrtc.org>
Reviewed-by: Emad Omara <emadomara@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24176}
[modify] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/api/BUILD.gn
[add] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/api/asyncresolverfactory.h
[modify] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/api/peerconnectioninterface.h
[modify] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/p2p/BUILD.gn
[add] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/p2p/base/basicasyncresolverfactory.cc
[add] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/p2p/base/basicasyncresolverfactory.h
[add] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/p2p/base/basicasyncresolverfactory_unittest.cc
[modify] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/p2p/base/p2ptransportchannel.cc
[modify] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/p2p/base/p2ptransportchannel.h
[modify] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/pc/jseptransportcontroller.cc
[modify] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/pc/jseptransportcontroller.h
[modify] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/pc/jseptransportcontroller_unittest.cc
[modify] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/pc/peerconnection.cc
[modify] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/pc/peerconnection.h
[modify] https://crrev.com/e20867ff6d92da8901eefc918a68c8b97cb65293/pc/peerconnectionfactory.cc

Project Member

Comment 33 by bugdroid1@chromium.org, Aug 13 (6 days ago)

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/b336c2784f5e1e6e2f59e62a18b2d0e21a555b41

commit b336c2784f5e1e6e2f59e62a18b2d0e21a555b41
Author: Zach Stein <zstein@webrtc.org>
Date: Mon Aug 13 17:39:58 2018

Implement serialization for ICE candidates with hostname addresses.

Bug: webrtc:4165
Change-Id: I5ba0f25e458013ac3982648fc33d92d2a00e8fdd
Reviewed-on: https://webrtc-review.googlesource.com/93250
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Zach Stein <zstein@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24275}
[modify] https://crrev.com/b336c2784f5e1e6e2f59e62a18b2d0e21a555b41/pc/webrtcsdp.cc
[modify] https://crrev.com/b336c2784f5e1e6e2f59e62a18b2d0e21a555b41/pc/webrtcsdp_unittest.cc

Sign in to add a comment