Websocket getting cut off when working with CallKit API, iOS 17.5 and higher

[seoplague]

Before the iOS 17.5 update, calling worked relatively stable. However, starting from this version and on, Safari instantly force-closes all open websocket connections when the "Answer" button on the calling UI is hit. So, basically, the call ends right after it answers, because in our case websockets are crucial for the SIP negotiation process.

Firstly, I inspected the Safari console, and there is a new red error saying: WebSocket connection to 'wss://home.thirdlane.com/wss' failed: The operation couldn’t be completed. Software caused connection abort.

Secondly, I checked the Xcode logs, and there are several warnings saying Invalidating grant <invalid NS/CF object> failed every time the call is answered.

@mattkhaw Maybe you also encountered this problem after upgrading to 17.5 and found a solution to this problem?

[mattkhaw]

Mine seems to work fine. Maybe the problem lies with the SIP used? I'm using WebRTC to handle this though. So far so good. Even works on the latest version of iOS.

[seoplague]

@mattkhaw I also use WebRTC with https://github.com/cordova-rtc/cordova-plugin-iosrtc.
After updating to iOS 17.5 I see the following behavior of my app when the phone is locked and the app is closed:
I receive a VoiP push and see iOS native call screen. When I pick up the phone I see a sip transport on the sip server for a few seconds, which closes after a few seconds. I can continue speak with caller, but I can handle any sip events correctly: bye, hold and other. And I don't understand what's going on. Maybe you have some suggestions on this?

[mattkhaw]

@seoplague Not sure this post helps but it seems to be similar to your case based on the error that you mentioned in the first post -> Receiving invalid_grant, but only during App Store Review

I understand that it might not be the exact issue that you are facing, but it seems that it might be caused by the backend and according to that link, the backend is using the same token to retry and hence, causes this error. Hope this helps.

[seoplague]

@mattkhaw could you check please your app on IOS > 17.5 this case:

1. Close App
2. Block Phone
3. Make a call
4. Pickup a phone from Voip Push
5. Try to open App from Native Call screen
6. Continue conversation

If in this case your App is working correctly it will helps me in debug my app.
Very big thanks.

[mattkhaw]

@mattkhaw could you check please your app on IOS > 17.5 this case:

1. Close App
2. Block Phone
3. Make a call
4. Pickup a phone from Voip Push
5. Try to open App from Native Call screen
6. Continue conversation

If in this case your App is working correctly it will helps me in debug my app. Very big thanks.

Like I mentioned in my previous post, my app seems to be working as intended. This problem is not related to the plugin itself. Most likely caused by your backend.

[Qvadis]

Same behaviour here. After I answer via callkit, sometimes it works and sometimes it doesn't. What I see is that the app code stops working and I see an "Invalid grant" trace in Xcode. Here's another post related https://forums.developer.apple.com/forums/thread/758232?page=1#798910022

[seoplague]

Like I mentioned in my previous post, my app seems to be working as intended. This problem is not related to the plugin itself. Most likely caused by your backend.

@Qvadis or @mattkhaw thanks, but it's my thread :) without answer. if you have Cordova VoiP App which works correctly in my case. Can you share your experience? I use:

1. "cordova-ios": "^7.1.0",
2. "cordova-plugin-background-mode": "^0.7.3",
3. "cordova-plugin-callkit": "^1.0.0",
4. "cordova-plugin-device": "^3.0.0",
5. "cordova-plugin-ionic-webview": "^5.0.1",
6. "cordova-plugin-iosrtc": "^8.0.4",
7. "cordova-plugin-wkwebview-ionic-xhr": "^2.1.1",
8. "sip.js": "0.15.11"

And use the following behavior:

cordova.plugins.CordovaCall.on('receiveCall', function () {
      console.log('On Receive Call');
      const ua = new SIP.UA({...});
      ua.connect();
  });
  
cordova.plugins.CordovaCall.on('answer', function () {
    console.log('On Call Answer');
    answer();
});

After receiveCall in 3-5 seconds ua.transport stoped.
Do you use cordova-plugin-backgroundmode ? How ?
When you say backend what you mean ?

[Qvadis]

My app is definitely working like yours, @seoplague. I'm experiencing the same (including the Invalidating grant <invalid NS/CF object> failed). I'm very interested in getting to the bottom of this. I've been fighting this for weeks,

Every time I receive the voip it wakes up. It executes code and "dies". Then I answer and again it executes some code and "dies" and the same when I hang up.

"cordova-ios": "^7.1.0",
"cordova-plugin-background-mode-fixed": "^0.7.9",
"cordova-plugin-ionic-webview": "^5.0.0",
"cordova-plugin-iosrtc": "^8.0.4",
"cordova-plugin-media": "^7.0.0",
"cordova-plugin-nativeaudio": "^3.0.9"

In my case Callkit and background plugins mode are forks but with no significant changes related to this.

I opened a feedback assistant to apple and I attached them the sysdiagnose to see if they can shed some light here.

Let's see if we can help each other!

[mattkhaw]

