Connecting to TURN over TLS

KNC

unread,

Aug 25, 2014, 10:52:39 PM8/25/14

to turn-server-project...@googlegroups.com

Hi all,

According to this SO post, the standard says that "running TURN over TLS does not protect application data between the server and the peer" and that the encryption must be done at the application layer.

Given that WebRTC already uses srtp, are there any benefits of connecting to a TURN server on a TLS port?

Thanks.

Oleg Moskalenko

unread,

Aug 25, 2014, 11:54:27 PM8/25/14

to KNC, turn-server-project...@googlegroups.com

Yes, to protect the TURN protocol security-related details - between the client and the server.

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.
Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/d/optout.

Thomas Bruun

unread,

Aug 26, 2014, 5:01:18 AM8/26/14

to Oleg Moskalenko, KNC, turn-server-project...@googlegroups.com

An added benefit of this is that binding requests will work on more strict network setups. In our experience using WebRTC on our own corporate network, we have to use TURN over TLS in order to get a working connection.

--

Thomas Bruun

Developer – https://appear.in

Oleg Moskalenko

unread,

Aug 26, 2014, 11:15:36 AM8/26/14

to Thomas Bruun, KNC, turn-server-project...@googlegroups.com

That's right.

Oleg

Kishore N C

unread,

Aug 26, 2014, 11:56:24 AM8/26/14

to Oleg Moskalenko, Thomas Bruun, turn-server-project...@googlegroups.com

Thanks. We have an enterprise customer who uses squid proxy, and the only allowed TCP ports are 443 and 80. Our TURN server is set-up to run using TLS on 443, and this works fine for everyone else. But, these guys still get a black screen. One of their developers asked if this was because we were using self-signed certs on the TURN server. As far as I have read, this is not a problem. So I wanted to find out if perhaps running on port 80 might work, with the caveat that it's not over a secure channel.

Upon further reading however, it looks like some enterprise firewalls/proxies actually block or are unable to handle non-HTTP(s) traffic on ports 80 and 443. Has anyone encountered this? How does one counter such a set-up?

--
It is our choices that show what we truly are,
far more than our abilities.

Oleg Moskalenko

unread,

Aug 26, 2014, 1:08:53 PM8/26/14

to Kishore N C, Thomas Bruun, turn-server-project...@googlegroups.com

If you are using TLS - is it able to distinguish it from HTTPS ?

Sent from my iPhone

KNC

unread,

Aug 26, 2014, 1:22:00 PM8/26/14

to turn-server-project...@googlegroups.com, kish...@gmail.com, tho...@appear.in

Yes, a telnet on port 443 fails, while loading the page via HTTPS work fine on Chrome (after self-signed cert warning). i.e. telnet IP_ADDRESS 443 fails, while https://IP_ADDDRESS works fine.

Squid is supposed to allow CONNECT on port 443, according to this post, so I don't know what else could be a problem.

On Tuesday, August 26, 2014 10:38:53 PM UTC+5:30, Oleg Moskalenko wrote:

If you are using TLS - is it able to distinguish it from HTTPS ?

Sent from my iPhone

On Aug 26, 2014, at 8:56 AM, Kishore N C <kish...@gmail.com> wrote:

Thanks. We have an enterprise customer who uses squid proxy, and the only allowed TCP ports are 443 and 80. Our TURN server is set-up to run using TLS on 443, and this works fine for everyone else. But, these guys still get a black screen. One of their developers asked if this was because we were using self-signed certs on the TURN server. As far as I have read, this is not a problem. So I wanted to find out if perhaps running on port 80 might work, with the caveat that it's not over a secure channel.

Upon further reading however, it looks like some enterprise firewalls/proxies actually block or are unable to handle non-HTTP(s) traffic on ports 80 and 443. Has anyone encountered this? How does one counter such a set-up?

On Tue, Aug 26, 2014 at 8:45 PM, Oleg Moskalenko <mom0...@gmail.com> wrote:

That's right.

Oleg

On Aug 26, 2014, at 2:00 AM, Thomas Bruun <tho...@appear.in> wrote:

An added benefit of this is that binding requests will work on more strict network setups. In our experience using WebRTC on our own corporate network, we have to use TURN over TLS in order to get a working connection.

