melihercan / WebRTCme

A cross-platform framework for adding WebRTC support to .NET MAUI, Blazor, and Desktop applications by using a single unified .NET/C# API.
https://github.com/melihercan/WebRTCme
MIT License
226 stars 46 forks source link

iOS turn server list couldn't be obtained #2

Closed alzubitariq closed 3 years ago

alzubitariq commented 3 years ago

On iOS emulator giving an exception but in real device gives turn server list couldn't be obtained. On android it is working

melihercan commented 3 years ago

Do you have network connectivity between iOS and the signaling server? You can easily check this by opening a browser on iOS and enter server address with the port (in my code it is: https://192.168.1.48:5053). This should show the index page of the server.

alzubitariq commented 3 years ago

Yes it is there , actually there was many configuration json files Demo contains

Video-2021-04-28-220325

Video-2021-04-28-221053

melihercan commented 3 years ago

Unlike Android, iOS simulator has no Camera support. That is why I run all my tests on an iOS phone. I thought you are getting the exception due to this call (iOS/MediaView.cs, line 46: /var/ _videoCapturer = new Webrtc.RTCCameraVideoCapturer(); There is a workaround for this issue by using RTCFileVideoCapturer on simulator like this: if (DeviceInfo.DeviceType == DeviceType.Virtual) { _videoCapturer = new RTCFileVideoCapturer(); _videoCapturer.Delegate = videoSource; } else { _videoCapturer = new RTCCameraVideoCapturer(); _videoCapturer.Delegate = videoSource; } I will add this later.

I did a quick debugging session and figured out that the exception is thrown even before that. It occurs during SignalR HubConnectionBuilder in file SignallingServerProxy and it is related to MessagePAckProtocol. See the comment at line 51: //// iOS has problems with MessagePack: //// https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/signalr/messagepackhubprotocol.md //.If(DeviceInfo.Platform != DevicePlatform.iOS, builder => builder.AddMessagePackProtocol()) //// Workaround: tick 'Enable the Mono interpreter' option (unticked for release build) Please check the link for more details, but briefly this has something to do with ahead of time compiling. See the workaround: Workaround: tick 'Enable the Mono interpreter' option (unticked for release build) Unfortunately this option is grayed out for simulator. So until further analysis and solution, using a real device looks like the only option for now.

melihercan commented 3 years ago

Link: MessagePack issue

alzubitariq commented 3 years ago

Thank you for your response and effort. I have one more question , you know most of networks like 4G , ADSL new routers have an Symmetric NATs where the ports keep changing randomly . which means first approach will fail (stun) In cases like this, we have to fall back to TURN WhatsApp , Facebook Messenger and Skype using TURN approach and that's the expensive solution. So my question was do you think we have to follow TURN ?

melihercan commented 3 years ago

In general, it is better to employ both STUN and TURN servers. Please check ITurnServerProxy interface. Here we are returning list of RTCIceServers, that can contain both STUN and TURN entries. WebRTC will try to use STUN first and if all STUNs fail, then it will employ TURN as fall back, so your connection will not fail due to Symmetric NATs for example. This is all handled in WebRTC automatically.

If you debug Xirsys server, you will see that they return IceServer entries both in STUN and TURN.

If you are sure that your clients can be NAT discoverable and not symmetric, or not filtered out by firewalls, then you can use STUN only ICE server entries like I do in my StunOnly example.