The server stun returned an error with code 701 stun host lookup received error

The WebRTC API event icecandidateerror is sent to an RTCPeerConnection if an error occurs while performing ICE negotiations through a STUN or TURN server. The event object is of type RTCPeerConnectionIceErrorEvent, and contains information describing the error in some amount of detail.

This event is not cancelable and does not bubble.

Syntax

Use the event name in methods like addEventListener(), or set an event handler property.

addEventListener('icecandidateerror', (event) => { });

onicecandidateerror = (event) => { };

Event type

Event properties

The RTCPeerConnectionIceErrorEvent interface includes the properties found on the Event interface, as well as the following properties:

address Read only

A string providing the local IP address used to communicate with the STUN or TURN server being used to negotiate the connection, or null if the local IP address has not yet been exposed as part of a local ICE candidate.

errorCode Read only

An unsigned integer value stating the numeric STUN error code returned by the STUN or TURN server. If no host candidate can reach the server, this property is set to the number 701, which is outside the range of valid STUN error codes. The 701 error is fired only once per server URL, and only while the icegatheringstate is gathering.

errorText Read only

A string containing the STUN reason text returned by the STUN or TURN server. If communication with the STUN or TURN server couldn’t be established at all, this string will be a browser-specific string explaining the error.

port Read only

An unsigned integer value giving the port number over which communication with the STUN or TURN server is taking place, using the IP address given in address. null if the connection hasn’t been established (that is, if address is null).

url Read only

A string indicating the URL of the STUN or TURN server with which the error occurred.

Description

The error object’s errorCode property is one of the numeric STUN error codes. There is one additional, WebRTC-specific, error which lies outside the valid STUN error code range: 701. Error 701 indicates that none of the ICE candidates were able to successfully make contact with the STUN or TURN server.

The 701 error is fired only once per server URL from the list of available STUN or TURN servers provided when creating the RTCPeerConnection. These errors occur only when the connection’s ICE gathering state is gathering.

Example

The following example establishes a handler for icecandidateerrors that occur on the RTCPeerConnection pc. This handler looks specifically for 701 errors that indicate that candidates couldn’t reach the STUN or TURN server.

When this happens, the server URL and the error message are passed to a function called reportConnectFail() to log or output the connection failure.

pc.addEventListener("icecandidateerror", (event) => {
  if (event.errorCode === 701) {
    reportConnectFail(event.url, event.errorText);
  }
});

Note that if multiple STUN and/or TURN servers are provided when creating the connection, this error may happen more than once, if more than one of those servers fails. Each provided server is tried until a connection is established.

Specifications

Specification
WebRTC 1.0: Real-Time Communication Between Browsers # dom-rtcpeerconnection-onicecandidateerror

Browser compatibility

BCD tables only load in the browser

STUN server address is incompatible | Error code=701:

I have installed the TURN server everything in the server code is working fine. no error in the log file. only a warning stating

but the TURN server running on the server.

here is what shows when I check lsof -i :3478

when I check STUN in Trickle ICE it throws an errors

what’s going wrong in this.

2 Answers 2

I think that 701 error is a more generic connectivity error that Trickle ICE uses to indicate it didn’t get a binding response back. Run stunclient your.stun.ip.address with the command line tools at www.stunprotocol.org to see if your STUN service is accessible from the outside world.

STUN technically requires being hosted on a device with two IP addresses and two ports. It’s typically a command line parameter to specify which IP addresses the server should listen on. But most server implementations can operate on a host with a single IP address.

The second IP address and port on the server is used for STUN client filtering tests to detect what type of NAT is in effect. The client sends a binding request on the server’s primary ip and port, but with a change request attribute to have the server respond from the alternate IP address or port. More often than not, this binding request with a change-request attribute fails since NATs will not forward traffic from the other IP/port.

The filtering test is useful for logging what type of NAT the client is on. So that failed connections can be debugged and that success/failure metrics can be correlated to NAT type.

Since most ICE implementations will exchange all available address candidates (local, mapped, and relay), the filtering test isn’t very or useful to connectivity establishment.

Источник

Coturn stun server returned an error with code=701

I have my own server with ubuntu 19.

NOTE: I need a stun/turn server for a video chat web application. It works already if both devices are in the same network.

I have successfully installed and configured coturn. I can successfully start the turnserver by running: turnserver or nohup turnserver & in the terminal.

NOTE: I have an SSH connection to my server.

