APNs VoiP Push Delivery Speed

Question

Created 1d

Replies 2

Boosts 0

Participants 3

We have an app that uses PushKit and CallKit for video calling. These are often emergency calls, so very latency-sensitive.

We keep track of when we sent out the APNs request and when the phone started ringing. The p95 latency is about 2 seconds (mean is ~800ms), which feels quite long..

Is this normal? I'd expect <500ms most of the time given that the devices and servers are all within the US. The users typically have a stable internet connection.

Our requests look like this:

POST https://api.push.apple.com/3/device/<DEVICE_TOKEN>

apns-topic: com.vpt.physician.voip
apns-push-type: voip
apns-priority: 10
apns-expiration: 0
authorization: bearer <APNS_PROVIDER_TOKEN>
content-type: application/json

{
  "aps": {
    "content-available": 1
  },
  "title": "Example Text",
  "type": "CallFromTablet",
  "timeout_ms": 30000
}

If there's any more info I can provide to help troubleshoot this, let me know. Thanks in advance.

Boost

Answer 1

Engineer OP

Apple

23h

I should first remind you that APNs does not have an SLA, and is considered a best-effort service. So for mission critical applications, it would be up to you to decide whether it is suitable for your use case or not.

That said, under regular circumstances, the time for processing and sending out the push is expected to be within your own expected values, but outside the gate of APNs, we have no control over what happens.

The factors that add to the round-trip time would be:

aggregation time: the time it takes for your complete request and payload to be read in
processing time: the time within APNs to process your request, and send out the push
reception time: is the time it takes for the push to be received by the device
device processing time: while should be trivial, if we are starting to count milliseconds, then it needs to be considered. Also, I don't know how you are timing this, and whether the content-available flag means you are timing this within the app - which would add all sorts of time delays depending on your app's state.

So, while I believe the delays you are seeing is caused by the network, we can check what exactly has happened to a push that was unduly delayed.

If you can provide me with the following information for a delayed push:

the apns-id
time your server logged the request including the time zone
time you logged the receipt, and the method of this logging

Please provide a sample within the last couple of days, and @mention me in your response so I can get to it before our server logs roll.

0

Answer 2

DTS Engineer OP

Apple

19h

Argun's covered the specifics of the APNs itself fairly well, but I do have some general comments based on my own experience with VoIP:

We keep track of when we sent out the APNs request and when the phone started ringing. The p95 latency is about 2 seconds (mean is ~800ms), which feels quite long.

A few things to be careful/aware of about gathering and analyzing this kind of data:

Your app can end up receiving VoIP pushes LONG after (minutes and even hours) after they would have expired, which can and does completely distort any kind of statistical analysis. These delays are essentially "always" caused by network-level issues making the device unreachable, so they need to be thought of as a separate edge case outside of "normal" call latency.
Note that we specifically introduced a new delegate method to help your app deal with these kinds of delays. If you're not using it already, you should be. See this post for more details.
Make sure you're accounting for delays within your own app, particularly app launch time. I've seen apps take 2s+ to launch into the background and, even worse, I've seen VoIP apps where most of that time was in pre-main initialization, which ended up "hiding" their actual launch time from their own analysis.
Many developers are concerned about on-device delays (time between the push reaching the device and the push reaching the app) but, in my experience, this factor is essentially irrelevant. The time itself is fairly constant (well below 0.1s) and, more importantly, I've never seen any case where apnsd or callservicesd "delayed" a push in any meaningful way. That is, once a push reaches the device, any delay or failure I've ever seen has been caused by the app itself, not the system.

Having said that:

Is this normal?

...yes, I'd consider 2s to be well within the "normal" range. Historically, my rule of thumb was to expect ~4s of latency, but it's been a while since I actively tested it and I suspect network improvements have driven that number down somewhat.

Our requests look like this:

I don't know why you've included "content-available", but I wouldn't include it in a VoIP push. It's not necessary in a VoIP push (VoIP pushes are "inherently" invisible), so you're basically just wasting payload. More importantly, if something were to go wrong and you started sending VoIP pushes as standard pushes AND those pushes somehow reach the device in a deliverable state, then it would be better to show "something" (so you'd realize there was a problem) instead of having them fail invisibly.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0