Update: Yes it does for very plain implementations. We traced my problem down to a series of firewall & VPN issues that only occurred in our dev environment and working remotely (surprised?). Everything worked as expected once we were back inside the corporate network.

I also have the same issue - has anybody open a FB request to Apple?

Working now after I added "-ld64" to "Other linker Flags". Thank you @songme

@eskimo Good to see your reply. The WebRTC code is Googles native WebRTC library with the network connections in C/C++. So it's definitely not WKWebView nor is it the Network framework. We are digging into the code now to see if its a wrapper around BSD sockets or ?. Historically, this code has worked fine in iOS version 12-16; today running iOS 14-16.5. It's just under iOS 17 that we are seeing a problem with UDP. We aren't seeing any errors in our logs or any 'failures' in the connections; data just doesn't seem to flow either in or out. Any ideas where we can look to help determine the cause? Additional logs or keywords we could look for?

@eskimo Are there any new restrictions to cryptography algorithms in iOS 17?

After further research, it does appear to be using BSD Sockets for the communications. Assuming that my researcher is correct... any ideas where I could look for the root cause of the problem?

@eskimo Developing video visit (video meetings, video chat, etc.) on the iOS simulators is problematic as the camera is not available on the simulator so the bulk of our development is on the actual devices. With that in mind, under the iOS 16 simulators, the incoming UDP audio and video streams from iOS 16 devices are working as expected within the limit of the simulators. The iOS 17 simulator is failing in the same fashion of the iOS 17 device fails = no incoming video stream is detected. Replicated all problems on the beta 2. So any hints on where we can look for error messages, console logs, etc. to find where the failure is?

@eskimo We are running Xcode 15.0 beta 2 on MacOS 13.4.1. Since the problem does not occur on on Xcode 14/Mac OS 13.4.1 iOS 16 simulator; but does occur on Xcode 15/MacOS 13.4.1 iOS 17 simulator doe that then point to something in iOS 17 itself since the simulator is talking directly to the MacOS kernel? It also fails directly on an iPhone 12 running iOS 17 beta 2; failing on both WiFi and Cell networks. Also, is there anything we can do to trigger more debug information in the console to help pin down where it is failing? As mentioned above, we are not receiving any error messages, and from what we can tell, the connection appears to happen; but no data is flowing.

Adding to the device list, iPad mini 6, running iOS 17 beta 2 on WiFi exhibits the same problem.

@eskimo Using the Activity Monitor on the Mac, it does appear to show incoming data peaks when others join the conference. I will try instruments on the device next.

@eskimo We think we have found it - and it appears to be a bug in the runtime library for Swift: let stringForiOSTesting = "Hello\r\nthere. Will \r you \rseparate" let arrayOfComponents = stringForiOSTesting.components(separatedBy: "\r") print("arrayOfComponents::\(arrayOfComponents.count)") print("arrayOfComponents::\(arrayOfComponents)") => iOS 17!!!!!!!!!!!``` arrayOfComponents::1 arrayOfComponents::["Hello\r\nthere. Will \r you \rseparate"] => iOS 16 (expected results arrayOfComponents::4 arrayOfComponents::["Hello", "\nthere. Will ", " you ", "separate"]

FB12545393 has been filed. It even includes a project that recreates the bug. For this fix, we went with .newlines instead of "/r" and that fixes the problem with min code change. let arrayOfComponents = stringForiOSTesting.components(separatedBy: .newlines)