iOS App not able to get VoIP push notification when device is powered on, After opening App VoIP push receiving

Question

Created 2w

Replies 3

Boosts 0

Participants 2

When User restarted iOS device, after powering on iOS App is not able to get VoIP push notification. If user opens App, immediate VoIP push receiving.

In Normal (App Kill or Background state) everything works as expected. Issue is when device is powered on and immediately( In 1-2 mins) try to call on device.

We are using delegate to show Call to User

public func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void)

Answered by DTS Engineer in 851374022

Before unlocking device - here understood as caused by device security as first authentication for device yet to be done after restart and device might not have an active network. In our case we can see 4G network symbol is shown on locked device screen.

After unlocking device - in this case we can see network symbol 4G is shown on device but still waiting for up to 1/2 minutes App is not receiving VoIP push notification. If User opens App after 1/2 minutes then immediately App is getting VoIP push callback and App showing incoming call popup. In between Caller ends the call and incoming call popup become ghost call.

What you're describing above are "user level" failures. That is, something did not work the way the user "thought" it should. As a practical matter, that kind of failure doesn't tell you ANYTHING about what's actually going "wrong". The next step here is to figure out what actually happened at the system level, then decide how to fix it. Critically, during that process it's very important that you simply focus on finding out what happened, NOT guessing/speculating on what you think the problem might be.

Case in point:

If you guide or provide some more input on these two points about factors which are considered when push is sent from APNS to device, it will help to understand the issue.

The basic assumption you're making here is that the reason the call didn't ring is that the push did not reach the device when it should have. My experience has been that this simply is not true. More specifically, having investigated many "why didn't my VoIP push arrive" reports across 10+ years, here is the broad list of reasons from most to least common:

The VoIP push did arrive but delivery failed due to bugs in the app.
The VoIP push did NOT arrive because the device did not have a functioning network interface at the time the push was sent.
The VoIP push did NOT arrive because of an issue with the WiFi network disrupting the push connection.

That's the entire list. In terms of other failures, I have seen a few cases where bugs on our side caused the app to fail; however, all of those failures occurred AFTER the push had reached the device, and all of them involved unusual call patterns (notably, stress testing by ending/reporting calls every few seconds for hours at a time).

In your particular case, I'd also exclude 2 & 3 from that list unless there is something extraordinarily rare/unusual about your particular cellular configuration. I've never seen push fail over cellular, primarily because:

We work with our cellular partners to ensure that their networks properly manage the push delivery connection.
The push delivery connection is SO low bandwidth that it's basically guaranteed that "everything else" will fail before the push channel does.

Your input in this case will really help to understand such scenarios. Appreciate your time, looking forward to hearing from you.

Given that you're testing on cellular, then I think the problem is with your app. That's what I listed as #2 in this post:

...
The push DID reach the app, but the app failed to work properly. Exactly WHY it failed is also quite variable, but a few common cases are:

The app assumes the user will always log in when the app launches, which breaks when the app is launched into the background.
The app assumes data will be available when it isn't, particularly in the case where the app is relaunched on a locked device immediately after reboot ("Prior to first unlock").
The app does NOT in fact immediately report every incoming call to CallKit as the API contract requires.

The one thing I'd add to that list is that previous call failures like the ones above mean that callservicesd has stopped launching your app at all. You can reset this by deleting your app and reinstalling it. Note that this "stop launch" is what can cause this behavior:

If User opens App after 1/2 minutes, then immediately App is getting VoIP push callback and App showing incoming call popup.

What happens is that the push was queued for delivery to your app over XPC, but the app launched was bypassed (because your app had already failed too many times). Those queued messages are then delivered when the app is later launched.

On the investigation side, the best approach is to reproduce the issue, collect a sysdiagnose, and then go through the console log archive to find out what actually went wrong. This forum post is a good example of what that kind of analysis looks like, but the basic "flow" for this process is:

Use the time button in the bottom left of Console.app to narrow the time range to whatever time frame the failure you’re looking for actually happened.
Narrow the list to just callservicesd.
Find the time the failure occurred and "see what happened".

The process from there depends on what you'll find, but I suspect you'll find that your app is not being launched because it failed to report too many times and/or is crashing/failing for one of the reasons I listed above.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

2w

When a user restarts an iOS device, after powering on, the iOS app is not able to receive VoIP push notifications. If the user opens the app, there is immediate VoIP push reception.

First off, has the user unlocked their device, or are you still "prior to first unlock"?

The issue here is that VoIP app launches prior to first unlock are not entirely consistent. That can and will happen (so you need to be prepared for them), but there are also cases where it won't happen for reasons entirely external to your app. See this forum post for one example of this issue.

Setting aside that special case, every pushKit delivery failure I've ever investigated has been caused by one of the two cases described here.

