[jitsi-users] users Digest, Vol 44, Issue 5


All: Disregard my earlier post and question. This issue has been sorted and narrowed down to a misbehaving switch that was added to rack. The offending switch has been severely reprimanded.



From: users <users-bounces@jitsi.org> on behalf of users-request@jitsi.org <users-request@jitsi.org>
Sent: Friday, November 4, 2016 11:51 AM
To: users@jitsi.org
Subject: users Digest, Vol 44, Issue 5

Send users mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."

Today's Topics:

   1. Re: Unusual problem with Jitsi Meet (Nelson, Jerry G. - US)
   2. Re: TCP Harvester on Port 80 (Jason Thomas)


Message: 1
Date: Fri, 4 Nov 2016 12:56:08 +0000
From: "Nelson, Jerry G. - US" <Edward.Nelson1@caci.com>
To: "users@jitsi.org" <users@jitsi.org>
Subject: Re: [jitsi-users] Unusual problem with Jitsi Meet
Message-ID: <1478264166375.83473@caci.com>
Content-Type: text/plain; charset="iso-8859-1"

Thx for the response Andrea,

This is a pretty flat network topology. Nothing major occurring in that regard. We don't see any TX/RX errors either in the local NIC nor on the switch port itself which is what makes this such a puzzling issue. If it was that it would be an easy diagnosis! Using Jitsi-Meet from other rooms in the same building do not have this issue.

I'm still considering it's some type of localized interference.



Date: Thu, 3 Nov 2016 18:10:27 +0100
From: Andrea Magatti <andrea.magatti@gmail.com>
To: Jitsi Users <users@jitsi.org>
Subject: Re: [jitsi-users] Unusual problem with Jitsi Meet
Content-Type: text/plain; charset="utf-8"

Hi Nelson,
seems like a true network problem.
Did you check your switches?
What about the network topology?

When you say "different locations", do you mean different offices in
different city/countries, or simply different room?


From: Nelson, Jerry G. - US
Sent: Thursday, November 3, 2016 11:19 AM
To: users@jitsi.org
Subject: Unusual problem with Jitsi Meet


My organization uses Jitsi Meet for various conferences. We have multiple locations where these conferences are held, but one in particular is problematic. Whenever a source PC is connected in this one room, the network connection shows on the UI as very poor (1 or less bars on the indicator) yet there is no real identifiable network issues. Multiple pings run to several different network hosts including the jitsi-meet server show sub 1ms ping response times. Other applications run on this system do not have issues. The only other odd thing that occurs here is a wireless mouse shows really odd behavior (jittery and jumpy...has led me to think it may be RF interference?). I'm wondering if anyone else has seen this type of behavior and were able to resolve the issue. I've tried running this on different systems, used different cameras, different microphones, different network cables and even ran a long cable to a network port in a different room. Network statistics show no TX or RX errors and the server is running at around 50% or less. Other users on these conferences can see and hear each other flawlessly but anything originating from this room is horrible.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jitsi.org/pipermail/users/attachments/20161104/97e61414/attachment-0001.html>


Message: 2
Date: Fri, 4 Nov 2016 09:47:41 -0600
From: Jason Thomas <mail@jasonthom.as>
To: Jitsi Users <users@jitsi.org>
Subject: Re: [jitsi-users] TCP Harvester on Port 80
Content-Type: text/plain; charset="utf-8"

I may give up on this configuration and try the two server configuration,
although it isn't ideal for me. However, in the long run it probably will
be better to work on making a load balancing solution like you have

Regarding the current approach to serving everything on port 443, the
behavior is very strange.

Today I have tested again going to port 4443, verified it works, and taken
a packet capture with all incoming and outgoing UDP blocked except for DNS.

Basically I see traffic on port 4443 when it is set up as the TCP_HARVESTER

When I switch to port 80 (To make it easy to distinguish from the other
traffic on port 443), I see that I can telnet to port 80 on my bridge, when
before it was closed, and I see relevant logs that the TCP_HARVESTER is
available there, as well as a candidate being advertised by the bridge for
tcpssl on port 80.

However, when doing a wireshark- I never see any traffic to my bridge on
port 80 at all, as well as getting an ICEConnectionStateFailed condition.

Shouldn't there at least be ICE packets determining whether that port is
available or not?

- Jason.

On Fri, Nov 4, 2016 at 1:33 AM, Andrea Magatti <andrea.magatti@gmail.com> wrote:

Hi Jason,

I've managed to solve this question using one machine so serve HTTPS for
BOSH, port 443, (hosting prosody and jicofo), and 4 machine (heavy load)
with only video-bridge (i kept open 443, 4443, and UDP restricted to
10k-11k ports)

Then on the js config of jitsi meet, i used only TCP signalling (UDP

This way when jvb start if the harvester finds 443 port free, it bind to
that port.

Next step will be adding more shards of jitsi-meet (one for
https/xmpp/jicofo, and several for jvb), and balancing these shards with a
SW load balancer ( I'm using Azure)


On Thu, Nov 3, 2016 at 8:58 PM, Jason Thomas <mail@jasonthom.as> wrote:

So, I have managed to set up JVB to serve my HTTPS content over port 443
by following the instructions at https://github.com/jitsi/ji
tsi-videobridge/blob/master/doc/http.md, but I am seeing the same exact
behavior now as when I was
trying port 80 with my nginx setup.

If I set org.jitsi.videobridge.TCP_HARVESTER_PORT=443 and block all
incoming/outgoing UDP (Except for port 63 for DNS),
I receive an IceConnectionStateFailed status.

If I instead set org.jitsi.videobridge.TCP_HARVESTER_PORT=4443 then it
is able to negotiate to use the TCP 4443 port, and video connection works.

My test environment is as follows:

[Meet/JVB Server] -> [ Laptop ] [ Client 1 ] [ Client 2]

Basically I have a separate server on the LAN, and I open two browser
tabs to test.

I just tested with meet.jit.si, and it works using port 443 with all UDP
blocked, however it appears as if the bridge is separate from the HTTP

meet.jit.si relevant candidate line:
a=candidate:2 1 ssltcp 1694498815 443 typ srflx raddr rport 443 generation 0

mylocaljvb.com relevant candidate line:
a=candidate:1 1 ssltcp 2130706431 443 typ host generation 0

Any ideas would be greatly appreciated. Thanks for the help so far!

- Jason.

On Nov 3, 2016, at 9:34 AM, Boris Grozev <boris@jitsi.org> wrote:

On 03/11/16 10:24, Jason Thomas wrote:


  Thanks for your prompt response. Definitely having JVB serve
everything seems like the best solution.

At the moment I am using NGINX, but also providing websockets because I
am using XMPP for Keyboard/Mouse remote control
that needs to be more performant than the XHR method.

Do you know if JVB currently supports web sockets?

I'm not certain, but I'm pretty sure web sockets are not supported.

If not, I can switch back to using http-bind, and maybe use the WebRTC

for sending these events.

Yes, you can definitely do that! See here for the format used by the

And here for the API, if you are using lib-jitsi-meet (to play nice with
lib-jitsi-meet you will need to format the messages in a certain way,
namely use a JSON object with a distinct "type" field):



users mailing list
Unsubscribe instructions and other list options:

users mailing list
Unsubscribe instructions and other list options:


[image: Andrea Magatti on about.me]

Andrea Magatti

users mailing list
Unsubscribe instructions and other list options:

- Jason Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jitsi.org/pipermail/users/attachments/20161104/4069ef07/attachment.html>


Subject: Digest Footer

users mailing list


End of users Digest, Vol 44, Issue 5