WebRTC, UDP, and iOS 17

What API are you using for WebRTC? The one built in to WKWebView? Or something based directly on Network framework? Or BSD Sockets?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@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?

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

Nothing that immediately springs to mind. Having said that, it’s hard to say anything definitive without know what APIs this code is calling. If it’s doing all its own crypto, Apple’s crypto algorithm choices won’t affect it at all.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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?

it does appear to be using BSD Sockets for the communications.

My experience is that the vast bulk of BSD Sockets issues with UDP relate to interface selection. Folks either:

• Fail to bind to an interface when they should, for example, when doing broadcasts, or

• Bind to an interface when they shouldn’t, for example, when working with a UDP flow, where setting up a connected UDP socket is a much better idea

Does your app fail in the iOS 17 simulator? Or just on a real device?

That matters because it affects how you might go about debugging it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@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?

The iOS 17 simulator is failing in the same fashion of the iOS 17 device fails = no incoming video stream is detected.

Where you running these on macOS 13? Or macOS 14 beta?

This matters because, when you use BSD Sockets, the simulator talks directly to the macOS kernel. If you’re running both simulators on macOS 13 then you still using last year’s kernel, which rules out a whole raft of potential issues. It means that the origin of the problem is almost certainly within your app’s process.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@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.

So, to summarise:

| macOS  | Xcode  | iOS        | Result |
| -----  | ------ | ---        | ------ |
| 13.4.1 | 14.3   | 16.x       | OK     |
| 13.4.1 | 14.3   | 16.x sim   | OK     |
| 13.4.1 | 15.0b2 | 17.0b2     | NG     |
| 13.4.1 | 15.0b2 | 17.0b2 sim | NG     |

Is that right?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

Haven't tried Xcode 13.3

Yeah, that was a typo on my part. I’ve gone back and fixed it. I also changed Xcode 15.0b3 to 15.0b2. Sheesh, I was obviously having a bad day when I wrote that post [1].

So, yeah, this is strange. Normally bugs like this only show up on real hardware, either because they’re tied to the kernel or tied to stuff, like WWAN, that’s only available on real hardware. The fact that you’re seeing this on the sim is strange.

It’s good news, however, because the simulator gives you access to more debugging tools. To start, have you looked at a packet trace for this? Specifically, I’m curious:

• Are the outgoing packets for your video stream being sent?

• If so, are the incoming packets being received by the Mac?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Actually, I was, after spending 5 minutes fighting DevForums’s support for Markdown tables (r. 81109741). Eventually I decided to revert to using a code block )-:

@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"]

Interesting.

components(separatedBy:) is not a Swift call but a Foundation one. The native Swift call is split(separator:maxSplits:omittingEmptySubsequences:). You should switch to that, not just to work around this problem but also because it’s a better API.

However, I’d appreciate you filing a bug about this. Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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)

I started having difficulties with WebRTC connections in my iOS app after upgrading to iOS 17. The behavior isn't totally consistent, but it looks like there are network issues when connecting via a STUN server, but not via TURN. Via STUN, the connection is established and then usually drops after a few seconds. Is anyone else experiencing these issues?

This is the WebRTC package I'm using: https://github.com/stasel/WebRTC

I don’t think your issue is related to aearmstrong’s original issue. Their problem was caused by a now-fixed bug in Swift’s string support (FB12545393).

I recommend that you start a new thread for your issue.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"