Not working for more than 2 people in the room

Yes, and right now I am forwarding everything just to be sure.

But I now think it is definetly a firewall problem.

By opening chrome://webrtc-internals before the conference you can check the last setRemoteDescription in a peer connection tab and check whether you see the bridge public address, if so jvb is configured correctly and it is firewall/port forwarding issue.

Hi @damencho,

I do not see the the bridge public IP:

type: answer, sdp: v=0
o=- 1923518516 2 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=fmtp:111 minptime=10; useinbandfec=1
a=rtcp:1 IN IP4 0.0.0.0
a=rtcp-fb:111 transport-cc
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=setup:passive
a=mid:audio
a=sendrecv
a=ice-ufrag:F5bB
a=ice-pwd:Cu70cWmDRQkaSo6fcaF70Vgt
a=fingerprint:sha-256 74:79:23:F3:B1:9C:43:F0:63:3B:28:A7:6C:0C:B9:3F:E8:BB:D7:B7:57:2C:8E:75:20:E8:89:18:A7:BD:A9:18
a=ssrc:2425464916 cname:J3vRb5FeXuc5RQ0Q-1
a=ssrc:2425464916 msid:742ff182-37f9-4fbf-b65e-4326aba8aa63-1 4cda505c-fff0-4774-a320-b276c29aeaeb-1
a=ssrc:2425464916 mslabel:742ff182-37f9-4fbf-b65e-4326aba8aa63-1
a=ssrc:2425464916 label:4cda505c-fff0-4774-a320-b276c29aeaeb-1
a=rtcp-mux
m=video 1 RTP/SAVPF 102 96 97 98 99 100 101 122 127 121 125 107 108 109 124 120 123 119 114 115 116
c=IN IP4 0.0.0.0
a=rtpmap:102 H264/90000
a=rtpmap:96 VP8/90000
a=rtpmap:97 rtx/90000
a=rtpmap:98 VP9/90000
a=rtpmap:99 rtx/90000
a=rtpmap:100 VP9/90000
a=rtpmap:101 rtx/90000
a=rtpmap:122 rtx/90000
a=rtpmap:127 H264/90000
a=rtpmap:121 rtx/90000
a=rtpmap:125 H264/90000
a=rtpmap:107 rtx/90000
a=rtpmap:108 H264/90000
a=rtpmap:109 rtx/90000
a=rtpmap:124 H264/90000
a=rtpmap:120 rtx/90000
a=rtpmap:123 H264/90000
a=rtpmap:119 rtx/90000
a=rtpmap:114 red/90000
a=rtpmap:115 rtx/90000
a=rtpmap:116 ulpfec/90000
a=fmtp:102 level-asymmetry-allowed=1; packetization-mode=1; profile-level-id=42001f
a=fmtp:97 apt=96
a=fmtp:98 profile-id=0
a=fmtp:99 apt=98
a=fmtp:100 profile-id=2
a=fmtp:101 apt=100
a=fmtp:122 apt=102
a=fmtp:127 level-asymmetry-allowed=1; packetization-mode=0; profile-level-id=42001f
a=fmtp:121 apt=127
a=fmtp:125 level-asymmetry-allowed=1; packetization-mode=1; profile-level-id=42e01f
a=fmtp:107 apt=125
a=fmtp:108 level-asymmetry-allowed=1; packetization-mode=0; profile-level-id=42e01f
a=fmtp:109 apt=108
a=fmtp:124 level-asymmetry-allowed=1; packetization-mode=1; profile-level-id=4d0032
a=fmtp:120 apt=124
a=fmtp:123 level-asymmetry-allowed=1; packetization-mode=1; profile-level-id=640032
a=fmtp:119 apt=123
a=fmtp:115 apt=114
a=rtcp:1 IN IP4 0.0.0.0
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=rtcp-fb:123 goog-remb
a=rtcp-fb:123 transport-cc
a=rtcp-fb:123 ccm fir
a=rtcp-fb:123 nack
a=rtcp-fb:123 nack pli
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:13 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 urn:3gpp:video-orientation
a=extmap:2 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=setup:passive
a=mid:video
a=sendrecv
a=ice-ufrag:F5bB
a=ice-pwd:Cu70cWmDRQkaSo6fcaF70Vgt
a=fingerprint:sha-256 74:79:23:F3:B1:9C:43:F0:63:3B:28:A7:6C:0C:B9:3F:E8:BB:D7:B7:57:2C:8E:75:20:E8:89:18:A7:BD:A9:18
a=ssrc:3564884020 cname:J3vRb5FeXuc5RQ0Q-1
a=ssrc:3564884020 msid:8508419a-b340-4a2b-bf22-43ccb4be55e8-1 735cdf5d-725b-4176-b59c-7996a41009ac-1
a=ssrc:3564884020 mslabel:8508419a-b340-4a2b-bf22-43ccb4be55e8-1
a=ssrc:3564884020 label:735cdf5d-725b-4176-b59c-7996a41009ac-1
a=ssrc:2126961287 cname:J3vRb5FeXuc5RQ0Q-1
a=ssrc:2126961287 msid:8508419a-b340-4a2b-bf22-43ccb4be55e8-1 735cdf5d-725b-4176-b59c-7996a41009ac-1
a=ssrc:2126961287 mslabel:8508419a-b340-4a2b-bf22-43ccb4be55e8-1
a=ssrc:2126961287 label:735cdf5d-725b-4176-b59c-7996a41009ac-1
a=ssrc-group:FID 3564884020 2126961287
a=rtcp-mux

