Following my first draft at Elm + WebRTC (introduced in the previous post). I’ve been trying to fix signaling issues, without success on iOS.
Turns out “perfect negotiation” is not ready yet. So I’m back to the classic simple caller/callee pattern from 2019-12-13 and have deactivated perfect negotiation for now.
All is working relatively well except with iOS devices now. I don’t own any iOS device, and trying to debug over phone and screenshots is getting tiresome to my family iPhone owner. So I’m hoping someone here with some iOS dev skills would be interested to help.
The main symptom for now is that in a peer connection between one iOS and one non-iOS, the non-iOS one receives the stream of the iOS one but not vice-versa. I’ve tried to add try-catch in a lot of places, and ultimately also added
window.onunhandledrejection catch-all. The errors are transferred to the
error port of the app and displayed in an overlay when clicking on the top-right button as below.
Any help on this would be greatly appreciated! Issues, PRs, and/or screenshots are much welcomed! To test it, you can clone and deploy the
classic-signaling branch on heroku. PS: you can also adapt
server.js at lines 1, 7-10 and 15 to use a self-signed certificate locally but that won’t work with an iOS device which requires a “true” certificate for secure websockets.
git clone firstname.lastname@example.org:mpizenberg/elm-allo.git
git checkout classic-signaling
git push heroku +HEAD:master
I don’t have any apple devices, but are you sure that you have a real error on iOS?
As the peer connection seems to be successfully established (non-iOS peer can see the iOS peer) it could be possible that only playing the video is prohibited by Safari.
You could try to display the video element controls and if the iOS peer can then see the other one after pressing “play” you know where you need to investigate further. Autoplay of video with audio is misused for annoying ads so the browsers try to block it.
A simple solution could be to call play() and then mute the video if it fails and try again.
At work we also had several problems integrating WebRTC conferencing into our elm app and your description seems like a problem we had with playing the received media stream.
I did not look at your code, but you could also send a message to the server when
ontrack is triggered or the ICE connection state changes so you get a minimal logging experience in the server logs.
Another interesting thing would be to poll getStats() and send connection stats to the server (e.g. kbit/s or received frames are usually interesting)
Your analysis was quite on point. Actually the issue was somewhat iOS-related but not really. Most official WebRTC example use the
onunmute event listener inside the
ontrack event to only update the video stream when data is actually available. It turns out that
onunmute event was never triggered on iOS devices. So adding the stream directly
ontrack seemed to have solved that issue.
I didn’t thought of sending logs to the server, that could have helped indeed. However I’ve added logs to the interface in addition to errors. That helped too and was basically how I realized that the
onunmute event was never triggered so here again, quite on spot!
This could be interesting indeed, I’ve added an issue about this.
That’s great to read.
Maybe looking into other events would also be a good idea for a nicer detection when the stream is playing. I have also seen
loadedmetadata being used for such a detection.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.