Regarding the key differences between the logs of PID 405 and the logs mentioned above, it appears that they demonstrate the results of repeated each incoming call tests performed after the app was launched. For more details, I have uploaded VID_20250407_111252.mp4 to FB17345744. Please refer to it. As you can see in VID_20250407_111252.mp4, I made five outgoing call attempts (incoming calls on the test device) when I obtained "FjSoftPhone-2025-04-07-1113XX.ips." Based on the iPhone's time display, these operations occurred around 11:12-11:13 (around 0:00:00-0:00:52 in the video timestamp). I believe that 0xBAADCA11 occurred during the first, second, and third incoming calls, and the fourth and fifth incoming calls were ignored. Finally, when Wi-Fi was turned OFF (around 0:01:14 in the video timestamp), the app detected the incoming ghost call with a delay (around 0:01:19 in the video timestamp). Here's a summary of the operations and their timestamps: [Operation Time][Video Timestamp][Operation] [04/07 11:12] [0:00:02] [Caller: Make call (1) ] [04/07 11:13] [0:00:16] [Caller: Make call (2) ] [04/07 11:13] [0:00:28] [Caller: Make call (3) ] [04/07 11:13] [0:00:40] [Caller: Make call (4) ] [04/07 11:13] [0:00:52] [Caller: Make call (5) ] [04/07 11:14] [0:01:14] [Callee: Wi-Fi OFF ] [04/07 11:14] [0:01:19] [Callee: Accept ghost call] I Wrote the app's operation sequence in "BAADCA11.jpg"( attachment file of this incident). Could you please review this sequence and let me know if there are any deficiencies in the app's processing? linkText

The direct cause of the crash is that your app never registed a PushKit handler with callservicesd. You can confirm this by searching for the string "Registering client process" logged by callservicesd. Here is what's logged by an early run of your app (pid=405): The application log shows that the following operations were performed at the following times. What else should the app do to register a PushKit handler with callservicesd? time:04/07 11:10:50.666 operations: dispatch_queue_t mainQueue = dispatch_get_main_queue(); // Create a push registry object voipRegistry = [[PKPushRegistry alloc] initWithQueue: mainQueue]; // Set the registry's delegate to self voipRegistry.delegate = self; // Set the push type to VoIP voipRegistry.desiredPushTypes = [NSSet setWithObject:PKPushTypeVoIP]; Reference sample source: https://developer.apple.com/documentation/pushkit/pkpushregistry?language=objc ...my recommendation is that voip apps should create their basic call handling "infrastructure" as early as possible (typically, applicationDidFinishLaunching) AND that the "core" component should be able to FULLY process a call without ANY of the rest of your app functioning at all. I understood this advice to mean that when you receive a push signal, you should end the push signal reception process in your app as quickly as possible. In this specific incident, the app is not receiving a push signal, so it cannot end the push signal reception process in the app as quickly as possible. Did this advice mean something different?

Thank you for your response. Have you looked at exactly what happens when your app launches in that configuration? I don't see how this would change the systems routing for pushes, but I could see it distorting your apps own network logic. Are you asking about the behavior of the app when WiFi is ON (when it crashes)? I have checked exactly how the app works when WiFi is ON (when it crashes). Application life sycle didn't start when it. iOS didn't call application after push. I haven't checked exactly how the app works when Wi-Fi is OFF, because there are no problems. Also, how is the app being distributed to the device? I do not that there are extra verification steps for enterprise apps and, in theory, it's possible that issues with that verification process could delay the app launch long enough that callservicesd then terminates the app. This application is distributing via App Store(And I tested TestFlight version). You can either file a bug and post the number back here, or you can file a code level support request and send them through email. I reported(and attached logs) about this to Feedback assistant. Number is FB17345744. Would you take a logs from above report?

