We ship a Live Caller ID Lookup extension (PIR-based) for spam call blocking. It works, and our PIR server is fast. But in practice, whether a call gets blocked depends on the quality of the user's internet connection at the moment the call arrives. The system waits only about 1 second for the blocking response. On a fast, stable connection it arrives in time. On an average or unstable connection it often doesn't, and the spam call rings through. So under the current platform limits we cannot guarantee blocking for every call.
How we measured
- For each call we read the device syslog (CommCenter, CallDirectory, ciphermld, callservicesd) and our server logs.
- The extension cache was reset before each call, so every call triggered a real network lookup.
- All times are in ms and measured from addNewIncomingCall.
Server-side processing of the PIR query was consistently 51–61 ms. The variance is almost entirely network transfer between the device and the server (or relay):
- In call D, HTTP/2 metrics show the ~28 KB request was handed to the network stack immediately (outbound_duration_ms=0), but response headers arrived only after 2216 ms.
- In call E, the device waited ~660 ms between finishing the upload to the relay and receiving the first byte of the response.
- Connection setup on a new connection cost 176–271 ms (DNS + TCP + TLS, or a QUIC handshake to the relay).
- Before the first byte was sent, the system spent another 54–225 ms after the call arrived.
In the failing cases the syslog shows:
CallDirectory: not all blocking fetches returned within 1 second(s) callservicesd: shouldBlock: NO shouldSilence NO
The block response (shouldBlock=1) then arrives 100–1500 ms too late, and the call keeps ringing.
What works: repeat calls
After the first lookup the result is cached on the device. A repeat call from the same number is silenced without contacting the server, whatever the connection speed. In our logs, follow-up calls from the same number were silenced within ~65 ms of addNewIncomingCall, with no network request. So a user may get the first spam call from a number but not the next ones. The first call, though, is exactly the one users complain about.
The problem with the 1-second budget
Each blocking lookup has to:
- Send a PIR query
- Receive a response of ~22–25 KB.
- Often open a new TLS/QUIC connection through the OHTTP relay.
All of this has to fit into about 1 second, together with the system's own overhead before the request is sent. On a good connection that takes about 250–650 ms. On an average mobile or congested Wi-Fi connection it easily goes past 1 second, and nothing the developer can optimize on the server helps. Our server already responds in about 50 ms.