Live Caller ID Lookup Identity tag not displayed: Suspecting a limit issue

[Alan-Cheng]

Hello Apple team and @karulont ,

We are currently operating our own OHTTP gateway, and it successfully forwards requests to our PIR service endpoints — including /config and /queries.

Our PIR service can complete the entire verification and query process correctly when accessed directly. However, when the request goes through Apple’s OHTTP relay, the caller ID on the iPhone cannot be displayed properly.

We suspect this might be caused by the response size limit described in the earlier discussion:
👉 apple/pir-service-example#111 (comment)

🔍 Current Behavior
When accessed directly (without OHTTP), everything works correctly — our PIR service completes the full verification and query process as expected.

In our initial application form for OHTTP relay access, we specified a request size of around 5 KB and a response size of around 3 KB, which now appears to be too small.

Based on our latest observations, the actual /queries responses are typically around 30 KB or larger, which might be exceeding the configured limits and causing the issue.

Could you please help verify or adjust the configured request and response size limits that were set when we initially applied for OHTTP relay access?
We would like to update both the request and response size limits to 50 KB.

[karulont]

I have filed a request to get the limits changed.

[Alan-Cheng]

Hello @karulont ,

Thank you for filing the request to change the limits.

While waiting for the limit adjustment, we've gathered further diagnostic information from the iOS device's execution logs, which might help you pinpoint the issue on the Apple Relay side.

Our OHTTP Gateway and PIR Service logs both show that they are returning normal, successful responses to the Apple OHTTP Relay. However, the feature still fails to work on the iPhone.

The following error messages are consistently appearing in the iOS Call Directory extension logs, indicating a failure within the Apple ecosystem after the response is sent from our services:

預設	09:37:46.635890+0800	com.apple.CallKit.CallDirectory	requestDataByKeywords:shardIds:completionHandler: XPC request complete, results(0) error:Error Domain=CipherML.CipherMLError Code=8 "server error (Unknown server error.)" UserInfo={NSLocalizedDescription=server error (Unknown server error.)}
預設	09:37:46.635947+0800	com.apple.CallKit.CallDirectory	[0x72b086800] invalidated because the current process cancelled the connection by calling xpc_connection_cancel()
預設	09:37:46.636194+0800	com.apple.CallKit.CallDirectory	sending action: <private> payload: <private>
預設	09:37:46.636219+0800	com.apple.CallKit.CallDirectory	received Data useCase: <private>
預設	09:37:46.636310+0800	com.apple.CallKit.CallDirectory	block data = (null)
預設	09:37:46.636321+0800	com.apple.CallKit.CallDirectory	error = Error Domain=com.apple.CipherML Code=400 UserInfo={NSLocalizedDescription=<private>, NSUnderlyingError=0x72a830690 {Error Domain=CipherML.CipherMLError Code=8 UserInfo={NSLocalizedDescription=<private>}}}

This error: Error Domain=CipherML.CipherMLError Code=8 "server error (Unknown server error.)" accompanied by a Code=400 in com.apple.CipherML seems to be the direct cause of the feature failure, but it does not provide a detailed root cause (like an explicit "size limit exceeded" message).

Given that our services show success, do these errors suggest that the failure is occurring within the Apple OHTTP Relay (e.g., the relay failed to process/forward our response, perhaps still due to the existing size limit), or somewhere in the subsequent processing on the Apple infrastructure before the result reaches the CallKit extension?

Any insight you can provide on this specific error sequence would be greatly appreciated!

[karulont]

Check the iOS logs for subsystem:com.apple.cipherml. It might offer more clues.
But this does look like the response size limit issue on Apple's OHTTP Relay.

[Alan-Cheng]

Thanks for the suggestion — we’ll check the com.apple.cipherml subsystem logs on the iOS device as you recommended to gather more details.

Meanwhile, could you please let us know how long it typically takes for the new request/response size limits to take effect once the change request is approved?

Also, we’d like to clarify one thing:
When we first applied for OHTTP relay access, we specified a request size limit of 5 KB and a response size limit of 3 KB, but in practice both our request and response payloads are larger than 25 KB.
Despite that, our OHTTP Gateway is still receiving the forwarded requests from Apple’s OHTTP Relay without issue — which seems to suggest that the relay may only enforce limits on response size, not on request size.

Just to confirm — does Apple’s OHTTP Relay enforce size limits on both request and response payloads, or only on the response side?

[Alan-Cheng]

We checked the subsystem:com.apple. The key errors repeatedly show an upstream failure during Live Lookup queries:

Critical Errors from ciphermld Logs

1. HTTP 502 Bad Gateway: The API endpoint is returning a direct server error when attempting to query.

錯誤 09:37:46.633155+0800 ciphermld Failed to query. { URL: https://osbstage.twmsolution.com/pir/queries } { Status Code: 502, Headers { ... "proxy-status" = ( "error=proxy_internal_response" ) } }

2. Request Size Confirmed: Just before the 502, the request length is logged as length: 28364. This confirms the large request size is successfully reaching the service, further questioning the OHTTP Relay request limit enforcement.

預設	09:37:46.192951+0800	ciphermld	Request to queries-batch has started for userId: '<private>', length: 28364
預設	09:37:46.192964+0800	ciphermld	Request to queries-batch has started for userId: '<private>', length: 28361
預設	09:37:46.632862+0800	ciphermld	Request to queries-batch has finished response, length: 0

3. Configuration Warning: We also noted a recurring configuration warning:

錯誤 09:36:32.499625+0800 ciphermld Configuration missing for usecase 'com.taiwanmobile.OpScamBuster.LiveCallerIDLookupExtension.identity'

The 502 Bad Gateway highly suggests an issue on the service endpoint itself, possibly due to the large payload size. Your clarification on the OHTTP Relay's size limit enforcement (Request vs. Response) remains critical.

[karulont]

I believe the problem is still the OHTTP relay's size limit enforcement.
Unfortunately, the request to update the limits did not make much progress while I was away.

[Alan-Cheng]

Thanks for the update!
This feature is quite critical for our app development, so the current size limit is slowing us down.
Would it be possible to prioritize the limit update?
Let us know if we can help in any way. Thanks again!

[Alan-Cheng]

Hi @karulont — just checking in on this.

Since the request/response size limit is still blocking our Live Lookup feature in production, we want to ensure this remains on the radar.

Do you happen to have any update on the limit increase schedule, or is there anything we can provide to help move this forward?

Really appreciate your support!

Thanks,
Alan

[karulont]

Hi, thank you for checking in on this.

I do not know when the limits will be updated, but I have ensured that it is still on our radar.