Error 1020 : media cloud not reach the server

371 views
Skip to first unread message

Quentin Callebert

unread,
Oct 28, 2020, 9:53:22 AM10/28/20
to BigBlueButton-dev
Hello, 

After a lot of research, I come here to ask you for help.


I'm a linux systems administrator in a french engineering school. To prevent a possible reconfinement in France due to the covid-19 pandemic I have to install BBB servers.

To make tests, I have installed one server BBB with "bbb-demo", everything works well. 

On the other hand, when I want to use the webcam, I get an error 1020.

-On https://test.bigbluebutton.org I don't have any errors.
-Is happening intermittently
-I have tried with : Chrome, Firefox, Edge, Brave on Windows 10 ; Chrome and Firefox on Android. And finally with Safari on IOS. And I always have the same result. One out of 3 times I have a 1020 error.

The servers are behind a stormshield firewall and is behind NAT.

Here is the return of the command bbb-conf --check :

BigBlueButton Server 2.2.28 (2210)
                    Kernel version: 4.4.0-193-generic
                      Distribution: Ubuntu 16.04.7 LTS (64-bit)
                            Memory: 8141 MB
                         CPU cores: 8

/usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties (bbb-web)
       bigbluebutton.web.serverURL: https://bbb01.ensait.fr
                defaultGuestPolicy: ALWAYS_ACCEPT
                 svgImagesRequired: true

/etc/nginx/sites-available/bigbluebutton (nginx)
                       server name: bbb01.ensait.fr
                              port: 80, [::]:80
                              port: 443 ssl
                    bbb-client dir: /var/www/bigbluebutton

/var/www/bigbluebutton/client/conf/config.xml (bbb-client)
                Port test (tunnel): rtmp://bbb01.ensait.fr
                              red5: bbb01.ensait.fr
              useWebrtcIfAvailable: true

/opt/freeswitch/etc/freeswitch/vars.xml (FreeSWITCH)
                       local_ip_v4: 192.168.100.81
                   external_rtp_ip: 193.48.37.81
                   external_sip_ip: 193.48.37.81

/opt/freeswitch/etc/freeswitch/sip_profiles/external.xml (FreeSWITCH)
                        ext-rtp-ip: $${external_rtp_ip}
                        ext-sip-ip: $${external_sip_ip}
                        ws-binding: :5066
                       wss-binding: 193.48.37.81:7443

/usr/local/bigbluebutton/core/scripts/bigbluebutton.yml (record and playback)
                     playback_host: bbb01.ensait.fr
                 playback_protocol: https
                            ffmpeg: 4.2.4-1ubuntu0.1bbb1~16.04.1

/etc/bigbluebutton/nginx/sip.nginx (sip.nginx)
                        proxy_pass: 193.48.37.81

/usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml (Kurento SFU)
                        kurento.ip: 192.168.100.81
                       kurento.url: ws://127.0.0.1:8888/kurento
                    kurento.sip_ip: 192.168.100.81
                    localIpAddress: 192.168.100.81
               recordScreenSharing: true
                     recordWebcams: true
                  codec_video_main: VP8
               codec_video_content: VP8

/usr/share/meteor/bundle/programs/server/assets/app/config/settings.yml (HTML5 client)
                             build: 1058
                        kurentoUrl: wss://bbb01.ensait.fr/bbb-webrtc-sfu
                  enableListenOnly: true


# Potential problems described below
# IP does not match:
#                           IP from ifconfig: 192.168.100.81
#   /etc/nginx/sites-available/bigbluebutton: bbb01.ensait.fr
# Warning: API URL IPs do not match host:
#
#                                IP from ifconfig: 192.168.100.81
#  /var/lib/tomcat7/demo/bbb_api_conf.jsp: bbb01.ensait.fr


# Warning: The setting of 193.48.37.81 for proxy_pass in
#
#    /etc/bigbluebutton/nginx/sip.nginx
#
# does not match the local IP address (192.168.100.81).
# (This is OK if you've manually changed the values)

# Warning: The API demos are installed and accessible from:
#
#
# and
#
#
# 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:
#
#    apt-get purge bbb-demo

Here is the outpour of WebRtcEndpoint.conf.ini :

