WebRTC iceconnectionstatechange and connectionstatechange dont fire "closed" event in Chrome 80. Does anyone have any workaround to detect the connectionstatechange when peer is closed? It doesnot fire even in plan-b
They don't fire when calling pc.close() anymore. See
https://bugs.chromium.org/p/chromium/issues/detail?id=1023736
If your JS code calls pc.close() you surely have detected that the other side went away somehow.
Related
I use php-webdriver for test automation on chrome, I want to listen to a chrome dev tools event, but the php-webdrvier does not a have a listen command, only execute, is there another way to listen to an event? I am interested in tracing.datacollected event specifically
I tried to find another way but I failed
this question may seem duplicate, but I've searched a lot, but could not find any appropriate solution.
I need my socket connection to not break when user kills/closes app. It works when user presses the home button and apps goes to background. But connection breaks when user kills or closes the app. I need behavior like how chat apps like whatsapp literally work. So when I close the whatsapp, I can still receive new messages.
If anyone has found any solution for this, please share.
Thank you.
Your Socket connection should run as a background task and continuously listen to stream of message events even when the app close then you can push notifications to notify the user.
https://github.com/jamesisaac/react-native-background-task provide an abstract layer for both iOS and Android
I've created a webrtc app on localhost. Because the input video and output video is coming from the same camera, I can't visually determine if the webrtc connection is indeed working correctly.
I went to chrome://webrtc-internals/, to inspect the details, but I am not sure which one tells me if connection is working. Is there some flag that I can check, perhaps on RTCPeerConnection object or in webrtc-internals, to determine if the connection is indeed successful?
If the connection is established successfully, then you will be seeing this in chrome://webrtc-internals/
24/07/2019, 16:54:53
signalingstatechange
stable
and
24/07/2019, 16:55:09
iceconnectionstatechange
completed
I have done the code changes by referring "kurento-one2many-call" node sample for webRTC video streaming using RTSP steam as source. Code is available on GitHub Repository. Presenter/source(PlayerEndpoint) is loaded on start of node application, and viewer will stream video stream by clicking on viewer button. No need to add presenter or click on presenter button.
But I am facing problem with this code, When I will click on viewer button, no any error on Chrome console log and on Firefox it shows "ICE failed, see about:webrtc for more details" error on console log. It just showing spinner and video did not get displayed.
If we monitor Node log, then everything is fine with it, PlayerEndpoint is created successfully and responding to ICE messages. Last line of log is printed as "Sending viewer candidate." after that it will stuck, nothing will be printed later. Same will happen for new viewer request.
Please help me to get out of this issue, or suggest me any code changes.
The STUN server you have configured in your WebRtcEndpoint.ini (173.194.66.127) is not generating any candidates. It's very likely that the server is down. Please use any other publicly available STUN server from this list. Also, don't forget to check that the server is indeed working by any of the following methods
Via the Trickle ICE test page. Don't forget to remove the existing STUN server.
In your KMS box, through the stun command. You might need to install the package via sudo apt-get install stun
I am testing websocket and trying to find scenarios to trigger an error event on the client side. The protocol says
If the user agent was required to fail the websocket connection or the WebSocket connection is closed with prejudice, fire a simple event named error at the WebSocket object.
However using this logic, I tried connecting to a server which does not support websocket. I see that browser is actually firing the "close" event but "error" event is not getting triggered.
Q : Should the above mentioned scenario fire an error event ? Also, what are the other scenarios with which I can possible trigger an error event on the client side ?
WebSockets specifications are not fully followed by all browsers.
So each implementation has own differences. For example Chrome wont throw onerror event on connection issues.
But FireFox does throw onerror whenever connection is broke by endpoint (disconnected from code, just turned off server, or even inability to connect).
So you can't really for now count on stability of this event implementations.
Based on my experience, I see for now that onerror event is pretty specific to browser, and has just a few logical scenarios in common.