Presentation https://docplayer.net/docview/57/40382450/#file=/storage/57/40382450/40382450.pdf
Post
Replies
Boosts
Views
Activity
Found it here https://wwdctogether.com/wwdc2016/230
Thanks, Scott and eskimo.
I need another piece of info, is there any order of serviceSubscriberCellularProviders dictionary values?
like if there is one Verizon physical SIM and AT&T eSIM.
then which value will come as 1st value of the dictionary?
Our real-time experience is 1st value of physical SIM and 2nd value of eSIM.
but on the internet, we saw many developers say they got eSIM value as 1st value and physical SIM as 2nd one.
Please confirm the significance of ordering.
That means that something in your process is leaking a file descriptor.
It will be very helpful if you please suggest some possible scenarios where fd might leak and to identify the process for fd leaking even though socket close was called.
if socket close is called, in iOS side what are the dependencies to make the FD free?
Not intrinsically, but there could be a bug in your code that causes it to leak the file descriptor under specific circumstances.
In 2 different servers, we saw different behavior, while connecting to one server it's normal, not increasing. but it's getting increased in another one. though in both server-client create TLS connection from time to time and every time it closes the socket.
Again, bumping up this limit is not the right way to address your problem. Does this problem reproduce on the simulator? The reason that’s relevant is that the simulator gives you access to more debugging tools (-:
Simulator run is not possible, can you please suggest some way to check from live devices.
What platform?
-->> iOS 13+ versions. Provided pcap is from iOS 15.2
What version of that platform?
-->> iOS 15.2
What app?
-->> ptt app, which is using SIP protocol.
And if it’s your app, what API are you calling?
-->> we are using open source BCD Sockets API. Open source RESIP.
iOS 13+ devices.
CXAnswerCallAction is a concrete subclass of CXCallAction.
When an incoming call is allowed by the system and "approved by the user", the provider sends provider(_:perform:) to its delegate. That means user need to pickup the call, i mean manually accept the call.
Responding to VoIP Notifications from PushKit
Receive incoming Voice-over-IP (VoIP) push notifications and use them to display the system call interface to the user.
-->> System call interface will be shown and User need to accept the call then call will be connected. So user can either accept or reject the call. Which API will ensure the auto acceptance of call?
Also I want to clarify the requirement -> if there is any call with VOIP push Notification, system call screen will not be shown and automatically receiver will start to hear voice of the caller.