[jitsi-dev] Audio/Video streaming over HTTPS (443).


#1


Hello,

I installed Jitsi-Meet (Quick install method) on a Debian Virtual Machine.
I set webrtcIceUdpDisable: true in /etc/jitsi/meet/myServer-config.js in
order to force JVB to use only port 443 for audio/video streaming, but it
fails to add pairs every time I connect 2 different clients...

Here's my configuration :
- Virtual Machine with: Debian GNU/Linux 8.2 (jessie)

- Two IP Addresses:
  1st interface => eth0 : 192.168.251.48 , nginx listening on 443 and JVB
listening on 4443
  2nd interface => eth0:1 : 192.168.251.62 , JVB listening on 4443 and port
443 is redirected to 4443 (Command : iptables -t nat -i eth0:1 -I
PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 4443) is that the
right command ? I'm not good with iptables.

- Here's the content of /etc/jitsi/videobridge/sip-communicator.properties:
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=443

According to jitsi.org this configuration should work. But it doesn't in my
case. could please tell what's wrong ?

PS : please find attached an extract from jvb.log.

jvb.log (15.3 KB)

···

--
______________________________________________
Hamza Khait


#2

Hey,


Hello,

I installed Jitsi-Meet (Quick install method) on a Debian Virtual
Machine. I set webrtcIceUdpDisable: true
in /etc/jitsi/meet/myServer-config.js in order to force JVB to use only
port 443 for audio/video streaming, but it fails to add pairs every time
I connect 2 different clients...

Here's my configuration :
- Virtual Machine with: Debian GNU/Linux 8.2 (jessie)

- Two IP Addresses:
   1st interface => eth0 : 192.168.251.48 , nginx listening on 443 and
JVB listening on 4443
   2nd interface => eth0:1 : 192.168.251.62 , JVB listening on 4443 and
port 443 is redirected to 4443 (Command : iptables -t nat -i eth0:1 -I
PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 4443) is that the
right command ? I'm not good with iptables.

- Here's the content of /etc/jitsi/videobridge/sip-communicator.properties:
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=443

According to jitsi.org <http://jitsi.org/> this configuration should
work. But it doesn't in my case. could please tell what's wrong ?

All the configuration looks good to me. Can you verify that you can reach the bridge on port 443 from the clients? Telnet to it and send it some data, it should close the connection on you without sending anything (as opposed to nginx which would send you back something).

You can also try making the bridge only listen on eth0:1, in case something with the multiple interfaces somehow causes a problem by setting
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth0:1

Regards,
Boris

···

On 14/12/15 08:26, Hamza Khait wrote:


#3

Hello Boris,

Hey,

All the configuration looks good to me. Can you verify that you can reach
the bridge on port 443 from the clients? Telnet to it and send it some
data, it should close the connection on you without sending anything (as
opposed to nginx which would send you back something).

​Yes I can reach both eth0 and eth0:1 on port 443 via telnet. The
connection is closed for both interfaces.

You can also try making the bridge only listen on eth0:1, in case
something with the multiple interfaces somehow causes a problem by setting
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth0:1

