Our app lets users connect to their homes via an OpenVPN connection. Specifically, we want them to be able to receive and send audio data from and to the intercoms which they have in their homes. For us, establishing the VPN connection and communicating with the home works like a charm. But sending or receiving the aforementioned audio data isn't possible. While the phone and the intercom are able to establish a SIP connection, they aren't able to send each other any audio data. Using the packet capturing tool on our firewall, we can see, that the audio data isn't being passed into the VPN tunnel but rather it is being sent over the local network connection. This affects only the audio data, meaning that for every other type of network traffic, communication over the VPN is working fine. If we route all traffic over the VPN tunnel via networkSettings?.ipv4Settings?.includedRoutes = [NEIPv4Route.default()]
, the audio data is being sent and received successfully (this isn't a viable solution for us though). Our guess is, that the packets aren't being sent to the network interface, to which they should be sent according to the routing table on the phone.
While going through the a sysdiagnose of the whole process, this stood out to us: Error acquiring assertion: <Error Domain=RBSServiceErrorDomain Code=1 "(originator doesn't have entitlement com.apple.runningboard.assertions.webkit AND originator doesn't have entitlement com.apple.multitasking.systemappassertions)"...
because it matches the time of the establishing of the call. Could this be the culprit? I've seen people mention this error in combination with problems of sound-playback in the WebView.
Generally speaking, this wasn't a problem in iOS 14 and it affects our OpenVPN implementation in the app, but has the same result when we use our OpenVPN configuration with the official "OpenVPN Connect" app. To reproduce:
- Use sip.js (newest version) to connect over a VPN split tunnel to an Asterisk server
- Call another party which is connected to the same server
- Be able to establish a SIP call to that other party
- But notice how the audio packets aren't being sent over the VPN tunnel, although they are addressed to the exact same Asterisk server
But isn't the WebRTC implementation of WebKit choosing which network interface to bind the UDP traffic to?
Quite possibly. I’m familiar with this issue from the networking side, I don’t have any expertise in how that breaks down on the web side.
You have a number of potential paths forward here:
-
WebKit is open source. If its WebRTC infrastructure is included in the open source, you could dig into that to see what it’s doing.
-
You could also discuss this with WebKit experts via WebKit’s numerous community communication channels.
-
You could seek formal support from Apple by opening a DTS tech support incident.
-
You could file a bug about the change in behaviour as compared to iOS 14. If you do, 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"