@seoplague I see. The reason why you don't understand "backend" is because you are using sip.js library and that library is just using P2P. My current setup consists of client app and also a custom dedicated service to help with connection establishment. As for packet routing, I have my own coturn server to handle video streams. The client apps won't communicate with one another using this method. In your case, the client apps are treated as their own servers. I think the problem lies in the architecture and app design.

@Qvadis For your case, maybe you can refer to the paragraph below and see whether this helps or not.

As we all know, there's a restriction for running apps in the background in iOS. Here's a useful resource albeit is from another developer instead of Apple -> iOS Background Execution Limits. I've encountered certain limitations on how to make this work on older iOS devices. The way that I solve this is by implementing a task deferring for connection establishment. Basically, what I did is to create a queue array and insert the intended task into this queue array and process this queue when the app is ready.

Another point I want to note is that, the headache that we all have is mostly the integration between native iOS code and Javascript for this kind of functionality. Native code can run in the background, however JavaScript only runs in the foreground. Basically, for JavaScript to run, the browser container has to be launched successfully and in the ready state. The problem I always have is that the library I'm using for handling my app state and UI is not ready when this happens. For this issue, I implement app wide logging and check from the logs to determine when I should answer/reject the call. Once I know where it is, this never becomes an issue.

FYI, my app doesn't use any background plugins since most if not all background plugins don't work for this type of functionality and just outright gets rejected by Apple and I don't want to deal with this kind of headache. Hence the design of my app won't have issues like this. As for Android (I know it is unrelated but it's good to know), this is not an issue at all since Android apps are queued in the background for continuous processing once it is opened.

From what you guys have described, my suspicion is still on the P2P architecture being not suitable for hybrid apps. There's also another situation might cause this issue is one of the client app calls the other party but hangs up immediately. As a result, the client app that receives the call doesn't have a point to connect to hence it might error out if not handled properly. Not sure whether this is related to your issue or not but no harm in checking that as well.

If you guys are interested to know what plugins I used, here's the list:-

1. "cordova-ios": "^6.2.0"
2. "cordova-plugin-iosrtc": "6.0.21"

The reason I don't bother with listing other plugins is because they are unrelated to this issue. As you can see, I'm not using the latest cordova-ios version nor using ionic for my app. This is because my app is not ready to be updated to the latest versions without breaking some other plugins or core functionality but this will be done when the time comes.

Sorry for the lengthy reply. I hope my suggestions help.

[seoplague]

@mattkhaw Thank you for your detailed answer. Could you describe in more details your approach for this point.

The problem I always have is that the library I'm using for handling my app state and UI is not ready when this happens. For this issue, I implement app wide logging and check from the logs to determine when I should answer/reject the call. Once I know where it is, this never becomes an issue.

I guess it can helps me for solving my issue.
Thanks.

[mattkhaw]

@mattkhaw Thank you for your detailed answer. Could you describe in more details your approach for this point.

The problem I always have is that the library I'm using for handling my app state and UI is not ready when this happens. For this issue, I implement app wide logging and check from the logs to determine when I should answer/reject the call. Once I know where it is, this never becomes an issue.

I guess it can helps me for solving my issue. Thanks.

Regarding this issue, this is an isolated incident since I'm using a third party library to handle my UI design and this library also has some lifecycle event handling built into it. Since the library I'm using also has event bus, I used this to handle the plugin's events for the JavaScript portion. In my case, there's an issue where these custom events don't fire because the library is not in the ready state hence those events don't get attached and ultimately, code doesn't get executed.

[Qvadis]

Thanks a lot @mattkhaw for your time.

Let me share a more detailed experience. I don't know if the plugin has nothing to do since it happens from iOS 17.5 and it seems to be something related to resources optimization (?).

When I receive the VOIP notification the app gets ready and executes the code inside the notification listener, and if the system allows it, it logins into our SIP server (asterisk is the server and JsSIP is the library I'm using).
When the system stop the code, the thread freezes and when I answer it resumes from this point. This could be dangerous since the app has calling states and it may lead to unknown scenarios.

After the answer, my app, that is already (or not) registered and connected to the SIP server, tries to establish the call. If iOS allows it, it establish the call and the communication happens. The app, however, freeze again and thus the call progress, the states and listeners doesn't. What is the result of this? The callee doesn't get notified when the caller hangs up, doesn't receive SIP messages or other important tasks cannot get executed.

Once I hang up, the app resumes and the events that happened during the call are lost.

So, to wrap things up: The javascript container gets executed and the app is ready, but something is freezing the app blocking it from progress normally (since 17.5, this is important).

Every time it freezes and stop the code I see the "Invalidating grant <invalid NS/CF object> failed"

Cheers,
Borja.

[seoplague]

@mattkhaw @Qvadis the problem was solved after updating IOS to 17.6.1.

[Qvadis]

@seoplague I'm experiencing the same. Do you see the invalid grant message gone as well?

EDIT: Something changed because with the app store app it seems to be working (I've made 10 tests, gotta test it more) but with the development app still the same :S

[seoplague]

@Qvadis The invalid grant message did not disappear. But the sip socket remains connected and everything is working.