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.onerror and 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.
Hello @mattpiz,
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.
Maybe looking into other events would also be a good idea for a nicer detection when the stream is playing. I have also seen loadeddata and loadedmetadata being used for such a detection.
