We are encountering the following issue with our VoIP application for iPhone, published on the App Store, and would appreciate your guidance on possible countermeasures.
The VoIP application (callee side) utilizes a Wi-Fi network. The sequence leading to the issue is as follows:
- VoIP App (callee): Launches
- iPhone (callee): Locks (e.g., by short-pressing the power button)
- VoIP App (callee): Transitions to a suspended state
- VoIP App (caller): Initiates a VoIP call
- VoIP App (callee): Receives a local push notification
- VoIP App (callee): Creates a UDP socket for call control (for SIP send/receive)
- VoIP App (callee): Creates a UDP socket for audio stream (for RTP send/receive)
- VoIP App (callee): Exchanges SIP messages (INVITE, 100 Trying, 180 Ringing, etc.) using the call control UDP socket
- VoIP App (callee): Answers the incoming call
- VoIP App (callee): Executes performAnswerCallAction()
Immediately after executing performAnswerCallAction() in the above sequence, the sendto() function for both the "UDP socket for call control (SIP send/receive)" and the "UDP socket for audio stream (RTP send/receive)" occasionally returns errno = 57 (ENOTCONN). (of course The VoIP app itself does not close the sockets in this timing)
Given that the user has performed an answer operation, the iPhone is in an active state, and the VoIP app is running, what could be the possible reasons why the sockets suddenly become unusable?
Could you please provide guidance on how to avoid such socket closures?
Our VoIP app uses SCNetworkReachabilitySetCallback to receive network change notifications, but no notifications regarding network changes were received at the time errno = 57 occurred. Is it possible for sockets used by an application to be closed without any notification to the application itself?