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
Hello,
I am developing an internal phone application using CallKit.
I am experiencing an issue with the behavior of remoteHandle settings in iOS 26 and would appreciate any insights you can provide towards a solution.
1. Problem Description
When an iPhone running iOS 26 is in a sleep state and receives a VoIP incoming call where remoteHandle is set to nil or an empty string (@""), we are unable to transition to our application (the UIExtension provided by the provider) from the CallKit UI's "More" (…) button after answering the call.
2. Conditions and Symptoms
OS Version: iOS 26
Initial State: iPhone is in a sleep state
Call Type: An unsolicited(unknown number) VoIP incoming call where the CXCallUpdate's remoteHandle is set to either nil or [[CXHandle alloc] initWithType:CXHandleTypePhoneNumber value:@""]
Symptoms: After answering the VoIP call by sliding the button, selecting the "More" (…) button displayed on the CallKit screen does not launch our application's UIExtension (custom UI), and the iPhone instead stay to the CallKit screen.
3. Previous Behavior (Up to iOS 18)
Up to iOS 18, even when remoteHandle was set to an empty string using the following code, the application would transition normally from "More" after answering an incoming call from a sleep state.
CXCallUpdate *update = [[CXCallUpdate alloc] init];
update.remoteHandle = [[CXHandle alloc] initWithType:CXHandleTypePhoneNumber value:@""];
[provider reportNewIncomingCallWithUUID:uuid update:update completion:completion];
4. Unsuccessful Attempts to Resolve
The issue remained unresolved after changing the handling for unsolicited(unknown number) incoming calls as follows:
CXCallUpdate *update = [[CXCallUpdate alloc] init];
update.remoteHandle = nil; // Set remoteHandle to nil
[provider reportNewIncomingCallWithUUID:uuid update:update completion:completion];
5. Workaround (Temporary)
The problem can be resolved, and the application can transition successfully, by setting a dummy numerical value (e.g., "0") for the value in remoteHandle using the following code:
CXCallUpdate *update = [[CXCallUpdate alloc] init];
update.remoteHandle = [[CXHandle alloc] initWithType:CXHandleTypePhoneNumber value:@"0"]; // Set a dummy numerical value
[provider reportNewIncomingCallWithUUID:uuid update:update completion:completion];
6. Additional Information
If remoteHandle is correctly set with the caller's number (i.e., not an unsolicited(unknown number) call; e.g., value:@"1234567890"), the application transitions normally from the "More" button after answering an incoming call from a sleep state, even in iOS 26.
The above issue does not occur when answering incoming calls while the iPhone is in an active state (not sleeping).
7. Questions
Have there been any other reports of similar behavior?
Should this be considered a bug in CallKit for iOS 26? Should I make file a new Feedback report?
Is there a suitable method to resolve this issue when the caller ID is unsolicited (nil or an empty string)?
This problem significantly impacts user operations as end-users are unable to perform essential in-app actions such as hold or transfer after answering an unsolicited(unknown number) call from a sleep state. We are eager to find an urgent solution and would appreciate any information or advice you can provide.
Thank you for your assistance.
It has been approximately three weeks since we submitted our app for review via App Store Connect, but it remains "In Review" and the review process has not been completed.
For this reason, we also requested an expedited app review to the App Review Team last week.
Will the review proceed if we simply wait?
Is there any way to check the detailed status of this app review?