Error 2001 AUDIO_INPUT_LEVEL_TOO_LOW in Agora video Call - agora.io

Everything was working fine but After updating Agora to 3.1.2., once remote user joined the video call, After a few seconds, Video call disconnected and getting this error in the log
"type":"exception","code":2001,"msg":"AUDIO_INPUT_LEVEL_TOO_LOW"
Version info.
"ngx-agora": "2.0.1",
"agora-rtc-sdk": "3.1.2",
Angular 10.0.8

It is a known issue by the developer and the team is working on fixing it and is an open bug on the Agora IO Community Repo here.
In the words of the developer:
How to reproduce
If you create and publish your microphone audio track without any user interaction, the remote user may not hear you. In this case, the console will print some logs like SEND_AUDIO_BITRATE_TO_LOW and AUDIO_INPUT_LEVEL_TOO_LOW.
And once you interact with the webpage, the remote user will hear you.
Root cause
Agora Web SDK NG uses the AudioContext API to do some audio pre-processing by default. However, the AudioContext is restricted by the browser's autoplay policy. If user has not interacted with your webpage, the AudioContext will not run. So there is no audio data produced from the SDK's pre-processing module in this case.
How to avoid
We will fix this issue in v4.0.2, and it will be released next month.
For now, we recommend that you should ensure that the user has interacted with the webpage before the audio track is published. For example, the user is required to click the accpet or confirm button to start a call.

Related

Is it possible to force Chrome to refresh app notification settings when using Notification delegation

In a previous answer regarding Notification Delegation between Chrome and an Android TWA app it was said that:
"If the TWA has notifications disabled in Android Settings, we disable
them in Chrome instead. There's a little bit of latency with how this
gets propagated, but things should get updated on the next TWA launch
at latest.
How exactly Notification Delegation does work?
On my site I am sending the user to androids app notification settings when I find that notifications are not allowed in the browser.
But upon the users immediate return, the changes are not propagated to Chrome (to be expected from the comment above since the TWA is not launched again).
I wonder if there is anyway I can speed this up? Otherwise the user is forced to exit the page completely and restart the app before the permission is granted, which is not a very good user experience.
It seems the only workaround would be to force restarting the application, which is not a great user experience. I have filed an issue on Chromium bugs to track a fix for this: https://bugs.chromium.org/p/chromium/issues/detail?id=1064300

Load old saved conversation for bot emulator with Node.js

I am trying to load the past bot conversation for bot emulator when user triggers in the beginning using Node.js. How can I do it?
I have already saved the conversation in SQL server.
The emulator does not natively support this. It is, however, it is an open source project in which you can customize it to do this. I have written an example of how to do this in webchat. The emulator uses a build of webchat so i'm confident this could be accomplished in the emulator as well. You can find the example forn web chat I was talking about in this repo

Kurento: Kurento-room without webcam

I've seen that kurento-room isn't able of managing a user that enters only with microphone(no webcam).
The user actually appears in the room, with a black screen in the place where the webcam is normally located, but no audio is received from him either.
Why can this be happening?
That's an error in the connection of WebRTC endpoints. The thing is that the endpoint only negotiates audio, but the connection was made with audio and video profiles, and the media server committed seppuku. It should be fixed by now, providing the right media profiles in the connect method.

RROR – unable to acquire LMS API, content may not play properly and results may not be recorded. Please contact technical support

We are in the process of implementing Success Factors LMS, and trying to play and view SCORM compatible files exported from Adobe Captivate 8 and 9 in Success Factors LMS.
I get the message - 'ERROR – unable to acquire LMS API, content may not play properly and results may not be recorded. Please contact technical support’
I have tried SCORM versions 1.2 v3 and 2004 V2 and V4. We can view the content, however it does not track, show as complete etc.
We are also producing Scorm compliant files using Skillcast and Articulate, but we still hit the same issue, we can view the content after closing the API error window, but still does not track.
Anyone experienced this problem before? Or know of a fix?
Many thanks
Normally this issue comes up when the course is unable to get the SCORM API from the LMS...I have seen a ton of SCORM content running in Success Factors before, so I wonder if the issue is in the setup. Are you seeing any "Access Denied" type errors in the browser element inspector/developer tools? I wonder if the course just can not find/have access to the player window. If the course is launching in a new window, you may want to try launching it in the frameset. I have seen folks get around this issue by making sure the player and sco are in the same window...
If you wanted to rule out the content being the issue, you can always test your content in the SCORM Cloud's free sandbox (https://cloud.scorm.com) to make sure the course is properly asking for the API...
If you have any other questions, we would be happy to help...you can just shoot us an email at support#scorm.com.
Thank you!
Joe
The error occurs because the content is not speaking to the Learning Management System (LMS). The code that runs to initialize the session doesn't happen. There is no return "ping" from the LMS.
You will get this error when you publish in SCORM and run from your desktop, or from a web server that isn't connected to an LMS. If it occurs when you are launching from an LMS it can either mean that the SCORM API isn't configured correctly, or your content server is on a different domain (cross-domain) than your application servers.
To test, you should try launching your content in different browsers. Our system was configured in such a way that Firefox and Chrome read our content to be cross-domain issue, and threw the SCORM API error, but Internet Explorer worked just fine.
In the end, it was determined that our server configuration in tandem with our firewall and security settings read the Content server as cross-domain and we had to redeploy our content servers within the firewall.

Screen Sharing on webRTC

Is it possible to capture desktop screen sharing through webRTC.. As we know that it just captures the screen on the browser tab but is it possible to capture the whole desktop screen like navigating through files on computer or opening and viewing files like pdf etc..
Currently, only "stateless" screen capturing is available in RTCWeb implementations (both chrome & firefox). E.g.
Install chrome extension and then try this demo
Above demo will simply capture screen of "any" opened application's screen. Though, such screen capturing API fails to capture screens of full-screen game applications.
More information available here:
https://developer.chrome.com/extensions/desktopCapture (HTTPs+getUserMedia+postMessage)
Regarding remote desktop sharing from a web-browser, it has a pile
more security risks associated with it compared to screen sharing. The
UI/security aspects will be tough to deal with, and the feature will
be very susceptible to social engineering -- phone call: "this is
Google/Dell/Computer-Management; we've detected your machine has a
virus on it; could you browse to and we'll assist you in
removing it" -- etc. Ref
Yes, it's possible. At least using Chrome. There are several ways of doing it, but the simplest one is:
Add this constaint when you invoke getUserMedia:
constraints.video.mandatory.chromeMediaSource = 'screen'
When starting chrome, use this argument (chrome version > 35):
--enable-usermedia-screen-capturing
You can find an example of sharing screen and recording the shared screen at a remote server repository here:
https://github.com/Kurento/kurento-tutorial-js/blob/develop/kurento-recorder-screen/static/index.js
If you try to execute that example, play close attention to the security restrictions. All signalling needs to travel using TLS. Using raw HTTP will produce chrome to refuse sharing screen.
Yes it is. I recently worked on WebRTC and was able to stream desktop easily. Following links helped me implement my requirements :
Firefox Extension : http://mozilla.github.io/webrtc-landing/
Dont forget to add your *.github.io to about:config -> getUserMedia screensharing allowed domains
Google Chrome extension : https://developer.chrome.com/extensions/samples#search
Open this in Run : Chrome.exe --enable-usermedia-screen-capturing
Other Reference : https://github.com/muaz-khan/WebRTC-Experiment