Our app displays a website from local storage (meaning our WKSecurityOrigin protocol is file, not https) which connects to a local Asterisk server over wss://* in order to make and receive Sip calls from and to intercroms in the users local network. The sip connection works as expected and we're able to make and receive calls. After we've established voice communication to an intercrom, we're able to receive and play the audio information from the other party but we aren't able to send any audio information back from our iOS device. The WebView doesn't display any errors and we're able to access navigator.mediaDevices.getUserMedia without any problems. It's like the microphone on our iPhone was muted (which isn't the case though, our WKMediaCaptureState is Active). If we load the same website from https://, this problem disappears and the other party is able to hear us. We also handle the microphone permission request with this rudimentary code in our WebView:
- (void) webView:(WKWebView *)webView
requestMediaCapturePermissionForOrigin:(WKSecurityOrigin *)origin
initiatedByFrame:(WKFrameInfo *)frame type:(WKMediaCaptureType)type
decisionHandler:(void (^)(WKPermissionDecision decision))decisionHandler
API_AVAILABLE(ios(15.0))
{
if (type == WKMediaCaptureTypeMicrophone) {
decisionHandler(WKPermissionDecisionGrant);
}
}
Previously we just relied on the user clicking "Allow" in the popup which asked if they'd accept the app accessing the systems microphone. Either way, microphone access, if granted, shouldn't be the issue here.
We've also built a testing website to see what the data received from the microphone looks like in the WebView. By implementing this we can see, that the data chunks received from the MediaRecorder are empty while loading from file and contain data while loading from https.
This tells us that once again, iOS treats file contexts differently from https even though they're both considered equally secure contexts. Our setup was working after this was fixed in iOS 14.5 now it's once again broken and we have no idea why. We don't know if the WebView behaves the same towards camera access. We'd be glad if somebody could tell us if this was expected behaviour and how iOS is going to treat the file context in the future. We rely heavily on displaying our website from local storage because the website allows the used to control their home and we don't want to download this potentially large website every time they open our app since reducing interaction time is key here.
*to securely connect to the local server we installed the root CA with which the Asterisk's server cert was signed on our iOS system, this results in the WebView trusting our Asterisk server and allowing secure connections to it