*This is actually true of the prior to first unlock case, as most of those are caused by device security that meant the device didn't have a working network connection.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

1

Answer 2

abhijeetAvaya OP

2w

@DTS Engineer, Thanks Kevin for attention and reply on this issue.

We are facing this issue in both case after power on -

before unlocking device - here understood caused by device security as first authentication for device yet to done after restart and device might not have active network. In our case we can see 4G network symbol is shown on locked device screen.
After unlocking device - in this case we can see network symbol 4G is shown on device but still waiting for up to 1/2 minutes App is not receiving VoIP push notification. If User opens App after 1/2 minutes then immediately App is getting VoIP push callback and App showing incoming call popup. In between Caller ends the call and incoming call popup become ghost call.

If you guide or provide some more input on this two point about factors which are considered when push is sent from APNS to device, will help to understand issue.

Your input in this case will really helps to understand or such scenarios. Appreciate your time, looking forward to hearing from you.

0

Answer 3

DTS Engineer OP

Apple

1w

Recommended

Before unlocking device - here understood as caused by device security as first authentication for device yet to be done after restart and device might not have an active network. In our case we can see 4G network symbol is shown on locked device screen.

After unlocking device - in this case we can see network symbol 4G is shown on device but still waiting for up to 1/2 minutes App is not receiving VoIP push notification. If User opens App after 1/2 minutes then immediately App is getting VoIP push callback and App showing incoming call popup. In between Caller ends the call and incoming call popup become ghost call.

What you're describing above are "user level" failures. That is, something did not work the way the user "thought" it should. As a practical matter, that kind of failure doesn't tell you ANYTHING about what's actually going "wrong". The next step here is to figure out what actually happened at the system level, then decide how to fix it. Critically, during that process it's very important that you simply focus on finding out what happened, NOT guessing/speculating on what you think the problem might be.

Case in point:

If you guide or provide some more input on these two points about factors which are considered when push is sent from APNS to device, it will help to understand the issue.

The basic assumption you're making here is that the reason the call didn't ring is that the push did not reach the device when it should have. My experience has been that this simply is not true. More specifically, having investigated many "why didn't my VoIP push arrive" reports across 10+ years, here is the broad list of reasons from most to least common:

The VoIP push did arrive but delivery failed due to bugs in the app.
The VoIP push did NOT arrive because the device did not have a functioning network interface at the time the push was sent.
The VoIP push did NOT arrive because of an issue with the WiFi network disrupting the push connection.

That's the entire list. In terms of other failures, I have seen a few cases where bugs on our side caused the app to fail; however, all of those failures occurred AFTER the push had reached the device, and all of them involved unusual call patterns (notably, stress testing by ending/reporting calls every few seconds for hours at a time).

In your particular case, I'd also exclude 2 & 3 from that list unless there is something extraordinarily rare/unusual about your particular cellular configuration. I've never seen push fail over cellular, primarily because:

We work with our cellular partners to ensure that their networks properly manage the push delivery connection.
The push delivery connection is SO low bandwidth that it's basically guaranteed that "everything else" will fail before the push channel does.

Your input in this case will really help to understand such scenarios. Appreciate your time, looking forward to hearing from you.

Given that you're testing on cellular, then I think the problem is with your app. That's what I listed as #2 in this post:

...
The push DID reach the app, but the app failed to work properly. Exactly WHY it failed is also quite variable, but a few common cases are:

The app assumes the user will always log in when the app launches, which breaks when the app is launched into the background.
The app assumes data will be available when it isn't, particularly in the case where the app is relaunched on a locked device immediately after reboot ("Prior to first unlock").
The app does NOT in fact immediately report every incoming call to CallKit as the API contract requires.

The one thing I'd add to that list is that previous call failures like the ones above mean that callservicesd has stopped launching your app at all. You can reset this by deleting your app and reinstalling it. Note that this "stop launch" is what can cause this behavior:

If User opens App after 1/2 minutes, then immediately App is getting VoIP push callback and App showing incoming call popup.

What happens is that the push was queued for delivery to your app over XPC, but the app launched was bypassed (because your app had already failed too many times). Those queued messages are then delivered when the app is later launched.

On the investigation side, the best approach is to reproduce the issue, collect a sysdiagnose, and then go through the console log archive to find out what actually went wrong. This forum post is a good example of what that kind of analysis looks like, but the basic "flow" for this process is:

Use the time button in the bottom left of Console.app to narrow the time range to whatever time frame the failure you’re looking for actually happened.
Narrow the list to just callservicesd.
Find the time the failure occurred and "see what happened".

The process from there depends on what you'll find, but I suspect you'll find that your app is not being launched because it failed to report too many times and/or is crashing/failing for one of the reasons I listed above.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0