mattermost / mattermost-webrtc

23 stars 21 forks source link

Some tweaks to the Dockerfile that I found necessary #3

Closed Analect closed 5 years ago

Analect commented 7 years ago

Was trying to build an image from the Dockerfile locally, but it keeps failing at step 5.

Step 5 : RUN git clone git://git.libwebsockets.org/libwebsockets &&     cd libwebsockets &&     git checkout v1.5-chrome47-firefox41 &&     mkdir build &&     cd build &&     cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_C_FLAGS="-fpic" .. &&     make && make install &&     cd ~ && rm -rf libwebsockets
 ---> Running in a22f447e9a84
Cloning into 'libwebsockets'...
fatal: remote error: access denied or repository not exported: /libwebsockets
The command '/bin/sh -c git clone git://git.libwebsockets.org/libwebsockets &&     cd libwebsockets &&     git checkout v1.5-chrome47-firefox41 &&     mkdir build &&     cd build &&     cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_C_FLAGS="-fpic" .. &&     make && make install &&     cd ~ && rm -rf libwebsockets' returned a non-zero code: 128

I tried tweaking the clone end-point to that shown at the bottom of this page, but that didn't work, so reverted to using https://github.com/warmcat/libwebsockets.

In step 7, where the COPY from ../vagrant/janus ... this fails, if you are building the image from within the docker folder, since you can only copy folders from the root directory of where the docker build command is run from and can't reference relative paths as is currently done in the Dockerfile ... so, as per this SO, the work-around is to run from the root of the repo with docker build -f docker/Dockerfile -t mattermost/webrtc .

While the webrtc container seems to run up OK, and I can initiate a call from mattermost ... when the other user answers ... there's an on-screen error warning There was a problem connecting the video call and in the browser console, I get these errors.

5.ba9fb6c….js:1 Is the gateway down? (connected=false)value @ 5.ba9fb6c….js:1value @ 5.ba9fb6c….js:7(anonymous function) @ 5.ba9fb6c….js:7value @ main.bce07c6….js:25p.callback @ main.bce07c6….js:23(anonymous function) @ main.bce07c6….js:23a.emit @ main.bce07c6….js:43n.onreadystatechange @ main.bce07c6….js:23

The logs from the webrtc container don't appear to show any errors ... or nothing that's obvious.

JANUS Streaming plugin initialized!
Loading plugin 'libjanus_textroom.so'...
Streaming watchdog started
JANUS TextRoom plugin initialized!
Transport plugins folder: /opt/janus/lib/janus/transports
Loading transport plugin 'libjanus_pfunix.so'...
TextRoom watchdog started
Configuring SOCK_SEQPACKET Unix Sockets server (Janus API)
[WARN] Unix Sockets server disabled (Admin API)
JANUS Unix Sockets transport plugin initialized!
Loading transport plugin 'libjanus_websockets.so'...
Unix Sockets thread started
libwebsockets < 1.6 available, using old API
WebSockets server started (port 8188)...
Secure WebSockets server started (port 8189)...
[WARN] Admin WebSockets server disabled
[WARN] Secure Admin WebSockets server disabled
JANUS WebSockets transport plugin initialized!
Loading transport plugin 'libjanus_http.so'...
Secure WebSocket (Janus API) thread started
WebSocket (Janus API) thread started
HTTP webserver started (port 8088, /janus path listener)...
HTTPS webserver started (port 8089, /janus path listener)...
Admin/monitor HTTP webserver started (port 7088, /admin path listener)...
Admin/monitor HTTPS webserver started (port 7089, /admin path listener)...
JANUS REST (HTTP/HTTPS) transport plugin initialized!
HTTP/Janus sessions watchdog started

Obviously looked at forum to troubleshoot, but haven't found anything on there.

enahum commented 7 years ago

Hi @Analect,

Thanks for the report.

First of all I just moved the Dockerfile to the root of the folder so we can remove the get rid of the relative paths.

also the image is building fine for me with libwesockets

$ docker build -t mattermost/webrtc .
Sending build context to Docker daemon 528.3 MB
Step 1/12 : FROM ubuntu:16.04
 ---> e4415b714b62