I also ensured that the necessary ports are open and checked them with netstat -tulpn .

I have been also restarting coturn a few times while testing sudo service coturn restart .

I use these configurations in the turnserver.conf :

This is my iceServers config in js, which I believe should work (I have done TONS of other combinations).

I have done TONS of different stun/turn server combinations, e.g.:

I used google’s stun servers: stun.l.google.com:19302, stun2.l.google.com:19302 etc.

I tried ports 3478 and 5349 (of course after restarting coturn)

I tried to use credentials for the stun server, but I am sure it does not need them

I tried to use IP6 address

Basically the testing URL above always gives me:

It does not matter whether I use google’s stun server or my own, the error is the same.

My webproject and the video chat WORKS great if I use the same network, but I believe stun and turn servers are not used in the same network.

Also while I updated my JS file I always deleted cache, so the new JS file was used. So that was also not an issue.

EDIT

This combination does not give an error, only:

I simply used IP6 for the stun and IP4 for turn. Video chat in different network still does not work, nowhere other errors to find.

EDIT:

Noticed today that https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ does not work. I had no errors on firefox. BUT you can enter some nonesense there and it will also show no errors.

EDIT:

I have also added now valid certificates:

Seems to work. I restarted coturn and status tells me that everything is running without issues.

Video chat still does not work in different networks.

Источник

Getting Timeout and Error with code 701 on clicking Gather Candidates for ICE Server #1251

Comments

chiangky commented Jan 6, 2020

Please read first!

Please use discuss-webrtc for general technical discussions and questions.

• [ v] I have provided steps to reproduce
• [ v] I have provided browser name and version
• [ v] I have provided a link to the sample here or a modified version thereof

Browser affected

Google Chrome Version 79.0.3945.88 (Official Build) (64-bit)
Firefox v71.0 (32bit)

Description

In my same PC and same networking environment, both Chrome & Firefox browser has different testing result. Firefox works fine but Chrome is not working.

Steps to reproduce

1. Connect the PC to the router (My Public IP: 112.118.183.xxx ; LAN local IP: 192.168.8.228)
2. Launch https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
3. Click «Reset to defaults» button
4. Input STUN URI: «stun:stun1.l.google.com:19302» and click «Add Server» button
5. Input STUN URI: «stun:stun2.l.google.com:19302» and click «Add Server» button
6. Input STUN URI: «stun:stun3.l.google.com:19302» and click «Add Server» button
7. Input STUN URI: «stun:stun4.l.google.com:19302» and click «Add Server» button
8. ICE options «IceTransports value:» set to «all» (default)
9. ICE options «ICE Candidate Pool:» set to «0» (default)
10. Click on «Gather Candidates» button

Expected results

It should display all the candidates of Type ‘Host’ or ‘srflx’, and no errors show at the bottom.

Actual results

Error code 701 shows at the bottom of «Gather Candidates» button.
The server stun:stun1.l.google.com:19302 returned an error with code=701:
STUN allocate request timed out.
The server stun:stun2.l.google.com:19302 returned an error with code=701:
STUN allocate request timed out.
The server stun:stun3.l.google.com:19302 returned an error with code=701:
STUN allocate request timed out.
The server stun:stun.l.google.com:19302 returned an error with code=701:
STUN allocate request timed out.
The server stun:stun4.l.google.com:19302 returned an error with code=701:
STUN allocate request timed out.

Screenshot of Chrome test result:

Screenshot of Firefox test result:

The text was updated successfully, but these errors were encountered:

Источник

701 error #1232

Comments

Archer-Thane commented Oct 28, 2019

The issue is not browser specific. Tested with: Chrome Version 78.0.3904.70 (Official Build) (64-bit)
and Firefox 69.0.1

Description

I’ve used pion turn server. the instructions are found inside github page
After a simple setup using test as username and password, I see a 701 error code from trickle Ice page.
Worth to mention that the pion program started correctly at port 3478 on UDP. this is verified using fuser 3478/tcp command from server’s terminal.
First of all, what means this error and where can I find description about error codes, and second is how to fix this?

Steps to reproduce

1- open https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
2- STUN or TURN URI: turn:aalimoshaver.com:3478
3- TURN username: test
4- TURN password: test

Expected results

This should show a success test, which indicates done.

Actual results

I got these as error text:
The server stun:aalimoshaver.com:3478 returned an error with code=701:
STUN allocate request timed out.
The server turn:aalimoshaver.com:3478?transport=udp returned an error with code=701:
TURN allocate request timed out.

The text was updated successfully, but these errors were encountered:

Источник

The server returned an error with code=701: STUN/TURN allocate request timed out. #678

Comments

bruke291 commented Jan 7, 2021

First, many thanks to everybody and so sorry for my English.

I’m beginer in this, i installed and configured Coturn, it looks good. But when i tried test with Trickle ICE tools i got error 701:

I have tried everything but it still fails.

Please help me!
Thanks and best regards!

The text was updated successfully, but these errors were encountered:

bruke291 commented Jan 7, 2021

@misi can you help me look into it please

misi commented Jan 7, 2021

See for stun 701 error code:
The standard

If no host candidate can reach the server, errorCode will be set to the value 701 which is outside the STUN error code range. This error is only fired once per server URL while in the RTCIceGatheringState of «gathering».

The source of a browser implementation

So try to check your app signaling and server rechability from the client..

bruke291 commented Jan 8, 2021

Thanks for supporting me.
Im suspecting the problem is that there are some un-open ports between min-port 49152 and max-port 65535, because i checked stun/turn url on browser and both port 3478 and 5349 are open.
This is the list of detail specs:

I would appreciate it very much if you could provide me with a more detailed explanation or support, since my experience with setting up the server is still quite limited.

Thank you very much!

bruke291 commented Jan 8, 2021

See for stun 701 error code:
The standard

If no host candidate can reach the server, errorCode will be set to the value 701 which is outside the STUN error code range. This error is only fired once per server URL while in the RTCIceGatheringState of «gathering».

The source of a browser implementation

So try to check your app signaling and server rechability from the client..

About reachability, as i mentioned earlier, i checked everything i could, and i am suspecting the problem is that there are some un-open ports between min-port 49152 and max-port 65535.

misi commented Jan 8, 2021

@bruke291 Unfortunately I am busy with the actual release. I can support you only latter..
Many thanks for your patience..

misi commented Jan 8, 2021 •

Have you tested that from your browser machine you can create a tcp connection to the server tcp port?
I use in my example server ip 127.0.0.1

You should see if e.g. telnet server port that telnet connection established.. connected

And on server you should see if started with —verbose option

bruke291 commented Jan 8, 2021

@bruke291 Unfortunately I am busy with the actual release. I can support you only latter..
Many thanks for your patience..

@misi please, take your time. I appreciate all the help you have given me so far. Thank you very much!

bruke291 commented Jan 8, 2021

Have you tested that from your browser machine you can create a tcp connection to the server tcp port?
I use in my example server ip 127.0.0.1

You should see if e.g. telnet server port that telnet connection established.. connected

And on server you should see if started with —verbose option

Yes i can create a tcp connection to my server with tcp port.
Im using this command:
telnet 127.0.0.1 3478
and the result is the same as yours
29: IPv4. tcp or tls connected to: 127.0.0.1:59062

And when I apply the specs to the WebRTC demo, it works. But when i tried to test my STUN/TURN server on Trickle ICE I got an error like the Issue Title.

LordDashMe commented Apr 6, 2021

Same issue here!
No changes from the server config, this is working before but now this error message keep showing.

plukito commented Apr 8, 2021

In my case, I added ?transport=tcp and it’s working immediately because I opened the port as TCP.
Check whether you open the port as UDP or TCP.

LordDashMe commented Apr 11, 2021

Same issue here!
No changes from the server config, this is working before but now this error message keep showing.

Update: In Firefox browser, no message shown related to that error. This message can only be seen on Chrome.

ivanlukomskiy commented Jul 2, 2021 •

For me the cause of timeout was that I set up coturn without providing credentials.

Here is how I started the server:
turnserver or turnserver —no-auth

When I tried to test this server with Trickle Ice, Google Chrome after a minute of wait showed «Not reachable» and in webrtc-internals I can see TURN allocate request timed out .

In Firefox i also got «Not reachable» and in webrtc log i could see Missing MESSAGE-INTEGRITY .

I did some checks with tcpdump and found out that server successfully received and processed TURN ALLOCATE request and responded back to the client. I also validated that response was received on the client-side.

As I understand, when coturn is used without auth, MESSAGE-INTEGRITY attribute is not included in the response and browsers reject such responses. Interestingly enough, unsafely-treat-insecure-origin-as-secure flag in chromium seems to disable message integrity validation and turn server check works fine!

