[jitsi-dev] Questions about a docker image (and/or proxy/nat)


#1

Hi

I continue fighting to build my docker image. It is very simple, getting
the debian image, adding the jitsi repo, adding the pkg and running a
dkpg-reconfigure to set the defaults parameters.

To test, I installed in the 'debian way', using a new debian box, and
following the steps above. Runs fine. With this steps, I know that my env
haven't limitations or problems.

The next step was install my image. So, I used the follow command:
$ docker run -it --name jitsi --network host filhocf/jitsi-meet:20161016

With it, docker pulls my image and runs it, calling a initial script for
conf proposes. The --network option says to docker expose all interfaces of
container to host. Is like the first scenary, with jitsi installed in the
host. To here, all ok.

The third step was put my instance into internal network of docker:
$ docker run -it --name jitsi -p 80:80 -p 443:443
filhocf/jitsi-meet:20161016

With this step, only ports 80 and 443 are exposed. I tried again, without
success. After, I followed this instructions (
https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md#running-behind-nat),
changing the file /etc/jitsi/videobridge/sip-communicator.properties with
this lines:

org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<Docker.IP.Address>
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<Public.IP.Address>
After restarted all services, I tried again without success.

So, my ask is how can I make the UDP pkgs pass through Nginx? Or if is
possible to use only TCP instead UDP pkgs? If yes, where can I find more
info? Do you have some other suggestion for this question?

Since now, thanks in advance.

Regards,
Claudio Ferreira


#2

Try exposing the (other) ports used for media: just 10000, or 10000-20000.

Regards,
Boris

···

On 06/10/16 02:20, Claudio Ferreia Filho wrote:

Hi

I continue fighting to build my docker image. It is very simple, getting
the debian image, adding the jitsi repo, adding the pkg and running a
dkpg-reconfigure to set the defaults parameters.

To test, I installed in the 'debian way', using a new debian box, and
following the steps above. Runs fine. With this steps, I know that my
env haven't limitations or problems.

The next step was install my image. So, I used the follow command:
$ docker run -it --name jitsi --network host filhocf/jitsi-meet:20161016

With it, docker pulls my image and runs it, calling a initial script for
conf proposes. The --network option says to docker expose all interfaces
of container to host. Is like the first scenary, with jitsi installed in
the host. To here, all ok.

The third step was put my instance into internal network of docker:
$ docker run -it --name jitsi -p 80:80 -p 443:443
filhocf/jitsi-meet:20161016

With this step, only ports 80 and 443 are exposed.


#3

Hi,
Exposing 10000/udp worked for me. The RTP packets do not go through nginx – as far as I know they go from browser directly to videobridge. So the docker container that starts videobridge needs to have port 10000/udp published (videobridge by default works in a “single port setup” – where all the media streams are passing through a single 10000/udp port.)
Jernej

···

From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Claudio Ferreia Filho
Sent: 6. oktober 2016 1:20
To: Jitsi Developers
Subject: [jitsi-dev] Questions about a docker image (and/or proxy/nat)

Hi

I continue fighting to build my docker image. It is very simple, getting the debian image, adding the jitsi repo, adding the pkg and running a dkpg-reconfigure to set the defaults parameters.

To test, I installed in the 'debian way', using a new debian box, and following the steps above. Runs fine. With this steps, I know that my env haven't limitations or problems.

The next step was install my image. So, I used the follow command:
$ docker run -it --name jitsi --network host filhocf/jitsi-meet:20161016

With it, docker pulls my image and runs it, calling a initial script for conf proposes. The --network option says to docker expose all interfaces of container to host. Is like the first scenary, with jitsi installed in the host. To here, all ok.

The third step was put my instance into internal network of docker:
$ docker run -it --name jitsi -p 80:80 -p 443:443 filhocf/jitsi-meet:20161016

With this step, only ports 80 and 443 are exposed. I tried again, without success. After, I followed this instructions (https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md#running-behind-nat), changing the file /etc/jitsi/videobridge/sip-communicator.properties with this lines:

org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<Docker.IP.Address>
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<Public.IP.Address>
After restarted all services, I tried again without success.

So, my ask is how can I make the UDP pkgs pass through Nginx? Or if is possible to use only TCP instead UDP pkgs? If yes, where can I find more info? Do you have some other suggestion for this question?

Since now, thanks in advance.

Regards,
Claudio Ferreira


#4

Hi
Thank you, Boris and Jersei, by your replies, but isn't a acceptable
situation. Imagine a second scenary:

        +--+ +--+
user -> |RP| -> |JS|
        +--+ +--+
        DMZ Internal net

Where RP = Reverse Proxy, like a Nginx, and JS is the jitsi server,
installed in the host. Other similar situation are some PaaS providers,
where the machine have a external (and real) IP that is routed to internal
IP by NAT. In my PoV is the same situation too, and both without success.
Docker is practically the same thing.
In other words, you can connect with external IP, open the main page, look
your self, look other people connecting into room, but haven't interchange
of audio and video between participants in the room. I understood that this
change is based in UDP communication. I already configured the
sip.communicator file for videobridge, and nothing.
Any other suggestion?

Regards,
Claudio Ferreira

···

2016-10-06 5:30 GMT-03:00 Trnkoczy, Jernej <Jernej.Trnkoczy@fgg.uni-lj.si>:

Hi,

Exposing 10000/udp worked for me. The RTP packets do not go through nginx
– as far as I know they go from browser directly to videobridge. So the
docker container that starts videobridge needs to have port 10000/udp
published (videobridge by default works in a “single port setup” – where
all the media streams are passing through a single 10000/udp port.)

Jernej

*From:* dev [mailto:dev-bounces@jitsi.org] *On Behalf Of *Claudio Ferreia
Filho
*Sent:* 6. oktober 2016 1:20
*To:* Jitsi Developers
*Subject:* [jitsi-dev] Questions about a docker image (and/or proxy/nat)

Hi

I continue fighting to build my docker image. It is very simple, getting
the debian image, adding the jitsi repo, adding the pkg and running a
dkpg-reconfigure to set the defaults parameters.

To test, I installed in the 'debian way', using a new debian box, and
following the steps above. Runs fine. With this steps, I know that my env
haven't limitations or problems.

The next step was install my image. So, I used the follow command:

$ docker run -it --name jitsi --network host filhocf/jitsi-meet:20161016

With it, docker pulls my image and runs it, calling a initial script for
conf proposes. The --network option says to docker expose all interfaces of
container to host. Is like the first scenary, with jitsi installed in the
host. To here, all ok.

The third step was put my instance into internal network of docker:

$ docker run -it --name jitsi -p 80:80 -p 443:443
filhocf/jitsi-meet:20161016

With this step, only ports 80 and 443 are exposed. I tried again, without
success. After, I followed this instructions (https://github.com/jitsi/
jitsi-meet/blob/master/doc/manual-install.md#running-behind-nat),
changing the file /etc/jitsi/videobridge/sip-communicator.properties with
this lines:

org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false

org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<Docker.IP.Address>

org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<Public.IP.Address>

After restarted all services, I tried again without success.

So, my ask is how can I make the UDP pkgs pass through Nginx? Or if is
possible to use only TCP instead UDP pkgs? If yes, where can I find more
info? Do you have some other suggestion for this question?

Since now, thanks in advance.

Regards,

Claudio Ferreira

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


#5

Hi,
I do not completely understand what do you want. If UDP traffic is not allowed (e.g. blocked by firewall) - then I believe that videobridge has a small web server (jetty) included – and it is possible to stream video/audio using TCP on port 443. However I never tested this and I do not know if it needs special configuration. Maybe somebody else will be able to help…

I am running jitsi-meet in Docker container using Docker bridge networking. I put the following in the sip-communicator config file of videobridge:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<Here I put the IP of docker container – so you need to find out which local IP was assigned to your container – eg. 172.17.0.2>
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<Public.IP.Address – the IP of the docker host>
And this works for me…

But I did not make the Docker image following “easy install” – I’ve tried but had problems with reconfiguration. So I made the docker image using “manual install” process – which was a bit painful and took me a very long time to figure out (the official documentation is missing some little tricks).

Jernej

···

From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Claudio Ferreia Filho
Sent: 6. oktober 2016 12:33
To: Jitsi Developers
Subject: Re: [jitsi-dev] Questions about a docker image (and/or proxy/nat)

Hi
Thank you, Boris and Jersei, by your replies, but isn't a acceptable situation. Imagine a second scenary:

        +--+ +--+
user -> |RP| -> |JS|
        +--+ +--+
        DMZ Internal net

Where RP = Reverse Proxy, like a Nginx, and JS is the jitsi server, installed in the host. Other similar situation are some PaaS providers, where the machine have a external (and real) IP that is routed to internal IP by NAT. In my PoV is the same situation too, and both without success. Docker is practically the same thing.
In other words, you can connect with external IP, open the main page, look your self, look other people connecting into room, but haven't interchange of audio and video between participants in the room. I understood that this change is based in UDP communication. I already configured the sip.communicator file for videobridge, and nothing.
Any other suggestion?

Regards,
Claudio Ferreira

2016-10-06 5:30 GMT-03:00 Trnkoczy, Jernej <Jernej.Trnkoczy@fgg.uni-lj.si<mailto:Jernej.Trnkoczy@fgg.uni-lj.si>>:
Hi,
Exposing 10000/udp worked for me. The RTP packets do not go through nginx – as far as I know they go from browser directly to videobridge. So the docker container that starts videobridge needs to have port 10000/udp published (videobridge by default works in a “single port setup” – where all the media streams are passing through a single 10000/udp port.)
Jernej

From: dev [mailto:dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org>] On Behalf Of Claudio Ferreia Filho
Sent: 6. oktober 2016 1:20
To: Jitsi Developers
Subject: [jitsi-dev] Questions about a docker image (and/or proxy/nat)

Hi

I continue fighting to build my docker image. It is very simple, getting the debian image, adding the jitsi repo, adding the pkg and running a dkpg-reconfigure to set the defaults parameters.

To test, I installed in the 'debian way', using a new debian box, and following the steps above. Runs fine. With this steps, I know that my env haven't limitations or problems.

The next step was install my image. So, I used the follow command:
$ docker run -it --name jitsi --network host filhocf/jitsi-meet:20161016

With it, docker pulls my image and runs it, calling a initial script for conf proposes. The --network option says to docker expose all interfaces of container to host. Is like the first scenary, with jitsi installed in the host. To here, all ok.

The third step was put my instance into internal network of docker:
$ docker run -it --name jitsi -p 80:80 -p 443:443 filhocf/jitsi-meet:20161016

With this step, only ports 80 and 443 are exposed. I tried again, without success. After, I followed this instructions (https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md#running-behind-nat), changing the file /etc/jitsi/videobridge/sip-communicator.properties with this lines:

org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<Docker.IP.Address>
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<Public.IP.Address>
After restarted all services, I tried again without success.

So, my ask is how can I make the UDP pkgs pass through Nginx? Or if is possible to use only TCP instead UDP pkgs? If yes, where can I find more info? Do you have some other suggestion for this question?

Since now, thanks in advance.

Regards,
Claudio Ferreira

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


#6

Hi

I found more some questions, now specifically about NAT.

I'm using my docker image and it runs fine in a host with real IP. The
problem (apparently) is the STUN communication.

Using a Wireshark to snif my communication, between the browser and the
server, returned a strange data. My public IP is 200.x.x.x, but my browser
try a STUN comm to IP 192.x.x.x (local IP of my server behind the NAT,
where the NAT only translate 200.x.x.x -> 192.x.x.x and back) and to
172.x.x.x, that is a internal IP in a docker net, but the true is that my
browser need to connect to 200.x.x.x.

For my browser ask STUN to 172.x or 192.x is because STUN server are saying
to connect in this IP. So, my ask change to: Who do the paper of STUN in
the 'easy mode' ? Prosody? Jicofo? Other? And I understand that we need to
set the STUN server to say it external IP. How can I do it?

Regards,
Claudio Ferreira

···

2016-10-06 8:01 GMT-03:00 Trnkoczy, Jernej <Jernej.Trnkoczy@fgg.uni-lj.si>:

Hi,

I do not completely understand what do you want. If UDP traffic is not
allowed (e.g. blocked by firewall) - then I believe that videobridge has a
small web server (jetty) included – and it is possible to stream
video/audio using TCP on port 443. However I never tested this and I do not
know if it needs special configuration. Maybe somebody else will be able to
help…

I am running jitsi-meet in Docker container using Docker bridge
networking. I put the following in the sip-communicator config file of
videobridge:

org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<Here I put the IP of
docker container – so you need to find out which local IP was assigned to
your container – eg. 172.17.0.2>

org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<Public.IP.Address –
the IP of the docker host>

And this works for me…

But I did not make the Docker image following “easy install” – I’ve tried
but had problems with reconfiguration. So I made the docker image using
“manual install” process – which was a bit painful and took me a very long
time to figure out (the official documentation is missing some little
tricks).

Jernej

*From:* dev [mailto:dev-bounces@jitsi.org] *On Behalf Of *Claudio Ferreia
Filho
*Sent:* 6. oktober 2016 12:33
*To:* Jitsi Developers
*Subject:* Re: [jitsi-dev] Questions about a docker image (and/or
proxy/nat)

Hi

Thank you, Boris and Jersei, by your replies, but isn't a acceptable
situation. Imagine a second scenary:

        +--+ +--+

user -> |RP| -> |JS|

        +--+ +--+

        DMZ Internal net

Where RP = Reverse Proxy, like a Nginx, and JS is the jitsi server,
installed in the host. Other similar situation are some PaaS providers,
where the machine have a external (and real) IP that is routed to internal
IP by NAT. In my PoV is the same situation too, and both without success.
Docker is practically the same thing.

In other words, you can connect with external IP, open the main page, look
your self, look other people connecting into room, but haven't interchange
of audio and video between participants in the room. I understood that this
change is based in UDP communication. I already configured the
sip.communicator file for videobridge, and nothing.

Any other suggestion?

Regards,

Claudio Ferreira

2016-10-06 5:30 GMT-03:00 Trnkoczy, Jernej <Jernej.Trnkoczy@fgg.uni-lj.si
>:

Hi,

Exposing 10000/udp worked for me. The RTP packets do not go through nginx
– as far as I know they go from browser directly to videobridge. So the
docker container that starts videobridge needs to have port 10000/udp
published (videobridge by default works in a “single port setup” – where
all the media streams are passing through a single 10000/udp port.)

Jernej

*From:* dev [mailto:dev-bounces@jitsi.org] *On Behalf Of *Claudio Ferreia
Filho
*Sent:* 6. oktober 2016 1:20
*To:* Jitsi Developers
*Subject:* [jitsi-dev] Questions about a docker image (and/or proxy/nat)

Hi

I continue fighting to build my docker image. It is very simple, getting
the debian image, adding the jitsi repo, adding the pkg and running a
dkpg-reconfigure to set the defaults parameters.

To test, I installed in the 'debian way', using a new debian box, and
following the steps above. Runs fine. With this steps, I know that my env
haven't limitations or problems.

The next step was install my image. So, I used the follow command:

$ docker run -it --name jitsi --network host filhocf/jitsi-meet:20161016

With it, docker pulls my image and runs it, calling a initial script for
conf proposes. The --network option says to docker expose all interfaces of
container to host. Is like the first scenary, with jitsi installed in the
host. To here, all ok.

The third step was put my instance into internal network of docker:

$ docker run -it --name jitsi -p 80:80 -p 443:443
filhocf/jitsi-meet:20161016

With this step, only ports 80 and 443 are exposed. I tried again, without
success. After, I followed this instructions (https://github.com/jitsi/
jitsi-meet/blob/master/doc/manual-install.md#running-behind-nat),
changing the file /etc/jitsi/videobridge/sip-communicator.properties with
this lines:

org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false

org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<Docker.IP.Address>

org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<Public.IP.Address>

After restarted all services, I tried again without success.

So, my ask is how can I make the UDP pkgs pass through Nginx? Or if is
possible to use only TCP instead UDP pkgs? If yes, where can I find more
info? Do you have some other suggestion for this question?

Since now, thanks in advance.

Regards,

Claudio Ferreira

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

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


#7

Hi,
Sorry I cannot understand the question. Can you try my docker image (all four components are running in one Docker container) and see if it has the same problems:

docker run -it -p 443:443 -p 444:444 -p 10000:10000/udp jernejtrnkoczy/jitsimeet004

Jernej

···

From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Claudio Ferreia Filho
Sent: 6. oktober 2016 15:58
To: Jitsi Developers
Subject: Re: [jitsi-dev] Questions about a docker image (and/or proxy/nat)

Hi

I found more some questions, now specifically about NAT.

I'm using my docker image and it runs fine in a host with real IP. The problem (apparently) is the STUN communication.

Using a Wireshark to snif my communication, between the browser and the server, returned a strange data. My public IP is 200.x.x.x, but my browser try a STUN comm to IP 192.x.x.x (local IP of my server behind the NAT, where the NAT only translate 200.x.x.x -> 192.x.x.x and back) and to 172.x.x.x, that is a internal IP in a docker net, but the true is that my browser need to connect to 200.x.x.x.

For my browser ask STUN to 172.x or 192.x is because STUN server are saying to connect in this IP. So, my ask change to: Who do the paper of STUN in the 'easy mode' ? Prosody? Jicofo? Other? And I understand that we need to set the STUN server to say it external IP. How can I do it?

Regards,
Claudio Ferreira

2016-10-06 8:01 GMT-03:00 Trnkoczy, Jernej <Jernej.Trnkoczy@fgg.uni-lj.si<mailto:Jernej.Trnkoczy@fgg.uni-lj.si>>:
Hi,
I do not completely understand what do you want. If UDP traffic is not allowed (e.g. blocked by firewall) - then I believe that videobridge has a small web server (jetty) included – and it is possible to stream video/audio using TCP on port 443. However I never tested this and I do not know if it needs special configuration. Maybe somebody else will be able to help…

I am running jitsi-meet in Docker container using Docker bridge networking. I put the following in the sip-communicator config file of videobridge:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<Here I put the IP of docker container – so you need to find out which local IP was assigned to your container – eg. 172.17.0.2>
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<Public.IP.Address – the IP of the docker host>
And this works for me…

But I did not make the Docker image following “easy install” – I’ve tried but had problems with reconfiguration. So I made the docker image using “manual install” process – which was a bit painful and took me a very long time to figure out (the official documentation is missing some little tricks).

Jernej

From: dev [mailto:dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org>] On Behalf Of Claudio Ferreia Filho
Sent: 6. oktober 2016 12:33
To: Jitsi Developers
Subject: Re: [jitsi-dev] Questions about a docker image (and/or proxy/nat)

Hi
Thank you, Boris and Jersei, by your replies, but isn't a acceptable situation. Imagine a second scenary:

        +--+ +--+
user -> |RP| -> |JS|
        +--+ +--+
        DMZ Internal net

Where RP = Reverse Proxy, like a Nginx, and JS is the jitsi server, installed in the host. Other similar situation are some PaaS providers, where the machine have a external (and real) IP that is routed to internal IP by NAT. In my PoV is the same situation too, and both without success. Docker is practically the same thing.
In other words, you can connect with external IP, open the main page, look your self, look other people connecting into room, but haven't interchange of audio and video between participants in the room. I understood that this change is based in UDP communication. I already configured the sip.communicator file for videobridge, and nothing.
Any other suggestion?

Regards,
Claudio Ferreira

2016-10-06 5:30 GMT-03:00 Trnkoczy, Jernej <Jernej.Trnkoczy@fgg.uni-lj.si<mailto:Jernej.Trnkoczy@fgg.uni-lj.si>>:
Hi,
Exposing 10000/udp worked for me. The RTP packets do not go through nginx – as far as I know they go from browser directly to videobridge. So the docker container that starts videobridge needs to have port 10000/udp published (videobridge by default works in a “single port setup” – where all the media streams are passing through a single 10000/udp port.)
Jernej

From: dev [mailto:dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org>] On Behalf Of Claudio Ferreia Filho
Sent: 6. oktober 2016 1:20
To: Jitsi Developers
Subject: [jitsi-dev] Questions about a docker image (and/or proxy/nat)

Hi

I continue fighting to build my docker image. It is very simple, getting the debian image, adding the jitsi repo, adding the pkg and running a dkpg-reconfigure to set the defaults parameters.

To test, I installed in the 'debian way', using a new debian box, and following the steps above. Runs fine. With this steps, I know that my env haven't limitations or problems.

The next step was install my image. So, I used the follow command:
$ docker run -it --name jitsi --network host filhocf/jitsi-meet:20161016

With it, docker pulls my image and runs it, calling a initial script for conf proposes. The --network option says to docker expose all interfaces of container to host. Is like the first scenary, with jitsi installed in the host. To here, all ok.

The third step was put my instance into internal network of docker:
$ docker run -it --name jitsi -p 80:80 -p 443:443 filhocf/jitsi-meet:20161016

With this step, only ports 80 and 443 are exposed. I tried again, without success. After, I followed this instructions (https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md#running-behind-nat), changing the file /etc/jitsi/videobridge/sip-communicator.properties with this lines:

org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<Docker.IP.Address>
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<Public.IP.Address>
After restarted all services, I tried again without success.

So, my ask is how can I make the UDP pkgs pass through Nginx? Or if is possible to use only TCP instead UDP pkgs? If yes, where can I find more info? Do you have some other suggestion for this question?

Since now, thanks in advance.

Regards,
Claudio Ferreira

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

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


#8

When the docker container starts you should be able to point your browser to https://IP.OF.YOUR.DOCKERHOST:444
Jernej

···

From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Claudio Ferreia Filho
Sent: 6. oktober 2016 15:58
To: Jitsi Developers
Subject: Re: [jitsi-dev] Questions about a docker image (and/or proxy/nat)

Hi

I found more some questions, now specifically about NAT.

I'm using my docker image and it runs fine in a host with real IP. The problem (apparently) is the STUN communication.

Using a Wireshark to snif my communication, between the browser and the server, returned a strange data. My public IP is 200.x.x.x, but my browser try a STUN comm to IP 192.x.x.x (local IP of my server behind the NAT, where the NAT only translate 200.x.x.x -> 192.x.x.x and back) and to 172.x.x.x, that is a internal IP in a docker net, but the true is that my browser need to connect to 200.x.x.x.

For my browser ask STUN to 172.x or 192.x is because STUN server are saying to connect in this IP. So, my ask change to: Who do the paper of STUN in the 'easy mode' ? Prosody? Jicofo? Other? And I understand that we need to set the STUN server to say it external IP. How can I do it?

Regards,
Claudio Ferreira

2016-10-06 8:01 GMT-03:00 Trnkoczy, Jernej <Jernej.Trnkoczy@fgg.uni-lj.si<mailto:Jernej.Trnkoczy@fgg.uni-lj.si>>:
Hi,
I do not completely understand what do you want. If UDP traffic is not allowed (e.g. blocked by firewall) - then I believe that videobridge has a small web server (jetty) included – and it is possible to stream video/audio using TCP on port 443. However I never tested this and I do not know if it needs special configuration. Maybe somebody else will be able to help…

I am running jitsi-meet in Docker container using Docker bridge networking. I put the following in the sip-communicator config file of videobridge:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<Here I put the IP of docker container – so you need to find out which local IP was assigned to your container – eg. 172.17.0.2>
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<Public.IP.Address – the IP of the docker host>
And this works for me…

But I did not make the Docker image following “easy install” – I’ve tried but had problems with reconfiguration. So I made the docker image using “manual install” process – which was a bit painful and took me a very long time to figure out (the official documentation is missing some little tricks).

Jernej

From: dev [mailto:dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org>] On Behalf Of Claudio Ferreia Filho
Sent: 6. oktober 2016 12:33
To: Jitsi Developers
Subject: Re: [jitsi-dev] Questions about a docker image (and/or proxy/nat)

Hi
Thank you, Boris and Jersei, by your replies, but isn't a acceptable situation. Imagine a second scenary:

        +--+ +--+
user -> |RP| -> |JS|
        +--+ +--+
        DMZ Internal net

Where RP = Reverse Proxy, like a Nginx, and JS is the jitsi server, installed in the host. Other similar situation are some PaaS providers, where the machine have a external (and real) IP that is routed to internal IP by NAT. In my PoV is the same situation too, and both without success. Docker is practically the same thing.
In other words, you can connect with external IP, open the main page, look your self, look other people connecting into room, but haven't interchange of audio and video between participants in the room. I understood that this change is based in UDP communication. I already configured the sip.communicator file for videobridge, and nothing.
Any other suggestion?

Regards,
Claudio Ferreira

2016-10-06 5:30 GMT-03:00 Trnkoczy, Jernej <Jernej.Trnkoczy@fgg.uni-lj.si<mailto:Jernej.Trnkoczy@fgg.uni-lj.si>>:
Hi,
Exposing 10000/udp worked for me. The RTP packets do not go through nginx – as far as I know they go from browser directly to videobridge. So the docker container that starts videobridge needs to have port 10000/udp published (videobridge by default works in a “single port setup” – where all the media streams are passing through a single 10000/udp port.)
Jernej

From: dev [mailto:dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org>] On Behalf Of Claudio Ferreia Filho
Sent: 6. oktober 2016 1:20
To: Jitsi Developers
Subject: [jitsi-dev] Questions about a docker image (and/or proxy/nat)

Hi

I continue fighting to build my docker image. It is very simple, getting the debian image, adding the jitsi repo, adding the pkg and running a dkpg-reconfigure to set the defaults parameters.

To test, I installed in the 'debian way', using a new debian box, and following the steps above. Runs fine. With this steps, I know that my env haven't limitations or problems.

The next step was install my image. So, I used the follow command:
$ docker run -it --name jitsi --network host filhocf/jitsi-meet:20161016

With it, docker pulls my image and runs it, calling a initial script for conf proposes. The --network option says to docker expose all interfaces of container to host. Is like the first scenary, with jitsi installed in the host. To here, all ok.

The third step was put my instance into internal network of docker:
$ docker run -it --name jitsi -p 80:80 -p 443:443 filhocf/jitsi-meet:20161016

With this step, only ports 80 and 443 are exposed. I tried again, without success. After, I followed this instructions (https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md#running-behind-nat), changing the file /etc/jitsi/videobridge/sip-communicator.properties with this lines:

org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=<Docker.IP.Address>
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=<Public.IP.Address>
After restarted all services, I tried again without success.

So, my ask is how can I make the UDP pkgs pass through Nginx? Or if is possible to use only TCP instead UDP pkgs? If yes, where can I find more info? Do you have some other suggestion for this question?

Since now, thanks in advance.

Regards,
Claudio Ferreira

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

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


#9

The documentation is a little buried:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#orgjitsivideobridgenat_harvester_local_address

Boris

···

On 06/10/16 16:57, Claudio Ferreia Filho wrote:

Hi

I found more some questions, now specifically about NAT.

I'm using my docker image and it runs fine in a host with real IP. The
problem (apparently) is the STUN communication.

Using a Wireshark to snif my communication, between the browser and the
server, returned a strange data. My public IP is 200.x.x.x, but my
browser try a STUN comm to IP 192.x.x.x (local IP of my server behind
the NAT, where the NAT only translate 200.x.x.x -> 192.x.x.x and back)
and to 172.x.x.x, that is a internal IP in a docker net, but the true is
that my browser need to connect to 200.x.x.x.

For my browser ask STUN to 172.x or 192.x is because STUN server are
saying to connect in this IP. So, my ask change to: Who do the paper of
STUN in the 'easy mode' ? Prosody? Jicofo? Other? And I understand that
we need to set the STUN server to say it external IP. How can I do it?


#10

I already tried this without success, as described in first email. However,
if I understand your intent, videobridge is who do the paper of STUN. Is it?

How can I verify if JVB is honoring this configuration?

Regards,
Claudio Ferreira

···

2016-10-06 11:09 GMT-03:00 Boris Grozev <boris@jitsi.org>:

On 06/10/16 16:57, Claudio Ferreia Filho wrote:

Hi

I found more some questions, now specifically about NAT.

I'm using my docker image and it runs fine in a host with real IP. The
problem (apparently) is the STUN communication.

Using a Wireshark to snif my communication, between the browser and the
server, returned a strange data. My public IP is 200.x.x.x, but my
browser try a STUN comm to IP 192.x.x.x (local IP of my server behind
the NAT, where the NAT only translate 200.x.x.x -> 192.x.x.x and back)
and to 172.x.x.x, that is a internal IP in a docker net, but the true is
that my browser need to connect to 200.x.x.x.

For my browser ask STUN to 172.x or 192.x is because STUN server are
saying to connect in this IP. So, my ask change to: Who do the paper of
STUN in the 'easy mode' ? Prosody? Jicofo? Other? And I understand that
we need to set the STUN server to say it external IP. How can I do it?

The documentation is a little buried:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/
tcp.md#orgjitsivideobridgenat_harvester_local_address


#11

Jernei, you can use the option '--network host' , where make your container
expose all ports to host in the fly. IMHO, is better that map each port.

Anyway, thank you by your suggestion and repo. I will take a look in your
dockfile.

Regards,
Claudio Ferreira

···

2016-10-06 11:08 GMT-03:00 Trnkoczy, Jernej <Jernej.Trnkoczy@fgg.uni-lj.si>:

docker run -it -p 443:443 -p 444:444 -p 10000:10000/udp
jernejtrnkoczy/jitsimeet004


#12

Look at the remote candidates in chrome://webrtc-internals. They should include the public IP address of the server.

Regards,
Boris

···

On 06/10/16 17:39, Claudio Ferreia Filho wrote:

2016-10-06 11:09 GMT-03:00 Boris Grozev <boris@jitsi.org
<mailto:boris@jitsi.org>>:

    On 06/10/16 16:57, Claudio Ferreia Filho wrote:

        Hi

        I found more some questions, now specifically about NAT.

        I'm using my docker image and it runs fine in a host with real
        IP. The
        problem (apparently) is the STUN communication.

        Using a Wireshark to snif my communication, between the browser
        and the
        server, returned a strange data. My public IP is 200.x.x.x, but my
        browser try a STUN comm to IP 192.x.x.x (local IP of my server
        behind
        the NAT, where the NAT only translate 200.x.x.x -> 192.x.x.x and
        back)
        and to 172.x.x.x, that is a internal IP in a docker net, but the
        true is
        that my browser need to connect to 200.x.x.x.

        For my browser ask STUN to 172.x or 192.x is because STUN server are
        saying to connect in this IP. So, my ask change to: Who do the
        paper of
        STUN in the 'easy mode' ? Prosody? Jicofo? Other? And I
        understand that
        we need to set the STUN server to say it external IP. How can I
        do it?

    The documentation is a little buried:
    https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#orgjitsivideobridgenat_harvester_local_address
    <https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#orgjitsivideobridgenat_harvester_local_address>

I already tried this without success, as described in first email.
However, if I understand your intent, videobridge is who do the paper of
STUN. Is it?

How can I verify if JVB is honoring this configuration?


#13

Good morning !

I'm trying to find how to send an image just from clipboard, without download it, like in trillian.

It's possible in Jitsi ?

Regards,

···

--
Rocco Sette
netika Technicien Système & Réseau
3 rue de Sarrelouis - 67000 Strasbourg
rocco.sette@netika.net <mailto:rocco.sette@netika.net>
Hotline KaliLab : +33 (0)3 68 46 16 50
Accueil : +33 (0)3 68 46 16 28
Fax : +33 (0)3 88 52 82 02

Twitter <https://twitter.com/netika_france> LinkedIN <http://www.linkedin.com/company/netika-sarl> Viadeo <http://www.viadeo.com/v/company/netika>

La préservation de l'environnement est un exercice quotidien : n'imprimez ce mail que si nécessaire.


#14

So jvb inside docker is seeing only 172.x.x. address, is this correct?

If this is the case you should put the following config:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=172.x.x.x
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=200.x.x.x

What you should see in the sdp are only 172.x and 200.x addresses.
And make sure whatever comes to the media ports 10000-20000 on 200.x.x
got correctly routed and reach jvb which is inside docker.

Regards
damencho

···

On Thu, Oct 6, 2016 at 12:41 PM, Claudio Ferreia Filho <filhocf@gmail.com> wrote:

2016-10-06 11:51 GMT-03:00 Boris Grozev <boris@jitsi.org>:

On 06/10/16 17:39, Claudio Ferreia Filho wrote:

2016-10-06 11:09 GMT-03:00 Boris Grozev <boris@jitsi.org
<mailto:boris@jitsi.org>>:

    On 06/10/16 16:57, Claudio Ferreia Filho wrote:

        Hi

        I found more some questions, now specifically about NAT.

        I'm using my docker image and it runs fine in a host with real
        IP. The
        problem (apparently) is the STUN communication.

        Using a Wireshark to snif my communication, between the browser
        and the
        server, returned a strange data. My public IP is 200.x.x.x, but
my
        browser try a STUN comm to IP 192.x.x.x (local IP of my server
        behind
        the NAT, where the NAT only translate 200.x.x.x -> 192.x.x.x and
        back)
        and to 172.x.x.x, that is a internal IP in a docker net, but the
        true is
        that my browser need to connect to 200.x.x.x.

        For my browser ask STUN to 172.x or 192.x is because STUN server
are
        saying to connect in this IP. So, my ask change to: Who do the
        paper of
        STUN in the 'easy mode' ? Prosody? Jicofo? Other? And I
        understand that
        we need to set the STUN server to say it external IP. How can I
        do it?

    The documentation is a little buried:

https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#orgjitsivideobridgenat_harvester_local_address

<https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#orgjitsivideobridgenat_harvester_local_address>

I already tried this without success, as described in first email.
However, if I understand your intent, videobridge is who do the paper of
STUN. Is it?

How can I verify if JVB is honoring this configuration?

Look at the remote candidates in chrome://webrtc-internals. They should
include the public IP address of the server.

Regards,

Boris

Boris, this is my setRemoteDescription:

type: offer, sdp: v=0
o=- 1923518516 2 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE audio video data
m=audio 1 RTP/SAVPF 111 103 104 126
c=IN IP4 0.0.0.0
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:126 telephone-event/8000
a=fmtp:111 minptime=10; useinbandfec=1
a=rtcp:1 IN IP4 0.0.0.0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=setup:actpass
a=mid:audio
a=sendrecv
a=ice-ufrag:45orf1audfte6a
a=ice-pwd:66lo2ge7ug91kl0aaitkd5jflr
a=fingerprint:sha-1
83:42:78:C9:3E:2F:75:CF:FF:D9:80:EF:8A:12:DA:52:4E:9A:D2:F9
a=candidate:1 1 ssltcp 2130706431 172.17.0.1 4443 typ host generation 0
a=candidate:2 1 ssltcp 2130706431 192.168.4.41 4443 typ host generation 0
a=candidate:3 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
a=candidate:4 1 udp 2113932031 192.168.4.41 10000 typ host generation 0
a=ssrc:3928738533 cname:mixed
a=ssrc:3928738533 label:mixedlabelaudio0
a=ssrc:3928738533 msid:mixedmslabel mixedlabelaudio0
a=ssrc:3928738533 mslabel:mixedmslabel
a=rtcp-mux
m=video 1 RTP/SAVPF 100
c=IN IP4 0.0.0.0
a=rtpmap:100 VP8/90000
a=fmtp:100 x-google-start-bitrate=800
a=rtcp:1 IN IP4 0.0.0.0
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=setup:actpass
a=mid:video
a=sendrecv
a=ice-ufrag:45orf1audfte6a
a=ice-pwd:66lo2ge7ug91kl0aaitkd5jflr
a=fingerprint:sha-1
83:42:78:C9:3E:2F:75:CF:FF:D9:80:EF:8A:12:DA:52:4E:9A:D2:F9
a=candidate:1 1 ssltcp 2130706431 172.17.0.1 4443 typ host generation 0
a=candidate:2 1 ssltcp 2130706431 192.168.4.41 4443 typ host generation 0
a=candidate:3 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
a=candidate:4 1 udp 2113932031 192.168.4.41 10000 typ host generation 0
a=ssrc:277210242 cname:mixed
a=ssrc:277210242 label:mixedlabelvideo0
a=ssrc:277210242 msid:mixedmslabel mixedlabelvideo0
a=ssrc:277210242 mslabel:mixedmslabel
a=rtcp-mux
m=application 1 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=setup:actpass
a=mid:data
a=sendrecv
a=ice-ufrag:45orf1audfte6a
a=ice-pwd:66lo2ge7ug91kl0aaitkd5jflr
a=fingerprint:sha-1
83:42:78:C9:3E:2F:75:CF:FF:D9:80:EF:8A:12:DA:52:4E:9A:D2:F9
a=candidate:1 1 ssltcp 2130706431 172.17.0.1 4443 typ host generation 0
a=candidate:2 1 ssltcp 2130706431 192.168.4.41 4443 typ host generation 0
a=candidate:3 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
a=candidate:4 1 udp 2113932031 192.168.4.41 10000 typ host generation 0
a=rtcp-mux
a=sctpmap:5000 webrtc-datachannel 1024

As you can see, it gets the internal IP (local 192.x.x.x and docker
172.x.x.x), even I configured sip-communicator as suggested.

# cat /etc/jitsi/videobridge/sip-communicator.properties
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=192.168.4.41
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=200.x.x.x

As you can see, the LOCAL_ADDRESS is the same ssltcp and udp IPs at
chrome://webrtc-internals.

Some other suggest?

Regards,
Claudio Ferreira

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


#15

Boris, this is my setRemoteDescription:

type: offer, sdp: v=0
o=- 1923518516 2 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE audio video data
m=audio 1 RTP/SAVPF 111 103 104 126
c=IN IP4 0.0.0.0
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:126 telephone-event/8000
a=fmtp:111 minptime=10; useinbandfec=1
a=rtcp:1 IN IP4 0.0.0.0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=setup:actpass
a=mid:audio
a=sendrecv
a=ice-ufrag:45orf1audfte6a
a=ice-pwd:66lo2ge7ug91kl0aaitkd5jflr
a=fingerprint:sha-1
83:42:78:C9:3E:2F:75:CF:FF:D9:80:EF:8A:12:DA:52:4E:9A:D2:F9
a=candidate:1 1 ssltcp 2130706431 172.17.0.1 4443 typ host generation 0
a=candidate:2 1 ssltcp 2130706431 192.168.4.41 4443 typ host generation 0
a=candidate:3 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
a=candidate:4 1 udp 2113932031 192.168.4.41 10000 typ host generation 0
a=ssrc:3928738533 cname:mixed
a=ssrc:3928738533 label:mixedlabelaudio0
a=ssrc:3928738533 msid:mixedmslabel mixedlabelaudio0
a=ssrc:3928738533 mslabel:mixedmslabel
a=rtcp-mux
m=video 1 RTP/SAVPF 100
c=IN IP4 0.0.0.0
a=rtpmap:100 VP8/90000
a=fmtp:100 x-google-start-bitrate=800
a=rtcp:1 IN IP4 0.0.0.0
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=setup:actpass
a=mid:video
a=sendrecv
a=ice-ufrag:45orf1audfte6a
a=ice-pwd:66lo2ge7ug91kl0aaitkd5jflr
a=fingerprint:sha-1
83:42:78:C9:3E:2F:75:CF:FF:D9:80:EF:8A:12:DA:52:4E:9A:D2:F9
a=candidate:1 1 ssltcp 2130706431 172.17.0.1 4443 typ host generation 0
a=candidate:2 1 ssltcp 2130706431 192.168.4.41 4443 typ host generation 0
a=candidate:3 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
a=candidate:4 1 udp 2113932031 192.168.4.41 10000 typ host generation 0
a=ssrc:277210242 cname:mixed
a=ssrc:277210242 label:mixedlabelvideo0
a=ssrc:277210242 msid:mixedmslabel mixedlabelvideo0
a=ssrc:277210242 mslabel:mixedmslabel
a=rtcp-mux
m=application 1 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=setup:actpass
a=mid:data
a=sendrecv
a=ice-ufrag:45orf1audfte6a
a=ice-pwd:66lo2ge7ug91kl0aaitkd5jflr
a=fingerprint:sha-1
83:42:78:C9:3E:2F:75:CF:FF:D9:80:EF:8A:12:DA:52:4E:9A:D2:F9
a=candidate:1 1 ssltcp 2130706431 172.17.0.1 4443 typ host generation 0
a=candidate:2 1 ssltcp 2130706431 192.168.4.41 4443 typ host generation 0
a=candidate:3 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
a=candidate:4 1 udp 2113932031 192.168.4.41 10000 typ host generation 0
a=rtcp-mux
a=sctpmap:5000 webrtc-datachannel 1024

As you can see, it gets the internal IP (local 192.x.x.x and docker
172.x.x.x), even I configured sip-communicator as suggested.

# cat /etc/jitsi/videobridge/sip-communicator.properties
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=192.168.4.41
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=200.x.x.x

As you can see, the LOCAL_ADDRESS is the same ssltcp and udp IPs at
chrome://webrtc-internals.

Some other suggest?

Regards,
Claudio Ferreira

···

2016-10-06 11:51 GMT-03:00 Boris Grozev <boris@jitsi.org>:

On 06/10/16 17:39, Claudio Ferreia Filho wrote:

2016-10-06 11:09 GMT-03:00 Boris Grozev <boris@jitsi.org
<mailto:boris@jitsi.org>>:

    On 06/10/16 16:57, Claudio Ferreia Filho wrote:

        Hi

        I found more some questions, now specifically about NAT.

        I'm using my docker image and it runs fine in a host with real
        IP. The
        problem (apparently) is the STUN communication.

        Using a Wireshark to snif my communication, between the browser
        and the
        server, returned a strange data. My public IP is 200.x.x.x, but my
        browser try a STUN comm to IP 192.x.x.x (local IP of my server
        behind
        the NAT, where the NAT only translate 200.x.x.x -> 192.x.x.x and
        back)
        and to 172.x.x.x, that is a internal IP in a docker net, but the
        true is
        that my browser need to connect to 200.x.x.x.

        For my browser ask STUN to 172.x or 192.x is because STUN server
are
        saying to connect in this IP. So, my ask change to: Who do the
        paper of
        STUN in the 'easy mode' ? Prosody? Jicofo? Other? And I
        understand that
        we need to set the STUN server to say it external IP. How can I
        do it?

    The documentation is a little buried:
    https://github.com/jitsi/jitsi-videobridge/blob/master/doc/
tcp.md#orgjitsivideobridgenat_harvester_local_address
    <https://github.com/jitsi/jitsi-videobridge/blob/master/doc/
tcp.md#orgjitsivideobridgenat_harvester_local_address>

I already tried this without success, as described in first email.
However, if I understand your intent, videobridge is who do the paper of
STUN. Is it?

How can I verify if JVB is honoring this configuration?

Look at the remote candidates in chrome://webrtc-internals. They should
include the public IP address of the server.

Regards,

Boris


#16

Hi Claudio,
I know, but this could lead to conflicting ports with other services (containers) running on the same machine. There are many ports used by jitsi-meet that do not need to be published (e.g. 5347, 5280, 5222, 5269). Besides that I think that the right approach is to have every component (vidoebridge, jicofo, Prosody, nginx) in a separate container. Using the Docker bridge I am able to experiment and find out which ports must be published to the outside and which not (I am a jitsi meet newbie and there is lack of documentation – so it is hard to find out how exactly the components communicate)
Anyway in the end I intend to run the container in the Kubernetes cluster, which again has different networking setup – so first I really need to figure out exactly how the components are communicating.
Cheers,
Jernej

···

From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Claudio Ferreia Filho
Sent: 6. oktober 2016 19:23
To: Jitsi Developers
Subject: Re: [jitsi-dev] Questions about a docker image (and/or proxy/nat)

2016-10-06 11:08 GMT-03:00 Trnkoczy, Jernej <Jernej.Trnkoczy@fgg.uni-lj.si<mailto:Jernej.Trnkoczy@fgg.uni-lj.si>>:
docker run -it -p 443:443 -p 444:444 -p 10000:10000/udp jernejtrnkoczy/jitsimeet004

Jernei, you can use the option '--network host' , where make your container expose all ports to host in the fly. IMHO, is better that map each port.

Anyway, thank you by your suggestion and repo. I will take a look in your dockfile.

Regards,
Claudio Ferreira


#17

Hi

After a intense discussion, Damian and Boris helped me in find the error.

The configuration in the sip-communicator.properties, using the nightly
build from one week ago, in /etc/jitsi/videobridge wasn't read by JVB. It
is reading from /usr/share/jitsi-videobridge/.sip-communicator directory.

So, I did a symbolic link from this directory to /etc, or in a hand-ons:

# cd /usr/share/jitsi-videobridge/.sip-communicator
# ln -s /etc/jitsi/videobridge/sip-communicator.properties
sip-communicator.properties

After this, was only restart all services (jicofo, jvb, nginx and prosody),
that the docker entrypoint already do.

As I used a deb pkg, I understand that is a bug, so I opened a issue in
Github (#989).

With this workaround, my box is working fine.

Thanks to all who helped in this solution.

Best regards,
Claudio Ferreira

···

2016-10-06 16:40 GMT-03:00 Damian Minkov <damencho@jitsi.org>:

So jvb inside docker is seeing only 172.x.x. address, is this correct?

If this is the case you should put the following config:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=172.x.x.x
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=200.x.x.x

What you should see in the sdp are only 172.x and 200.x addresses.
And make sure whatever comes to the media ports 10000-20000 on 200.x.x
got correctly routed and reach jvb which is inside docker.

Regards
damencho

On Thu, Oct 6, 2016 at 12:41 PM, Claudio Ferreia Filho > <filhocf@gmail.com> wrote:
> 2016-10-06 11:51 GMT-03:00 Boris Grozev <boris@jitsi.org>:
>>
>> On 06/10/16 17:39, Claudio Ferreia Filho wrote:
>>>
>>>
>>> 2016-10-06 11:09 GMT-03:00 Boris Grozev <boris@jitsi.org
>>> <mailto:boris@jitsi.org>>:
>>>
>>>
>>> On 06/10/16 16:57, Claudio Ferreia Filho wrote:
>>>
>>> Hi
>>>
>>> I found more some questions, now specifically about NAT.
>>>
>>> I'm using my docker image and it runs fine in a host with real
>>> IP. The
>>> problem (apparently) is the STUN communication.
>>>
>>> Using a Wireshark to snif my communication, between the browser
>>> and the
>>> server, returned a strange data. My public IP is 200.x.x.x, but
>>> my
>>> browser try a STUN comm to IP 192.x.x.x (local IP of my server
>>> behind
>>> the NAT, where the NAT only translate 200.x.x.x -> 192.x.x.x
and
>>> back)
>>> and to 172.x.x.x, that is a internal IP in a docker net, but
the
>>> true is
>>> that my browser need to connect to 200.x.x.x.
>>>
>>> For my browser ask STUN to 172.x or 192.x is because STUN
server
>>> are
>>> saying to connect in this IP. So, my ask change to: Who do the
>>> paper of
>>> STUN in the 'easy mode' ? Prosody? Jicofo? Other? And I
>>> understand that
>>> we need to set the STUN server to say it external IP. How can I
>>> do it?
>>>
>>>
>>> The documentation is a little buried:
>>>
>>> https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#
orgjitsivideobridgenat_harvester_local_address
>>>
>>> <https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#
orgjitsivideobridgenat_harvester_local_address>
>>>
>>>
>>> I already tried this without success, as described in first email.
>>> However, if I understand your intent, videobridge is who do the paper
of
>>> STUN. Is it?
>>>
>>> How can I verify if JVB is honoring this configuration?
>>
>>
>> Look at the remote candidates in chrome://webrtc-internals. They should
>> include the public IP address of the server.
>>
>> Regards,
>>
>> Boris
>
>
> Boris, this is my setRemoteDescription:
>
> type: offer, sdp: v=0
> o=- 1923518516 2 IN IP4 0.0.0.0
> s=-
> t=0 0
> a=group:BUNDLE audio video data
> m=audio 1 RTP/SAVPF 111 103 104 126
> c=IN IP4 0.0.0.0
> a=rtpmap:111 opus/48000/2
> a=rtpmap:103 ISAC/16000
> a=rtpmap:104 ISAC/32000
> a=rtpmap:126 telephone-event/8000
> a=fmtp:111 minptime=10; useinbandfec=1
> a=rtcp:1 IN IP4 0.0.0.0
> a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
> a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
> a=setup:actpass
> a=mid:audio
> a=sendrecv
> a=ice-ufrag:45orf1audfte6a
> a=ice-pwd:66lo2ge7ug91kl0aaitkd5jflr
> a=fingerprint:sha-1
> 83:42:78:C9:3E:2F:75:CF:FF:D9:80:EF:8A:12:DA:52:4E:9A:D2:F9
> a=candidate:1 1 ssltcp 2130706431 172.17.0.1 4443 typ host generation 0
> a=candidate:2 1 ssltcp 2130706431 192.168.4.41 4443 typ host generation 0
> a=candidate:3 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
> a=candidate:4 1 udp 2113932031 192.168.4.41 10000 typ host generation 0
> a=ssrc:3928738533 cname:mixed
> a=ssrc:3928738533 label:mixedlabelaudio0
> a=ssrc:3928738533 msid:mixedmslabel mixedlabelaudio0
> a=ssrc:3928738533 mslabel:mixedmslabel
> a=rtcp-mux
> m=video 1 RTP/SAVPF 100
> c=IN IP4 0.0.0.0
> a=rtpmap:100 VP8/90000
> a=fmtp:100 x-google-start-bitrate=800
> a=rtcp:1 IN IP4 0.0.0.0
> a=rtcp-fb:100 ccm fir
> a=rtcp-fb:100 nack
> a=rtcp-fb:100 nack pli
> a=rtcp-fb:100 goog-remb
> a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
> a=setup:actpass
> a=mid:video
> a=sendrecv
> a=ice-ufrag:45orf1audfte6a
> a=ice-pwd:66lo2ge7ug91kl0aaitkd5jflr
> a=fingerprint:sha-1
> 83:42:78:C9:3E:2F:75:CF:FF:D9:80:EF:8A:12:DA:52:4E:9A:D2:F9
> a=candidate:1 1 ssltcp 2130706431 172.17.0.1 4443 typ host generation 0
> a=candidate:2 1 ssltcp 2130706431 192.168.4.41 4443 typ host generation 0
> a=candidate:3 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
> a=candidate:4 1 udp 2113932031 192.168.4.41 10000 typ host generation 0
> a=ssrc:277210242 cname:mixed
> a=ssrc:277210242 label:mixedlabelvideo0
> a=ssrc:277210242 msid:mixedmslabel mixedlabelvideo0
> a=ssrc:277210242 mslabel:mixedmslabel
> a=rtcp-mux
> m=application 1 DTLS/SCTP 5000
> c=IN IP4 0.0.0.0
> a=setup:actpass
> a=mid:data
> a=sendrecv
> a=ice-ufrag:45orf1audfte6a
> a=ice-pwd:66lo2ge7ug91kl0aaitkd5jflr
> a=fingerprint:sha-1
> 83:42:78:C9:3E:2F:75:CF:FF:D9:80:EF:8A:12:DA:52:4E:9A:D2:F9
> a=candidate:1 1 ssltcp 2130706431 172.17.0.1 4443 typ host generation 0
> a=candidate:2 1 ssltcp 2130706431 192.168.4.41 4443 typ host generation 0
> a=candidate:3 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
> a=candidate:4 1 udp 2113932031 192.168.4.41 10000 typ host generation 0
> a=rtcp-mux
> a=sctpmap:5000 webrtc-datachannel 1024
>
> As you can see, it gets the internal IP (local 192.x.x.x and docker
> 172.x.x.x), even I configured sip-communicator as suggested.
>
> # cat /etc/jitsi/videobridge/sip-communicator.properties
> org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=192.168.4.41
> org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=200.x.x.x
>
> As you can see, the LOCAL_ADDRESS is the same ssltcp and udp IPs at
> chrome://webrtc-internals.
>
> Some other suggest?
>
> Regards,
> Claudio Ferreira
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

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


#18

Hi,

Can you paste your config file for jvb
(/etc/jitsi/videobridge/config). It should have the following:
JAVA_SYS_PROPS="$JVB_EXTRA_JVM_PARAMS
-Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi
-Dnet.java.sip.communicator.SC_HOME_DIR_NAME=videobridge
-Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi
-Djava.util.logging.config.file=/etc/jitsi/videobridge/logging.properties"

So this instructs jvb to use /etc/jitsi/videobridge as home and search
for the config file there.
I think I see the bug inside the debian script:
https://github.com/jitsi/jitsi-videobridge/blob/master/resources/install/debian/postinst
It is that maybe you install it with default values and then
reconfigure it and in such case its this part that got executed:
https://github.com/jitsi/jitsi-videobridge/blob/master/resources/install/debian/postinst#L74
Which currently is not correct.

Glad you solved it.

Regards
damencho

···

On Fri, Oct 7, 2016 at 9:50 AM, Claudio Ferreia Filho <filhocf@gmail.com> wrote:

Hi

After a intense discussion, Damian and Boris helped me in find the error.

The configuration in the sip-communicator.properties, using the nightly
build from one week ago, in /etc/jitsi/videobridge wasn't read by JVB. It is
reading from /usr/share/jitsi-videobridge/.sip-communicator directory.

So, I did a symbolic link from this directory to /etc, or in a hand-ons:

# cd /usr/share/jitsi-videobridge/.sip-communicator
# ln -s /etc/jitsi/videobridge/sip-communicator.properties
sip-communicator.properties

After this, was only restart all services (jicofo, jvb, nginx and prosody),
that the docker entrypoint already do.

As I used a deb pkg, I understand that is a bug, so I opened a issue in
Github (#989).

With this workaround, my box is working fine.

Thanks to all who helped in this solution.

Best regards,
Claudio Ferreira

2016-10-06 16:40 GMT-03:00 Damian Minkov <damencho@jitsi.org>:

So jvb inside docker is seeing only 172.x.x. address, is this correct?

If this is the case you should put the following config:
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=172.x.x.x
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=200.x.x.x

What you should see in the sdp are only 172.x and 200.x addresses.
And make sure whatever comes to the media ports 10000-20000 on 200.x.x
got correctly routed and reach jvb which is inside docker.

Regards
damencho

On Thu, Oct 6, 2016 at 12:41 PM, Claudio Ferreia Filho >> <filhocf@gmail.com> wrote:
> 2016-10-06 11:51 GMT-03:00 Boris Grozev <boris@jitsi.org>:
>>
>> On 06/10/16 17:39, Claudio Ferreia Filho wrote:
>>>
>>>
>>> 2016-10-06 11:09 GMT-03:00 Boris Grozev <boris@jitsi.org
>>> <mailto:boris@jitsi.org>>:
>>>
>>>
>>> On 06/10/16 16:57, Claudio Ferreia Filho wrote:
>>>
>>> Hi
>>>
>>> I found more some questions, now specifically about NAT.
>>>
>>> I'm using my docker image and it runs fine in a host with real
>>> IP. The
>>> problem (apparently) is the STUN communication.
>>>
>>> Using a Wireshark to snif my communication, between the
>>> browser
>>> and the
>>> server, returned a strange data. My public IP is 200.x.x.x,
>>> but
>>> my
>>> browser try a STUN comm to IP 192.x.x.x (local IP of my server
>>> behind
>>> the NAT, where the NAT only translate 200.x.x.x -> 192.x.x.x
>>> and
>>> back)
>>> and to 172.x.x.x, that is a internal IP in a docker net, but
>>> the
>>> true is
>>> that my browser need to connect to 200.x.x.x.
>>>
>>> For my browser ask STUN to 172.x or 192.x is because STUN
>>> server
>>> are
>>> saying to connect in this IP. So, my ask change to: Who do the
>>> paper of
>>> STUN in the 'easy mode' ? Prosody? Jicofo? Other? And I
>>> understand that
>>> we need to set the STUN server to say it external IP. How can
>>> I
>>> do it?
>>>
>>>
>>> The documentation is a little buried:
>>>
>>>
>>> https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#orgjitsivideobridgenat_harvester_local_address
>>>
>>>
>>> <https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#orgjitsivideobridgenat_harvester_local_address>
>>>
>>>
>>> I already tried this without success, as described in first email.
>>> However, if I understand your intent, videobridge is who do the paper
>>> of
>>> STUN. Is it?
>>>
>>> How can I verify if JVB is honoring this configuration?
>>
>>
>> Look at the remote candidates in chrome://webrtc-internals. They should
>> include the public IP address of the server.
>>
>> Regards,
>>
>> Boris
>
>
> Boris, this is my setRemoteDescription:
>
> type: offer, sdp: v=0
> o=- 1923518516 2 IN IP4 0.0.0.0
> s=-
> t=0 0
> a=group:BUNDLE audio video data
> m=audio 1 RTP/SAVPF 111 103 104 126
> c=IN IP4 0.0.0.0
> a=rtpmap:111 opus/48000/2
> a=rtpmap:103 ISAC/16000
> a=rtpmap:104 ISAC/32000
> a=rtpmap:126 telephone-event/8000
> a=fmtp:111 minptime=10; useinbandfec=1
> a=rtcp:1 IN IP4 0.0.0.0
> a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
> a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
> a=setup:actpass
> a=mid:audio
> a=sendrecv
> a=ice-ufrag:45orf1audfte6a
> a=ice-pwd:66lo2ge7ug91kl0aaitkd5jflr
> a=fingerprint:sha-1
> 83:42:78:C9:3E:2F:75:CF:FF:D9:80:EF:8A:12:DA:52:4E:9A:D2:F9
> a=candidate:1 1 ssltcp 2130706431 172.17.0.1 4443 typ host generation 0
> a=candidate:2 1 ssltcp 2130706431 192.168.4.41 4443 typ host generation
> 0
> a=candidate:3 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
> a=candidate:4 1 udp 2113932031 192.168.4.41 10000 typ host generation 0
> a=ssrc:3928738533 cname:mixed
> a=ssrc:3928738533 label:mixedlabelaudio0
> a=ssrc:3928738533 msid:mixedmslabel mixedlabelaudio0
> a=ssrc:3928738533 mslabel:mixedmslabel
> a=rtcp-mux
> m=video 1 RTP/SAVPF 100
> c=IN IP4 0.0.0.0
> a=rtpmap:100 VP8/90000
> a=fmtp:100 x-google-start-bitrate=800
> a=rtcp:1 IN IP4 0.0.0.0
> a=rtcp-fb:100 ccm fir
> a=rtcp-fb:100 nack
> a=rtcp-fb:100 nack pli
> a=rtcp-fb:100 goog-remb
> a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
> a=setup:actpass
> a=mid:video
> a=sendrecv
> a=ice-ufrag:45orf1audfte6a
> a=ice-pwd:66lo2ge7ug91kl0aaitkd5jflr
> a=fingerprint:sha-1
> 83:42:78:C9:3E:2F:75:CF:FF:D9:80:EF:8A:12:DA:52:4E:9A:D2:F9
> a=candidate:1 1 ssltcp 2130706431 172.17.0.1 4443 typ host generation 0
> a=candidate:2 1 ssltcp 2130706431 192.168.4.41 4443 typ host generation
> 0
> a=candidate:3 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
> a=candidate:4 1 udp 2113932031 192.168.4.41 10000 typ host generation 0
> a=ssrc:277210242 cname:mixed
> a=ssrc:277210242 label:mixedlabelvideo0
> a=ssrc:277210242 msid:mixedmslabel mixedlabelvideo0
> a=ssrc:277210242 mslabel:mixedmslabel
> a=rtcp-mux
> m=application 1 DTLS/SCTP 5000
> c=IN IP4 0.0.0.0
> a=setup:actpass
> a=mid:data
> a=sendrecv
> a=ice-ufrag:45orf1audfte6a
> a=ice-pwd:66lo2ge7ug91kl0aaitkd5jflr
> a=fingerprint:sha-1
> 83:42:78:C9:3E:2F:75:CF:FF:D9:80:EF:8A:12:DA:52:4E:9A:D2:F9
> a=candidate:1 1 ssltcp 2130706431 172.17.0.1 4443 typ host generation 0
> a=candidate:2 1 ssltcp 2130706431 192.168.4.41 4443 typ host generation
> 0
> a=candidate:3 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
> a=candidate:4 1 udp 2113932031 192.168.4.41 10000 typ host generation 0
> a=rtcp-mux
> a=sctpmap:5000 webrtc-datachannel 1024
>
> As you can see, it gets the internal IP (local 192.x.x.x and docker
> 172.x.x.x), even I configured sip-communicator as suggested.
>
> # cat /etc/jitsi/videobridge/sip-communicator.properties
> org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=192.168.4.41
> org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=200.x.x.x
>
> As you can see, the LOCAL_ADDRESS is the same ssltcp and udp IPs at
> chrome://webrtc-internals.
>
> Some other suggest?
>
> Regards,
> Claudio Ferreira
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

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

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