An app setup like this will work fine under basic testing because the developer/user habitually logs in as soon as they open the app. However, it will be terminated under real world conditions when the system or the user kills the app. The system correctly launches the app into the background, then terminates it because the app is blocked at #1 and has not created a PKPushRegistry object. The crash at step 8 of [Operation] in the initial explanation only occurs when implementing sXGP-SIM. There is no problem when using LTE-SIM(with the same operation perfectly.) If Wi-Fi is enabled when the LTE-SIM is implemented, the crash that in step 8 of the [Operation] in the first explanation will not occur 100%. If Wi-Fi is enabled when the sXGP-SIM is implemented, the crash that in step 8 of the [Operation] in the first explanation will occur 100%. In other words, the problem is not occurring because there is a difference in the app's executing route when a push message is received after the developer/user opens the app and when a push message is received after the app is terminated. What does that crash log show? I'm happy to take a look if you post the log, but my guess is that it will show one of three things: my crash log was below. code:0xBAADCA11 explanation: Is there a way to send the logs other than uploading them directly here? If not, I would like to refrain from uploading logs that include the app name to a public site, Is it okay if I hide(Change the app name to ***, etc.) the app name in the logs? my recommendation is that voip apps should create their basic call handling "infrastructure" as early as possible (typically, applicationDidFinishLaunching) AND that the "core" component should be able to FULLY process a call without ANY of the rest of your app functioning at all. I see your point. We understand that my app needs to be processed as quickly as possible. However in my case, app doesn't get first entry(didReceiveIncomingPushWithPayload). So app can't do anythig...

I have opened FB16493124 in the feedback assistant regarding this issue. Could you please let me know at here also if you found something.

I feel your description describe about the Technical Support Incident from me(TSI:771875962). But I heard this probelm already fiexd in the TSI:771875962. If so, should we assume that the BAADCA11 problem fixed in iOS15 will reoccur in iOS17?(Or is this new problem??) When I was investigating this ticket before, I had set a restriction in my system to not accept the next incoming call within 7 seconds to avoid the problem, but should I reimpose the same restriction? Best Regards,

Hi Kevin Thank you for your kind reply. There was a mistake in my initial inquiry. I apologize. I will correct the mistake, so could you please check again? 11:00 AM: The PBX server requests a VoIP PUSH notification from APNs. The app was connected to the Internet, but did not receive VoIP PUSH. ** There was an error in the explanation here last time. ** It is unclear whether the iPhone was within the range of a network that could connect to the Internet or outside of it. It is certain that it is not connected to the LAN (Wi-Fi) at least. The extension is not working. The following are hypotheses. The APNs server was unable to send the VoIP PUSH to the iPhone. Or..., The VoIP PUSH reached the iPhone, but the delegate (didReceiveIncomingPushWithPayload) was not called. 14:31 PM: The iPhone connected to the LAN (Wi-Fi). The extension started working. 14:55:11 PM: A call comes in from my server (PBX) via the local network, and NetworkExtension calls the iOS API (API name is reportIncomingCall). However, iOS does not call the delegate didReceiveIncomingCallWithUserInfo for reportIncomingCall. 14:55:11 PM: At almost the same time, iOS calls the VoIP PUSH delegate didReceiveIncomingPushWithPayload. (Instead of calling the delegate didReceiveIncomingCallWithUserInfo for reportIncomingCall?) The content of this VoIP (APNs) PUSH was the 11:00 AM call. This is just my guess. It is unlikely that APNs notified the VoIP PUSH that occurred at 11:00 AM at 14:55:11 PM (due to processing delay). The 11:00 VoIP PUSH reached the iPhone, but got stuck inside iOS. At 14:55:11 PM, the extension called reportIncomingCall, which triggered the VoIP PUSH delegate didReceiveIncomingPushWithPayload to be called. We apologize for the confusion. Unfortunately, we were unable to obtain diagnostic logs and have not issued a bugreport. Could you please let us know if there is a known issue? Is there a possibility that this can be avoided by implementing it on the application side? Best Regards,

Just to clarify here, the system doesn't differentiate or attempt any kind of de-duplication or arbitration between VOIP pushes and the network extension. The voip push can fail to reach your device because the device is on an isolated network, but that's no different than any other failed voip push. You mean, the composition of iOS internal components, it is difficult to imagine that Local Push will be replaced by VoIP Push. Correct? The "11:00 AM:, 14:55:11 PM:, 14:55:11 PM:" events in my report are facts obtained from the logs of My App and our PUSH server. But I haven't looked at the iOS logs, so I may be misunderstanding something. Would a sysdiagnose be necessary to perform a more detailed analysis? However, at this time, I couldn't be collected sysdiagnose. **Do you need sysdiagnose? ** If the problem that occurs infrequently, it may be difficult to collect a sysdiagnose, but if you need it, I will try to collect it. In any case, the solution here is that voip apps should start their own background task inside the call delegate and end that background task at some later point, after the call has started. Note that this approach should be used for BOTH PKPushRegistry and NEAppPushManager, as it ensures the app has a reliable lifetime regardless of system behavior. Thank you for your advice. Don't worry about them. We already do.