TL/DR: Adding —auth= :

—lt-cred-mech to the startup command fixed the issue for me:

turnserver —user=user:12345678 —lt-cred-mech

v1shva commented Aug 18, 2021

In my case, I added ?transport=tcp and it’s working immediately because I opened the port as TCP.
Check whether you open the port as UDP or TCP.

This was the case for me, I had not open the port 3478 UDP, only 3478 TCP. After opening the port it was fixed.

chrbsg commented Feb 10, 2022

I was getting this error with the trickle-ice sample in Chrome and «401: Unauthorized» in the turnserver log, apparently because the realm wasn’t set in /etc/turnserver.conf, and the domainname wasn’t set on the EC2 machine that I was testing coturn on. The comment in turnserver.conf says that in this case realm will default to an empty string, which seems to fail in Chrome, but works in Firefox.

I think the fix for this case should be that coturn explicitly disallows an empty realm, or uses a valid string default, instead of defaulting to «».

praveenjha-github commented Feb 18, 2022

I am facing an error message 701 in Gathering candidates of TURN server, could you please help:-

i have already started my turn server in terminal:-

after that i have gone to WebRTC ICE checking:-

As, you can see above there is an error 701 coming, so can you please tell that why am getting this error, following changes i have also done:-

1:- Checked my turnserver.conf file , but have only port 3478 opened in it.

2:- have also added (—auth=: —lt-cred-mech) in turnserver.conf file

3:- checked the firewall settings, have the port TCP opened in that

Any help, will be really appreciated.

tyki6 commented Mar 9, 2022 •

got the same problem
All port are open, test telnet connection: OK, firefox: 0 error message, Chrome:

any help will be appreciated

manrajgrover commented Mar 21, 2022

I am also facing this issue.

I have a server that I access using ssh and I port forward the ports. I have port forwarded required ports, i.e. 3478, 5349, and a small range of ports:

I am able to access the Turn server (I get the «Done» in the Trickle ICE page on using transport as TCP [ turn:localhost:3478?transport=tcp ]). However, I’m unable to access the STUN server. The error is:

The page says: On the server, I am getting responses on running turnutils_stunclient -p 3478 localhost .

I feel I should set some configuration in order to get stun response to work over ssh.

ideviant commented May 6, 2022

I’m using VPN in the client when got the 701 error.
After turned off the VPN, the check passed.

namdoel1412 commented Aug 7, 2022

I’m using VPN in the client when got the 701 error. After turned off the VPN, the check passed.

I have the same problem.

Neustradamus commented Aug 8, 2022

@ggarber: Can you look it?

kamilk91 commented Aug 29, 2022

1: IO method (general relay thread): epoll (with changelist) 1: turn server created 1: IPv4. SCTP listener opened on : 0.0.0.0:3478 1: IPv4. TCP listener opened on : 0.0.0.0:3478 1: IPv4. UDP listener opened on: 0.0.0.0:3478 1: Total General servers: 2 1: IO method (admin thread): epoll (with changelist) 1: IO method (auth thread): epoll (with changelist) 1: IO method (auth thread): epoll (with changelist) 1: SQLite DB connection success: /var/lib/turn/turndb 4: handle_udp_packet: New UDP endpoint: local addr 0.0.0.0:3478, remote addr 79.184.37.15:55434 4: session 001000000000000001: realm user <>: incoming packet BINDING processed, success 9: handle_udp_packet: New UDP endpoint: local addr 0.0.0.0:3478, remote addr 79.184.37.15:63833 9: session 000000000000000001: realm user <>: incoming packet BINDING processed, success 14: session 001000000000000001: realm user <>: incoming packet BINDING processed, success 19: session 000000000000000001: realm user <>: incoming packet BINDING processed, success

it looks like my server starting without port i specified as TLS in turnserver.conf:

ggarber commented Sep 17, 2022

@ideviant @namdoel1412 It looks like your VPN is blocking the access to your TURN server. Can you check it is reachable like mentioned here #678 (comment) ?

Also can you check if your turn server is receiving any packet from your client with a packet sniffer?

I can take a look if you can provide that.

tarkhil commented Nov 16, 2022

Okay, same problem here. TURN server is in container, I’ve mapped ports 3478 tcp/udp. 5349 tcp/udp, 10000-20000 udp

syslog (realm omitted)

and «server returned code 701»

eakraly commented Nov 17, 2022