;; Local network interfaces used for ICE gathering.
;;
;; If you know which network interfaces should be used to perform ICE (for
;; WebRTC connectivity), you can define them here. Doing so has several
;; advantages:
;;
;; * The WebRTC ICE gathering process will be much quicker. Normally, it needs
;;   to gather local candidates for all of the network interfaces, but this step
;;   can be made faster if you limit it to only the interface that you know will
;;   work.
;;
;; * It will ensure that the media server always decides to use the correct
;;   network interface. With WebRTC ICE gathering it's possible that, under some
;;   circumstances (in systems with virtual network interfaces such as
;;   "docker0") the ICE process ends up choosing the wrong local IP.
;;
;; <networkInterfaces> is a comma-separated list of network interface names.
;;
;; Examples:
;; networkInterfaces=eth0
;; networkInterfaces=eth0,enp0s25
;;
;networkInterfaces=eth0

;; List of IPs to be ignored during the gathering phase when networkInterfaces
;; is enabled.
;;
;; If you set up the networkInterfaces option and the desired interfaces have
;; IPs that you don't wish to be used by libnice's NiceAgent, you
;; you can define them here.
;;
;; The general use case is filtering out IP addresses which are in the private
;; address ranges in environments where they aren't needed. This allows a fine
;; tuning to the number of server-side candidates generated by Kurento, reducing
;; signalling overhead and potentially speeding up connectivity checks.
;;
;; <ipIgnoreList> is a comma-separated list of IP (IPv4 and IPV6) addresses
;;
;; Examples:
;; ipIgnoreList=10.10.0.254
;; ipIgnoreList=fd12:3456:789a:1::1

;; STUN server IP address.
;;
;; The ICE process uses STUN to punch holes through NAT firewalls.
;;
;; <stunServerAddress> MUST be an IP address; domain names are NOT supported.
;;
;; You need to use a well-working STUN server. Use this to check if it works:
;;
;; From that check, you should get at least one Server-Reflexive Candidate
;; (type "srflx").
;;
stunServerAddress=turn.ensait.fr
stunServerPort=3478

;; TURN server URL.
;;
;; When STUN is not enough to open connections through some NAT firewalls,
;; using TURN is the remaining alternative.
;;
;; Note that TURN is a superset of STUN, so you don't need to configure STUN
;; if you are using TURN.
;;
;; The provided URL should follow one of these formats:
;;
;;   * user:password@ipaddress:port
;;   * user:password@ipaddress:port?transport=[udp|tcp|tls]
;;
;; <ipaddress> MUST be an IP address; domain names are NOT supported.
;; <transport> is OPTIONAL. Possible values: udp, tcp, tls. Default: udp.
;;
;; You need to use a well-working TURN server. Use this to check if it works:
;;
;; From that check, you should get at least one Server-Reflexive Candidate
;; (type "srflx") AND one Relay Candidate (type "relay").
;;

;; Certificate used for DTLS authentication.
;;
;; If you want KMS to use a specific certificate for DTLS, then provide it here.
;; You can provide both RSA or ECDSA files; the choice between them is done when
;; calling the WebRtcEndpoint constructor.
;;
;; If this setting isn't specified, a different set of self-signed certificates
;; is generated automatically for each WebRtcEndpoint instance.
;;
;; This setting can be helpful, for example, for situations where you have to
;; manage multiple media servers and want to make sure that all of them use the
;; same certificate. Some browsers, such as Firefox, require this in order to
;; allow multiple WebRTC connections from the same tab to different KMS.
;;
;; Absolute path to the concatenated certificate (chain) file(s) + private key,
;; in PEM format.
;pemCertificateRSA=/path/to/cert+key.pem
;pemCertificateECDSA=/path/to/cert+key.pem

;; External IPv4 and IPv6 addresses of the media server.
;;
;; Forces all local IPv4 and/or IPv6 ICE candidates to have the given address.
;; This is really nothing more than a hack, but it's very effective to force a
;; public IP address when one is known in advance for the media server. In doing
;; so, KMS will not need a STUN or TURN server, but remote peers will still be
;; able to contact it.
;;
;; You can try using these settings if KMS is deployed on a publicly accessible
;; server, without NAT, and with a static public IP address. But if it doesn't
;; work for you, just go back to configuring a STUN or TURN server for ICE.
;;
;; Only set this parameter if you know what you're doing, and you understand
;; 100% WHY you need it. For the majority of cases, you should just prefer to
;; configure a STUN or TURN server.
;;
;; <externalIPv4> is a single IPv4 address.
;; <externalIPv6> is a single IPv6 address.
;;
;externalIPv4=198.51.100.1
;externalIPv6=2001:0db8:85a3:0000:0000:8a2e:0370:7334