Step 2/12 : RUN apt-get -y update && apt-get -y upgrade && apt-get install -y bash wget libmicrohttpd-dev libjansson-dev libnice-dev                                          libopus-dev libssl-dev libsofia-sip-ua-dev libglib2.0-dev                                          libogg-dev pkg-config gengetopt libtool automake git cmake
 ---> Using cache
 ---> c516a059a3b3
Step 3/12 : RUN cd ~ &&     wget https://github.com/cisco/libsrtp/archive/v1.5.4.tar.gz &&     tar xfv v1.5.4.tar.gz &&     cd libsrtp-1.5.4 &&     ./configure --prefix=/usr --enable-openssl &&     make shared_library && make install &&     cd ~ && rm -rf libsrtp-1.5.4
 ---> Using cache
 ---> 910259c72dc2
Step 4/12 : RUN git clone https://github.com/sctplab/usrsctp &&     cd usrsctp &&     ./bootstrap &&     ./configure --prefix=/usr && make && make install &&     cd ~ && rm -rf usrsctp
 ---> Using cache
 ---> 6d893617b250
Step 5/12 : RUN git clone git://git.libwebsockets.org/libwebsockets &&     cd libwebsockets &&     git checkout v1.5-chrome47-firefox41 &&     mkdir build &&     cd build &&     cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_C_FLAGS="-fpic" .. &&     make && make install &&     cd ~ && rm -rf libwebsockets
 ---> Using cache
 ---> 303b082975b3
Step 6/12 : RUN git clone https://github.com/meetecho/janus-gateway.git &&     cd janus-gateway &&     sh autogen.sh &&     ./configure --prefix=/opt/janus --disable-rabbitmq --disable-mqtt &&     make &&     make install && make configs &&     rm /opt/janus/etc/janus/*.cfg.sample &&     mkdir -p /opt/janus/certs &&     openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:1024 -keyout /opt/janus/certs/privateKey.key -out /opt/janus/certs/certificate.crt -subj '/C=US/ST=California/L=Palo Alto/O=Mattermost/OU=WebRTC/CN=dockerhost' &&     cd ~ && rm -rf janus-gateway
 ---> Using cache
 ---> c81885e18a97
