I investigated what network interface names are assigned to carrier networks on a dual SIM iPhone by examining the output of getifaddrs(). (An part of the program used for this is provided below.)
//////////////
struct ifaddrs *interfaces = NULL;
struct ifaddrs *an_interface = NULL;
if (0 == getifaddrs(&interfaces)) {
an_interface = interfaces;
while (an_interface != NULL) {
if( an_interface->ifa_addr->sa_family == AF_INET) {
NSString* name = [NSString stringWithUTF8String:an_interface->ifa_name];
NSLog(@"Interface name is: %@", name);
}
an_interface = an_interface->ifa_next;
}
}
freeifaddrs(interfaces);
In this investigation, it appeared that the interface name for the sXGP SIM selected under "iPhone > Settings > Cellular > Cellular Data" was always "pdp_ip0".
(A screenshot of "Cellular Data" is provided below. this is sample of sXGP selected )"
[QUESTION]
Is the SIM selected in Settings of iPhone always assigned to "pdp_ip0"?
[BACKGROUND]
I am developing a VoIP application and opening sockets by specifying IP addresses for communication.
On a dual SIM iPhone, multiple networks (IP addresses) are visible. Therefore, I need to determine which network to use. My question is whether I can reliably make this decision based on the network interface name.
If the SIM selected in Settings is always assigned to "pdp_ip0", I intend to open the socket using the IP address of "pdp_ip0".
Alternatively, should I use a different method to select the appropriate network interface?
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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?
Topic:
App & System Services
SubTopic:
Notifications
Tags:
APNS
User Notifications
PushKit
Push To Talk