APNS notifications of apns-push-type pushtotalk sometimes stop arriving after switching networks

The best course of action on this would be to file a Feedback report, include detailed info, logs and sample code or models that reproduce the issue, and post the FB number here once you do.

Bug Reporting: How and Why? has tips on creating a successful bug report.

Please go to https://developer.apple.com/bug-reporting/profiles-and-logs/ and follow the instructions for APNs for iOS to install a logging profile on your device. Then reproduce the issue, and follow the instructions at the above link to create a sysdiagnose. And attach that to the Feedback report as well.

Use the following test procedure:

• mark the time/date with time zone (we need that info)
• turn off WiFi and Cellular (Airplane mode)
• Turn everything back on, wait to connect to WiFi
• mark the time/date with time zone when device connects to WiFi
• send a push that will be delivered
• mark the time, and let us know the push token and apns-id
• continue with your test steps, by turning off WiFi
• mark the time
• turn on cellular and mark the time it connects
• confirm connection by browsing to https://apple.com
• send a push that will fail and mark the time and apns-id
• if you get "device is offline" immediately confirm by browsing to https://apple.com and mark the time

ASAP after this create the sysdiagnose following the instructions at the above link and attach it to the Feedback report along with all the detailed info in the above test steps.

Once the FB is filed, post the FB number here and @ tag me

So, the first place I'd start here is the console log data here:

Delivery LogLast updated:
 30/01/25, 16:45:06 GMT+13 Refresh
30 Jan 2025, 16:45:03.661 GMT+13
received by APNS Server

30 Jan 2025, 16:45:03.662 GMT+13
discarded as device was offline

What "offline" here means is "the device did not have a working connection to our push server". WHY that was the case isn't something I can easily answer, but the direct cause isn't really something I can dispute.

Related to that point:

The device is actually very much online.

Are regular pushes working? What about standard pushes to your app (instead of PTT pushes)?

Similarly:

Switching networks again oftern makes things come right. But it doesn't seem to come right by itself.

Switching to what network? Cellular to WiFi? Or the other direction? The biggest oddity here is that you're failing on cellular, as the VAST majority of push delivery problems are tied to local network configuration problems.

Some other questions here:

• I assume that the PTT is active when you're in the background? By design, PTT pushes only work while your app's channel is active

• What happens if you foreground your app?

• If it works when your app is foregrounded, completely delete your app from the iPhone, reinstall it, and then test again. PTT apps have similar reporting requirements as CallKit and will also stop delivery if you fail "to often". The API structure means that this is much harder to do, but it can happen on development devices if you crash to often or have other failures.

• Have you collected a sysdiagnose of the failure? What does that log show?

Finally, a clarification here:

We can't respond to network changes and do anything as the whole point of using push-to-talk push notifications is to wake up the app when in the background to answer a call, this means we are not running and therefore cannot respond to network changes to try to work arround this issue.

Just like voip apps using PushKit, your app doesn't really have ANY role in addressing reliability. The goal of using apns here is to make maintaining this network connection the systems responsibility, NOT your apps.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

So, the first point is here:

Are regular pushes working? What about standard pushes to your app (instead of PTT pushes)? Regular pushes have the same problem.

If regulare pushes are failing to reach the device, then this is no longer an app level issue. It could be an issue with the network, an issue with the push side itself, or a mix of both, but it isn't something your app will have be able to do anything about. More to the point, most of these issues aren't really "fixable" in any meaningful sense, particularly on WWAN.

In any case, looking at your sysdiagnose:

Have you collected a sysdiagnose of the failure? Yes I have collected a sysdiagnose and have attached it to the feedback assistant issue.

From the log data, I see two issues. The "indirect" cause is that your cell connection was not good:

2025-02-03 15:32:40.350567+1300  <PCInterfaceUsabilityMonitor: 0x5542de300> Interface Manager: WWAN(pdp_ip0) LinkQuality changed from unknown to good (100)
2025-02-03 15:33:41.628638+1300  <PCInterfaceUsabilityMonitor: 0x5542de300> Interface Manager: WWAN(pdp_ip0) LinkQuality changed from good to poor (50)
2025-02-03 15:34:13.641619+1300  <PCInterfaceUsabilityMonitor: 0x5542de300> Interface Manager: WWAN(pdp_ip0) LinkQuality changed from poor to good (100)
2025-02-03 15:34:41.136569+1300  <PCInterfaceUsabilityMonitor: 0x5542de300> Interface Manager: WWAN(pdp_ip0) LinkQuality changed from good to poor (50)
2025-02-03 15:35:32.247051+1300  <PCInterfaceUsabilityMonitor: 0x5542de300> Interface Manager: WWAN(pdp_ip0) LinkQuality changed from poor to good (100)

Your test occurred during a "good" window, however, keep in mind that these notifications have significant lag and transitions like this generally indicate significant connection problems.

However,the direct cause was that the development push link came up ~2 minutes after the production link:

-Both links down:

2025-02-03 15:32:35.222678+1300 APSUserCourier <APSCourierConnectionManager: 0x104bb9920; production> adjusting connection. Connected on 1 interfaces. Current link quality: wwan is off; wifi is off
2025-02-03 15:32:35.223001+1300 APSUserCourier <APSCourierConnectionManager: 0x104bb89a0; development> adjusting connection. Connected on 2 interfaces. Current link quality: wwan is off; wifi is off

-Production link up:

2025-02-03 15:32:40.356696+1300  APSUserCourier <APSCourierConnectionManager: 0x104bb9920; production> adjusting connection. Connected on 1 interfaces. Current link quality: wwan is good; wifi is off

-Development link up:

2025-02-03 15:34:25.509916+1300 APSUserCourier <APSCourierConnectionManager: 0x104bb89a0; development> adjusting connection. Connected on 2 interfaces. Current link quality: wwan is good; wifi is off

WHY that occurred is not a question I can answer. It's possible it was a side effect of the poor connection or there may be another factor I've overlooked. I'm looking into that cause, however, I don't think the answer will be actionable within your app.

Finally, on this point:

Not sure why this one actually got stored and delivered but 2 1/2 minutes late: 15:35:48

This is actually a VERY long standing disconnect between how the apns server processes messages and how callservicesd/PushKit deal with them. Basically, if the push server "queues" a message for delivery but is unable to deliver it, that push may end up being delivered well after it's expiration. Historically, that hasn't really been an issue but the relatively recent CallKit/PTT requirements make it much more problematic.

In any case, please file a separate bug about voip/PTT being delivered "well" after expiration and post that number back here. This is the first time it's come up with the PTT framework and that makes it a good time to revisit this issue.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware