Fallback port (TCP_HARVESTER_PORT) is not working since JVB2

Hello !

Now my ~/.sip-communicator/sip-communicator.properties is properly taken in account by JVB and it’s working like a charm under NAT or not :

INFO: Attempting to load legacy config file at path /root, .sip-communicator, sip-communicator.properties
INFO: Registered the LegacyConfigurationServiceShim in OSGi.

Here is my sip-communicator.properties file (Not under NAT here) :

org.ice4j.ipv6.DISABLED=true
org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false
org.jitsi.videobridge.TCP_HARVESTER_PORT=80
org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT=10000

And as we can see here, the single port harvester is taken in account :
INFO: Initialized SinglePortUdpHarvester with address publicIP:10000/udp

According to this documentation, my fallback port is also properly set, but there is no mention of a fallback port in JVB logs and when I close my 10000/UDP port in my firewall the pair fails.

I already tried to change the port to 4443 or remove / add some directives but it won’t work. Also there is nothing listening in netstat -tunlp except 10000/UDP

Thanks in advance for your help !

Best regards,

1 Like

@Boris_Grozev did we remove the tcp harvester?
I know we disabled it by default as the recommended way if doing tcp is through coturn.

Up @Boris_Grozev :wink:

@damencho Could you tell me more about coturn ? I don’t exactly understand the association between a TURN server and the fallback port… :stuck_out_tongue:

Thanks !

I have to say that we urgently a definite answer, a lot of corporation don’t allow 10000/udp

(by the way why not using the skype range ?, it will be much easier to have corp to adopt Jitsi)

Thank you a lot
Christopher

1 Like

TURN server allows the following scenario:

  1. try
    client -> UDP/10000 -> :no_entry: (blocked by the corporate firewall) -> VideoBridge

  2. try
    client -> TCP/443 -> :white_check_mark: (allowed by the corporate firewall) -> TURN server -> UDP/10000 -> VideoBridge

Coturn is installed as a recommended package while installing the Jitsi-Meet package. Nginx can differ the http packages and the turn packages and redirects them to the right backends.

1 Like

Thank you for the explanation, we have plans to install coturn later (for 1to1 calls purpose) but it’s a little bit of overkill just for a fallback port.

Any news about the SINGLE_PORT_HARVESTER_PORT directive ?

Did you add org.jitsi.videobridge.DISABLE_TCP_HARVESTER=false to the config?
AFAIK, it’s disabled by default.

Hello !

Thanks for your answer, yes it seems it’s disable by default now (I think it’s not documented :wink: ).

Unfortunatly it stills won’t work but I can see it tries to.

Context : I used the 4443 port to prevent conflict with anything and checked that jvb listens the port and my client is able to bind to it (yes & yes).

In jvb logs we can see the proper transport description with both ports :

INFO: Transport description:
 <transport xmlns='urn:xmpp:jingle:transports:ice-udp:1' pwd='42gq3gbj69cq7fanf4kr0j1s17' ufrag='67c0d1edogf60o'><rtcp-mux/><fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' setup='active' hash='sha-256'>D8:56:4C:7F:FD:19:6E:6B:FC:38:E7:84:43:65:AD:A9:5B:15:E2:DA:FB:4B:04:96:D7:CF:E7:93:27:1F:39:1B</fingerprint><candidate component='1' foundation='1' generation='0' id='6ecfe08e5203a9940ffffffffba56826e' network='0' priority='2130706431' protocol='ssltcp' tcptype='passive' type='host' ip='serverIP' port='4443'/><candidate component='1' foundation='2' generation='0' id='600803275203a9940ffffffffba569823' network='0' priority='2130706431' protocol='udp' type='host' ip='serverIP' port='10000'/></transport>

It tries to bind 10000/UDP and fails (This is wanted) :

INFO: Pair failed: serverIP:10000/udp/host -> clientIP:58977/udp/host (stream-61f57349.RTP)

After that, it tries to bind 4443/TCP but it also fails (it timeout actually) :

INFO: Pair failed: serverIP:4443/tcp/host -> clientIP:9/tcp/host (stream-61f57349.RTP)
INFO: Read timeout for socket: Socket[addr=/clientIP,port=61454,localport=4443]

My Javascript console says :

[modules/RTC/BridgeChannel.js] <l._send>:  Bridge Channel send: no opened channel.

It seems to be a network related issue but all seems good to me… I also tried to tcpdump the 4443/TCP and it says something when I connect with the 10000/UDP closed client but I can’t interpret it :

13:21:21.641922 IP clientIP.62671 > gatewayIP: Flags [S], seq 1591956518, win 8192, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0
	0x0000:  4500 0034 2f5c 4000 7006 57d9 b951 34a1  E..4/\@.p.W..Q4.
	0x0010:  a772 ee29 f4cf 115b 5ee3 5426 0000 0000  .r.)...[^.T&....
	0x0020:  8002 2000 1261 0000 0204 05a0 0103 0308  .....a..........
	0x0030:  0101 0402                                ....
13:21:21.642038 IP gatewayIP > clientIP.62671: Flags [S.], seq 3292801252, ack 1591956519, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 8], length 0
	0x0000:  4500 0034 0000 4000 4006 b735 a772 ee29  E..4..@.@..5.r.)
	0x0010:  b951 34a1 115b f4cf c444 28e4 5ee3 5427  .Q4..[...D(.^.T'
	0x0020:  8012 7210 83b5 0000 0204 05b4 0101 0402  ..r.............
	0x0030:  0103 0308                                ....
13:21:21.663290 IP clientIP.62671 > gatewayIP: Flags [.], ack 1, win 258, length 0
	0x0000:  4500 0028 2f5d 4000 7006 57e4 b951 34a1  E..(/]@.p.W..Q4.
	0x0010:  a772 ee29 f4cf 115b 5ee3 5427 c444 28e5  .r.)...[^.T'.D(.
	0x0020:  5010 0102 84e4 0000                      P.......
13:21:21.676601 IP clientIP.62671 > gatewayIP: Flags [P.], seq 1:165, ack 1, win 258, length 164
	0x0000:  4500 00cc 2f5e 4000 7006 573f b951 34a1  E.../^@.p.W?.Q4.
	0x0010:  a772 ee29 f4cf 115b 5ee3 5427 c444 28e5  .r.)...[^.T'.D(.
	0x0020:  5018 0102 631f 0000 1603 0100 9f01 0000  P...c...........
	0x0030:  9b03 01cd e00e 972b e43e f6ad 5391 a192  .......+.>..S...
	0x0040:  b3ae d4a7 c832 b487 a0bf 9c3e 89f8 4856  .....2.....>..HV
	0x0050:  d8b9 8a00 0052 c00a c014 0039 0038 0088  .....R.....9.8..
	0x0060:  0087 c019 003a 0089 c009 c013 0033 0032  .....:.......3.2
	0x0070:  009a 0099 0045 0044 c018 0034 009b 0046  .....E.D...4...F
	0x0080:  c007 c011 c016 0018 c008 c012 0016 0013  ................
	0x0090:  c017 001b 0035 0084 002f 0096 0041 0007  .....5.../...A..
	0x00a0:  0005 0004 000a 00ff 0100 0020 000b 0004  ................
	0x00b0:  0300 0102 000a 000c 000a 001d 0017 001e  ................
	0x00c0:  0019 0018 0023 0000 0017 0000            .....#......
13:21:21.676645 IP gatewayIP > clientIP.62671: Flags [.], ack 165, win 119, length 0
	0x0000:  4500 0028 5f15 4000 4006 582c a772 ee29  E..(_.@.@.X,.r.)
	0x0010:  b951 34a1 115b f4cf c444 28e5 5ee3 54cb  .Q4..[...D(.^.T.
	0x0020:  5010 0077 83a9 0000                      P..w....

Thanks in advance for your help ! :+1:

up @damencho ?

I have no idea why it does not work.
TCP harvester is not recommended to be used as there are problems with it (not sure for all of them) … that’s why it was disabled, we recommend using a turn server for tcp media.
One problem we were seeing reports for is that at some point the jvb starts using 100% of the cpu … maybe it was only the old jvb … not sure. It is possible we broke it as we do not use it at all … and as such not used feature it may go away at some point …

@Jerome_LEMAN_GARIN if you see candidates for udp/10000 and tcp/4443 then your bridge is configured correctly (note that we removed the fallback port, but the documentation hasn’t been updated). Do you have any firewall between the client and bridge that could start blocking the session on 4443? The stream is not a genuine TLS stream and firewalls can recognize it, this is the main reason we recommend using TURN/TLS.

If you wanted to dig deep and debug this you could get captures from both the client and the server and see if all packets make it (make sure to save in a pcap file so it can be interpreted more easily).

Boris