;; External IP address of the media server.
;;
;; DEPRECATED: Use "externalIPv4" and/or "externalIPv6" instead.
;;
;; Forces all local IPv4 and IPv6 ICE candidates to have the given address. This
;; is really nothing more than a hack, but it's very effective to force a public
;; IP address when one is known in advance for the media server. In doing so,
;; KMS will not need a STUN or TURN server, but remote peers will still be able
;; to contact it.
;;
;; You can try using this setting if KMS is deployed on a publicly accessible
;; server, without NAT, and with a static public IP address. But if it doesn't
;; work for you, just go back to configuring a STUN or TURN server for ICE.
;;
;; Only set this parameter if you know what you're doing, and you understand
;; 100% WHY you need it. For the majority of cases, you should just prefer to
;; configure a STUN or TURN server.
;;
;; <externalAddress> is a single IPv4 or IPv6 address.
;;
;externalAddress=198.51.100.1
;externalAddress=2001:0db8:85a3:0000:0000:8a2e:0370:7334

;; Whether to enable TCP candidate gathering via NiceAgent's ice-tcp property.
;; The motivation behind this is to potentially speed up gathering
;; by preventing TCP candidate gathering in scenarios where they aren't needed.
;;
;; <niceAgentIceTcp> MUST be either 0 (FALSE) or 1 (TRUE)
;; Default is 1 (TRUE)
;;
;niceAgentIceTcp=1

And here the outpour of turn-stun-servers.xml :

<?xml version="1.0" encoding="UTF-8"?>
        xsi:schemaLocation="http://www.springframework.org/schema/beans

    <bean id="stun0" class="org.bigbluebutton.web.services.turn.StunServer">
        <constructor-arg index="0" value="stun:turn.ensait.fr"/>
    </bean>


    <bean id="turn0" class="org.bigbluebutton.web.services.turn.TurnServer">
        <constructor-arg index="0" value="9a9029b2e459d46fbacb4090a6249022"/>
        <constructor-arg index="1" value="turns:turn.ensait.fr:443?transport=tcp"/>
        <constructor-arg index="2" value="86400"/>
    </bean>
    
    <bean id="turn1" class="org.bigbluebutton.web.services.turn.TurnServer">
        <constructor-arg index="0" value="9a9029b2e459d46fbacb4090a6249022"/>
        <constructor-arg index="1" value="turn:turn.ensait.fr:443?transport=tcp"/>
        <constructor-arg index="2" value="86400"/>
    </bean>

    <bean id="stunTurnService"
            class="org.bigbluebutton.web.services.turn.StunTurnService">
        <property name="stunServers">
            <set>
                <ref bean="stun0"/>
            </set>
        </property>
        <property name="turnServers">
            <set>
                <ref bean="turn0"/>
                <ref bean="turn1"/>
            </set>
        </property>
    </bean>
</beans>

You will find attached to the message the log file from Firefox about:webrtc 

Thank you in advance for your help.
I remain at your disposal for any further request.
I look forward to hearing from you.
Quentin
aboutWebrtc.html

hyunho

unread,
Oct 28, 2020, 8:49:22 PM10/28/20
to BigBlueButton-dev
The same problem occurred in IOS14 and the turn server was configured but has not been resolved.

It seems that related articles continue to be posted, but it is frustrating because there is no clear resolution.

Has anyone worked it out?

2020년 10월 28일 수요일 오후 10시 53분 22초 UTC+9에 quentin....@gmail.com님이 작성:

Akshay Kumar

unread,
Oct 29, 2020, 10:48:19 AM10/29/20
to BigBlueButton-dev
Getting this error on iOS and mac (safari browser) from last couple of weeks. (works fine in chrome on ubuntu and android)

I havent setup a Turn server and still it used to work fine for all users, now all of a sudden only iOS users are unable to share their video stream, 

Also tried another isntallation with a Turn server using the (installed via bbb-install.sh) still no luck.

One thing I have observerd is that even on chrome browser in dev tools, if I emulate an iPhone even then the issue persists.

Anybody else getting the same error?

clientLogger: Camera SHARER has not succeeded in 15000 for w_cqzgqnd5enmd_26e8b1be268006dbd8976aaf5ba173d3b4b28da4919d989a88d8546ac71e7e77
Reply all
Reply to author
Forward
0 new messages