Hi Thank you for your response. I am sorry. my before descrption was incorrect. myApp is executing following sequence. But iPhone sometimes doesn't call didActivateAudioSession of step6 after this sequence. (I said "sometimes", but once it occurs, it will occur repeatedly) How about this sequence? If you have some notice about it, could you tell me it? myApp --- AVAudioSession setCategory: AVAudioSessionCategoryPlayAndRecord --->iOS myApp <-- return YES ---- iOS myApp --- AVAudioSession setMode: AVAudioSessionModeVoiceChat --->iOS myApp <-- return YES ---- iOS myApp --- AVAudioSession setActive:YES --->iOS myApp <-- return YES ---- iOS myApp --- CXStartCallAction --->iOS myApp <-- performStartCallAction callback --- iOS myApp <-- didActivateAudioSession callback ----iOS

Hi //////// I'll correct the line breaks and repost it. //////// Thank you for your response. I am sorry. my before descrption was incorrect. myApp is executing following sequence. But iPhone sometimes doesn't call didActivateAudioSession of step6 after this sequence. (I said "sometimes", but once it occurs, it will occur repeatedly) How about this sequence? If you have some notice about it, could you tell me it? myApp --- AVAudioSession setCategory: AVAudioSessionCategoryPlayAndRecord --->iOS myApp <-- return YES ---- iOS myApp --- AVAudioSession setMode: AVAudioSessionModeVoiceChat --->iOS myApp <-- return YES ---- iOS myApp --- AVAudioSession setActive:YES --->iOS myApp <-- return YES ---- iOS myApp --- CXStartCallAction --->iOS myApp <-- performStartCallAction callback --- iOS myApp <-- didActivateAudioSession callback ----iOS

Hi DTS Engineer, What about my last comment? Do you need some additinal infomation?

//////// I'll correct the line feed and repost it. //////// Users of my app have reported that they are sometimes unable to receive Voice-over-IP (VoIP) push notifications when using a SIM. (There is no problem when using WiFi) VoIP push notifications were not received during the following period. Could you confirm diagnostic logs and could you please tell me why my app can't receive VoIP push? [diagnostic logs] https://drive.google.com/drive/folders/1gSAbr1Fy1SrjlmRXuAzoXqiaxnNbFhj8?usp=sharing [Problem period] 2024/06/17 05:34:59 - 2024/06/17 09:04:42 Number of times that the push server pushed and it received a normal APNs response: 31 Number of times that iPhone received pushes: 0 2024/06/17 23:05:03 - 2024/06/18 09:02:16 Number of times that the push server pushed and it received a normal APNs response: 192 Number of times that iPhone received pushes: 0 2024/06/15 00:35:56 - 2024/06/15 09:55:57 Number of times that the push server pushed and it received a normal APNs response: 138 Number of times that iPhone received pushes: 0

I tried grep "apsd[131:", 15:45:11.000+0900","15:34:22.998+0900", and "09:06:19.991+0900" for *.txt *.log in all sysdiagnoses, but there were no hits. How can I read sysdiagnose? Do I need to do any further processing on the resulting files after decompress tar? Also, is it OK for developers to read sysdiagnose? I would like to confirm myself start/end time of logs on next time, so could you tell me about it?

Thank you for your detailed explanation. This problem reappeard and I received a new sysdiagnose, so I checked the log myself based on your advice. The complaint from my customer this time was that an APNs PUSH was sent during the following times 1 to 3, but the PUSH did not arrive and VoIP calls could not be received. 2024-08-08 03:47:16 2024/08/08 15:32:09 2024/08/08 15:32:24 I read the sysdiagnose and found that there was no sysdiagnose during the following periods. This is coincides with the time when PUSH was not received. 2024-08-08 01:53:01.925793 +0900 to 2024 - 08-08 05:35:43.505458 +0900 2024-08-08 15:31:33.819839 +0900 to 2024 - 08-08 15:32:35.081712 +0900 Why is there no sysdiagnose? [sysdiagnose] https://drive.google.com/file/d/1bT4rix7Y4BqqJX-EW4Zp4peiC7ygED2f/view?usp=sharing I feel the iPhone may have been turned off, so if there is a log that proves this, I want to tell it to customer, if yes, please tell me the keywords to search in the log. Also, I understood that when the iPhone is turned off, the sysdiagnose before the power was turned off disappears, but is this a misunderstanding? If the period without sysdiagnose above indicates that the power was turned off, the sysdiagnose of this will contain the log before the power was turned off. Best Regards,

This customer is using local push in a Wi-Fi Area, And using APNs push out of a Wi-Fi Area(=in a LTE) The following issues were reported in each area. About local push issue Could you tell me mean of following error in a sysdiagnose202408.zip > localpush-sysdiagnose? 2024-08-08 09:42:39.411505+900: nssessionmanager NESMAppPushSession[LocalPushDefaultConfiguration:CF5370FF-878F-4B2E-B39A-8B672E9F678F] 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.} Extention called reportIncomingCall at 2024-08-08 09:42:39.406(I confirmed it from my VoIP app log), but iOS doesn't kick my VoIP application. Does above log specify cause of this behaviour? (Not only this, but even for 182 calls from 2024-08-08 09:29:20.256 to 2024-08-08 15:33:45.096, iOS did not kick my VoIP application.) About APNs push issue Between 2024-08-08 19:34:16.813 and 2024-08-09 09:27:29.415, Customer is reporting that used my VoIP app via LTE connection. And during that time the server sent a PUSH request 144 times to APNs(I confirmd this from my server log), but the APNs PUSH was not received on an iPhone. (didReceiveIncomingPushWithPayload was not called). Why? Can I confirm below about this from sysdiagnos? If yes, please tell me keyword of sysdiagnose filter. I will confirm sysdiagnose202408.zip > apnspush-sysdiagnose. Did iPhone have an active LTE network connection during this time? If there is evidence that customer were using a Wi-Fi network instead of LTE during this time?(If there is a Wi-Fi without Internet connectivity and local push unregistered, I think they will not receive APNs push.) sysdiagnose202408.zip https://drive.google.com/file/d/1zT0r7cOSgESbwX0X1ekgGUjZG4309Ysy/view?usp=drive_link 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?

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,

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 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?

[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?

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

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

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.