[jitsi-users] Getting Jitsi Meet to work in a container behind double NAT


#1

Hello everyone :slight_smile:

First of all, thank you so much for working on Jitsi Meet, it's an amazing
tool and I've been using it through meet.jit.si for months without (big :D)
issues! :slight_smile:

I am now trying to set it up on my server, but I'm having a few issues.

The user-facing problem is:
- browser loads the page
- browser asks for permission to access mic and camera
- after permission is granted, no video connection is established, i.e. all
the user sees is the blue screen with the big mic and camera icons in the
middle

My setup:
Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container that
runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04

Server maps <port A> to container's 443 via UFW

I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there were
no changes.

I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

Using Wireshark, I can see that the client browser first connects to <port

and exchanges data, then at one point it starts sending SYN to

<public_ip>:443, which looks wrong to me (and is already used by another
service on the server).

jvb.log shows 1 conference, 0 videostreams.

The only WARNING I get in jvb.log is "IceUdpTransportManager.log() Cannot
get transport type", the rest are INFO messages

The log also shows
net.java.sip.communicator.service.media.DISABLE_VIDEO_SUPPORT=true
... that looks a bit strange if you ask me :slight_smile:

Do you guys have any hint for me? How could I debug this?

Cheers,
Andrea


#2

@Andrea...Couple of thing:

1. Since you are behind router (NAT), simplified for the sake of
troubleshooting, don't use UFW for now
2. You will need to port forward tcp 443, udp 10000-20000 to your Ubuntu
box hosting Jitsi Meet
3. add the below to /etc/jitsi/videobridge/sip-communicator.properties
org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<jitsi- server>
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>

add the below line i reference to your host domain to
/etc/jitsi/jicofo/sip-communicator.properties
org.jitsi.jicofo.auth.URL=XMPP:jitsi-meet.example.com

If you install barebone installation of Ubuntu with SSH package, you don't
need to add:
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

This should work. Once it does, you can apply UFW and allow TCP 443 and UDP
10000-20000

Hope this helps.

···

On Wed, Sep 28, 2016 at 4:18 AM, Andrea Bernabei <and.bernabei@gmail.com> wrote:

Hello everyone :slight_smile:

First of all, thank you so much for working on Jitsi Meet, it's an amazing
tool and I've been using it through meet.jit.si for months without (big
:D) issues! :slight_smile:

I am now trying to set it up on my server, but I'm having a few issues.

The user-facing problem is:
- browser loads the page
- browser asks for permission to access mic and camera
- after permission is granted, no video connection is established, i.e.
all the user sees is the blue screen with the big mic and camera icons in
the middle

My setup:
Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container that
runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04

Server maps <port A> to container's 443 via UFW

I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there were
no changes.

I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

Using Wireshark, I can see that the client browser first connects to <port
> and exchanges data, then at one point it starts sending SYN to
<public_ip>:443, which looks wrong to me (and is already used by another
service on the server).

jvb.log shows 1 conference, 0 videostreams.

The only WARNING I get in jvb.log is "IceUdpTransportManager.log() Cannot
get transport type", the rest are INFO messages

The log also shows net.java.sip.communicator.serv
ice.media.DISABLE_VIDEO_SUPPORT=true ... that looks a bit strange if you
ask me :slight_smile:

Do you guys have any hint for me? How could I debug this?

Cheers,
Andrea

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

--
-john-


#3

Hi Andrea,

Have you checked in the “chrome://webrtc-internals <chrome://webrtc-internals>” page what are the candidates (IP addresses to use for RTP data) that the bridge is advertising?

You might also want to have a look at this https://github.com/gpolitis/systemd-ec2-metadata in case you want to avoid the NAT harvesters configurations.

I hope this helps.

Best,
George

···

On Sep 28, 2016, at 6:18 AM, Andrea Bernabei <and.bernabei@gmail.com> wrote:

Hello everyone :slight_smile:

First of all, thank you so much for working on Jitsi Meet, it's an amazing tool and I've been using it through meet.jit.si <http://meet.jit.si/> for months without (big :D) issues! :slight_smile:

I am now trying to set it up on my server, but I'm having a few issues.

The user-facing problem is:
- browser loads the page
- browser asks for permission to access mic and camera
- after permission is granted, no video connection is established, i.e. all the user sees is the blue screen with the big mic and camera icons in the middle

My setup:
Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container that runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04

Server maps <port A> to container's 443 via UFW

I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there were no changes.

I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

Using Wireshark, I can see that the client browser first connects to <port A> and exchanges data, then at one point it starts sending SYN to <public_ip>:443, which looks wrong to me (and is already used by another service on the server).

jvb.log shows 1 conference, 0 videostreams.

The only WARNING I get in jvb.log is "IceUdpTransportManager.log() Cannot get transport type", the rest are INFO messages

The log also shows net.java.sip.communicator.service.media.DISABLE_VIDEO_SUPPORT=true ... that looks a bit strange if you ask me :slight_smile:

Do you guys have any hint for me? How could I debug this?

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


#4

i think you need to free up the 443 port for jetty or nginx, depending on
your setup, since webrtc streams needs to be served on https

···

On Wed, Sep 28, 2016 at 1:18 PM, Andrea Bernabei <and.bernabei@gmail.com> wrote:

Hello everyone :slight_smile:

First of all, thank you so much for working on Jitsi Meet, it's an amazing
tool and I've been using it through meet.jit.si for months without (big
:D) issues! :slight_smile:

I am now trying to set it up on my server, but I'm having a few issues.

The user-facing problem is:
- browser loads the page
- browser asks for permission to access mic and camera
- after permission is granted, no video connection is established, i.e.
all the user sees is the blue screen with the big mic and camera icons in
the middle

My setup:
Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container that
runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04

Server maps <port A> to container's 443 via UFW

I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there were
no changes.

I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

Using Wireshark, I can see that the client browser first connects to <port
> and exchanges data, then at one point it starts sending SYN to
<public_ip>:443, which looks wrong to me (and is already used by another
service on the server).

jvb.log shows 1 conference, 0 videostreams.

The only WARNING I get in jvb.log is "IceUdpTransportManager.log() Cannot
get transport type", the rest are INFO messages

The log also shows net.java.sip.communicator.serv
ice.media.DISABLE_VIDEO_SUPPORT=true ... that looks a bit strange if you
ask me :slight_smile:

Do you guys have any hint for me? How could I debug this?

Cheers,
Andrea

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

--
Regards,
Mirko

¯\_(ツ)_/¯


#5

@Andrea...Couple of thing:

1. Since you are behind router (NAT), simplified for the sake of
troubleshooting, don't use UFW for now

I use ufw to forward the ports from the server to the container, but I just
modify before.rules file and explicitly add the iptables rules. It's
already working successfully with other containers. You mean you want me to
use iptables directly instead of ufw to do the port forwarding?

I have
- A PREROUTING -d 192.168.1.X/32 -p tcp -dport <portA> -j DNAT
--to-destination 10.197.Y.Z:443
- A PREROUTING -d 192.168.1.X/32 -p UDP -m multiport -dports 10000:20000 -j
DNAT --to-destination 10.197.Y.Z
- A PREROUTING -d 192.168.1.X/32 -p tcp -m multiport -dports 5222,5269,5347
-j DNAT --to-destination 10.197.Y.Z
in the before.rules file for ufw

I don't think the ports are blocked, since I have other services (in
separate containers) correctly running on port 443 and others (with port
forwarding)

2. You will need to port forward tcp 443, udp 10000-20000 to your Ubuntu

box hosting Jitsi Meet

See point 1

3. add the below to /etc/jitsi/videobridge/sip-communicator.properties
org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<jitsi- server>
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>

