Yes.... it was confirmed to me that the 60 sec behaviour is by design. I would suggest you file an enhancement request with them if you believe as I do that this is too short. For PABX behaviour calls can ring for longer than that in busy situations. Also as far as I know the callback we get from Callkit doesnt allow me to distinguish between a caller rejecting the call rather than this 60 sectimeout. In that case it looks to our call records that the user rejected the call rather than it being a missed call :-(
Post not yet marked as solved
Just an update in case it helps anybody....
A function was called unexpectedly twice in quick succession leading to the NSSString being de-allocated before NSURL got to use it.
I put some defensive code in and it seems to have fixed it
Post not yet marked as solved
Updated to Sonoma 14.3 But I still see the same problems
There were no VoIP Pushes to start an incoming call
Callkit does not seem to work so I get no Audio.
Am I missing something?
This was happening for me when using Xcode 14.3.1
In Case it helps anybody I found that if I deleted ~/Library/Caches/org.swift.swiftpm then it fixed the problem for me
Post not yet marked as solved
I have eventually "trapped" the contents of the NSString that was converted to a NSURL which causes a crash in a real customer site
I show it below...( For our customer privacy I've hidden our server replacing it with xxxxxx.xxxxx.xx below but they are just lowercase alphabetical characters)
If I run this myself now then I don't get a crash!!! SO for some reason this just occurred in the real customer at that time!!
Anybody got any ideas?
I am running this on Thread 2 in case that is a factor?
NSString *dave = @"https://xxxxxxxx.xxxxx.xx/test/gate/b8e23d6e5dcfb0d5025fcc928f55ac1d5ae6ed03/settings";
NSURL *url = [NSURL URLWithString:dave]; <--- Crashes here
Post not yet marked as solved
Same here
Cannot compile my code anymore
Sandbox: rsync(37768) deny(1) file-write-create /Users...../Build/Debug-iphoneos/MyApp.app/Frameworks/InputBarAccessoryView.framework/.Info.plist.nd7plo
I also see this.. In the device logfile I see the following
10:33:40.041163+0100 callservicesd Exceeded ringing duration of 60 seconds; disconnecting call with identifier
I have seen it on a device running iOS16.1.1 and another device running iOS16.4.1
So this looks like an intentional action by Callkit... This makes a VoIP App very limited in PBX Call queuing situations where calls might be ringing for long durations.
Is there some way to avoid it. I cannot find anything
Post marked as Apple Recommended
I get the same warning in XCode14 Beta 5 in my objective C main() when it calls UIApplicationMain(argc, argv, nil, nil); (See below)
I use a WKWebView to allow user to login.
For me it seems to happen if I display a WkWebView when I start my Aop. If I run and don't need to display the WkWebView (Ie I already have login details) then I don't seem to get the warning...
int main(int argc, char *argv[]) {
@autoreleasepool {
int retVal = UIApplicationMain(argc, argv, nil, nil);
return retVal;
}
}
All a bit worrying but I have no clue what it means.
Post not yet marked as solved
Update to above
In summary I believe that with Simulator running with Xcode 14.0 beta 5 ( (986.2) SimulatorKit 624 CoreSimulator 857.7 ) simulating iOS16 then Callkit didActivateAudioSession never happens.
If I use that simulator to run iPhone with iOS16 then didActivateAudioSession NEVER gets called so I get no speech path on my calls
If I run from that Xcode on my real device iPhone 12 running iOS16 Beta5 then it works correctly (didActivateAudioSession is called as expected)
If I run on the simulator running iPhone 12 with iOS15.2 then that too works correctly (didActivateAudioSession is called as expected)
If I run on simulator with Xcode 13.2.1 running iOS15.2 then that that too works correctly (didActivateAudioSession is called as expected)
Post not yet marked as solved
I eventually updated to Monterey 12.5 But I still see the same problems
There were no VoIP Pushes to start an incoming call
Callkit does not seem to work so I get no Audio.
Hey Scott.. Thanks... Yeah a few days I had already seen your Forum post with Eskimo about iCloud Frame Relay and I checked with customers and subsequently ruled it out as a cause of the problem.
This morning we actually discovered the real cause of our problem...
On one of our users experiencing the problem at the BSD socket level getaddrinfo was resolving to BOTH an IPv4 and IPv6 address. My code only ever tried to connect on iPv6 in that case. That failed to connect presumably because the cellular provider has some type of fault. They are newer 5G networks here in Europe.
I tried a new testflight version with customer this morning that will now try to connect to IPv4 instead if that happens and it fixed the problem!!!!
It was another forum item I saw from Eskimo
https://developer.apple.com/forums/thread/48996?answerId=146136022#146136022
which pointed me in this direction where he says "BSD Sockets requires you to call getaddrinfo and then write a loop over each returned address, opening and connecting the socket, until you get one that works. Doing that reasonably well requires some ugly code, code that can’t be as good as the OS’s implementation!!
That man Eskimo is a genius and saved me a ton of work!! I was close to starting a major rewrite of our App to use higher level networking code.
Thanks for your help
Post not yet marked as solved
I have been testing iOS14Beta 8 and I made about 400 incoming VoIP Pushes in the space of an hour or so. For those incoming calls I got two cases of "Killing VoIP app because it failed to post an incoming call in time" even though my code does that.
I have logged that Issue in a separate Forum item ( https://developer.apple.com/forums/thread/653756) as I think that is a bug in iOS14Beta's as I have never seen that issue with iOS13.x
Anyway after the second failure all other incoming VoIP Pushes were blocked with
"Application will not be launched because it failed to report an incoming call too many times (or repeatedly crashed.)"
This happened about 33 hours ago..
I tried restarting the iPhone (as Kevin DTS suggested) but it did not help. Pushes were still blocked. So maybe that behaviour has changed since Kevin's post.
Every few hours I make a test call to the App but the VoIP Push is still ignored.. Kevin also suggested that it should allow Pushes through after ~24 hours.
It would be great if we could get clarification from Apple about the following
1) What does "in time" mean? When we get a VoIP Push my understanding is that you must offer the call to Callkit before you return form pushRegistry:(PKPushRegistry *)registry didReceiveIncomingPushWithPayload:(PKPushPayload *)payload forType:(PKPushType)type withCompletionHandler:(void (^)(void))completion. However is there a time limit from when you start running this routine? We need to do some preprocessing on the pushed data before offering the call
2) When will iOS block all further incoming calls? For example is it if you fail to offer two calls within an hour. Or is it if you fail to offer 2 calls period? If you fail to offer a call and then 3 days later fail to offer a call will that Block all further calls. What is the algorithm?
3) When VoIP Pushes are blocked then what needs to happen to allow then through again? Is it simply a time period? if I keep sending calls in does that reset that? IE. Do you need no incoming Pushes for 24 hours to clear it?
4) Is there a new Issue in iOS14Betas Please see the separate thread about that
https://developer.apple.com/forums/thread/653756
General Comment
It has been a lot of work and very difficult to change our code to always offer calls before returning from "didReceiveIncomingPushWithPayload" routine. I can understand why Apple insist on that and will kill the App.
HOWEVER I suggest that blocking all further incoming calls is a very very severe step to take.
In complex call handing situations where you may not have a perfect connection back to your VoIP Server and there are time lags etc it is impossible to avoid the situation in extreme circumstances where a VoIP Push arrives but you are not in a position to offer the call.
Apple's Callkit framework is far superior to the competition but this step makes it extremely difficult to make a reliable VoIP App. A VoIP App is useless if calls are blocked..
Post not yet marked as solved
We are still seeing this issue on iOS14 Beta 8
After some testing we have not seen it happen yet on iOS 13.7
I presume iOS14 will be released soon so I hope we can get some solution from Apple.
Are other developers seeing this?
Post not yet marked as solved
I also see iOS killing the App Even BEFORE our App gets to run didReceiveIncomingPushWithPayload as can be seen from these 4 lines from console log
OUR PUSH ARRIVES
default 14:43:56.306168 +0100 apsd <APSCourier: 0x100e0d7d0>: Received message for enabled topic 'mds.mds.ourapp.us2.voip' onInterface: NonCellular with payload '{
aps = {
alert = "[1095],[Dave Maj Main],[],[],[0]";
};
}' with priority (null) for device token: NO
....
iOS DECIDES TO KILL OUR APP after 28 mSec
error 14:43:56.334866 +0100 callservicesd Killing VoIP app mds.mds.ourapp.us2 because it failed to post an incoming call in time.
....
didReceiveIncomingPushWithPayload is run in the App but iOS has already decided to kill it
default 14:43:56.341304 +0100 Our App MDS DEBUG => => => => => => New Push: Payload is [1095],[Dave Maj Main],[],[],[0]
....
iOS kills our App
default 14:43:56.345273 +0100 runningboardd [application<mds.mds.ourapp.us2>:641] Terminating with context: <RBSTerminateContext| domain:10 code:0xBAADCA11 explanation:<no explanation given> reportType:CrashLog maxTerminationResistance:Interactive>
Post not yet marked as solved
I see this issue Too.... Sometimes when running using XCode using Sandbox push servers I just never get thedidUpdatePushCredentials callback. It will frustrate me and then after a while it will start to work for a while..It is very frustrating hene trying to develop code for VoIP PushsSo far I have not seen the issue if I make an AdHoc distribution which will use the Production Push Servers. But I am worried when I deploy my solution that I will get real users seeing teh problem.Has anybody out theree found the reason for this?