​When I do this, I obtain "Error : Jitsi Videobridge is currently
unavailable. Please try again later!"​ Here's the exception log :
java.lang.reflect.UndeclaredThrowableException
at
org.jitsi.videobridge.Conference.getTransportManager(Conference.java:1174)
at org.jitsi.videobridge.Channel.initialize(Channel.java:545)
at org.jitsi.videobridge.RtpChannel.initialize(RtpChannel.java:938)
at org.jitsi.videobridge.Content.createRtpChannel(Content.java:269)
at
org.jitsi.videobridge.Videobridge.handleColibriConferenceIQ(Videobridge.java:738)
at
org.jitsi.videobridge.Videobridge.handleColibriConferenceIQ(Videobridge.java:553)
at
org.jitsi.videobridge.xmpp.ComponentImpl.handleColibriConferenceIQ(ComponentImpl.java:262)
at
org.jitsi.videobridge.xmpp.ComponentImpl.handleIQRequest(ComponentImpl.java:433)
at org.jitsi.videobridge.xmpp.ComponentImpl.handleIQ(ComponentImpl.java:364)
at org.jitsi.videobridge.xmpp.ComponentImpl.handleIQ(ComponentImpl.java:316)
at
org.jitsi.videobridge.xmpp.ComponentImpl.handleIQGet(ComponentImpl.java:415)
at
org.xmpp.component.AbstractComponent.processIQRequest(AbstractComponent.java:511)
at
org.xmpp.component.AbstractComponent.processIQ(AbstractComponent.java:289)
at
org.xmpp.component.AbstractComponent.processQueuedPacket(AbstractComponent.java:239)
at
org.xmpp.component.AbstractComponent.access$100(AbstractComponent.java:81)
at
org.xmpp.component.AbstractComponent$PacketProcessor.run(AbstractComponent.java:1051)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Failed to bind even a single host candidate
for component:Component id=1 parent stream=stream
no local candidates.
no remote candidates. preferredPort=10001 minPort=10001 maxPort=10101
at
org.ice4j.ice.harvest.HostCandidateHarvester.harvest(HostCandidateHarvester.java:381)
at org.ice4j.ice.Agent.gatherCandidates(Agent.java:462)
at org.ice4j.ice.Agent.createComponent(Agent.java:404)
at
net.java.sip.communicator.impl.netaddr.NetworkAddressManagerServiceImpl.createIceStream(NetworkAddressManagerServiceImpl.java:736)
at
org.jitsi.videobridge.IceUdpTransportManager.createIceAgent(IceUdpTransportManager.java:732)
at
org.jitsi.videobridge.IceUdpTransportManager.<init>(IceUdpTransportManager.java:323)
at
org.jitsi.videobridge.IceUdpTransportManager.<init>(IceUdpTransportManager.java:293)
at
org.jitsi.videobridge.Conference.getTransportManager(Conference.java:1169)
... 18 more

···

On 14 December 2015 at 17:10, Boris Grozev <boris@jitsi.org> wrote:

Regards,
Boris

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

--
______________________________________________
Hamza Khait


#4

Another question, when I'm connected to jitsi server with two clients, I
get this in JVB log :
2015-12-15 10:17:25.131 INFOS: [44] org.ice4j.ice.Agent.gatherCandidates()
Gather candidates for component stream.RTP
2015-12-15 10:17:25.132 INFOS: [44] org.ice4j.ice.Agent.createComponent()
192.168.251.62:4443/tcp (host)
2015-12-15 10:17:25.132 INFOS: [44] org.ice4j.ice.Agent.createComponent()
192.168.251.48:4443/tcp (host)
2015-12-15 10:17:25.132 INFOS: [44] org.ice4j.ice.Agent.createComponent()
192.168.251.62:10000/udp (host)
2015-12-15 10:17:25.132 INFOS: [44] org.ice4j.ice.Agent.createComponent()
192.168.251.48:10000/udp (host)
2015-12-15 10:17:25.132 INFOS: [44] org.ice4j.ice.Agent.createComponent()
192.168.251.62:443/tcp (srflx)
2015-12-15 10:17:25.132 INFOS: [44] org.ice4j.ice.Agent.createComponent()
192.168.251.48:443/tcp (srflx)
.........
.........
2015-12-15 10:17:27.723 INFOS: [69]
org.ice4j.ice.Component.updateRemoteCandidates() new Pair added:
192.168.251.62:10000/udp/host -> 172.24.0.64:42950/udp/host (stream.RTP)
2015-12-15 10:17:27.723 INFOS: [69]
org.ice4j.ice.Component.updateRemoteCandidates() new Pair added:
192.168.251.48:10000/udp/host -> 172.24.0.64:42950/udp/host (stream.RTP)
.........
.........
2015-12-15 10:17:27.731 INFOS: [67]
org.ice4j.ice.ConnectivityCheckClient.run() Pair failed:
192.168.251.62:10000/udp/host -> 172.24.0.64:42950/udp/host (stream.RTP)
2015-12-15 10:17:27.752 INFOS: [67]
org.ice4j.ice.ConnectivityCheckClient.run() Pair failed:
192.168.251.48:10000/udp/host -> 172.24.0.64:42950/udp/host (stream.RTP)