Hi @tarkhil
You are setting port range to 10000-20000 — can you pls verify if this port range is actually in the range of ephemeral ports that is used by OS of your container, host, and also exposed by the host? To my knowledge, it is not given that 10000-20000 will just work on any system.

I use debian based images (building my own) and setting port range to 32768-60999 and also explicitly allowing them in security group of infrastructure provider.

tarkhil commented Nov 17, 2022 •

I’ve configured coturn on different server, with external IP (no port mapping).

Источник

У меня есть собственный сервер с Ubuntu 19.

ПРИМЕЧАНИЕ. Мне нужен сервер оглушения / поворота для веб-приложения видеочата. Он уже работает, если оба устройства находятся в одной сети.

Я успешно установил и настроил coturn. Я могу успешно запустить Turnserver, запустив: turnserver или nohup turnserver & в терминале.

ПРИМЕЧАНИЕ. У меня SSH подключение к моему серверу.

Я также убедился, что необходимые порты открыты, и проверил их с помощью netstat -tulpn.

Я также несколько раз перезапускал coturn во время тестирования sudo service coturn restart.

Я использую эти конфигурации в turnserver.conf:

# Also tried 80
listening-port=3478
# Also tried 443
tls-listening-port=5349
listening-ip=<MY-IP4>
listening-ip=<MY-IP6>
relay-ip=<MY-IP4>
external-ip=<MY-IP4>
oauth
user=root:<password>
userdb=/var/lib/turn/turndb
no-stdout-log

Это моя конфигурация iceServers в js, которая, как я считаю, должна работать (я использовал ТОННУ других комбинаций).

var pcConfig = {
  'iceServers': [
    {
      'urls': 'stun:<MY-IP4>:80'
    },
    {
      'urls': 'turn:<MY-IP4>:80',
      'credential': '<PASSWORD>',
      'username': 'root'
    }
  ]
};

Я использовал ТОННУ различных комбинаций оглушения / поворота, например:

• Я использовал оглушающие серверы Google: stun.l.google.com:19302, stun2.l.google.com:19302 и т. Д.

• Пробовал порты 3478 и 5349 (конечно после перезапуска coturn)

• Я пробовал использовать учетные данные для оглушающего сервера, но уверен, что они ему не нужны

• Я пробовал использовать IP6-адрес

Я также проводил тесты в прямом эфире в своем веб-проекте, а также здесь: https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

По сути, приведенный выше URL-адрес тестирования всегда дает мне:

Note: errors from onicecandidateerror above are not neccessarily fatal. For example an IPv6 DNS lookup may fail but relay candidates can still be gathered via IPv4.
The server stun:<MY-IP4>:80 returned an error with code=701:
STUN server address is incompatible.
The server stun:<MY-IP4>:80 returned an error with code=701:
STUN server address is incompatible.

Неважно, использую ли я сервер оглушения Google или свой, ошибка одна и та же.

Мой веб-проект и видеочат отлично работают, если я использую одну и ту же сеть, но я считаю, что серверы оглушения и поворота не используются в одной сети.

Кроме того, когда я обновлял свой JS-файл, я всегда удалял кеш, поэтому использовался новый JS-файл. Так что это тоже не было проблемой.

ИЗМЕНИТЬ

Эта комбинация не дает ошибки, только:

Note: errors from onicecandidateerror above are not 
neccessarily fatal. For example an IPv6 DNS 
lookup may fail but relay candidates can still be gathered via IPv4.

Протестировано на https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

{
  'urls': 'stun:<MY-IP6>:80'
},
{
  'urls': 'turn:<MY-IP4>:80',
  'credential': '<PASSWORD>',
  'username': 'root'
}

Я просто использовал IP6 для оглушения и IP4 для поворота. Видеочат в другой сети по-прежнему не работает, других ошибок нигде не найти.

РЕДАКТИРОВАТЬ:

Сегодня заметил, что https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ не работает. У меня в firefox ошибок не было. НО вы можете ввести туда какую-то бессмыслицу, и она тоже не будет показывать ошибок …

РЕДАКТИРОВАТЬ:

Я также добавил действующие сертификаты:

cert=/usr/local/etc/turn.pem                                                                                    
pkey=/usr/local/etc/turn.key.pem

Кажется, работает. Я перезапустил coturn, и статус говорит мне, что все работает без проблем.

Видеочат по-прежнему не работает в разных сетях.