On Tue, Aug 26, 2014 at 5:54 AM, Oleg Moskalenko <mom0...@gmail.com> wrote:

Yes, to protect the TURN protocol security-related details - between the client and the server.

Sent from my iPhone

On Aug 25, 2014, at 7:52 PM, KNC <kish...@gmail.com> wrote:

Hi all,

According to this SO post, the standard says that "running TURN over TLS does not protect application data between the server and the peer" and that the encryption must be done at the application layer.

Given that WebRTC already uses srtp, are there any benefits of connecting to a TURN server on a TLS port?

Thanks.

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/d/optout.

--
Thomas Bruun
Developer – https://appear.in

Oleg Moskalenko

unread,

Aug 26, 2014, 4:34:46 PM8/26/14

to turn-server-project...@googlegroups.com, kish...@gmail.com, tho...@appear.in

without decrypting the traffic, an HTTPS session is no different from a "plain" TLS session. I do not understand how your proxy can differentiate them.

Thomas Bruun

unread,

Aug 26, 2014, 5:14:33 PM8/26/14

to Oleg Moskalenko, turn-server-project...@googlegroups.com, kish...@gmail.com, Thomas Bruun

Are you sure that the people who get a working connection actually
*needs* TURN over TLS? We recently had an issue where TURN over TLS
did not work on our corporate network (which sounds very similar to
the one you are experiencing issues with), and it turned out that we
had wrongly configured the TURN server, causing all TLS handshakes to
fail.

>>>>> turn-server-project-rfc57...@googlegroups.com.

>>>>> To post to this group, send email to

>>>>> turn-server-project...@googlegroups.com.

>>>>> Visit this group at
>>>>> http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "TURN Server (Open-Source project)" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to

>>>>> turn-server-project-rfc57...@googlegroups.com.

>>>>> To post to this group, send email to

>>>>> turn-server-project...@googlegroups.com.

KNC

unread,

Aug 26, 2014, 8:47:32 PM8/26/14

to turn-server-project...@googlegroups.com, mom0...@gmail.com, kish...@gmail.com, tho...@appear.in

> Are you sure that the people who get a working connection actually
*needs* TURN over TLS?

I tried replication a firewall set-up locally by blocking all of my outgoing ports except 80 and 443 and enabling only TCP traffic. TURN was configured to listen via TLS only on 443. When I now connected to the video chat (did a trans-atlantic call) everything worked fine by using TURN on TLS. So, the TURN configuration is right.

Looks like I now have to now try a non-tls 443 port to see if that works. Technically, Chrome does support HTTP CONNECT tunnelling, so the proxy should be bypassed. Another thing I tried: I saw a couple of posts here that spoke about how sometimes UDP was optimistically picked over TCP, so I disabled "?transport=udp" from my webrtc client configuration. Still no luck.

>>>>> turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.

>>>>> To post to this group, send email to

>>>>> turn-server-project-rfc5766-turn-...@googlegroups.com.

>>>>> Visit this group at
>>>>> http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "TURN Server (Open-Source project)" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to

>>>>> turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.

>>>>> To post to this group, send email to

>>>>> turn-server-project-rfc5766-turn-...@googlegroups.com.

Mahes

unread,

Nov 23, 2017, 7:14:31 AM11/23/17

to TURN Server (Open-Source project)

Hi KNC,

Could you please advise how can i setup turnserver on TLS port?

I have an ec2 instance, which has below ports;

listening-port=443

tls-listening-port=443

on AWS sec. group, i have enabled as below-

Type Protocol portrange

Https TCP 443

and its working fine when i access over TCP.

But how can i set up TLS?

Please advise.

Thanks.

On Tuesday, 26 August 2014 08:22:39 UTC+5:30, KNC wrote:

Hi all,

According to this SO post, the standard says that "running TURN over TLS does not protect application data between the server and the peer" and that the encryption must be done at the application layer.

Given that WebRTC already uses srtp, are there any benefits of connecting to a TURN server on a TLS port?

Thanks.

On Tuesday, 26 August 2014 21:26:24 UTC+5:30, KNC wrote:

Thanks. We have an enterprise customer who uses squid proxy, and the only allowed TCP ports are 443 and 80. Our TURN server is set-up to run using TLS on 443, and this works fine for everyone else. But, these guys still get a black screen. One of their developers asked if this was because we were using self-signed certs on the TURN server. As far as I have read, this is not a problem. So I wanted to find out if perhaps running on port 80 might work, with the caveat that it's not over a secure channel.

Upon further reading however, it looks like some enterprise firewalls/proxies actually block or are unable to handle non-HTTP(s) traffic on ports 80 and 443. Has anyone encountered this? How does one counter such a set-up?

On Tue, Aug 26, 2014 at 8:45 PM, Oleg Moskalenko <mom0...@gmail.com> wrote:

That's right.

Oleg

On Aug 26, 2014, at 2:00 AM, Thomas Bruun <tho...@appear.in> wrote:

An added benefit of this is that binding requests will work on more strict network setups. In our experience using WebRTC on our own corporate network, we have to use TURN over TLS in order to get a working connection.

On Tue, Aug 26, 2014 at 5:54 AM, Oleg Moskalenko <mom0...@gmail.com> wrote:

Yes, to protect the TURN protocol security-related details - between the client and the server.

Sent from my iPhone

On Aug 25, 2014, at 7:52 PM, KNC <kish...@gmail.com> wrote:

Hi all,

According to this SO post, the standard says that "running TURN over TLS does not protect application data between the server and the peer" and that the encryption must be done at the application layer.

Given that WebRTC already uses srtp, are there any benefits of connecting to a TURN server on a TLS port?

Thanks.

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/d/optout.

--
Thomas Bruun
Developer – https://appear.in

Warren McDonald

unread,

Nov 27, 2017, 9:46:22 PM11/27/17

to TURN Server (Open-Source project)

The TURN server will listen on 443 for TLS connections, but you need to ensure the ICEServers config for your clients browsers or apps includes the "turns:" protocol designation.

It should look like turns:<turnserveraddress>:443&transport=tcp

Nitin Dhami

unread,

Feb 3, 2021, 10:42:18 AM2/3/21

to TURN Server (Open-Source project)

Hi,

were you able to setup turnserver over TLS,

if yes can you guide me as well as I am fairly new to this.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.

To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.

To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

Warren McDonald

unread,

Feb 5, 2021, 1:11:14 AM2/5/21

to TURN Server (Open-Source project)

This a bump form a pretty old thread, but yes, we use TLS all time.

Several Important things:

1. You must have a valid key and certificate signed by a cert authority recognised by the browsers (self signed certs will load and not present errors, but will not work)

2. The key and cert must be referenced correctly in the turnserver.conf. Also make sure the cert file has the intermediate certs included in the file to avoid chaining issues with some browsers (Safari on iOS mainly)

3. The turnserver process must be able to read the key and cert file locations (set group permssions for the turnserver group to the folder and files)

4. The turnserver process must have rights to bind to port 443, assuming that is what you want to use. Use command setcap CAP_NET_BIND_SERVICE=+eip /path/to/turnserver (Does not matter if using a port above port 1024)

5. Make sure nothing else is binding to port 443

6. Configure the turnserver.conf to allow the web admin interface and connect to this with a browser and check that you get no certificate errors (disable this again when finished proving as it is not good in production)

Cheers,

Warren

Nitin Dhami

unread,

Feb 5, 2021, 9:13:14 AM2/5/21

to TURN Server (Open-Source project)

Hi Thanks for the suggestions but now I am getting "TLS/TCP socket buffer operation error (callback)" on the server I am using instrumentisto/coturn

image and setting the configuration as mentioned there my TLS listening ports start but fail to when the call starts handshake fails as reported in the Wireshark.

do you have any suggestions

Thanks for replying.

Regards

Nitin

Nitin Dhami

unread,

Feb 6, 2021, 12:58:20 AM2/6/21

to TURN Server (Open-Source project)

I was able to run the co-turn server but I am getting TLS/TCP socket buffer operation error (callback) error

I am running the image of the coturn server using the configuration

