webrtc-as-rtmp-re-publishing-not-working

Max

Max

Administrator
Staff member
Faraz Ahmed said:
when we use https://wcs:8443/rest-api/push/startup we get following error message "SSL certificate problem: unable to get local issuer certificate", Although we have already imported SSL from webcall server admin dashboard. Can you please let us know what's the issue
Click to expand...
This message can be displayed by browser in two cases:
1. You are using self-signed certificate.
2. You are using Certificate Authority which is not trusted by the browser.
So please do the following:
1. Check if you have succesfully imported the certificate using WCS dashboard. Is dashboard itself marked by browser as secure when opening via HTTPS https://wcs:8444/admin/? If not, and you have imported certificate successfully, please check if it is a wildcard certificate *.yourdomain.com. If not, you're probably opening the page with a different servers name (for example, you have certificate for wcs.yourdomain.com, but opening as staging.yourdomain.com.
2. Check if browser displays connection as secure
1658193412216.png

If not, and you are using a right name to open, and certificate is not self-signed, check if browser claims for CA in certificate details
1658193777878.png

If something wrong with the CA (is not trusted), please ask the certificate issuer about the problem.
 
Max

Max

Administrator
Staff member
Faraz Ahmed said:
Sometimes during webcam streaming our stream not play good on Facebook like please check below screenshot
Click to expand...
This is definitely the publisher channell quality issue. Please use TCP transport when publishing WebRTC stream from webcam
Code: 
session.createStream({
    name: streamName,
    display: localVideo,
    constraints: {
        ...
    },
    transport: "TCP"
    ...
}).publish();
If this does not help, use a lower resolution and bitrate for publishing
Code: 
session.createStream({
    name: streamName,
    display: localVideo,
    constraints: {
        video: {
            width: 640,
            height: 360,
            maxBitrate: 500
        },
        audio: true
    },
    transport: "TCP"
    ...
}).publish();
 
F

Faraz Ahmed

Member
Hi @Max

We have noticed flashphoner server takes too much of cpu usage even though we have not published any stream and when we publish stream then its take more cpu due to which our other services stop responding and sometimes flashponer server itself stop responding too.

1658325232770.png


Thanks,
Faraz
 
Max

Max

Administrator
Staff member
Faraz Ahmed said:
and further can we set it on auto update whenever new version available?
Click to expand...
No. You can only check for updates manually
Code: 
sudo /usr/local/FlashphonerWebCallServer/bin check_update
and update if needed
Code: 
sudo /usr/local/FlashphonerWebCallServer/bin update
But it is not recommended to update server in production unless it's not working as expected.
 
Max

Max

Administrator
Staff member
Sorry, it's a mistype.
Should be
Code: 
sudo /usr/local/FlashphonerWebCallServer/bin/webcallserver check_update
and
Code: 
sudo /usr/local/FlashphonerWebCallServer/bin/webcallserver update
respectively. Please see the doc here.
 
F

Faraz Ahmed

Member
Hi @Max

our webcall server is working but after 4 minutes of streaming its stopped the stream and we get following error message in the console can you please check it and let us know the fix. We are using latest build 5.2.1644

Screenshot from 2023-05-29 19-06-27.png


Thanks,
Faraz
 
Max

Max

Administrator
Staff member
We checked the report. Seems like you're using an old WebSDK version on the frontend:
1685500479923.png

We recommend to update WebSDK to the latest build 2.0.228.
Also seems you should correct the video and audio constraints
1685500557045.png

1. Audio bitrate 1 Mbps seems too high even for stereo publishing, 128000 bps seems to be enough for sound to be clear
2. Video bitrate should be set as minBitrate and maxBitrate constraints
We also tested publishing to your server from Chrome 114 and Firefox 113 on Ubuntu 22.04 (like on your screenshot). WebRTC stream from Chrome 114 was published in 10 minutes without any problems, but Firefox 113 on Ubuntu seems to stop sending video packets after 1-1.5 minutes of publishing (WebRTC statistics shows a zero publishing bitrate).
We recommend to use Chrome on Ubuntu for WebRTC publishing.
 
Max

Max

Administrator
Staff member
We repeated the test in a following conditions:
- our test server in public network;
- our test server in AWS (beyond AWS NAT);
- your server from report.
WebRTC publishing from Firefox fails with Failed by ICE keep alive only on your server and only when stream is publishing via TCP. If stream is publishing via UDP, it not fails in 30+ minutes. This seems like some network configuration problem or traffic blocking based on packets content by network provider. We recommend to deploy an instance in other datacenter or try to use TURN server for publishing.
 
You must log in or register to reply here.
Top