< Back to Package Overview
Backgrounding and battery considerations
Different mobile operating systems have different implementation of power management and background requirements on applications. There is a tradeoff between power consumption and the level of service a background application receives. Client SDK keeps a balance between power consumption and service availability requirements.
Power Management Implementation
The following have been implemented by Client SDK:
- The event loop supported IOS socket implementation is based on Apple streaming sockets, which allow to keep persistent connections to SIP servers up while the application is in the background.
- When a network event happens, the event loop thread is waken up (through the streaming socket APIs). The thread stays awake long enough to process the incoming network message completely.
- When there is an active call (i.e., active media stream) and the application is put in the background Client SDK provides full service.
User can provide a keep alive timeout to wake the application (Client SDK) and restart subscriptions. This timer is used to refresh SIP subscriptions and registrations periodically, in the absence of inbound network message that can wake the application up.
- (void)applicationDidEnterBackground:(UIApplication *)application {
[application setKeepAliveTimeout:UIMinimumKeepAliveTimeout handler:^{
[client prepareForBackgroundInterval:UIMinimumKeepAliveTimeout];
}];
}
Detecting when application is in background
Detecting application's visibility change is done through the observing of NSNotificationCenter for entering background/foreground.
Service Specific Design Decisions
Different areas of Client SDK functionality were examined to determine whether a given functionality should work in full service mode, limited service mode or be disabled while the application is in the background. As stated at the beginning of this section, the decision is based on two criteria: power consumption management and the level of service that is appropriate while in the background.
Note that when the application is automatically put in the background, for example, due to incoming cellular call activity, the (VoIP) application cannot provide any media service. Any active call is automatically put on hold through SIP renegotiation. This is different from when the user puts the application in the background, for example, to bring up another application. The following decisions about how active calls are treated, are not applicable to cellular activity scenarios.
| Service type |
Level of service |
Notes |
| SIP registration |
Normal |
Registration is required in order to receive incoming network events. |
| SIP subscriptions |
Normal |
While in the background, the ccs-profile, reg, dialog, message waiting and feature status notifications can be received. Once received, the event loop thread wakes up to process the message. |
| Outgoing calls |
Normal |
While there is an active outgoing call or the call is in progress, the call is allowed to proceed while the application is put in the background. |
| Incoming calls |
Normal |
The event loop wakes up to process incoming SIP INVITE and reports the incoming call to the application thread for alerting. |
| Active p2p/conference call |
Normal |
Media streams stay alive. |
| Held p2p/conference call |
Signaling only |
Held call has no media. It remains held at signaling level while in the background. |
| Remotely held call |
Normal |
A remote hold operation may result in music on hold service. In this case, music on hold stream is played while in the background.
If there is no music on hold service provided by the network, the media stream remains removed, the call stays in the background with its signaling enabled.
When the remote party unholds the call, the incoming unhold request wakes up the application. Assuming there is no other active VoIP call, the media can be added to the application while in the background. |
| Presence subscription |
None |
When in the background, presence subscription is stopped for all contacts (except self-presence) in order to prevent presence notifications from waking up the application and consuming battery power. |
| Presence publish |
None |
Automatic presence publish (e.g., on the phone or idle) can be done while in the background. The trigger for this will be the changed call state. When the call state changes, presence publish is sent out. |
| PPM/HTTP-based services |
None |
Socket connection remains live until after pending requests are completed. The socket connection is then torn down, and no new request is allowed while in the background. |
Background and Suspend/Resume Interactions
Network disruption and restoration may occur while the application is in the foreground or background. Network connectivity monitoring reports all modules to receive information on when the network connection is lost or restored. Depending on the demands for different services and the background/foreground state of the application, there are various actions taken by Client SDK as documented below:
![Network Interruption and Restoration while in the foreground]()
![Application goes to background while in suspended mode]()
![Network Restored While in Background]()
![Network Suspended and Restored While in Background]()
![Transition to Suspended while in Background]()
