iOS turn server list couldn't be obtained

[melihercan]

iOS turn server list couldn't be obtained

[melihercan]

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]

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

• appsettings.Development.json ( "BaseUrl": "https://192.168.1.48:5053")
• appsettings.json( "BaseUrl": "https://melihercan.somee.com")
  .net Core contains
• launchSettings.json ("applicationUrl": "https://192.168.1.48:5053;http://192.168.1.48:5052")=>
  launchsettings only required on development process , which means not needed when publishing the app
• replaceMe... also there.
  I told you it is working on android only which means am walking on right path, and one more thing the NuGet packages still need an update

[melihercan]

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]

Link:
MessagePack issue

[alzubitariq]

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]

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.