[quote='878946022, DTS Engineer, /thread/817976?answerId=878946022#878946022'] The ACTUAL enforcement mechanism is a second check in callservicesd that happens a few seconds (~7s) after the push is delivered to your app. [/quote] If I display CallKit immediately after receiving the callback, and then the function returns, but the call ends within 7 seconds, will the second check be considered a misuse? [quote='878946022, DTS Engineer, /thread/817976?answerId=878946022#878946022'] First off, my major question would be why are you doing this? [/quote] We did this for two reasons: 1.Using VoIP + CallKit ensures call arrival rates while allowing users to easily answer calls from the lock screen. 2. Keeping the custom in-app call UI in the foreground and disabling CallKit gives users the ability to switch network nodes, improving call quality when the network is poor. But now I understand, we can keep both CallKit and the custom in-app call UI. The custom in-app call UI provides network node switching capabilities, while CallKit provides call control capabilities, right? [quote='878946022, DTS Engineer, /thread/817976?answerId=878946022#878946022'] Yes, it should reset every ~24 hours. However, keep in mind that ALL of these issues should be treated as failures in your app you need to fix. There's no reason a properly implemented VoIP app should EVER crash for failing to report a call. [/quote] However, several of our users have reported that they haven't received any VoIP calls in the background for over six months, and the VoIP restrictions haven't been reset after 24 hours. What could be the reason for this? (These users don't make too many calls, only 1-2 per week.)

Additional questions: 1. What does “timely” handling of VoIP pushes mean? After receiving a VoIP push in: -(void)pushRegistry:(PKPushRegistry *)registry didReceiveIncomingPushWithPayload:(PKPushPayload *)payload forType:(PKPushType)type withCompletionHandler:(void (^)(void))completion; If the app does not promptly present a CallKit incoming call or does not call the completion handler in time, it may be considered a violation. My questions are: What exactly counts as “timely”? Does CallKit need to be reported within the same runloop, or within a specific time window (for example, within 1 second)? Does the completion handler also have a similar timing requirement? 2. Cold launch delay When the app is not running, a VoIP push will cause the system to launch the app before calling didReceiveIncomingPushWithPayload. If the app launch process is slow, there may be a long delay between app launch and the push callback. Could this delay potentially cause the system to treat the push as improperly handled, resulting in a VoIP push restriction? 3. Ending CallKit quickly when the app is in the foreground When the app is already in the foreground, our current flow is: Receive VoIP push Report the call to CallKit After a very short delay (around 0.5 seconds), programmatically end the CallKit call Present the custom in-app call UI Could this behavior potentially be considered misuse of VoIP push or CallKit by the system? 4. Recovery after VoIP push restriction If the system determines that the app has violated VoIP push rules and VoIP pushes stop arriving, the only workaround we are currently aware of is: The user uninstalls and reinstalls the app Are there any other ways to recover from this state while preserving user data? Also, if the user does nothing, will the system automatically remove the restriction after some time? Thanks!