Typically, my WebSocket delegate stops receiving anything after app has gone into background state …
Correct. Shortly after an app is moved to the background, the system suspends it, and network activity on a TCP connection won’t resume it . See Technote 2277 Networking and Multitasking for more.
The standard approach here is to make a new network connection once you’ve resumed in the background because of the VoIP push.
Just as an aside, with regards this:
bind it to
you are, alas, off in the weeds. The
.backgroundQoS means that the queue is doing background work that doesn’t care if it’s delayed for a long time. It has nothing to do with executing in the background.
For detailed information on these queue values, check out the comments in the
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
 In fact, on modern system you’ll see socket resource reclaim (per TN2277) triggered immediately by the suspension.
Same time, I've found an interesting approach sending the call cancellation push as background push like so:
Basically, it could run the app within few minutes.
But in case of call ringing, the app is already in run, so this push delivers immediately.
Gonna check its behavior as it is a bit simplier than recreating the connection in my case.