docker run -itd --network=host new_coturn -n --log-file=stdout --listening-port=3478 --tls-listening-port=5349 --lt-cred-mech --fingerprint --cli-password=qwerty --verbose --user=luca:altran --cipher-list = "ALL" --realm=aln.org --cert=/mnt/turn_server_cert.pem --pkey=/mnt/turn_server_pkey.pem --pkey-pwd=altran --stale-nonce

==== Show him the instruments, Practical Frost: ====

0: : TLS supported

0: : DTLS supported

0: : DTLS 1.2 supported

0: : TURN/STUN ALPN supported

0: : Third-party authorization (oAuth) supported

0: : GCM (AEAD) supported

0: : OpenSSL compile-time version: OpenSSL 1.1.1i 8 Dec 2020 (0x1010109f)

0: :

0: : SQLite supported, default database location is /var/lib/coturn/turndb

0: : Redis supported

0: : PostgreSQL supported

0: : MySQL is not supported

0: : MongoDB supported

0: :

0: : Default Net Engine version: 3 (UDP thread per CPU core)

=====================================================

0: : Default Net Engine version: 3 (UDP thread per CPU core)

=====================================================

0: : Domain name:

0: : Default realm: altran.org

0: : ERROR:

CONFIGURATION ALERT: Unknown argument: ALL

0: : ERROR:

CONFIGURATION ALERT: Unknown argument: ALL

0: : SSL23: Certificate file found: /mnt/turn_server_cert.pem

0: : SSL23: Private key file found: /mnt/turn_server_pkey.pem

0: : TLS1.0: Certificate file found: /mnt/turn_server_cert.pem

0: : TLS1.0: Private key file found: /mnt/turn_server_pkey.pem

0: : TLS1.1: Certificate file found: /mnt/turn_server_cert.pem

0: : TLS1.1: Private key file found: /mnt/turn_server_pkey.pem

0: : TLS1.2: Certificate file found: /mnt/turn_server_cert.pem

0: : TLS1.2: Private key file found: /mnt/turn_server_pkey.pem

0: : TLS cipher suite: =

0: : DTLS: Certificate file found: /mnt/turn_server_cert.pem

0: : DTLS: Private key file found: /mnt/turn_server_pkey.pem

0: : DTLS1.2: Certificate file found: /mnt/turn_server_cert.pem

0: : DTLS1.2: Private key file found: /mnt/turn_server_pkey.pem

0: : DTLS cipher suite: =

0: : NO EXPLICIT LISTENER ADDRESS(ES) ARE CONFIGURED

0: : ===========Discovering listener addresses: =========

0: : Listener address to use: 127.0.0.1

0: : Listener address to use: 10.0.3.7

0: : Listener address to use: 172.17.0.1

0: : Listener address to use: 172.18.0.1

0: : Listener address to use: ::1

0: : =====================================================

0: : Total: 3 'real' addresses discovered

0: : =====================================================

0: : NO EXPLICIT RELAY ADDRESS(ES) ARE CONFIGURED

0: : ===========Discovering relay addresses: =============

0: : Relay address to use: 10.0.3.7

0: : Relay address to use: 172.17.0.1

0: : Relay address to use: 172.18.0.1

0: : Relay address to use: ::1

0: : =====================================================

0: : Total: 4 relay addresses discovered

0: : =====================================================

0: : pid file created: /var/run/turnserver.pid

0: : IO method (main listener thread): epoll (with changelist)

0: : Wait for relay ports initialization...

0: : relay 10.0.3.7 initialization...

0: : relay 10.0.3.7 initialization done

0: : relay 172.17.0.1 initialization...

0: : relay 172.17.0.1 initialization done

0: : relay 172.18.0.1 initialization...

0: : relay 172.18.0.1 initialization done

0: : relay ::1 initialization...

0: : relay ::1 initialization done

0: : Relay ports initialization done

0: : IO method (general relay thread): epoll (with changelist)

0: : turn server id=0 created

0: : IPv4. TLS/SCTP listener opened on : 127.0.0.1:3478

0: : IPv4. TLS/TCP listener opened on : 127.0.0.1:3478

0: : IPv4. TLS/SCTP listener opened on : 127.0.0.1:3479

0: : IPv4. TLS/TCP listener opened on : 127.0.0.1:3479

0: : IPv4. TLS/SCTP listener opened on : 127.0.0.1:5349

