Hello here,
Thank for provide us this fantastic tool.
I’ve read multiples topics and check some repositories on Github and I am impressed.
Thank to Jitsi, I’ve learn new technologies and skills, but it’s a big work in progress on my side 
I’ve a working stack of Jitsi (web, prosody, jicofo and jvb), I’ve followed the configuration in order to running my stack behind a NAT instance (documentation here), WS has been configured.
After running me first conference, audio is good, video working with more than 2 participants (video is not good but not important for now), but Screen Sharing not working.
In the console, I have the common error “Bridge Channel send: no opened channel”. Interrested fact in [modules/RTC/BridgeChannel.js] <l._send>: Bridge Channel send: no opened channel - #13 by mstran someone say you will stuck on 180p if JVB not working. But configuration seems good on JVB (sip-communicator.properties):
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS="100.10.1.14"
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS="165.172.140.191"
NB: Yes my local address is public one, this coming from my cloud provider
After activate log XMPP part on JVB (logging.properties):
org.jitsi.videobridge.xmpp.XmppConnection.level=ALL
I can see when I have two participants the message send by the JVB to prosody:
<iq xmlns="jabber:client" to="jvbbrewery@internal-muc.foobar/focus" from="j
vb@auth.foobar/ZgKIa3_t" id="anZiQGF1dGgubWVldC5jYWxsaXR5LnRlY2gvWmdLSWEzX3QAN1k3NUgtMjQ1NwBF5p6j00Cu9qnBpATvKaiT" type="result">
<conference xmlns="http://jitsi.org/protocol/colibri" id="67f0b53b9c60f35e" name="testingroom@muc.foobar" rtcstats-enabled="true" callstats-enabled="true">
<content name="audio">
<channel endpoint="fc12af3e" id="e1bb498a2bf8fc22" initiator="true" channel-bundle-id="fc12af3e" last-n="-1" rtp-level-relay-type="translator">
<source xmlns="urn:xmpp:jingle:apps:rtp:ssma:0" ssrc="414761362" />
</channel>
</content>
<content name="video">
<channel endpoint="fc12af3e" id="76cbebbe0d2082e4" initia tor="true" channel-bundle-id="fc12af3e" last-n="-1" rtp-level-relay-type="translator">
<source xmlns="urn:xmpp:jingle:apps:rtp:ssma:0" ssrc="3502538604" />
<ssrc-group xmlns="urn:xmpp:jingle:apps:rtp:ssma:0" semantics="FID">
<source ssrc="2567275508" />
<source ssrc="3103636259" />
</ssrc-group>
<ssrc-group xmlns="urn:xmpp:jingle:apps:rtp:ssma:0" semantics="FID">
<source ssrc="2483287022" />
<source ssrc="3258118416" />
</ssrc-group>
<ssrc-group xmlns="urn:xmpp:jingle:apps:rtp:ssma:0" semantics="FID">
<source ssrc="1987432807" />
<source ssrc="4195797450" />
</ssrc-group>
<ssrc-group xmlns="urn:xmpp:jingle:apps:rtp:ssma:0" semantics="SIM">
<source ssrc="2567275508" />
<source ssrc="2483287022" />
<source ssrc="1987432807" />
</ssrc-group>
<ssrc>
2567275508
</ssrc>
<ssrc>
3103636259
</ssrc>
<ssrc>
2483287022
</ssrc>
<ssrc>
3258118416
</ssrc>
<ssrc>
1987432807
</ssrc>
<ssrc>
419
5797450
</ssrc>
</channel>
</content>
<channel-bundle id="fc12af3e">
<transport xmlns="urn:xmpp:jingle:transports:ice-udp:1" pwd="4rd9farh1md1pvtanrqclo8clv" ufrag="56lon1fvsir71k">
<rtcp-mux />
<fingerprint xmlns="urn:
xmpp:jingle:apps:dtls:0" setup="passive" hash="sha-256">
5B:0B:08:44:38:E2:1B:B9:AD:40:71:0E:9D:F1:63:EE:17:75:B4:94:0B:16:E8:1D:D5:F4:47:17:38:1D:D5:54
</fingerprint>
<web-socket xmlns="http://jitsi.org/protocol/colibri" url="wss://foobar/colibri-ws/shard-0/67f0b53b9c60f35e/fc12af3e?pwd=4rd9farh1md1pvtanrqclo8clv" />
<candidate component="1" foundation="1" generation="0" id="2dfcd10bcefdcb0ffffffffd4e4815b" netw ork="0" priority="2130706431" protocol="udp" type="host" ip="100.10.1.14" port="30300" />
<candidate component="1" foundation="2" generation="0" id="66a5764dcefdcb0145073e7" network="0" priority="1694498815" protocol="udp" type="srflx" ip="165.172.140.191" port="30300" rel-addr="100.10.1.14" rel-port="30300" />
</transport>
</channel-bundle>
</conference>
</iq>
It’s quite strange on the first candidate it’s appear without the mapping of rel-addr.
From my computer and wireshark I can see requests to the public IP of JVB (NAT 165.172.140.191) on 30300 and response. And requests send to the local IP (100.10.1.14) on 30300 without any response.
I’ve no clue on why jitsi-meet try to open bridge on the local IP and why this candidate is not with the rel-addr.
I’ve also try to make the configuration on jvb.conf with the ice4j.harvest.mapping.static-mappings part.
Best
Bastien
Stack informations:
- Running on k8s based on github/hpi-schul-cloud/jitsi-deployment: one shard one jvb
- Version stable 7001
- Client Chrome and Firefox up to date