Step 7/12 : COPY vagrant/janus/config/*.cfg /opt/janus/etc/janus/
 ---> f24a69c897e7
Removing intermediate container f77e96b6b75a
Step 8/12 : EXPOSE 7088
 ---> Running in 73ce1d63a1a5
 ---> 6c12b09480c2
Removing intermediate container 73ce1d63a1a5
Step 9/12 : EXPOSE 7089
 ---> Running in a3984e2ba220
 ---> 51028d6b89b8
Removing intermediate container a3984e2ba220
Step 10/12 : EXPOSE 8188
 ---> Running in 12ce772e4164
 ---> e0ea52c55160
Removing intermediate container 12ce772e4164
Step 11/12 : EXPOSE 8189
 ---> Running in b05f3b6e838e
 ---> 173df3cb3770
Removing intermediate container b05f3b6e838e
Step 12/12 : CMD /opt/janus/bin/janus
 ---> Running in a77511023e37
 ---> 627720727f7c
Removing intermediate container a77511023e37
Successfully built 627720727f7c

and here my Janus log

---------------------------------------------------
  Starting Meetecho Janus (WebRTC Gateway) v0.2.1
---------------------------------------------------
2016-12-07T14:14:23.717789570Z 
Checking command line arguments...
Debug/log level is 4
Debug/log timestamps are disabled
Debug/log colors are enabled
Adding 'vmnet' to the ICE ignore list...
Using 172.17.0.4 as local IP...
Token based authentication enabled
Initializing ICE stuff (Full mode, ICE-TCP candidates disabled, IPv6 support disabled)
STUN server to use: stun.l.google.com:19302
ICE handles watchdog started
Testing STUN server: message is of 20 bytes
  >> Our public address is 190.162.180.124
BUNDLE is NOT going to be forced
rtcp-mux is NOT going to be forced
[WARN] OpenSSL pre-1.1.0
Fingerprint of our certificate: 92:DE:DB:26:3F:62:9A:08:07:BC:C6:7D:13:A5:00:83:51:B9:98:44:51:DB:02:99:57:49:E8:57:20:86:A9:3E
Plugins folder: /opt/janus/lib/janus/plugins
Sessions watchdog started
Loading plugin 'libjanus_streaming.so'...
JANUS Streaming plugin initialized!
Loading plugin 'libjanus_sip.so'...
Streaming watchdog started
JANUS SIP plugin initialized!
Loading plugin 'libjanus_videocall.so'...
SIP watchdog started
JANUS VideoCall plugin initialized!
Loading plugin 'libjanus_audiobridge.so'...
VideoCall watchdog started
JANUS AudioBridge plugin initialized!
Loading plugin 'libjanus_echotest.so'...
AudioBridge watchdog started
EchoTest watchdog started
JANUS EchoTest plugin initialized!
Loading plugin 'libjanus_textroom.so'...
JANUS TextRoom plugin initialized!
Loading plugin 'libjanus_voicemail.so'...
TextRoom watchdog started
JANUS VoiceMail plugin initialized!
Loading plugin 'libjanus_videoroom.so'...
VoiceMail watchdog started
JANUS VideoRoom plugin initialized!
Loading plugin 'libjanus_recordplay.so'...
VideoRoom watchdog started
JANUS Record&Play plugin initialized!
Record&Play watchdog started
Transport plugins folder: /opt/janus/lib/janus/transports
Loading transport plugin 'libjanus_http.so'...
HTTP webserver started (port 8088, /janus path listener)...
HTTPS webserver started (port 8089, /janus path listener)...
Admin/monitor HTTP webserver started (port 7088, /admin path listener)...
Admin/monitor HTTPS webserver started (port 7089, /admin path listener)...
JANUS REST (HTTP/HTTPS) transport plugin initialized!
Loading transport plugin 'libjanus_websockets.so'...
HTTP/Janus sessions watchdog started
libwebsockets < 1.6 available, using old API
WebSockets server started (port 8188)...
Secure WebSockets server started (port 8189)...
[WARN] Admin WebSockets server disabled
[WARN] Secure Admin WebSockets server disabled
JANUS WebSockets transport plugin initialized!
Loading transport plugin 'libjanus_pfunix.so'...
WebSocket (Janus API) thread started
Secure WebSocket (Janus API) thread started
Configuring SOCK_SEQPACKET Unix Sockets server (Janus API)
[WARN] Unix Sockets server disabled (Admin API)
JANUS Unix Sockets transport plugin initialized!
Unix Sockets thread started

There is a race condition in the code that needs to be fixed at some point that is the reason why sometimes you get the There was a problem connecting the video call, maybe if you retry you can get it to connect?

Hope this helps

Analect commented 7 years ago

@enahum Thanks for the quick response. Not sure about the step 5 problem in the Dockerfile ... maybe it has something to do with me running it form an aws ec2 instance ... sometimes certain endpoints aren't accessible from within an ec2 instance.

Ref. the problem with connecting the video call ... I have tried numerous times .. so don't think my problem is related to a race condition.

The logs from my webrtc container are broadly similar to yours. Does your log then capture attempts to make calls ... since mine doesn't grow from there ... suggesting that somehow mattermost is not connecting properly to it.

I'm wondering ... the other thing I notice in the console is this getUserMedia() warning. I am running mattermost using a http rather than https protocol (out of laziness in setting up the ssl stuff!) ... so perhaps that is also an explanation for why this webrtc may not be working against my instance of mattermost?

I think this particular warning is more related to s3 backup ... and somehow how mattermost is unable to get back user profile images ... but, as a I said above, perhaps this might also be a source of my problems in getting webrtc to work.

getUserMedia() no longer works on insecure origins. To use this feature, you should consider switching your application to a secure origin, such as HTTPS. See https://goo.gl/rStTGz for more details.(anonymous function) @ 5.ba9fb6c….js:8
http://myserver.com:8001/api/v3/users/65k7nxg67t8uzknbzwtzeiqfnc/image?time=1464276885722 Failed to load resource: the server responded with a status of 500 (Internal Server Error)
enahum commented 7 years ago

Oh yes you need to run webrtc behind SSL if not the browsers will complain

Analect commented 7 years ago

Just to confirm ... the webrtc stuff is running using SSL, I believe ... where I'm using ports 7089 and 8189 in the set-up against mattermost ... but are you saying that I also need mattermost itself to be running using ssl too?

enahum commented 7 years ago

Yes Mattermost should be running with SSL

Analect commented 7 years ago

@enahum I have changed mattermost to run on https protocol using a letsencrypt certificate. Now when I initiate a call ... the screen/cameras are working ... and I am getting prompted by both browsers (initiator and receiver) to permit camera/microphone ... which all looks fine ... however, as per below .. I'm still getting messages in the console `Is the gateway down? (connected=False)

Initializing WebRTC Client library
5.ba9fb6c….js:1 Library initialized: true
5.ba9fb6c….js:1 Using WebSockets to contact Janus: wss://myserver.com:8189
5.ba9fb6c….js:1 Server #1: trying WebSockets to contact Janus (wss://myserver.com:8189)
5.ba9fb6c….js:1 WebSocket connection to 'wss://myserver.com:8189/' failed: WebSocket opening handshake was canceledvalue @ 5.ba9fb6c….js:1e @ 5.ba9fb6c….js:1(anonymous function) @ 5.ba9fb6c….js:7value @ main.bce07c6….js:25p.callback @ main.bce07c6….js:23(anonymous function) @ main.bce07c6….js:23a.emit @ main.bce07c6….js:43n.onreadystatechange @ main.bce07c6….js:23
5.ba9fb6c….js:1 Error connecting to the Janus WebSockets server... wss://myserver.com:8189

I'm running both a dockerized mattermost and dockerized mattermost-webrtc on the same server. Presumably that's permitted?

Also, I'm not linking these two in any way ... ie. they aren't part of the same docker-compose file ... and aren't sharing a docker network.

All the relevant ports are open ... that are used by the mattermost-webrtc container.

I see that this mattermost-webrtc generates its own ssl certificates. I'm no expert on this ... but I'm assuming the SSL certs used for mattermost (ie. my letsencrypt solution) can be independent of those generated by the dockerized web-rtc container for its purposes?

Thanks for your patience!

enahum commented 7 years ago

OK first of all you need to ensure that the docker container where you are running MM can talk to the other container running the Webrtc server, that's probably the reason you aren't able to connect to the websocket.

Regarding the SSL stuff:

  1. Mattermost server should run with SSL so the browsers allow the use of the user media
  2. Webrtc server in the docker container is running with a self-signed certificate so you need allow unsecured connections from Mattermost to external services that is accomplished by going to the System Console -> Security -> Connections: and setting Enable Insecure Outgoing Connections: true
Analect commented 7 years ago

Yes .. 1 and 2 above are fulfilled.

When you say:

ensure that the docker container where you are running MM can talk to the other container running the Webrtc server

They are both running on the same EC2 instance, and I have opened relevant ports ... sometimes that is required even if both containers are on the same machine ... however, as per the docker run command in the README.md of this repo ... there isn't any explicit links being set between the MM containers (web,app,db) and the web-rtc containers .... should there be? ... in which case I would probably look to consolidate in a single docker-compose file.

So, as it stands ... the only thing the MM instance knows about the web-rtc container are the settings in the system console:

Gateway Websocket URL set as: wss://myserver.com:8189 Gateway Admin URL set as: https://myserver.com:7089/admin Gateway Amdin secret as: janusoverlord

Separately, I asked over here how the above settings might get permanently manifested in a config file.

enahum commented 7 years ago

my question is this

The MM docker container can reach myserver.com? and if so myserver.com have open the ports 8189 and 7089?

Analect commented 7 years ago

Yes ... both MM docker containers (app, web, db) and MM-webrtc happen to be running on the same machine ... so they should be able to reach eachother ... but my guess is in a some-what round-about way ... by routing via the internet ... the various webrtc services are exposed externally ... and then the settings in the MM app reference these.

I'm just wondering if this set-up is somehow precluding something from working. And if so, where all these containers are cohabiting in an instance, is there a better approach for them to communicate internally using something like the basic host_mode networking?

enahum commented 7 years ago

running on the same machine doesn't necessarily mean that they can talk to each other, so I guess that you would need something as the host_mode you are mentioning so the MM container can use the myserver.com domain or any other and reach the webrtc container

Analect commented 7 years ago

Thanks @enahum I'll experiment a bit tomorrow and report back.

hanzei commented 7 years ago

Are there any updates about this topic?

Analect commented 7 years ago

@Hanzei Sorry ... no updates from me. Haven't touched this in a while, since I started using a gitlab omnibus version that includes mattermost, although without features like webRTC at this point.

cpanato commented 5 years ago

closing this, this repo is not more maintained