[jitsi-users] TCP Harvester on Port 80


#1

I’m currently trying to set up more robust NAT/Firewall traversal for my videobridge due to dealing with some firewalls that
are only allowing outgoing ports 443 and 80.

In order to test this, I’ve configured my local firewall to block all UDP ports.

The default settings where Jitsi-Meet is serving off of port 443, and falling back on port 4443 for SSLTCP seems to be working fine
for getting around a firewall that blocks all incoming/outgoing UDP traffic.

I’ve tried following the instructions here:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md

In order to try to configure the harvester on a different port.

I set in /etc/jitsi/videobridge/sip-communicator.config:
org.jitsi.videobridge.TCP_HARVESTER_PORT=4444

And when I do a test, I can see that traffic is being relayed over TCP on port 4444 via chrome://webrtc-internals

If I set it to port 80 instead (I have done the work necessary to allow Jitsi to serve directly off of port 80) I see that it advertises the candidate
at tcp port 80.

I can telnet to my server on port 80 only when the above setting has been configured and the video bridge has started.

However, I get an ICEConnectionStateFailed condition.

I also tried setting:
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=80

And running a proxy to forward traffic from port 80 to port 4443 using socat:
socat TCP-LISTEN:80,fork TCP:192.168.130.8:4443

Which acts exactly as described above.

However if I switch the settings:
org.jitsi.videobridge.TCP_HARVESTER_PORT=80
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=4443

socat TCP-LISTEN:4443,fork TCP:192.168.130.8:80

It works.

So it isn’t the proxying, or anything to do with the mechanics of my setup, but it seems the client treats ssltcp on port 80 differently than 4443, or 4444.

My only option at this point seems to have two separate servers, one for my video bridge and one for serving my backend.

Does anyone know exactly why I am seeing this sort of behavior trying to use port 80 for media transport over TCP rather than 4443, or 443?

- Jason Thomas.


#2

I don't know why it happens (I haven't tried, or heard about anyone else trying to use port 80). But you might want to look into serving the web content using jitsi-videobridge on port 443 (thus avoiding the second address)[0].

Jitsi-videobridge can also be configured to only bind on certain IP addresses[1], so if the above doesn't work for you, you can avoid using a separate server by adding one more IP address.

Regards,
Boris

[0] https://github.com/jitsi/jitsi-videobridge/blob/master/doc/http.md
[1] https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#orgice4jiceharvestallowed_addresses

···

On 02/11/16 17:34, Jason Thomas wrote:

I’m currently trying to set up more robust NAT/Firewall traversal for my
videobridge due to dealing with some firewalls that
are only allowing outgoing ports 443 and 80.

In order to test this, I’ve configured my local firewall to block all
UDP ports.

The default settings where Jitsi-Meet is serving off of port 443, and
falling back on port 4443 for SSLTCP seems to be working fine
for getting around a firewall that blocks all incoming/outgoing UDP traffic.

I’ve tried following the instructions here:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md

In order to try to configure the harvester on a different port.

I set in /etc/jitsi/videobridge/sip-communicator.config:
org.jitsi.videobridge.TCP_HARVESTER_PORT=4444

And when I do a test, I can see that traffic is being relayed over TCP
on port 4444 via chrome://webrtc-internals

If I set it to port 80 instead (I have done the work necessary to allow
Jitsi to serve directly off of port 80) I see that it advertises the
candidate
at tcp port 80.

I can telnet to my server on port 80 only when the above setting has
been configured and the video bridge has started.

However, I get an ICEConnectionStateFailed condition.

I also tried setting:
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=80

And running a proxy to forward traffic from port 80 to port 4443 using
socat:
socat TCP-LISTEN:80,fork TCP:192.168.130.8:4443

Which acts exactly as described above.

However if I switch the settings:
org.jitsi.videobridge.TCP_HARVESTER_PORT=80
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=4443

socat TCP-LISTEN:4443,fork TCP:192.168.130.8:80

It works.

So it isn’t the proxying, or anything to do with the mechanics of my
setup, but it seems the client treats ssltcp on port 80 differently than
4443, or 4444.

My only option at this point seems to have two separate servers, one for
my video bridge and one for serving my backend.

Does anyone know exactly why I am seeing this sort of behavior trying to
use port 80 for media transport over TCP rather than 4443, or 443?


#3

Boris,

   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? If not, I can switch back to using http-bind, and maybe use the WebRTC DataChannel
for sending these events.

- Jason.

···

On Nov 2, 2016, at 6:09 PM, Boris Grozev <boris@jitsi.org> wrote:

On 02/11/16 17:34, Jason Thomas wrote:

I’m currently trying to set up more robust NAT/Firewall traversal for my
videobridge due to dealing with some firewalls that
are only allowing outgoing ports 443 and 80.

In order to test this, I’ve configured my local firewall to block all
UDP ports.

The default settings where Jitsi-Meet is serving off of port 443, and
falling back on port 4443 for SSLTCP seems to be working fine
for getting around a firewall that blocks all incoming/outgoing UDP traffic.

I’ve tried following the instructions here:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md

In order to try to configure the harvester on a different port.

I set in /etc/jitsi/videobridge/sip-communicator.config:
org.jitsi.videobridge.TCP_HARVESTER_PORT=4444

And when I do a test, I can see that traffic is being relayed over TCP
on port 4444 via chrome://webrtc-internals

If I set it to port 80 instead (I have done the work necessary to allow
Jitsi to serve directly off of port 80) I see that it advertises the
candidate
at tcp port 80.

I can telnet to my server on port 80 only when the above setting has
been configured and the video bridge has started.

However, I get an ICEConnectionStateFailed condition.

I also tried setting:
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=80

And running a proxy to forward traffic from port 80 to port 4443 using
socat:
socat TCP-LISTEN:80,fork TCP:192.168.130.8:4443

Which acts exactly as described above.

However if I switch the settings:
org.jitsi.videobridge.TCP_HARVESTER_PORT=80
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=4443

socat TCP-LISTEN:4443,fork TCP:192.168.130.8:80

It works.

So it isn’t the proxying, or anything to do with the mechanics of my
setup, but it seems the client treats ssltcp on port 80 differently than
4443, or 4444.

My only option at this point seems to have two separate servers, one for
my video bridge and one for serving my backend.

Does anyone know exactly why I am seeing this sort of behavior trying to
use port 80 for media transport over TCP rather than 4443, or 443?

I don't know why it happens (I haven't tried, or heard about anyone else trying to use port 80). But you might want to look into serving the web content using jitsi-videobridge on port 443 (thus avoiding the second address)[0].

Jitsi-videobridge can also be configured to only bind on certain IP addresses[1], so if the above doesn't work for you, you can avoid using a separate server by adding one more IP address.

Regards,
Boris

[0] https://github.com/jitsi/jitsi-videobridge/blob/master/doc/http.md
[1] https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#orgice4jiceharvestallowed_addresses

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#4

Boris,

   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 DataChannel

for sending these events.

Yes, you can definitely do that! See here for the format used by the bridge:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/datachannel-communication.md

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):

https://github.com/jitsi/lib-jitsi-meet/blob/master/JitsiConference.js#L1252

Regards,
Boris

···

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


#5

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/jitsi-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 endpoint.

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

mylocaljvb.com relevant candidate line:
a=candidate:1 1 ssltcp 2130706431 192.168.130.8 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:

Boris,

  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 DataChannel

for sending these events.

Yes, you can definitely do that! See here for the format used by the bridge:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/datachannel-communication.md

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):

https://github.com/jitsi/lib-jitsi-meet/blob/master/JitsiConference.js#L1252

Regards,
Boris

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#6

Hi,

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/
jitsi-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 don't see anything wrong with this setup, it should work. I would look
at a pcap for clue, although it would be hard to distinguish ICE from HTTPS.

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
endpoint.

Correct, there's no HTTP(S) handling there.

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

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

This seems to rule out my one idea - a failure of the TCP harvester to bind
(it used to happen if jetty is bound to a wildcard, but jvb tries to bind
to a specific address, IIRC). Still, verify in the jvb logs that it bound
correctly.

Regards,
Boris

···

On Thursday, November 3, 2016, Jason Thomas <mail@jasonthom.as> wrote:

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 > <javascript:_e(%7B%7D,'cvml','boris@jitsi.org');>> wrote:

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

Boris,

  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
DataChannel

for sending these events.

Yes, you can definitely do that! See here for the format used by the
bridge:
https://github.com/jitsi/jitsi-videobridge/blob/master/
doc/datachannel-communication.md

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):

https://github.com/jitsi/lib-jitsi-meet/blob/master/
JitsiConference.js#L1252

Regards,
Boris

_______________________________________________
users mailing list
users@jitsi.org <javascript:_e(%7B%7D,'cvml','users@jitsi.org');>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#7

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
disabled)

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)

By

···

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/
jitsi-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
endpoint.

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

mylocaljvb.com relevant candidate line:
a=candidate:1 1 ssltcp 2130706431 192.168.130.8 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:

Boris,

  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
DataChannel

for sending these events.

Yes, you can definitely do that! See here for the format used by the
bridge:
https://github.com/jitsi/jitsi-videobridge/blob/master/
doc/datachannel-communication.md

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):

https://github.com/jitsi/lib-jitsi-meet/blob/master/
JitsiConference.js#L1252

Regards,
Boris

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--

[image: Andrea Magatti on about.me]

Andrea Magatti
about.me/amagatti
  <http://about.me/amagatti>


#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
provided.

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
disabled)

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)

By

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
endpoint.

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

mylocaljvb.com relevant candidate line:
a=candidate:1 1 ssltcp 2130706431 192.168.130.8 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:

Boris,

  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
DataChannel

for sending these events.

Yes, you can definitely do that! See here for the format used by the
bridge:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/
datachannel-communication.md

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):

https://github.com/jitsi/lib-jitsi-meet/blob/master/JitsiCon
ference.js#L1252

Regards,
Boris

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--

[image: Andrea Magatti on about.me]

Andrea Magatti
about.me/amagatti
  <http://about.me/amagatti>

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
- Jason Thomas
   http://jasonthom.as


#9

Alright, I finally suspected there must be something else blocking or
filtering low TCP ports—
and I think this Chrome bug verifies my suspicion:

https://bugs.chromium.org/p/webrtc/issues/detail?id=3583

Unexpectedly it is Chrome itself that is preventing tcpssl connections to a
LAN IP address.

Hopefully if anyone else runs into this they won't waste a day figuring it
out like I did :slight_smile:

Thanks for everyone's help, I'll deploy remotely with my current
configuration and test.

- Jason.

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
provided.

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 Nov 4, 2016, at 9:47 AM, Jason Thomas <mail@jasonthom.as> wrote:

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
disabled)

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)

By

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
endpoint.

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

mylocaljvb.com relevant candidate line:
a=candidate:1 1 ssltcp 2130706431 192.168.130.8 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:

Boris,

  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
DataChannel

for sending these events.

Yes, you can definitely do that! See here for the format used by the
bridge:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/d
atachannel-communication.md

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):

https://github.com/jitsi/lib-jitsi-meet/blob/master/JitsiCon
ference.js#L1252

Regards,
Boris

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--

[image: Andrea Magatti on about.me]

Andrea Magatti
about.me/amagatti
  <http://about.me/amagatti>

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
- Jason Thomas
   http://jasonthom.as


#10

Hi,

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 provided.

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?

Yes, there should be.

It is very surprising that the browser connects to the bridge on meet.jit.si on 443, but not to your bridge on port 80.

You could move HTTPS to another port and re-run the test with 443 to see if there is any difference between 80 and 443.

You could also try (again with HTTPS on another port) to have the bridge bind on 4443 and redirect 443 to it. This will change the candidate types from host (as they were in your tests) to srflx (as they are on meet.jit.si). This shouldn't make any difference, but it is another thing that is not the same in the two environments.

Regards,
Boris

···

On 04/11/16 10:47, Jason Thomas wrote:


#11

Boris,

I have verified that the following bug is indeed the issue which was causing my failure to connect via my LAN:

https://bugs.chromium.org/p/webrtc/issues/detail?id=3583 <https://bugs.chromium.org/p/webrtc/issues/detail?id=3583>

Pushing to a server on AWS everything works entirely over port 443 with the configuration you suggested.

I appears it is default behavior for Chrome/WebRTC tcpssl to ignore candidates on low ports for local area network addresses.

Thanks for all of your help!

- Jason.

···

On Nov 4, 2016, at 10:11 AM, Boris Grozev <boris@jitsi.org> wrote:

Hi,

On 04/11/16 10:47, Jason Thomas wrote:

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 provided.

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?

Yes, there should be.

It is very surprising that the browser connects to the bridge on meet.jit.si <http://meet.jit.si/> on 443, but not to your bridge on port 80.

You could move HTTPS to another port and re-run the test with 443 to see if there is any difference between 80 and 443.

You could also try (again with HTTPS on another port) to have the bridge bind on 4443 and redirect 443 to it. This will change the candidate types from host (as they were in your tests) to srflx (as they are on meet.jit.si <http://meet.jit.si/>). This shouldn't make any difference, but it is another thing that is not the same in the two environments.

Regards,
Boris

_______________________________________________
users mailing list
users@jitsi.org <mailto:users@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#12

Good find! I'm glad you got it to work, and thank you for sharing.

Regards,
Boris

···

On 04/11/16 15:56, Jason Thomas wrote:

Boris,

I have verified that the following bug is indeed the issue which was
causing my failure to connect via my LAN:

https://bugs.chromium.org/p/webrtc/issues/detail?id=3583
<https://bugs.chromium.org/p/webrtc/issues/detail?id=3583>

Pushing to a server on AWS everything works entirely over port 443 with
the configuration you suggested.

I appears it is default behavior for Chrome/WebRTC tcpssl to ignore
candidates on low ports for local area network addresses.


#13

Another weird bug!!!
thanks

···

On Fri, Nov 4, 2016 at 10:04 PM, Boris Grozev <boris@jitsi.org> wrote:

On 04/11/16 15:56, Jason Thomas wrote:

Boris,

I have verified that the following bug is indeed the issue which was
causing my failure to connect via my LAN:

https://bugs.chromium.org/p/webrtc/issues/detail?id=3583
<https://bugs.chromium.org/p/webrtc/issues/detail?id=3583>

Pushing to a server on AWS everything works entirely over port 443 with
the configuration you suggested.

I appears it is default behavior for Chrome/WebRTC tcpssl to ignore
candidates on low ports for local area network addresses.

Good find! I'm glad you got it to work, and thank you for sharing.

Regards,
Boris

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--

[image: Andrea Magatti on about.me]

Andrea Magatti
about.me/amagatti
  <http://about.me/amagatti>