I have that, where jitsi-server is the IP of the container (10.197.Y.Z) and
publicip is the ISP-provided ip address

add the below line i reference to your host domain to
/etc/jitsi/jicofo/sip-communicator.properties
org.jitsi.jicofo.auth.URL=XMPP:jitsi-meet.example.com

I've just tried that, I did not notice any difference.
JiCoFo log has a warning (maybe it was there before the change as well):
"No pub-sub node mapped for jitsi-videobridge.<myFQDN>"

If you install barebone installation of Ubuntu with SSH package, you don't
need to add:
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

I did the install using the <stable> deb repo.
Why would those not be needed though? I thought MAPPED_PORT would advertise
to connect to server's <portA> instead of 443 (and <portA> will be
redirected to jitsibox's 443 by the port forwarding rules)

Should I remove both of them? even though you can't access the
jitsi-container from the internet on port443?

This should work. Once it does, you can apply UFW and allow TCP 443 and
UDP 10000-20000

Hope this helps.

No luck so far :frowning: but thanks for trying, I appreciate that.

Should I change jetty's port and tls port to be <portA> instead of 443? (to
convince clients that they shouldn't try connecting to 443 at all)

Cheers,
Andrea

···

2016-09-28 13:14 GMT+01:00 John Finding <findingjohn@gmail.com>:

On Wed, Sep 28, 2016 at 4:18 AM, Andrea Bernabei <and.bernabei@gmail.com> > wrote:

Hello everyone :slight_smile:

First of all, thank you so much for working on Jitsi Meet, it's an
amazing tool and I've been using it through meet.jit.si for months
without (big :D) issues! :slight_smile:

I am now trying to set it up on my server, but I'm having a few issues.

The user-facing problem is:
- browser loads the page
- browser asks for permission to access mic and camera
- after permission is granted, no video connection is established, i.e.
all the user sees is the blue screen with the big mic and camera icons in
the middle

My setup:
Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container
that runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04

Server maps <port A> to container's 443 via UFW

I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there were
no changes.

I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

Using Wireshark, I can see that the client browser first connects to
<port A> and exchanges data, then at one point it starts sending SYN to
<public_ip>:443, which looks wrong to me (and is already used by another
service on the server).

jvb.log shows 1 conference, 0 videostreams.

The only WARNING I get in jvb.log is "IceUdpTransportManager.log() Cannot
get transport type", the rest are INFO messages

The log also shows net.java.sip.communicator.serv
ice.media.DISABLE_VIDEO_SUPPORT=true ... that looks a bit strange if you
ask me :slight_smile:

Do you guys have any hint for me? How could I debug this?

Cheers,
Andrea

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

--
-john-

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


#6

Hi Andrea,

Have you checked in the “chrome://webrtc-internals” page what are the
candidates (IP addresses to use for RTP data) that the bridge is
advertising?

The "caller origin" that the page shows is correct. I tried enabling the
dumping of packets but it doesn't seem to be filling the log file with any
info

You might also want to have a look at this https://github.com/gpolitis/
systemd-ec2-metadata in case you want to avoid the NAT harvesters
configurations.

Interesting, thanks!

···

2016-09-28 15:54 GMT+01:00 George Politis <gp@jitsi.org>:

I hope this helps.

Best,
George

On Sep 28, 2016, at 6:18 AM, Andrea Bernabei <and.bernabei@gmail.com> > wrote:

Hello everyone :slight_smile:

First of all, thank you so much for working on Jitsi Meet, it's an amazing
tool and I've been using it through meet.jit.si for months without (big
:D) issues! :slight_smile:

I am now trying to set it up on my server, but I'm having a few issues.

The user-facing problem is:
- browser loads the page
- browser asks for permission to access mic and camera
- after permission is granted, no video connection is established, i.e.
all the user sees is the blue screen with the big mic and camera icons in
the middle

My setup:
Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container that
runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04

Server maps <port A> to container's 443 via UFW

I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there were
no changes.

I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

Using Wireshark, I can see that the client browser first connects to <port
> and exchanges data, then at one point it starts sending SYN to
<public_ip>:443, which looks wrong to me (and is already used by another
service on the server).

jvb.log shows 1 conference, 0 videostreams.

The only WARNING I get in jvb.log is "IceUdpTransportManager.log() Cannot
get transport type", the rest are INFO messages

The log also shows net.java.sip.communicator.serv
ice.media.DISABLE_VIDEO_SUPPORT=true ... that looks a bit strange if you
ask me :slight_smile:

Do you guys have any hint for me? How could I debug this?

Cheers,
Andrea
_______________________________________________
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


#7

Hi Mirko

Have you install the Jitsi-Meet server from scratch? Or through the debian repo?

Cheers.

···

On Wed, Sep 28, 2016 at 1:18 PM, Andrea Bernabei and.bernabei@gmail.com wrote:

Hello everyone :slight_smile:

First of all, thank you so much for working on Jitsi Meet, it’s an amazing tool and I’ve been using it through meet.jit.si for months without (big :D) issues! :slight_smile:

I am now trying to set it up on my server, but I’m having a few issues.

The user-facing problem is:

  • browser loads the page
  • browser asks for permission to access mic and camera
  • after permission is granted, no video connection is established, i.e. all the user sees is the blue screen with the big mic and camera icons in the middle

My setup:

Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container that runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04

Server maps to container’s 443 via UFW

I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there were no changes.

I modified /etc/jitsi/livebridge/sip-communicator.properties to add:

org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=

Using Wireshark, I can see that the client browser first connects to and exchanges data, then at one point it starts sending SYN to <public_ip>:443, which looks wrong to me (and is already used by another service on the server).

jvb.log shows 1 conference, 0 videostreams.

The only WARNING I get in jvb.log is “IceUdpTransportManager.log() Cannot get transport type”, the rest are INFO messages

The log also shows net.java.sip.communicator.service.media.DISABLE_VIDEO_SUPPORT=true … that looks a bit strange if you ask me :slight_smile:

Do you guys have any hint for me? How could I debug this?

Cheers,

Andrea


users mailing list

users@jitsi.org

Unsubscribe instructions and other list options:

http://lists.jitsi.org/mailman/listinfo/users
Regards,
Mirko

¯_(ツ)_/¯


#8

The jicofo config mentioned above is if you are using authentication
on the prosody side.
Maybe the problem has something to do with that double networking ...
not sure about that.
If you can verify that packets are coming in and going out the
container correctly, for example login in the container to verify
using nc, tcpdump on the 198.168... machine.
But if you are serving meet client through jvb's jetty at least port
443 should be ok. And you should be able to connect through 443 and
for media.

···

On Wed, Sep 28, 2016 at 8:25 AM, Andrea Bernabei <and.bernabei@gmail.com> wrote:

2016-09-28 13:14 GMT+01:00 John Finding <findingjohn@gmail.com>:

@Andrea...Couple of thing:

1. Since you are behind router (NAT), simplified for the sake of
troubleshooting, don't use UFW for now

I use ufw to forward the ports from the server to the container, but I just
modify before.rules file and explicitly add the iptables rules. It's already
working successfully with other containers. You mean you want me to use
iptables directly instead of ufw to do the port forwarding?

I have
- A PREROUTING -d 192.168.1.X/32 -p tcp -dport <portA> -j DNAT
--to-destination 10.197.Y.Z:443
- A PREROUTING -d 192.168.1.X/32 -p UDP -m multiport -dports 10000:20000 -j
DNAT --to-destination 10.197.Y.Z
- A PREROUTING -d 192.168.1.X/32 -p tcp -m multiport -dports 5222,5269,5347
-j DNAT --to-destination 10.197.Y.Z
in the before.rules file for ufw