I have one more question. [Quote from https://developer.apple.com/news/?id=09za8wzy] The Certification Authority (CA) for Apple Push Notification service (APNs) is changing. APNs will update the server certificates in sandbox on January 20, 2025, and in production on February 24, 2025. All developers using APNs will need to update their application’s Trust Store to include the new server certificate: SHA-2 Root : USERTrust RSA Certification Authority certificate. We are currently using the following certificate, which expires in 2028, but will this certificate be invalidated on February 24, 2025, instead of in 2028? [AAA Certificate Services Root (2028)] https://statics.teams.cdn.office.net/evergreen-assets/safelinks/1/atp-safelinks.html

Question 1 Do I need to update the server certificate of the Apple Push Notification Service at the following URL for the above provider server? URL https://developer.apple.com/jp/news/?id=09za8wzy Above was Japanese site. English site is here https://developer.apple.com/news/?id=09za8wzy Regarding the contents described here, does this mean that all incompatible apps around the world will no longer be able to push from this date onwards? At first, I couldn't believe this, so I asked this question. Also, if it is necessary to add a certificate to our push server, is the following an example of the command to add it correct? Am I correct in assuming that no other work is required? keytool -v -list -keystore /my-path/cacerts.jks

[QUESTION] Does the RVI interface provide real-time packet capture? I don't think that packet capture of RVI is done only at 1 second intervals, is this correct? PS. My customer says that when he does a packet trace on the RVI interface, there is a 1 second delay between the Mac and the iPhone (i.e. the Lightning cable), but I don't think that's possible. Am I right?

I confirmed point A(My App log) and PointD(RVI interface) of "Investigating Network Latency Problems". My App is sending packet with 20ms interval (To be precise, 15ms - 25ms, with an average period of 20ms). But RVI interface is recording packet with 1s interval. (Please refer png files in my comment before for detail) My App is using only BSD Sockets, and UDP for RTP packet. In addition I tested with Bluetooth OFF. [QUESTION] Does the RVI interface provide real-time packet capture? I don't think that packet capture of RVI is done only at 1 second intervals, is this correct?

Yes, my app is running RTP over UDP. NOTE I forgot to attach "Sending at 1 second intervals.png" "Receiving at 1 second intervals.png", so I'll attach it to this comment.

I have asked the customer to do unlock the iPhone as soon as it is turned on, and they are supposed to do so, but we have received additional questions about this behavior. Because APNs push and local push are mixed up in my logs, I am a bit confused and unable to answer the customer yet now. For this reason, I have separated APNs push and local push, and arranged the app and iPhone operations in chronological order. Looking at this, could you please answer the following three questions? [Question 1] If my arrange the app and iPhone operations in chronological order, they would look like this. Do you agree with me on this? [Question 2] In this log, should I suspect that the inability to receive APNs PUSH at point 5 is due to a network problem? There was no problem with the network, and the iPhone was not unlocked, so did it simply discard the PUSH received from the network? (From what I understand, I assume it's the latter.) [Question 3] I believe that the sysdiagnose log at points 8 and 10 is a log for local push incoming calls, but do you know why they are failing? ///////////////////////////////////////// For LOCAL PUSH INFO: point1(My app log info) Stop Extention (Moved to Wi-Fi out of area) 2024-08-08 19:34:16.813+0900 For APNS PUSH INFO: point2(sysdiagnose log info) An update had been installed and the device had not been unlocked. Note messages like: 2024-08-08 19:34:55.328+0900 routined[38:1637] [DATA PROTECTION] unlocked since boot, NO 2024-08-08 19:34:56.329+0900 atc[47:2598] [Default] Device locked, waiting for first unlock. 2024-08-08 19:34:58.530+0900 carkitd[153:2177] [DNDWD] Not fetching vehicle state - device has not unlocked since boot. 2024-08-08 19:34:59.066+0900 sharingd[68:3068] [AutoUnlock] ### Device not unlocked on start up after retry (state: <private>) 2024-08-08 19:35:00.546+0900 itunesstored[202:3664] [StoreServices] SSXPCServer: Invalidating connection; device has not been unlocked since boot For APNS PUSH INFO: point3(sysdiagnose log info) and then later 2024-08-09 09:27:25.112+0900 sharingd[68:1354] [PairedUnlock] Transitioned out of lock screen. 2024-08-09 09:27:25.112+0900 sharingd[68:1354] [PairedUnlock] Transitioned out of lock screen. For APNS PUSH INFO: point4(sysdiagnose log info) apsd launch, but is unable to register properly because of the protection state 2024-08-08 19:34:47.734+0900 apsd[134:1862] [xpc] Requesting container lookup; class = 12, identifier = <private>, group_identifier = <private>, create = 1, temp = 0, euid = 501, uid = 501 2024-08-08 19:34:47.734+0900 apsd[134:1862] [xpc] Query; euid = 501, uid = 501, class = 12, identifier = [(null)](0), flags = 900000003 2024-08-08 19:34:47.738+0900 apsd[134:1862] [unspecified] container_query_get_single_result: success 2024-08-08 19:34:47.738+0900 apsd[134:1862] [sandbox] Consumed sandbox extension; path = [<private>], handle = 1 2024-08-08 19:34:47.738+0900 apsd[134:1862] [unspecified] container_system_path_for_identifier: success 2024-08-08 19:34:47.754+0900 apsd[134:1862] [connectionServer] Attempt to set push wake topics without dark wake enabled: () 2024-08-08 19:34:47.761+0900 apsd[134:1862] [connectionServer] Attempt to set push wake topics without dark wake enabled: () 2024-08-08 19:34:47.766+0900 apsd[134:1862] [connectionServer] Attempt to set push wake topics without dark wake enabled: () 2024-08-08 19:34:47.770+0900 apsd[134:1862] [connectionServer] Attempt to set push wake topics without dark wake enabled: () For APNS PUSH INFO: point5(My push server log info) sent VoIP push 144 times. from 2024-08-08 19:56:25.046+0900 to 2024-08-09 09:27:01.206+0900 For LOCAL PUSH INFO: point6(My app log info) Start Extention (Moved to Wi-Fi in area) 2024-08-09 09:27:29.415+0900 For LOCAL PUSH INFO: point7(My app log info) My app log info: Incomming call 2024-08-09 09:54:39.209+0900 For LOCAL PUSH INFO??: point8(sysdiagnose log info) If you search for "failed to report", the cause is fairly clear. The messages occur in alternating pairs between callservicesd and nesessionmanager: 2024-08-09 09:54:39.235+0900 nesessionmanager[228:62692] [] NESMAppPushSession[LocalPushDefaultConfiguration:7EC72C65-84F2-4167-A654-11B9CEEE5953] failed to report incoming call to CallKit, error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.callkit.networkextension.messagecontrollerhost was invalidated from this process." UserInfo={NSDebugDescription=The connection to service named com.apple.callkit.networkextension.messagecontrollerhost was invalidated from this process.} 2024-08-09 09:54:39.239+0900 callservicesd[133:62552] [Default] Application <bundle id> will not be launched because it failed to report an incoming call too many times (or repeatedly crashed.) For LOCAL PUSH INFO: point9(My app log info) My app log info: Incomming call 2024-08-09 11:39:12.336+0900 For LOCAL PUSH INFO??: point10(sysdiagnose log info) Later message don't pair up quite as clearly, but I think that's mainly because callservicesd is logging slightly differently 2024-08-09 11:39:12.367+0900 callservicesd[133:88002] [Default] VoIP push for app <bundle id> dropped on the floor Best Regards,

Thank you for your comment About APNs push issue To sum up , I understand that the content is as follows, is this correct? Please let me know if I have misunderstood anything. In order to make a VoIP call via APNs PUSH, we must unlock the iPhone at least once after turning on an iPhone. If the iPhone remains in a locked state after being turned on an iPhone, we will not be able to make VoIP calls via APNs PUSH. If an iPhone continues to receive calls in state "2" and the number of calls exceeds a certain number, it will no longer be able to receive calls even after unlocking. Points 1 to 3 above are iPhone specifications and cannot be avoided by modifying the application. So, when using a VoIP application that uses APNs PUSH, customer must unlock their iPhone immediately after turning on an iPhone. About local push issue How about this issue? Could this also be because customer doesn't unlock an iPhone? I think that unless custmer unlock an iPhone, iPhone will not detect that it is in Wi-Fi range, Extension will not start, But Extention had started when problem happen. so, I guess that custmer unlock an iPhone. Or if there is a problem(above point3 problem) with APN push, will Local push also become unavailable?