Make sure you are checking setRemoteDescripotion and on that page there are several tabs, if you have one meeting open in chrome you will have two tabs there one for the p2p PeerConnection and one for the jvb PeerConnection, chack jvb’s one(I know it is jvb by seeing the addresses). Even if there is a problem you will see at least the internal address from the network interface that jvb can discover by itself. If you have two tabs open in chrome you will have 4 entries and so on.

Yes, I don’t see the IP address.

I see only IP4 0.0.0.0

You are looking at the wrong place. Here is how it looks on meet.jit.si:

Sorry for that,

it is advertizing the internal IP address:

a=candidate:1 1 ssltcp 2130706431 10.75.240.78 443 typ host generation 0
a=candidate:2 1 udp 2130706431 10.75.240.78 10000 typ host generation 0

is this normal?:

netstat -tulpen

udp6 0 0 10.75.240.78:10000 :::* 999 11848 498/java

Did you restart jvb after setting NAT_HARVESTER_LOCAL_ADDRESS and NAT_HARVESTER_PUBLIC_ADDRESS? Where did you set it, in which file?

I set in in /etc/jitsi/videobridge/sip-communicator.properties

And yes, I have restarted the whole server

So check the file again for some extra spaces or something unusual, apparently those settings are not taken into account.

org.jitsi.videobridge.AUTHORIZED_SOURCE_REGEXP=focus@auth.my.fqdn.com/.*
org.jitsi.videobridge.rest.jetty.host=::
org.jitsi.videobridge.rest.jetty.port=443
org.jitsi.videobridge.rest.jetty.ProxyServlet.hostHeader=my.fqdn.com
org.jitsi.videobridge.rest.jetty.ProxyServlet.pathSpec=/http-bind
org.jitsi.videobridge.rest.jetty.ProxyServlet.proxyTo=http://localhost:5280/http-bind
org.jitsi.videobridge.rest.jetty.ResourceHandler.resourceBase=/usr/share/jitsi-meet
org.jitsi.videobridge.rest.jetty.ResourceHandler.alias./config.js=/etc/jitsi/meet/my.fqdn.com-config.js
org.jitsi.videobridge.rest.jetty.ResourceHandler.alias./interface_config.js=/usr/share/jitsi-meet/interface_config.js
org.jitsi.videobridge.rest.jetty.ResourceHandler.alias./logging_config.js=/usr/share/jitsi-meet/logging_config.js
org.jitsi.videobridge.rest.jetty.ResourceHandler.alias./external_api.js=/usr/share/jitsi-meet/libs/external_api.min.js
org.jitsi.videobridge.rest.jetty.RewriteHandler.regex=^/([a-zA-Z0-9]+)$
org.jitsi.videobridge.rest.jetty.RewriteHandler.replacement=/
org.jitsi.videobridge.rest.jetty.SSIResourceHandler.paths=/
org.jitsi.videobridge.rest.jetty.tls.port=443
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.rest.jetty.sslContextFactory.keyStorePath=/etc/jitsi/videobridge/my.fqdn.com.jks
org.jitsi.videobridge.rest.jetty.sslContextFactory.keyStorePassword=changeit
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=10.75.240.78
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=x.x.x.x

Seems fine.

edited the file again, check for spaces.

All is good but it still advertises the internal IP

You did service jitsi-videobridge restart? If so show us the jvb logs, this is strange.

This is weird indeed.

After I made the changes I restarted teh server and it didnt work.

Now I ran service jitsi-videobridge restart and it works and shows the correct IP

@damencho thanks a lot. It is working :slight_smile:

Actually I turned the server off, tuned it back on and had the same problem.

had to do : service jitsi-videobridge restart for it to work again.

Seems you are not rebooting your server but suspending it :slight_smile:

1 Like