is normal to have "192.168.251.62:10000/udp" and "192.168.251.48:10000/udp"
? (even with webrtcIceUdpDisable: true ?)
is the port 10000 hard coded in JVB ?

···

On 15 December 2015 at 09:55, Hamza Khait <hamza.khait@gmail.com> wrote:

Hello Boris,

On 14 December 2015 at 17:10, Boris Grozev <boris@jitsi.org> wrote:

Hey,

All the configuration looks good to me. Can you verify that you can reach
the bridge on port 443 from the clients? Telnet to it and send it some
data, it should close the connection on you without sending anything (as
opposed to nginx which would send you back something).

​Yes I can reach both eth0 and eth0:1 on port 443 via telnet. The
connection is closed for both interfaces.

You can also try making the bridge only listen on eth0:1, in case
something with the multiple interfaces somehow causes a problem by setting
org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth0:1

​When I do this, I obtain "Error : Jitsi Videobridge is currently
unavailable. Please try again later!"​ Here's the exception log :
java.lang.reflect.UndeclaredThrowableException
at
org.jitsi.videobridge.Conference.getTransportManager(Conference.java:1174)
at org.jitsi.videobridge.Channel.initialize(Channel.java:545)
at org.jitsi.videobridge.RtpChannel.initialize(RtpChannel.java:938)
at org.jitsi.videobridge.Content.createRtpChannel(Content.java:269)
at
org.jitsi.videobridge.Videobridge.handleColibriConferenceIQ(Videobridge.java:738)
at
org.jitsi.videobridge.Videobridge.handleColibriConferenceIQ(Videobridge.java:553)
at
org.jitsi.videobridge.xmpp.ComponentImpl.handleColibriConferenceIQ(ComponentImpl.java:262)
at
org.jitsi.videobridge.xmpp.ComponentImpl.handleIQRequest(ComponentImpl.java:433)
at
org.jitsi.videobridge.xmpp.ComponentImpl.handleIQ(ComponentImpl.java:364)
at
org.jitsi.videobridge.xmpp.ComponentImpl.handleIQ(ComponentImpl.java:316)
at
org.jitsi.videobridge.xmpp.ComponentImpl.handleIQGet(ComponentImpl.java:415)
at
org.xmpp.component.AbstractComponent.processIQRequest(AbstractComponent.java:511)
at
org.xmpp.component.AbstractComponent.processIQ(AbstractComponent.java:289)
at
org.xmpp.component.AbstractComponent.processQueuedPacket(AbstractComponent.java:239)
at
org.xmpp.component.AbstractComponent.access$100(AbstractComponent.java:81)
at
org.xmpp.component.AbstractComponent$PacketProcessor.run(AbstractComponent.java:1051)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Failed to bind even a single host
candidate for component:Component id=1 parent stream=stream
no local candidates.
no remote candidates. preferredPort=10001 minPort=10001 maxPort=10101
at
org.ice4j.ice.harvest.HostCandidateHarvester.harvest(HostCandidateHarvester.java:381)
at org.ice4j.ice.Agent.gatherCandidates(Agent.java:462)
at org.ice4j.ice.Agent.createComponent(Agent.java:404)
at
net.java.sip.communicator.impl.netaddr.NetworkAddressManagerServiceImpl.createIceStream(NetworkAddressManagerServiceImpl.java:736)
at
org.jitsi.videobridge.IceUdpTransportManager.createIceAgent(IceUdpTransportManager.java:732)
at
org.jitsi.videobridge.IceUdpTransportManager.<init>(IceUdpTransportManager.java:323)
at
org.jitsi.videobridge.IceUdpTransportManager.<init>(IceUdpTransportManager.java:293)
at
org.jitsi.videobridge.Conference.getTransportManager(Conference.java:1169)
... 18 more