0: : IPv4. TLS/TCP listener opened on : 127.0.0.1:5349

0: : IPv4. TLS/SCTP listener opened on : 127.0.0.1:5350

0: : IPv4. TLS/TCP listener opened on : 127.0.0.1:5350

0: : IPv4. TLS/SCTP listener opened on : 10.0.3.7:3478

0: : IPv4. TLS/TCP listener opened on : 10.0.3.7:3478

0: : IPv4. TLS/SCTP listener opened on : 10.0.3.7:3479

0: : IPv4. TLS/TCP listener opened on : 10.0.3.7:3479

0: : IPv4. TLS/SCTP listener opened on : 10.0.3.7:5349

0: : IPv4. TLS/TCP listener opened on : 10.0.3.7:5349

0: : IPv4. TLS/SCTP listener opened on : 10.0.3.7:5350

0: : IPv4. TLS/TCP listener opened on : 10.0.3.7:5350

0: : IPv4. TLS/SCTP listener opened on : 172.17.0.1:3478

0: : IPv4. TLS/TCP listener opened on : 172.17.0.1:3478

0: : IPv4. TLS/SCTP listener opened on : 172.17.0.1:3479

0: : IPv4. TLS/TCP listener opened on : 172.17.0.1:3479

0: : IPv4. TLS/SCTP listener opened on : 172.17.0.1:5349

0: : IPv4. TLS/TCP listener opened on : 172.17.0.1:5349

0: : IPv4. TLS/SCTP listener opened on : 172.17.0.1:5350

0: : IPv4. TLS/TCP listener opened on : 172.17.0.1:5350

0: : IPv4. TLS/SCTP listener opened on : 172.18.0.1:3478

0: : IPv4. TLS/TCP listener opened on : 172.18.0.1:3478

0: : IPv4. TLS/SCTP listener opened on : 172.18.0.1:3479

0: : IPv4. TLS/TCP listener opened on : 172.18.0.1:3479

0: : IPv4. TLS/SCTP listener opened on : 172.18.0.1:5349

0: : IPv4. TLS/TCP listener opened on : 172.18.0.1:5349

0: : IPv4. TLS/SCTP listener opened on : 172.18.0.1:5350

0: : IPv4. TLS/TCP listener opened on : 172.18.0.1:5350

0: : IPv6. TLS/SCTP listener opened on : ::1:3478

0: : IPv6. TLS/TCP listener opened on : ::1:3478

0: : IPv6. TLS/SCTP listener opened on : ::1:3479

0: : IPv6. TLS/TCP listener opened on : ::1:3479

0: : IPv6. TLS/SCTP listener opened on : ::1:5349

0: : IPv6. TLS/TCP listener opened on : ::1:5349

0: : IPv6. TLS/SCTP listener opened on : ::1:5350

0: : IPv6. TLS/TCP listener opened on : ::1:5350

0: : IO method (general relay thread): epoll (with changelist)

0: : turn server id=1 created

0: : IPv4. DTLS/UDP listener opened on: 127.0.0.1:3478

0: : IPv4. DTLS/UDP listener opened on: 127.0.0.1:3479

0: : IPv4. DTLS/UDP listener opened on: 127.0.0.1:5349

0: : IPv4. DTLS/UDP listener opened on: 127.0.0.1:5350

0: : IPv4. DTLS/UDP listener opened on: 10.0.3.7:3478

0: : IPv4. DTLS/UDP listener opened on: 10.0.3.7:3479

0: : IPv4. DTLS/UDP listener opened on: 10.0.3.7:5349

0: : IPv4. DTLS/UDP listener opened on: 10.0.3.7:5350

0: : IPv4. DTLS/UDP listener opened on: 172.17.0.1:3478

0: : IPv4. DTLS/UDP listener opened on: 172.17.0.1:3479

0: : IPv4. DTLS/UDP listener opened on: 172.17.0.1:5349

0: : IPv4. DTLS/UDP listener opened on: 172.17.0.1:5350

0: : IPv4. DTLS/UDP listener opened on: 172.18.0.1:3478

0: : IPv4. DTLS/UDP listener opened on: 172.18.0.1:3479

