Jitsi Meet - Problem with TURN Server

Install & Config
,
#1

Good Morning,

I have a problem getting Jitsi to work with a TURN server.

The TURN server runs on the same server, but with a second IP. It runs on port 443.

But when I try to attend a meeting from a client that only has 443 tcp open, no video appears. With P2P as well as with more than 2 participants.

The TURN Server is a COTURN. STUN works fine.
When I check in Chrome under chrome: // webrtc-internals, I don’t see any TURN servers.

https://meet.lipp-xxyyzz.de/TEST, { iceServers: [stun:turn.lippxxyyzz.de:443], iceTransportPolicy: all, bundlePolicy: max-bundle, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: “plan-b” }, {advanced: [{googHighStartBitrate: {exact: 0}}, {googPayloadPadding: {exact: true}}, {googScreencastMinBitrate: {exact: 100}}, {googCpuOveruseDetection: {exact: true}}, {googCpuOveruseEncodeUsage: {exact: true}}, {googCpuUnderuseThreshold: {exact: 55}}, {googCpuOveruseThreshold: {exact: 85}}]}

UseStunTurn is activated for both p2p and other connections in the MEET-Config.
It is also stored in the respective Prosody-Lua-Config. Chredentials fit.
In the … videobridge / sip-communicator.properties Config I added the entry org.jitsi.videobridge.DISABLE_TCP_HARVESTER = true.

Certs for jitsi and Turn a valid.

Thank you for your help in advance.
Sorry for my not so good english.

greetings
Henrik

#2

Can nobody help me?

Im sorry for my bad englisch.

Best regards
Henrik

#3

Does your prosody advertises correctly turns server? Config.js does it have useStunserver true for both p2p and non p2p section?

#4

Is turn server running with trusted fullchain certs?

#5

Hello, thank you for your answer.

yes for p2p and Meetings with more user i activated useStunTurn in the config.

yes first i tried it with letsencrypt and in the second test with our purchased wildcard certificates.

Greetings Henrik

#6

Do you see in chrome://webrrtc-internals turns:… for your jvb connection. Open 3 tabs on meet.jit.si and see how the jvb peer connection looks like. Do you have the turns on your deployment?

#7

No, i write it above. Thats what confuse me. Only the STUN is shown.

When I check in Chrome under chrome: // webrtc-internals, I don’t see any TURN servers.

https://meet.lipp-xxyyzz.de/TEST, { iceServers: [stun:turn.lippxxyyzz.de:443], iceTransportPolicy: all, bundlePolicy: max-bundle, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: “plan-b” }, {advanced: [{googHighStartBitrate: {exact: 0}}, {googPayloadPadding: {exact: true}}, {googScreencastMinBitrate: {exact: 100}}, {googCpuOveruseDetection: {exact: true}}, {googCpuOveruseEncodeUsage: {exact: true}}, {googCpuUnderuseThreshold: {exact: 55}}, {googCpuOveruseThreshold: {exact: 85}}]}

What du you meen whis deployed?

In the /etc/jitsi/meet/meet.lippxxyyzz.de-config.js i have this in the p2p section:

stunServers: [
{ urls: ‘stun:turn.lippxxyyyzz.de:443’ },
],

In the /etc/prosody/conf.d/meet.lippxxyyzz.de.cf.lua i have this lines:

turncredentials_secret = “xxxxx”;
turncredentials = {
{ type = “stun”, host = “turn.lippxxyyzz.de”, port = “443” },
{ type = “turn”, host = “turn.lippxxyyzz.de”, port = “443”, transport = “udp” },
{ type = “turns”, host = “turn.lippxxyyzz.de”, port = “443”, transport = “tcp” }
};

grrets
Henrik

1 Like
#8

I think this is your p2p peer connection, this is not the jvb peer connection. The only thing you could see in iceServers for your jvb peer connection is turns.

And you have the module enabled, right?

#9

Hello, thank you for your answer. :slight_smile:

If I add several users to the meeting, some have the entry STUN under ICEServer, but those who only have port 443 open do not. The same applies to P2P.

I see some error messages in the Cotrun log:

188: session 003000000000000002: closed (2nd stage), user <> realm <turn.lippxxyyzz.de> origin <>, local 88.99.xx.179: 443, remote 88.70.xx.164: 57149, reason: allocation watchdog determined stale session state
189: session 001000000000000002: closed (2nd stage), user <> realm <turn.lippxxyyzz.de> origin <>, local 88.99.xx.179: 443, remote 88.70.xx.164: 53936, reason: allocation watchdog determined stale session state

I think I activated it. Or has i to enable it on another section?
These are my settings in the /etc/prosody/conf.d/meet.lippxxyyzz.de.

VirtualHost “meet.lippxxyyzz.de”
.
.
.
modules_enabled = {
“bosh”;
“pubsub”;
“ping”; - Enable mod_ping
“speakerstats”;
“turncredentials”;
“conference_duration”;
}
c2s_require_encryption = false

greets henrik

Ubuntu default TURN server installation
Ubuntu default TURN server installation
#10

Now i see a TURN in the WebRTC-Internals:

iceServers: [turns:turn.lippxxyyzz.de:443?transport=tcp], …

In the log of the turnserver i have this entrys:
200: session 002000000000000005: closed (2nd stage), user <> realm <turn.lippxxyyzz.de> origin <>, local 88.99.xx.179:443, remote 88.70.xx.164:59000, reason: TCP connection closed by client (callback)
200: session 005000000000000004: TCP socket closed remotely 217.91.xx.72:35024
200: session 003000000000000001: refreshed, realm=<turn.lippxxyyzz.de>, username=<1586269666>, lifetime=0
200: session 005000000000000004: closed (2nd stage), user <> realm <turn.lippxxyyzz.de> origin <>, local 88.99.xx.179:443, remote 217.91.xx.72:35024, reason: TCP connection closed by client (callback)
200: session 003000000000000001: realm <turn.lippxxyyzz.de> user <1586269666>: incoming packet REFRESH processed, success
201: session 003000000000000001: closed (2nd stage), user <1586269666> realm <turn.lippxxyyzz.de> origin <>, local 88.99.xx.179:443, remote 217.91.xx.72:57094, reason: allocation timeout
201: session 003000000000000001: delete: realm=<turn.lippxxyyzz.de>, username=<1586269666>
201: session 003000000000000001: peer 192.168.75.213 deleted
215: session 007000000000000004: TCP socket closed remotely 88.70.xx.164:59001
215: session 007000000000000004: closed (2nd stage), user <> realm <turn.lippxxyyzz.de> origin <>, local 88.99.xx.179:443, remote 88.70.xx.164:59001, reason: TCP connection closed by client (callback)
362: IPv4. tcp or tls connected to: 88.70.xx.164:56803
392: session 004000000000000003: TCP socket closed remotely 88.70.xx.164:56803
392: session 004000000000000003: closed (2nd stage), user <> realm <turn.lippxxyyzz.de> origin <>, local 88.99.xx.179:443, remote 88.70.xx.164:56803, reason: TCP connection closed by client (callback)

But no Video if only Port 443 TCP is open. If i open 10000 UDP, it works…

#11

Now it works. Thx for your help.

I can not say what i have done, to get it work. Sorry!

#12

Hi @Smithes158,

any idea what you have done to make it work. I’ve the some issue. Audio/Video only works if port 10000UDP is open. I would need to make it work if only Port 443 TCP is open.

#13

Same here: TURN has been configured in Prosody, but it is not used in P2P connections, with no audio/video. ICE seems to be happy.

2020-04-27 06:49:33.588 INFO: [130] [confId=766c6eee561ab9f7 gid=ffef29 stats_id=Sammy-Rw3 conf_name=testroom ufrag=dvnfv1e6svg2l7 epId=f8e08b0b local_ufrag=dvnfv1e6svg2l7] ConnectivityCheckClient.processSuccessResponse#627: Pair succeeded: 84.nnn.mmm.101:10000/udp/host -> 194.xxx.yyy.51:36722/udp/prflx (stream-f8e08b0b.RTP).
2020-04-27 06:49:33.590 INFO: [130] [confId=766c6eee561ab9f7 gid=ffef29 stats_id=Sammy-Rw3 conf_name=fairkom ufrag=dvnfv1e6svg2l7 name=stream-f8e08b0b epId=f8e08b0b local_ufrag=dvnfv1e6svg2l7] CheckList.handleNominationConfirmed#406: Selected pair for stream stream-f8e08b0b.RTP: 84.nnn.mmm.101:10000/udp/host -> 194.xxx.yyy.51:36722/udp/prflx (stream-f8e08b0b.RTP)
2020-04-27 06:49:33.591 INFO: [130] [confId=766c6eee561ab9f7 gid=ffef29 stats_id=Sammy-Rw3 conf_name=fairkom ufrag=dvnfv1e6svg2l7 epId=f8e08b0b local_ufrag=dvnfv1e6svg2l7] Agent.checkListStatesUpdated#1937: CheckList of stream stream-f8e08b0b is COMPLETED
2020-04-27 06:49:33.591 INFO: [130] [confId=766c6eee561ab9f7 gid=ffef29 stats_id=Sammy-Rw3 conf_name=fairkom ufrag=dvnfv1e6svg2l7 epId=f8e08b0b local_ufrag=dvnfv1e6svg2l7] Agent.setState#963: ICE state changed from Running to Completed.
2020-04-27 06:49:37.038 INFO: [137] [confId=766c6eee561ab9f7 epId=f8e08b0b gid=ffef29 stats_id=Sammy-Rw3 conf_name=testroom] Endpoint$7.onReady#876: SCTP connection is ready, creating the Data channel stack
2020-04-27 06:49:37.045 INFO: [137] [confId=766c6eee561ab9f7 epId=f8e08b0b gid=ffef29 stats_id=Sammy-Rw3 conf_name=testroom] Endpoint$7.onReady#903: Will wait for the remote side to open the data channel.
2020-04-27 06:49:37.048 INFO: [172] [confId=766c6eee561ab9f7 epId=f8e08b0b gid=ffef29 stats_id=Sammy-Rw3 conf_name=testroom] DataChannelStack.onIncomingDataChannelPacket#62: Received data channel open message
2020-04-27 06:49:37.050 INFO: [172] [confId=766c6eee561ab9f7 epId=f8e08b0b gid=ffef29 stats_id=Sammy-Rw3 conf_name=testroom] Endpoint$7.lambda$onReady$1#884: Remote side opened a data channel.

So how can I enforce ICE to use TURN in such a scenario? It seems only a data channel has been confirmed, no media channel.