Regards,
Boris

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

--
______________________________________________
Hamza Khait

--
______________________________________________
Hamza Khait


#5

You should not get a connection closing on eth0 443, as there is nginx
there, you should get an http reply from it.

In order to test the network setup, you can do the following -- stop
all the services in question and use netcat to probe all the ports.

This way you'll be sure the redirects are right. What you need is 443
on eth0 and 443 on eth0:1, internally redirected to 4443.

There could be some issue with the setup with network alias -- if you
have the option to add a second interface instead, you can test with
interface instead of an alias too.

···

On Tue, 15 Dec 2015 09:55:59 +0100 Hamza Khait wrote:

All the configuration looks good to me. Can you verify that you can
reach the bridge on port 443 from the clients? Telnet to it and send
it some data, it should close the connection on you without sending
anything (as opposed to nginx which would send you back something).

​Yes I can reach both eth0 and eth0:1 on port 443 via telnet. The
connection is closed for both interfaces.

--

Yasen Pramatarov
Lindeas Ltd. https://lindeas.com
'working on GNU/Linux ideas'
Professional Jitsi Meet services


#6

​Thank you Yasen for your answer.
The redirection problem has been solved but streaming still doesn't work...

​ ​
There could be some issue with the setup with network alias -- if you
have the option to add a second interface instead, you can test with
interface instead of an alias too.

​​This works fine now with netcat. Now I have eth0 and eth1. iptables
doesn't allow distinction between eth0 and eth0:1​

​I've noticed something strange in JVB log :
Pair failed: 192.168.251.62:10000/udp/host -> 172.24.0.64:35860/udp/host
Pair failed: 192.168.251.48:10000/udp/host -> 192.168.251.48:35860/udp/host​

​192.168.251.48 is my eth0
192.168.251.62​ is my eth1
192.168.251.48 The client's IP
Jitsi-videobridge doesn't use only tcp to add pairs. I'm wondering if it's
hard coded in the app or I'm not using the latest stable version of JVB.

Regards,

···

--
______________________________________________
Hamza Khait


#7

​​​172.24.0.64 is The client's IP*
Sorry​


#8

It looks like disabling UDP on the clients isn't working (if it were, the bridge would never know about these candidates). You can check by opening the javascript console and typing "config.webrtcIceUdpDisable". You should get "true".

I don't know why the TCP connection fails. You can check that:

1. The clients have the correct TCP candidates for the bridge. Go to "chrome://webrtc-internals", see the last "setRemoteDescription" call and look for the candidates.
2. The clients try to connect to the bridge (make a network dump on one of the client).

Regards,
Boris

···

On 15/12/15 18:43, Hamza Khait wrote:

​Thank you Yasen for your answer.
The redirection problem has been solved but streaming still doesn't work...

    ​ ​
    There could be some issue with the setup with network alias -- if you
      have the option to add a second interface instead, you can test with
      interface instead of an alias too.

​​This works fine now with netcat. Now I have eth0 and eth1. iptables
doesn't allow distinction between eth0 and eth0:1​

​I've noticed something strange in JVB log :
Pair failed: 192.168.251.62:10000/udp/host
<http://192.168.251.62:10000/udp/host> -> 172.24.0.64:35860/udp/host
<http://172.24.0.64:35860/udp/host>
Pair failed: 192.168.251.48:10000/udp/host
<http://192.168.251.48:10000/udp/host> -> 192.168.251.48:35860/udp/host
<http://192.168.251.48:35860/udp/host>​

​192.168.251.48 is my eth0
192.168.251.62​ is my eth1
192.168.251.48 The client's IP
Jitsi-videobridge doesn't use only tcp to add pairs. I'm wondering if
it's hard coded in the app or I'm not using the latest stable version of
JVB.