I don't think the ports are blocked, since I have other services (in
separate containers) correctly running on port 443 and others (with port
forwarding)

2. You will need to port forward tcp 443, udp 10000-20000 to your Ubuntu
box hosting Jitsi Meet

See point 1

3. add the below to /etc/jitsi/videobridge/sip-communicator.properties
org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<jitsi- server>
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>

I have that, where jitsi-server is the IP of the container (10.197.Y.Z) and
publicip is the ISP-provided ip address

add the below line i reference to your host domain to
/etc/jitsi/jicofo/sip-communicator.properties
org.jitsi.jicofo.auth.URL=XMPP:jitsi-meet.example.com

I've just tried that, I did not notice any difference.
JiCoFo log has a warning (maybe it was there before the change as well):
"No pub-sub node mapped for jitsi-videobridge.<myFQDN>"

If you install barebone installation of Ubuntu with SSH package, you don't
need to add:
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

I did the install using the <stable> deb repo.
Why would those not be needed though? I thought MAPPED_PORT would advertise
to connect to server's <portA> instead of 443 (and <portA> will be
redirected to jitsibox's 443 by the port forwarding rules)

Should I remove both of them? even though you can't access the
jitsi-container from the internet on port443?

This should work. Once it does, you can apply UFW and allow TCP 443 and
UDP 10000-20000

Hope this helps.

No luck so far :frowning: but thanks for trying, I appreciate that.

Should I change jetty's port and tls port to be <portA> instead of 443? (to
convince clients that they shouldn't try connecting to 443 at all)

Cheers,
Andrea

On Wed, Sep 28, 2016 at 4:18 AM, Andrea Bernabei <and.bernabei@gmail.com> >> wrote:

Hello everyone :slight_smile:

First of all, thank you so much for working on Jitsi Meet, it's an
amazing tool and I've been using it through meet.jit.si for months without
(big :D) issues! :slight_smile:

I am now trying to set it up on my server, but I'm having a few issues.

The user-facing problem is:
- browser loads the page
- browser asks for permission to access mic and camera
- after permission is granted, no video connection is established, i.e.
all the user sees is the blue screen with the big mic and camera icons in
the middle

My setup:
Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container
that runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04

Server maps <port A> to container's 443 via UFW

I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there were
no changes.

I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

Using Wireshark, I can see that the client browser first connects to
<port A> and exchanges data, then at one point it starts sending SYN to
<public_ip>:443, which looks wrong to me (and is already used by another
service on the server).

jvb.log shows 1 conference, 0 videostreams.

The only WARNING I get in jvb.log is "IceUdpTransportManager.log() Cannot
get transport type", the rest are INFO messages

The log also shows
net.java.sip.communicator.service.media.DISABLE_VIDEO_SUPPORT=true ... that
looks a bit strange if you ask me :slight_smile:

Do you guys have any hint for me? How could I debug this?

Cheers,
Andrea

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

--
-john-

_______________________________________________
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


#9

Hi Enviado,

From deb package, but i'm not the one with a problem, Andrea is from

previous mail :slight_smile:

···

On Wed, Sep 28, 2016 at 1:52 PM, freakazoid@riseup.net < freakazoid@riseup.net> wrote:

Hi Mirko

Have you install the Jitsi-Meet server from scratch? Or through the debian
repo?

Cheers.

Enviado desde mi Huawei

-------- Mensaje original --------
Asunto: Re: [jitsi-users] Getting Jitsi Meet to work in a container behind
double NAT
De: Mirko Brankovic
Para: Jitsi Users
CC:

i think you need to free up the 443 port for jetty or nginx, depending on
your setup, since webrtc streams needs to be served on https

On Wed, Sep 28, 2016 at 1:18 PM, Andrea Bernabei <and.bernabei@gmail.com> > wrote:

Hello everyone :slight_smile:

First of all, thank you so much for working on Jitsi Meet, it's an
amazing tool and I've been using it through meet.jit.si for months
without (big :D) issues! :slight_smile:

I am now trying to set it up on my server, but I'm having a few issues.

The user-facing problem is:
- browser loads the page
- browser asks for permission to access mic and camera
- after permission is granted, no video connection is established, i.e.
all the user sees is the blue screen with the big mic and camera icons in
the middle

My setup:
Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container
that runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04

Server maps <port A> to container's 443 via UFW

I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there were
no changes.

I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

Using Wireshark, I can see that the client browser first connects to
<port A> and exchanges data, then at one point it starts sending SYN to
<public_ip>:443, which looks wrong to me (and is already used by another
service on the server).

jvb.log shows 1 conference, 0 videostreams.

The only WARNING I get in jvb.log is "IceUdpTransportManager.log() Cannot
get transport type", the rest are INFO messages

The log also shows net.java.sip.communicator.serv
ice.media.DISABLE_VIDEO_SUPPORT=true ... that looks a bit strange if you
ask me :slight_smile:

Do you guys have any hint for me? How could I debug this?

Cheers,
Andrea

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

--
Regards,
Mirko

¯\_(ツ)_/¯

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

--
Regards,
Mirko

¯\_(ツ)_/¯


#10

i think you need to free up the 443 port for jetty or nginx, depending on
your setup, since webrtc streams needs to be served on https

Hi Mirko,
port 443 is free inside the container, but it's not free on the server that
holds those containers.
The server forwards <portA> to jitsi-container's 443

···

2016-09-28 12:43 GMT+01:00 Mirko Brankovic <mirkobrankovic@gmail.com>:

On Wed, Sep 28, 2016 at 1:18 PM, Andrea Bernabei <and.bernabei@gmail.com> > wrote:

Hello everyone :slight_smile:

First of all, thank you so much for working on Jitsi Meet, it's an
amazing tool and I've been using it through meet.jit.si for months
without (big :D) issues! :slight_smile:

I am now trying to set it up on my server, but I'm having a few issues.

The user-facing problem is:
- browser loads the page
- browser asks for permission to access mic and camera
- after permission is granted, no video connection is established, i.e.
all the user sees is the blue screen with the big mic and camera icons in
the middle

My setup:
Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container
that runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04

Server maps <port A> to container's 443 via UFW

I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there were
no changes.

I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

Using Wireshark, I can see that the client browser first connects to
<port A> and exchanges data, then at one point it starts sending SYN to
<public_ip>:443, which looks wrong to me (and is already used by another
service on the server).

jvb.log shows 1 conference, 0 videostreams.

The only WARNING I get in jvb.log is "IceUdpTransportManager.log() Cannot
get transport type", the rest are INFO messages

The log also shows net.java.sip.communicator.serv
ice.media.DISABLE_VIDEO_SUPPORT=true ... that looks a bit strange if you
ask me :slight_smile:

Do you guys have any hint for me? How could I debug this?

Cheers,
Andrea

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

--
Regards,
Mirko

¯\_(ツ)_/¯

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


#11

The jicofo config mentioned above is if you are using authentication
on the prosody side.

I'm lost already.
Oh by the way, both videobridge and prosody are using LetsEncrypt
certificate that I added to the java keystore
(and the connection to https://domain:<portA>/ works correctly, no security
errors)

Maybe the problem has something to do with that double networking ...
not sure about that.
If you can verify that packets are coming in and going out the
container correctly, for example login in the container to verify

using nc, tcpdump on the 198.168... machine.

I'll try to get some proof later.

But if you are serving meet client through jvb's jetty at least port
443 should be ok. And you should be able to connect through 443 and
for media.

Not sure what you mean by "serving meet client through jvb's jetty", I can
just say that I get the jitsi webpage and the prompt for mic and camera
access :slight_smile:

···

2016-09-28 14:40 GMT+01:00 Damian Minkov <damencho@jitsi.org>:

On Wed, Sep 28, 2016 at 8:25 AM, Andrea Bernabei <and.bernabei@gmail.com> > wrote:
>
>
> 2016-09-28 13:14 GMT+01:00 John Finding <findingjohn@gmail.com>:
>>
>> @Andrea...Couple of thing:
>>
>> 1. Since you are behind router (NAT), simplified for the sake of
>> troubleshooting, don't use UFW for now
>
>
> I use ufw to forward the ports from the server to the container, but I
just
> modify before.rules file and explicitly add the iptables rules. It's
already
> working successfully with other containers. You mean you want me to use
> iptables directly instead of ufw to do the port forwarding?
>
> I have
> - A PREROUTING -d 192.168.1.X/32 -p tcp -dport <portA> -j DNAT
> --to-destination 10.197.Y.Z:443
> - A PREROUTING -d 192.168.1.X/32 -p UDP -m multiport -dports 10000:20000
-j
> DNAT --to-destination 10.197.Y.Z
> - A PREROUTING -d 192.168.1.X/32 -p tcp -m multiport -dports
5222,5269,5347
> -j DNAT --to-destination 10.197.Y.Z
> in the before.rules file for ufw
>
> I don't think the ports are blocked, since I have other services (in
> separate containers) correctly running on port 443 and others (with port
> forwarding)
>
>
>> 2. You will need to port forward tcp 443, udp 10000-20000 to your Ubuntu
>> box hosting Jitsi Meet
>
>
> See point 1
>
>>
>> 3. add the below to /etc/jitsi/videobridge/sip-communicator.properties
>> org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=
false
>> org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<jitsi- server>
>> org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
>
>
> I have that, where jitsi-server is the IP of the container (10.197.Y.Z)
and
> publicip is the ISP-provided ip address
>
>>
>>
>> add the below line i reference to your host domain to
>> /etc/jitsi/jicofo/sip-communicator.properties
>> org.jitsi.jicofo.auth.URL=XMPP:jitsi-meet.example.com
>>
>
> I've just tried that, I did not notice any difference.
> JiCoFo log has a warning (maybe it was there before the change as well):
> "No pub-sub node mapped for jitsi-videobridge.<myFQDN>"
>
>>
>> If you install barebone installation of Ubuntu with SSH package, you
don't
>> need to add:
>> org.jitsi.videobridge.TCP_HARVESTER_PORT=443
>> org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>
>
>
> I did the install using the <stable> deb repo.
> Why would those not be needed though? I thought MAPPED_PORT would
advertise
> to connect to server's <portA> instead of 443 (and <portA> will be
> redirected to jitsibox's 443 by the port forwarding rules)
>
> Should I remove both of them? even though you can't access the
> jitsi-container from the internet on port443?
>
>>
>> This should work. Once it does, you can apply UFW and allow TCP 443 and
>> UDP 10000-20000
>>
>> Hope this helps.
>
>
> No luck so far :frowning: but thanks for trying, I appreciate that.
>
> Should I change jetty's port and tls port to be <portA> instead of 443?
(to
> convince clients that they shouldn't try connecting to 443 at all)
>
> Cheers,
> Andrea
>
>>
>>
>> On Wed, Sep 28, 2016 at 4:18 AM, Andrea Bernabei < > and.bernabei@gmail.com> > >> wrote:
>>>
>>> Hello everyone :slight_smile:
>>>
>>> First of all, thank you so much for working on Jitsi Meet, it's an
>>> amazing tool and I've been using it through meet.jit.si for months
without
>>> (big :D) issues! :slight_smile:
>>>
>>> I am now trying to set it up on my server, but I'm having a few issues.
>>>
>>> The user-facing problem is:
>>> - browser loads the page
>>> - browser asks for permission to access mic and camera
>>> - after permission is granted, no video connection is established, i.e.
>>> all the user sees is the blue screen with the big mic and camera icons
in
>>> the middle
>>>
>>> My setup:
>>> Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container
>>> that runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04
>>>
>>> Server maps <port A> to container's 443 via UFW
>>>
>>> I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there
were
>>> no changes.
>>>
>>> I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
>>> org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
>>> org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
>>> org.jitsi.videobridge.TCP_HARVESTER_PORT=443
>>> org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>
>>>
>>> Using Wireshark, I can see that the client browser first connects to
>>> <port A> and exchanges data, then at one point it starts sending SYN to
>>> <public_ip>:443, which looks wrong to me (and is already used by
another
>>> service on the server).
>>>
>>> jvb.log shows 1 conference, 0 videostreams.
>>>
>>> The only WARNING I get in jvb.log is "IceUdpTransportManager.log()
Cannot
>>> get transport type", the rest are INFO messages
>>>
>>> The log also shows
>>> net.java.sip.communicator.service.media.DISABLE_VIDEO_SUPPORT=true
... that
>>> looks a bit strange if you ask me :slight_smile:
>>>
>>> Do you guys have any hint for me? How could I debug this?
>>>
>>> Cheers,
>>> Andrea
>>>
>>> _______________________________________________
>>> users mailing list
>>> users@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/users
>>
>>
>>
>>
>> --
>> -john-
>>
>> _______________________________________________
>> 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

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


#12

Hi Andrea,

Have you checked in the “chrome://webrtc-internals” page what are the
candidates (IP addresses to use for RTP data) that the bridge is
advertising?

The "caller origin" that the page shows is correct. I tried enabling the
dumping of packets but it doesn't seem to be filling the log file with any
info

So, after I changed the "bosh" line (see my previous message), I now get a
focusDisconnected error.
Here's what jicofo.log reports:

Jicofo 2016-09-28 15:23:15.107 WARNING: [86]
org.jitsi.jicofo.xmpp.FocusComponent.processIQ() (serving component 'Jitsi
Meet Focus') Unexpected exception while processing IQ stanza: <iq
type="set" to="focus.<domain>" from="<id1>@<domain>/<id2>"
id="<id3>:sendIQ"><conference xmlns="http://jitsi.org/protocol/focus"
room="indifferentvirusesstinkprecisely@conference.<domain>"
machine-uid="<id4>"><property value="-1" name="channelLastN"/><property
value="false" name="adaptiveLastN"/><property value="true"
name="disableRtx"/><property value="true" name="enableLipSync"/><property
value="true" name="openSctp"/><property value="rewriting"
name="simulcastMode"/></conference></iq>
java.lang.NullPointerException
    at
java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
    at
org.jitsi.jicofo.auth.AbstractAuthAuthority.getSession(AbstractAuthAuthority.java:290)
    at
org.jitsi.jicofo.auth.XMPPDomainAuthAuthority.processAuthLocked(XMPPDomainAuthAuthority.java:86)
    at
org.jitsi.jicofo.auth.AbstractAuthAuthority.processAuthentication(AbstractAuthAuthority.java:415)
    at
org.jitsi.jicofo.xmpp.FocusComponent.processExtensions(FocusComponent.java:368)
    at
org.jitsi.jicofo.xmpp.FocusComponent.handleConferenceIq(FocusComponent.java:429)
    at
org.jitsi.jicofo.xmpp.FocusComponent.handleIQSet(FocusComponent.java:274)
    at
org.xmpp.component.AbstractComponent.processIQRequest(AbstractComponent.java:515)
    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)

jvb.log just reports INFO msgs and the usual WARNING about "Could not get
transport type".
prosody.log reports no errors

Any idea?

···

2016-09-28 16:25 GMT+01:00 Andrea Bernabei <and.bernabei@gmail.com>:

2016-09-28 15:54 GMT+01:00 George Politis <gp@jitsi.org>:

You might also want to have a look at this https://github.com/gpolitis/sy
stemd-ec2-metadata in case you want to avoid the NAT harvesters
configurations.

Interesting, thanks!

I hope this helps.

Best,
George

On Sep 28, 2016, at 6:18 AM, Andrea Bernabei <and.bernabei@gmail.com> >> wrote:

Hello everyone :slight_smile:

First of all, thank you so much for working on Jitsi Meet, it's an
amazing tool and I've been using it through meet.jit.si for months
without (big :D) issues! :slight_smile:

I am now trying to set it up on my server, but I'm having a few issues.

The user-facing problem is:
- browser loads the page
- browser asks for permission to access mic and camera
- after permission is granted, no video connection is established, i.e.
all the user sees is the blue screen with the big mic and camera icons in
the middle

My setup:
Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container
that runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04

Server maps <port A> to container's 443 via UFW

I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there were
no changes.

I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

Using Wireshark, I can see that the client browser first connects to
<port A> and exchanges data, then at one point it starts sending SYN to
<public_ip>:443, which looks wrong to me (and is already used by another
service on the server).

jvb.log shows 1 conference, 0 videostreams.

The only WARNING I get in jvb.log is "IceUdpTransportManager.log() Cannot
get transport type", the rest are INFO messages

The log also shows net.java.sip.communicator.serv
ice.media.DISABLE_VIDEO_SUPPORT=true ... that looks a bit strange if you
ask me :slight_smile:

Do you guys have any hint for me? How could I debug this?

Cheers,
Andrea
_______________________________________________
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


#13

Hahaha oops. Sorry.

···

On Wed, Sep 28, 2016 at 1:52 PM, freakazoid@riseup.net freakazoid@riseup.net wrote:

Hi Mirko

Have you install the Jitsi-Meet server from scratch? Or through the debian repo?

Cheers.

Enviado desde mi Huawei

-------- Mensaje original --------
Asunto: Re: [jitsi-users] Getting Jitsi Meet to work in a container behind double NAT
De: Mirko Brankovic
Para: Jitsi Users
CC:

i think you need to free up the 443 port for jetty or nginx, depending on your setup, since webrtc streams needs to be served on https


users mailing list

users@jitsi.org

Unsubscribe instructions and other list options:

http://lists.jitsi.org/mailman/listinfo/users

Regards,
Mirko

¯_(ツ)_/¯

On Wed, Sep 28, 2016 at 1:18 PM, Andrea Bernabei and.bernabei@gmail.com wrote:

Hello everyone :slight_smile:

First of all, thank you so much for working on Jitsi Meet, it’s an amazing tool and I’ve been using it through meet.jit.si for months without (big :D) issues! :slight_smile:

I am now trying to set it up on my server, but I’m having a few issues.

The user-facing problem is:

  • browser loads the page
  • browser asks for permission to access mic and camera
  • after permission is granted, no video connection is established, i.e. all the user sees is the blue screen with the big mic and camera icons in the middle

My setup:

Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container that runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04

Server maps to container’s 443 via UFW

I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there were no changes.

I modified /etc/jitsi/livebridge/sip-communicator.properties to add:

org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=

Using Wireshark, I can see that the client browser first connects to and exchanges data, then at one point it starts sending SYN to <public_ip>:443, which looks wrong to me (and is already used by another service on the server).

jvb.log shows 1 conference, 0 videostreams.

The only WARNING I get in jvb.log is “IceUdpTransportManager.log() Cannot get transport type”, the rest are INFO messages

The log also shows net.java.sip.communicator.service.media.DISABLE_VIDEO_SUPPORT=true … that looks a bit strange if you ask me :slight_smile:

Do you guys have any hint for me? How could I debug this?

Cheers,

Andrea


users mailing list

users@jitsi.org

Unsubscribe instructions and other list options:

http://lists.jitsi.org/mailman/listinfo/users
Regards,
Mirko

¯_(ツ)_/¯


#14

You can update jicofo from unstable. We will push new versions in
stable today or tomorrow, there was a fix recently fixed in jicofo
about NPE, which I think is the same what you experience.

···

On Wed, Sep 28, 2016 at 12:44 PM, Andrea Bernabei <and.bernabei@gmail.com> wrote:

2016-09-28 16:25 GMT+01:00 Andrea Bernabei <and.bernabei@gmail.com>:

2016-09-28 15:54 GMT+01:00 George Politis <gp@jitsi.org>:

Hi Andrea,

Have you checked in the “chrome://webrtc-internals” page what are the
candidates (IP addresses to use for RTP data) that the bridge is
advertising?

The "caller origin" that the page shows is correct. I tried enabling the
dumping of packets but it doesn't seem to be filling the log file with any
info

So, after I changed the "bosh" line (see my previous message), I now get a
focusDisconnected error.
Here's what jicofo.log reports:

Jicofo 2016-09-28 15:23:15.107 WARNING: [86]
org.jitsi.jicofo.xmpp.FocusComponent.processIQ() (serving component 'Jitsi
Meet Focus') Unexpected exception while processing IQ stanza: <iq type="set"
to="focus.<domain>" from="<id1>@<domain>/<id2>"
id="<id3>:sendIQ"><conference xmlns="http://jitsi.org/protocol/focus"
room="indifferentvirusesstinkprecisely@conference.<domain>"
machine-uid="<id4>"><property value="-1" name="channelLastN"/><property
value="false" name="adaptiveLastN"/><property value="true"
name="disableRtx"/><property value="true" name="enableLipSync"/><property
value="true" name="openSctp"/><property value="rewriting"
name="simulcastMode"/></conference></iq>
java.lang.NullPointerException
    at
java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
    at
org.jitsi.jicofo.auth.AbstractAuthAuthority.getSession(AbstractAuthAuthority.java:290)
    at
org.jitsi.jicofo.auth.XMPPDomainAuthAuthority.processAuthLocked(XMPPDomainAuthAuthority.java:86)
    at
org.jitsi.jicofo.auth.AbstractAuthAuthority.processAuthentication(AbstractAuthAuthority.java:415)
    at
org.jitsi.jicofo.xmpp.FocusComponent.processExtensions(FocusComponent.java:368)
    at
org.jitsi.jicofo.xmpp.FocusComponent.handleConferenceIq(FocusComponent.java:429)
    at
org.jitsi.jicofo.xmpp.FocusComponent.handleIQSet(FocusComponent.java:274)
    at
org.xmpp.component.AbstractComponent.processIQRequest(AbstractComponent.java:515)
    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)

jvb.log just reports INFO msgs and the usual WARNING about "Could not get
transport type".
prosody.log reports no errors

Any idea?

You might also want to have a look at this
https://github.com/gpolitis/systemd-ec2-metadata in case you want to avoid
the NAT harvesters configurations.

Interesting, thanks!

I hope this helps.

Best,
George

On Sep 28, 2016, at 6:18 AM, Andrea Bernabei <and.bernabei@gmail.com> >>> wrote:

Hello everyone :slight_smile:

First of all, thank you so much for working on Jitsi Meet, it's an
amazing tool and I've been using it through meet.jit.si for months without
(big :D) issues! :slight_smile:

I am now trying to set it up on my server, but I'm having a few issues.

The user-facing problem is:
- browser loads the page
- browser asks for permission to access mic and camera
- after permission is granted, no video connection is established, i.e.
all the user sees is the blue screen with the big mic and camera icons in
the middle

My setup:
Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container
that runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04

Server maps <port A> to container's 443 via UFW

I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there were
no changes.

I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

Using Wireshark, I can see that the client browser first connects to
<port A> and exchanges data, then at one point it starts sending SYN to
<public_ip>:443, which looks wrong to me (and is already used by another
service on the server).

jvb.log shows 1 conference, 0 videostreams.

The only WARNING I get in jvb.log is "IceUdpTransportManager.log() Cannot
get transport type", the rest are INFO messages

The log also shows
net.java.sip.communicator.service.media.DISABLE_VIDEO_SUPPORT=true ... that
looks a bit strange if you ask me :slight_smile:

Do you guys have any hint for me? How could I debug this?

Cheers,
Andrea
_______________________________________________
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

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


#15

no problem :smiley:

···

On Wed, Sep 28, 2016 at 2:40 PM, freakazoid@riseup.net < freakazoid@riseup.net> wrote:

Hahaha oops. Sorry.

Enviado desde mi Huawei

-------- Mensaje original --------
Asunto: Re: [jitsi-users] Getting Jitsi Meet to work in a container behind
double NAT
De: Mirko Brankovic
Para: Jitsi Users
CC:

Hi Enviado,

From deb package, but i'm not the one with a problem, Andrea is from
previous mail :slight_smile:

On Wed, Sep 28, 2016 at 1:52 PM, freakazoid@riseup.net < > freakazoid@riseup.net> wrote:

Hi Mirko

Have you install the Jitsi-Meet server from scratch? Or through the
debian repo?

Cheers.

Enviado desde mi Huawei

-------- Mensaje original --------
Asunto: Re: [jitsi-users] Getting Jitsi Meet to work in a container
behind double NAT
De: Mirko Brankovic
Para: Jitsi Users
CC:

i think you need to free up the 443 port for jetty or nginx, depending on
your setup, since webrtc streams needs to be served on https

On Wed, Sep 28, 2016 at 1:18 PM, Andrea Bernabei <and.bernabei@gmail.com> >> wrote:

Hello everyone :slight_smile:

First of all, thank you so much for working on Jitsi Meet, it's an
amazing tool and I've been using it through meet.jit.si for months
without (big :D) issues! :slight_smile:

I am now trying to set it up on my server, but I'm having a few issues.

The user-facing problem is:
- browser loads the page
- browser asks for permission to access mic and camera
- after permission is granted, no video connection is established, i.e.
all the user sees is the blue screen with the big mic and camera icons in
the middle

My setup:
Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container
that runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04

Server maps <port A> to container's 443 via UFW

I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there
were no changes.

I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
org.jitsi.videobridge.TCP_HARVESTER_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>

Using Wireshark, I can see that the client browser first connects to
<port A> and exchanges data, then at one point it starts sending SYN to
<public_ip>:443, which looks wrong to me (and is already used by another
service on the server).

jvb.log shows 1 conference, 0 videostreams.

The only WARNING I get in jvb.log is "IceUdpTransportManager.log()
Cannot get transport type", the rest are INFO messages

The log also shows net.java.sip.communicator.serv
ice.media.DISABLE_VIDEO_SUPPORT=true ... that looks a bit strange if
you ask me :slight_smile:

Do you guys have any hint for me? How could I debug this?

Cheers,
Andrea

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

--
Regards,
Mirko

¯\_(ツ)_/¯

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

--
Regards,
Mirko

¯\_(ツ)_/¯

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

--
Regards,
Mirko

¯\_(ツ)_/¯


#16

The jicofo config mentioned above is if you are using authentication
on the prosody side.

I'm lost already.
Oh by the way, both videobridge and prosody are using LetsEncrypt
certificate that I added to the java keystore
(and the connection to https://domain:<portA>/ works correctly, no
security errors)

Maybe the problem has something to do with that double networking ...
not sure about that.
If you can verify that packets are coming in and going out the
container correctly, for example login in the container to verify

using nc, tcpdump on the 198.168... machine.

I'll try to get some proof later.

But if you are serving meet client through jvb's jetty at least port
443 should be ok. And you should be able to connect through 443 and
for media.

Not sure what you mean by "serving meet client through jvb's jetty", I can
just say that I get the jitsi webpage and the prompt for mic and camera
access :slight_smile:

Using Chrome's console I found out that the even though I visit
https://<domain>:<port>/
the client is trying to connect to https://<domain>/http-bind?room=blablabla
i.e. it's not connecting to the right port.

I grepped http-bind and found that
/etc/jitsi/meet/<domain>-config.js has a "bosh" entry that has that url.
I modified it to explicitly add the port, i.e. it's now
'//<domain>:<port>/http-bind'
and that fixed the blue screen issue!

Now I can see my video at the bottom right corner. The rest of the screen
is black, and Chrome console reports "focusDisconnected" errors.

I'll do more debuggining in the evening :wink: In the meanwhile, if you guys
have any hint, please let me know!

PS Is there any other place where I should append the <port> to, like the
"bosh" config line?

···

2016-09-28 14:58 GMT+01:00 Andrea Bernabei <and.bernabei@gmail.com>:

2016-09-28 14:40 GMT+01:00 Damian Minkov <damencho@jitsi.org>:

On Wed, Sep 28, 2016 at 8:25 AM, Andrea Bernabei <and.bernabei@gmail.com> >> wrote:
>
>
> 2016-09-28 13:14 GMT+01:00 John Finding <findingjohn@gmail.com>:
>>
>> @Andrea...Couple of thing:
>>
>> 1. Since you are behind router (NAT), simplified for the sake of
>> troubleshooting, don't use UFW for now
>
>
> I use ufw to forward the ports from the server to the container, but I
just
> modify before.rules file and explicitly add the iptables rules. It's
already
> working successfully with other containers. You mean you want me to use
> iptables directly instead of ufw to do the port forwarding?
>
> I have
> - A PREROUTING -d 192.168.1.X/32 -p tcp -dport <portA> -j DNAT
> --to-destination 10.197.Y.Z:443
> - A PREROUTING -d 192.168.1.X/32 -p UDP -m multiport -dports
10000:20000 -j
> DNAT --to-destination 10.197.Y.Z
> - A PREROUTING -d 192.168.1.X/32 -p tcp -m multiport -dports
5222,5269,5347
> -j DNAT --to-destination 10.197.Y.Z
> in the before.rules file for ufw
>
> I don't think the ports are blocked, since I have other services (in
> separate containers) correctly running on port 443 and others (with port
> forwarding)
>
>
>> 2. You will need to port forward tcp 443, udp 10000-20000 to your
Ubuntu
>> box hosting Jitsi Meet
>
>
> See point 1
>
>>
>> 3. add the below to /etc/jitsi/videobridge/sip-communicator.properties
>> org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.
checkReplay=false
>> org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<jitsi- server>
>> org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
>
>
> I have that, where jitsi-server is the IP of the container (10.197.Y.Z)
and
> publicip is the ISP-provided ip address
>
>>
>>
>> add the below line i reference to your host domain to
>> /etc/jitsi/jicofo/sip-communicator.properties
>> org.jitsi.jicofo.auth.URL=XMPP:jitsi-meet.example.com
>>
>
> I've just tried that, I did not notice any difference.
> JiCoFo log has a warning (maybe it was there before the change as well):
> "No pub-sub node mapped for jitsi-videobridge.<myFQDN>"
>
>>
>> If you install barebone installation of Ubuntu with SSH package, you
don't
>> need to add:
>> org.jitsi.videobridge.TCP_HARVESTER_PORT=443
>> org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>
>
>
> I did the install using the <stable> deb repo.
> Why would those not be needed though? I thought MAPPED_PORT would
advertise
> to connect to server's <portA> instead of 443 (and <portA> will be
> redirected to jitsibox's 443 by the port forwarding rules)
>
> Should I remove both of them? even though you can't access the
> jitsi-container from the internet on port443?
>
>>
>> This should work. Once it does, you can apply UFW and allow TCP 443 and
>> UDP 10000-20000
>>
>> Hope this helps.
>
>
> No luck so far :frowning: but thanks for trying, I appreciate that.
>
> Should I change jetty's port and tls port to be <portA> instead of 443?
(to
> convince clients that they shouldn't try connecting to 443 at all)
>
> Cheers,
> Andrea
>
>>
>>
>> On Wed, Sep 28, 2016 at 4:18 AM, Andrea Bernabei < >> and.bernabei@gmail.com> >> >> wrote:
>>>
>>> Hello everyone :slight_smile:
>>>
>>> First of all, thank you so much for working on Jitsi Meet, it's an
>>> amazing tool and I've been using it through meet.jit.si for months
without
>>> (big :D) issues! :slight_smile:
>>>
>>> I am now trying to set it up on my server, but I'm having a few
issues.
>>>
>>> The user-facing problem is:
>>> - browser loads the page
>>> - browser asks for permission to access mic and camera
>>> - after permission is granted, no video connection is established,
i.e.
>>> all the user sees is the blue screen with the big mic and camera
icons in
>>> the middle
>>>
>>> My setup:
>>> Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container
>>> that runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04
>>>
>>> Server maps <port A> to container's 443 via UFW
>>>
>>> I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there
were
>>> no changes.
>>>
>>> I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
>>> org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
>>> org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
>>> org.jitsi.videobridge.TCP_HARVESTER_PORT=443
>>> org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>
>>>
>>> Using Wireshark, I can see that the client browser first connects to
>>> <port A> and exchanges data, then at one point it starts sending SYN
to
>>> <public_ip>:443, which looks wrong to me (and is already used by
another
>>> service on the server).
>>>
>>> jvb.log shows 1 conference, 0 videostreams.
>>>
>>> The only WARNING I get in jvb.log is "IceUdpTransportManager.log()
Cannot
>>> get transport type", the rest are INFO messages
>>>
>>> The log also shows
>>> net.java.sip.communicator.service.media.DISABLE_VIDEO_SUPPORT=true
... that
>>> looks a bit strange if you ask me :slight_smile:
>>>
>>> Do you guys have any hint for me? How could I debug this?
>>>
>>> Cheers,
>>> Andrea
>>>
>>> _______________________________________________
>>> users mailing list
>>> users@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/users
>>
>>
>>
>>
>> --
>> -john-
>>
>> _______________________________________________
>> 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

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


#17

Is it possible you could use something like OpenVPN to create a non-NATted
tunnel between client and server, just to check that these are able to work
nicely together, without the NAT complication?

If that works, then you could introduce one level of NAT at a time, to track
down which bit is causing the problem.

Antony.

···

On Wednesday 28 September 2016 at 19:44:05, Andrea Bernabei wrote:

So, after I changed the "bosh" line (see my previous message), I now get a
focusDisconnected error.

jvb.log just reports INFO msgs and the usual WARNING about "Could not get
transport type".
prosody.log reports no errors

Any idea?

--
"It would appear we have reached the limits of what it is possible to achieve
with computer technology, although one should be careful with such statements;
they tend to sound pretty silly in five years."

- John von Neumann (1949)

                                                   Please reply to the list;
                                                         please *don't* CC me.


#18

You can update jicofo from unstable. We will push new versions in
stable today or tomorrow, there was a fix recently fixed in jicofo
about NPE, which I think is the same what you experience.

Aaand success! Video is working after updating to the packages from
unstable repo!
Thanks a lot everyone for the help! \o/

···

2016-09-28 18:49 GMT+01:00 Damian Minkov <damencho@jitsi.org>:

On Wed, Sep 28, 2016 at 12:44 PM, Andrea Bernabei > <and.bernabei@gmail.com> wrote:

>
>
> 2016-09-28 16:25 GMT+01:00 Andrea Bernabei <and.bernabei@gmail.com>:
>>
>>
>>
>> 2016-09-28 15:54 GMT+01:00 George Politis <gp@jitsi.org>:
>>>
>>> Hi Andrea,
>>>
>>> Have you checked in the “chrome://webrtc-internals” page what are the
>>> candidates (IP addresses to use for RTP data) that the bridge is
>>> advertising?
>>>
>>
>> The "caller origin" that the page shows is correct. I tried enabling the
>> dumping of packets but it doesn't seem to be filling the log file with
any
>> info
>
>
> So, after I changed the "bosh" line (see my previous message), I now get
a
> focusDisconnected error.
> Here's what jicofo.log reports:
>
> Jicofo 2016-09-28 15:23:15.107 WARNING: [86]
> org.jitsi.jicofo.xmpp.FocusComponent.processIQ() (serving component
'Jitsi
> Meet Focus') Unexpected exception while processing IQ stanza: <iq
type="set"
> to="focus.<domain>" from="<id1>@<domain>/<id2>"
> id="<id3>:sendIQ"><conference xmlns="http://jitsi.org/protocol/focus"
> room="indifferentvirusesstinkprecisely@conference.<domain>"
> machine-uid="<id4>"><property value="-1" name="channelLastN"/><property
> value="false" name="adaptiveLastN"/><property value="true"
> name="disableRtx"/><property value="true" name="enableLipSync"/><
property
> value="true" name="openSctp"/><property value="rewriting"
> name="simulcastMode"/></conference></iq>
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> at
> org.jitsi.jicofo.auth.AbstractAuthAuthority.getSession(
AbstractAuthAuthority.java:290)
> at
> org.jitsi.jicofo.auth.XMPPDomainAuthAuthority.processAuthLocked(
XMPPDomainAuthAuthority.java:86)
> at
> org.jitsi.jicofo.auth.AbstractAuthAuthority.processAuthentication(
AbstractAuthAuthority.java:415)
> at
> org.jitsi.jicofo.xmpp.FocusComponent.processExtensions(
FocusComponent.java:368)
> at
> org.jitsi.jicofo.xmpp.FocusComponent.handleConferenceIq(
FocusComponent.java:429)
> at
> org.jitsi.jicofo.xmpp.FocusComponent.handleIQSet(
FocusComponent.java:274)
> at
> org.xmpp.component.AbstractComponent.processIQRequest(
AbstractComponent.java:515)
> 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)
>
>
> jvb.log just reports INFO msgs and the usual WARNING about "Could not get
> transport type".
> prosody.log reports no errors
>
> Any idea?
>
>>
>>>
>>> You might also want to have a look at this
>>> https://github.com/gpolitis/systemd-ec2-metadata in case you want to
avoid
>>> the NAT harvesters configurations.
>>
>>
>> Interesting, thanks!
>>
>>>
>>> I hope this helps.
>>>
>>> Best,
>>> George
>>>
>>> On Sep 28, 2016, at 6:18 AM, Andrea Bernabei <and.bernabei@gmail.com> > >>> wrote:
>>>
>>> Hello everyone :slight_smile:
>>>
>>> First of all, thank you so much for working on Jitsi Meet, it's an
>>> amazing tool and I've been using it through meet.jit.si for months
without
>>> (big :D) issues! :slight_smile:
>>>
>>> I am now trying to set it up on my server, but I'm having a few issues.
>>>
>>> The user-facing problem is:
>>> - browser loads the page
>>> - browser asks for permission to access mic and camera
>>> - after permission is granted, no video connection is established, i.e.
>>> all the user sees is the blue screen with the big mic and camera icons
in
>>> the middle
>>>
>>> My setup:
>>> Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container
>>> that runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04
>>>
>>> Server maps <port A> to container's 443 via UFW
>>>
>>> I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there
were
>>> no changes.
>>>
>>> I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
>>> org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
>>> org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
>>> org.jitsi.videobridge.TCP_HARVESTER_PORT=443
>>> org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>
>>>
>>> Using Wireshark, I can see that the client browser first connects to
>>> <port A> and exchanges data, then at one point it starts sending SYN to
>>> <public_ip>:443, which looks wrong to me (and is already used by
another
>>> service on the server).
>>>
>>> jvb.log shows 1 conference, 0 videostreams.
>>>
>>> The only WARNING I get in jvb.log is "IceUdpTransportManager.log()
Cannot
>>> get transport type", the rest are INFO messages
>>>
>>> The log also shows
>>> net.java.sip.communicator.service.media.DISABLE_VIDEO_SUPPORT=true
... that
>>> looks a bit strange if you ask me :slight_smile:
>>>
>>> Do you guys have any hint for me? How could I debug this?
>>>
>>> Cheers,
>>> Andrea
>>> _______________________________________________
>>> 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
>>
>>
>
>
> _______________________________________________
> 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


#19

Great success :smiley:

···

On Wed, Sep 28, 2016 at 10:49 PM, Andrea Bernabei <and.bernabei@gmail.com> wrote:

2016-09-28 18:49 GMT+01:00 Damian Minkov <damencho@jitsi.org>:

You can update jicofo from unstable. We will push new versions in
stable today or tomorrow, there was a fix recently fixed in jicofo
about NPE, which I think is the same what you experience.

Aaand success! Video is working after updating to the packages from
unstable repo!
Thanks a lot everyone for the help! \o/

On Wed, Sep 28, 2016 at 12:44 PM, Andrea Bernabei >> <and.bernabei@gmail.com> wrote:

>
>
> 2016-09-28 16:25 GMT+01:00 Andrea Bernabei <and.bernabei@gmail.com>:
>>
>>
>>
>> 2016-09-28 15:54 GMT+01:00 George Politis <gp@jitsi.org>:
>>>
>>> Hi Andrea,
>>>
>>> Have you checked in the “chrome://webrtc-internals” page what are the
>>> candidates (IP addresses to use for RTP data) that the bridge is
>>> advertising?
>>>
>>
>> The "caller origin" that the page shows is correct. I tried enabling
the
>> dumping of packets but it doesn't seem to be filling the log file with
any
>> info
>
>
> So, after I changed the "bosh" line (see my previous message), I now
get a
> focusDisconnected error.
> Here's what jicofo.log reports:
>
> Jicofo 2016-09-28 15:23:15.107 WARNING: [86]
> org.jitsi.jicofo.xmpp.FocusComponent.processIQ() (serving component
'Jitsi
> Meet Focus') Unexpected exception while processing IQ stanza: <iq
type="set"
> to="focus.<domain>" from="<id1>@<domain>/<id2>"
> id="<id3>:sendIQ"><conference xmlns="http://jitsi.org/protocol/focus"
> room="indifferentvirusesstinkprecisely@conference.<domain>"
> machine-uid="<id4>"><property value="-1" name="channelLastN"/><property
> value="false" name="adaptiveLastN"/><property value="true"
> name="disableRtx"/><property value="true" name="enableLipSync"/><propert
y
> value="true" name="openSctp"/><property value="rewriting"
> name="simulcastMode"/></conference></iq>
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> at
> org.jitsi.jicofo.auth.AbstractAuthAuthority.getSession(Abstr
actAuthAuthority.java:290)
> at
> org.jitsi.jicofo.auth.XMPPDomainAuthAuthority.processAuthLoc
ked(XMPPDomainAuthAuthority.java:86)
> at
> org.jitsi.jicofo.auth.AbstractAuthAuthority.processAuthentic
ation(AbstractAuthAuthority.java:415)
> at
> org.jitsi.jicofo.xmpp.FocusComponent.processExtensions(Focus
Component.java:368)
> at
> org.jitsi.jicofo.xmpp.FocusComponent.handleConferenceIq(Focu
sComponent.java:429)
> at
> org.jitsi.jicofo.xmpp.FocusComponent.handleIQSet(FocusCompon
ent.java:274)
> at
> org.xmpp.component.AbstractComponent.processIQRequest(Abstra
ctComponent.java:515)
> at
> org.xmpp.component.AbstractComponent.processIQ(AbstractCompo
nent.java:289)
> at
> org.xmpp.component.AbstractComponent.processQueuedPacket(Abs
tractComponent.java:239)
> at
> org.xmpp.component.AbstractComponent.access$100(AbstractComp
onent.java:81)
> at
> org.xmpp.component.AbstractComponent$PacketProcessor.run(Abs
tractComponent.java:1051)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
Executor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
lExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
>
> jvb.log just reports INFO msgs and the usual WARNING about "Could not
get
> transport type".
> prosody.log reports no errors
>
> Any idea?
>
>>
>>>
>>> You might also want to have a look at this
>>> https://github.com/gpolitis/systemd-ec2-metadata in case you want to
avoid
>>> the NAT harvesters configurations.
>>
>>
>> Interesting, thanks!
>>
>>>
>>> I hope this helps.
>>>
>>> Best,
>>> George
>>>
>>> On Sep 28, 2016, at 6:18 AM, Andrea Bernabei <and.bernabei@gmail.com> >> >>> wrote:
>>>
>>> Hello everyone :slight_smile:
>>>
>>> First of all, thank you so much for working on Jitsi Meet, it's an
>>> amazing tool and I've been using it through meet.jit.si for months
without
>>> (big :D) issues! :slight_smile:
>>>
>>> I am now trying to set it up on my server, but I'm having a few
issues.
>>>
>>> The user-facing problem is:
>>> - browser loads the page
>>> - browser asks for permission to access mic and camera
>>> - after permission is granted, no video connection is established,
i.e.
>>> all the user sees is the blue screen with the big mic and camera
icons in
>>> the middle
>>>
>>> My setup:
>>> Public IP --> router (NAT) --> server (192.168.1.X) --> LXD container
>>> that runs jitsi-meet (NAT, 10.197.Y.Z) on Ubuntu 16.04
>>>
>>> Server maps <port A> to container's 443 via UFW
>>>
>>> I tried forwarding 10000-20000UDP, 5222/5269 (XMPP), 5347, but there
were
>>> no changes.
>>>
>>> I modified /etc/jitsi/livebridge/sip-communicator.properties to add:
>>> org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=10.197.Y.Z
>>> org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<public_ip>
>>> org.jitsi.videobridge.TCP_HARVESTER_PORT=443
>>> org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=<port A>
>>>
>>> Using Wireshark, I can see that the client browser first connects to
>>> <port A> and exchanges data, then at one point it starts sending SYN
to
>>> <public_ip>:443, which looks wrong to me (and is already used by
another
>>> service on the server).
>>>
>>> jvb.log shows 1 conference, 0 videostreams.
>>>
>>> The only WARNING I get in jvb.log is "IceUdpTransportManager.log()
Cannot
>>> get transport type", the rest are INFO messages
>>>
>>> The log also shows
>>> net.java.sip.communicator.service.media.DISABLE_VIDEO_SUPPORT=true
... that
>>> looks a bit strange if you ask me :slight_smile:
>>>
>>> Do you guys have any hint for me? How could I debug this?
>>>
>>> Cheers,
>>> Andrea
>>> _______________________________________________
>>> 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
>>
>>
>
>
> _______________________________________________
> 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

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

--
Regards,
Mirko
¯\_(ツ)_/¯