websockets and webRTC test failure - new installation bigbluebutton

[Kate Dawson]

Hi, 

I've have a fresh installation of bigbluebutton.  I believe I have followed the instructions accurately. However  the check url always shows "loading" for the WebRTC Echo Test and the WebRTC Socket Test. 

The client and bigbluebutton server are both behind a firewall, but on the same LAN segment, so there is no packet filtering or network address translation between them.

Please see below the output from bbb-conf --check, and the output from the /check web page

Thanks in advance, 

Kate

root@bbb-2-dev:/etc/nginx/sites-available# bbb-conf --check

BigBlueButton Server 1.0.0 (1062)

                    Kernel version: 4.4.0-31-generic

                      Distribution: Ubuntu 14.04.5 LTS (64-bit)

                            Memory: 3952 MB

/var/www/bigbluebutton/client/conf/config.xml (bbb-client)

  Port test (tunnel): 172.25.1.198

                              Red5: 172.25.1.198

              useWebrtcIfAvailable: true

/opt/freeswitch/conf/sip_profiles/external.xml (FreeSWITCH)

                    websocket port: 5066

                    WebRTC enabled: true

/etc/nginx/sites-available/bigbluebutton (nginx)

                       server name: 172.25.1.198

                              port: 80

                    bbb-client dir: /var/www/bigbluebutton

/var/lib/tomcat7/webapps/bigbluebutton/WEB-INF/classes/bigbluebutton.properties (bbb-web)

                      bbb-web host: 172.25.1.198

/var/lib/tomcat7/webapps/demo/bbb_api_conf.jsp (API demos)

                               url: 172.25.1.198

/var/www/bigbluebutton/check/conf/config.xml (client check)

                      client check: 172.25.1.198

/usr/share/red5/webapps/bigbluebutton/WEB-INF/red5-web.xml (red5)

                  voice conference: FreeSWITCH

                     capture video: true

                   capture desktop: true

/usr/local/bigbluebutton/core/scripts/bigbluebutton.yml (record and playback)

                     playback host: 172.25.1.198

** Potential problems described below **

# Warning: The API demos are installed and accessible from:

#

#    http://172.25.1.198/demo/demo1.jsp

#

# These API demos allow anyone to access your server without authentication

# to create/manage meetings and recordings. They are for testing purposes only.

# If you are running a production system, remove them by running:

#

#    sudo apt-get purge bbb-demo

# Warning: The client self check is installed and accessible from:

#

#    http://172.25.1.198/check

#

Warning

Java Enabled:       Java is disabled in your browser

Loading...

WebRTC Echo Test:       null

WebRTC Socket Test:     null

Succeded

Browser:        Chrome 54.0.2840.59

Client Check Version:       0.9.0-30

Cookie Enabled:     true

Download Speed:     83.196 Mbps (19.749 MB in 1 seconds)

Flash Version:      24.0.0.221

Is Pepper Flash:        true

Language:       en-GB

Ping:       51.6 ms

Port 9123:      connect

RTMP BigBlueButton app:     NetConnection.Connect.Success

RTMP deskShare app:     NetConnection.Connect.Success

RTMP sip app:       NetConnection.Connect.Success

RTMPT BigBlueButton app:        NetConnection.Connect.Success

RTMPT deskShare app:        NetConnection.Connect.Success

RTMPT sip app:      NetConnection.Connect.Success

RTMPT video app:        NetConnection.Connect.Success

RTMP video app:     NetConnection.Connect.Success

Screen Size:        1024 x 768 

User Agent:     Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36

WebRTC Supported:       true

[Chad Pilkey]

WebRTC in Chrome won't work unless you have SSL setup on your server. I think we create a fake microphone for that check page, but it might be running into an error with that. I would suggest trying in Firefox if SSL isn't an option.

[Kate Dawson]

I've also tested using Firefox on Windows. The results are the same.  Additionally I have another host that has a been configured to use https with a valid certificate from letsencrypt.  This shows a similar error. 

See below output from /check on Windows and Firefox

Loading...

WebRTC Echo Test:               null

WebRTC Socket Test:             null

Succeded

Browser:                Firefox 51.0

Client Check Version:           0.9.0-30

Cookie Enabled:         true