0: : IPv4. DTLS/UDP listener opened on: 172.18.0.1:5349

0: : IPv4. DTLS/UDP listener opened on: 172.18.0.1:5350

0: : IPv6. DTLS/UDP listener opened on: ::1:3478

0: : IPv6. DTLS/UDP listener opened on: ::1:3479

0: : IPv6. DTLS/UDP listener opened on: ::1:5349

0: : IPv6. DTLS/UDP listener opened on: ::1:5350

0: : Total General servers: 2

0: : turn server id=1 created

0: : IPv4. TLS/SCTP listener opened on : 127.0.0.1:3478

0: : IPv4. TLS/TCP listener opened on : 127.0.0.1:3478

0: : IPv4. TLS/SCTP listener opened on : 127.0.0.1:3479

0: : IPv4. TLS/TCP listener opened on : 127.0.0.1:3479

0: : IPv4. TLS/SCTP listener opened on : 127.0.0.1:5349

0: : IPv4. TLS/TCP listener opened on : 127.0.0.1:5349

0: : IPv4. TLS/SCTP listener opened on : 127.0.0.1:5350

0: : IPv4. TLS/TCP listener opened on : 127.0.0.1:5350

0: : IPv4. TLS/SCTP listener opened on : 10.0.3.7:3478

0: : IPv4. TLS/TCP listener opened on : 10.0.3.7:3478

0: : IPv4. TLS/SCTP listener opened on : 10.0.3.7:3479

0: : IPv4. TLS/TCP listener opened on : 10.0.3.7:3479

0: : IPv4. TLS/SCTP listener opened on : 10.0.3.7:5349

0: : IPv4. TLS/TCP listener opened on : 10.0.3.7:5349

0: : IPv4. TLS/SCTP listener opened on : 10.0.3.7:5350

0: : IPv4. TLS/TCP listener opened on : 10.0.3.7:5350

0: : IPv4. TLS/SCTP listener opened on : 172.17.0.1:3478

0: : IPv4. TLS/TCP listener opened on : 172.17.0.1:3478

0: : IPv4. TLS/SCTP listener opened on : 172.17.0.1:3479

0: : IPv4. TLS/TCP listener opened on : 172.17.0.1:3479

0: : IPv4. TLS/SCTP listener opened on : 172.17.0.1:5349

0: : IPv4. TLS/TCP listener opened on : 172.17.0.1:5349

0: : IPv4. TLS/SCTP listener opened on : 172.17.0.1:5350

0: : IPv4. TLS/TCP listener opened on : 172.17.0.1:5350

0: : IPv4. TLS/SCTP listener opened on : 172.18.0.1:3478

0: : IO method (auth thread): epoll (with changelist)

0: : IPv4. TLS/TCP listener opened on : 172.18.0.1:3478

0: : IPv4. TLS/SCTP listener opened on : 172.18.0.1:3479

0: : IPv4. TLS/TCP listener opened on : 172.18.0.1:3479

0: : IPv4. TLS/SCTP listener opened on : 172.18.0.1:5349

0: : IPv4. TLS/TCP listener opened on : 172.18.0.1:5349

0: : IPv4. TLS/SCTP listener opened on : 172.18.0.1:5350

0: : IPv4. TLS/TCP listener opened on : 172.18.0.1:5350

0: : IPv6. TLS/SCTP listener opened on : ::1:3478

0: : IPv6. TLS/TCP listener opened on : ::1:3478

0: : IPv6. TLS/SCTP listener opened on : ::1:3479

0: : IPv6. TLS/TCP listener opened on : ::1:3479

0: : IPv6. TLS/SCTP listener opened on : ::1:5349

0: : IPv6. TLS/TCP listener opened on : ::1:5349

0: : IPv6. TLS/SCTP listener opened on : ::1:5350

0: : IPv6. TLS/TCP listener opened on : ::1:5350

0: : IO method (auth thread): epoll (with changelist)

0: : IO method (admin thread): epoll (with changelist)

0: : IPv4. CLI listener opened on : 127.0.0.1:5766

0: : SQLite DB connection success: /var/lib/coturn/turndb

roote-Ubuntu:/home/advnetworkuser#

Reply all

Reply to author

Forward