Download Speed:         28.313 Mbps (19.749 MB in 5 seconds)

Flash Version:          24.0.0.221

Is Pepper Flash:                false

Java Enabled:           1.8.0_101, 1.8.0_111, 1.8.0_121, 1.8.0_45, 1.8.0_51, 1.8.0_60, 1.8.0_65, 1.8.0_66, 1.8.0_71, 1.8.0_73, 1.8.0_77, 1.8.0_91

Language:               en-GB

Ping:           108.0 ms

Port 9123:              connect

RTMP BigBlueButton app:         NetConnection.Connect.Success

RTMP deskShare app:             NetConnection.Connect.Success

RTMP sip app:           NetConnection.Connect.Success

RTMP video app:         NetConnection.Connect.Success

RTMPT BigBlueButton app:                NetConnection.Connect.Success

RTMPT deskShare app:            NetConnection.Connect.Success

RTMPT sip app:          NetConnection.Connect.Success

RTMPT video app:                NetConnection.Connect.Success

Screen Size:            1366 x 768

User Agent:             Mozilla/5.0 (Windows NT 6.1; rv:51.0) Gecko/20100101 Firefox/51.0

WebRTC Supported:               true

[Chad Pilkey]

There might be something useful in the browser console. It's getting stuck somewhere and that would probably give some indication. If you put the log in pastebin and link it back here I can take a look through it.

Can you also test against our demo server (https://demo.bigbluebutton.org/) from the same machine and see that that can connect successfully.

[Kate Dawson]

Hiya Chad,

Here is the browser console.log

Sending message that cannot be cloned. Are you trying to send an XPCOM object?  MessageChannel.jsm:657:6
Sending message that cannot be cloned. Are you trying to send an XPCOM object?  MessageChannel.jsm:657:6
Object { enabled: true, version: Array[1], minimum: "1.7.0_51+", appropriate: true }  api-bridge.js:169:3
Joining the audio test first  bbb_webrtc_bridge_sip.js:97:5
User info callback [myUserID=12345,myUsername=bbbTestUser,myAvatarURL=undefined,myRole=undefined,amIPresenter=undefined,dialNumber=undefined,voiceBridge=undefined,isListenOnly=false].  bbb_webrtc_bridge_sip.js:50:13
12345-bbbID-bbbTestUser  bbb_webrtc_bridge_sip.js:67:13
user 12345-bbbID-bbbTestUser calling to 9196undefined  bbb_webrtc_bridge_sip.js:244:5
Fetching STUN/TURN server info for user agent  bbb_webrtc_bridge_sip.js:145:5

All the /check tests pass for my Firefox browser at https://demo.bigbluebutton.org/check

Regards,

Kate

[Chad Pilkey]

Okay it makes sense now. The problem is the voice conference it's trying to connect to "9196undefined". The check page uses dummy data to test all of the connections and in the past we used an undefined voiceBridge value and just connected to the echo test (9196) directly, but that broke at some point in 1.0 because we stopped connecting directly to the echo test and instead connected through a combined conference id (9196+voiceBridge).

We ended up finding the issue while working on 1.1 and fixed it there so it's no longer present in 1.1-beta, but we didn't backport a fix. To get the check page working again in 1.0 you would need to find this line (https://github.com/bigbluebutton/bigbluebutton/blob/v1.0.x-release/bbb-client-check/resources/lib/api-bridge.js#L227), and change "undefined" to "" (an empty string). I'm not sure where the check page is actually located on the file system unfortunately. You might be able to find the directory by following the nginx redirect definition in "/etc/bigbluebutton/nginx/" or try looking in "/var/www/bigbluebutton".

[Kate Dawson]

Hi Chad, I made the change to the javscript file, however I still got the same result.

However I do believe that the client is using webrtc for audio, so perhaps passing the "/check" isn't so important (  I don't get prompted to use flash for audio, though I do for video  - is this correct ? )

Thanks,

Kate Dawson

[Chad Pilkey]

The client should try WebRTC audio first and then fall back to Flash audio if WebRTC doesn't work. If you aren't seeing warnings about WebRTC in the actual client I wouldn't worry about it too much. You're probably hitting some sort of bug in the /check page, but I'm not sure exactly where.

Webcams are still shared through Flash because we don't have a workable WebRTC path yet.