< Back to Package Overview
Supporting sleep, hibernation and docking
Overview
The following page describes Client SDK behavior for handling desktop environment standby/hibernation and wake-up scenarios. In general, the standby/hibernation and wake cycle can be considered as a special case of a more general network disruption handler. The sleep/hibernation cycle can be broken down to the following steps:
- System informs the Client SDK/application (by means of the power monitor listener) that the system is about to go the sleep mode.
- Client SDK module that listens for power monitor takes necessary actions (listed below) before the system goes to the sleep mode.
- Client SDK's network connectivity monitor informs all modules that the network connection is lost.
- The system goes to the standby/hibernation mode.
![System is about to sleep]()
When the system wakes up:
- Client SDK modules are informed that the network connection is back.
- The modules restore functionality based on the last known state prior to switching to the standby/hibernation mode.
![System wakes up]()
Client SDK is responsible for handling all these operations without user interaction. You can control functionality by observing services availability notifications.
Power and connectivity monitor logic
- Client SDK listens for NSReachability callbacks to determine whether the network connectivity is lost.
- Loss of network interface results in suspended state on the Client SDK services.
- Sleep/wake calls are received through the I/O Kit API.
- Mac OS gives process some time before the system goes to sleep. This time interval is not specified by the OS documentation.
- Сlosure of sockets is automatically done by the system.
As explained in the overview section, the functionality is restored to the normal state after Resume() is called on suspended objects/modules. This triggers re-establishment of persistent network connections and signaling with the network servers to bring up all functionality to the normal state.
Auto Sleep
While active on a call, auto-sleep is not automatically turned off.
Actions taken as a result of Power Monitor Listening
The following services listen for power monitor events to take specific actions before the system goes to the sleep mode. The rationale for that is as follows: when the services need to notify the network applications that the endpoint is no longer reachable, they inform the network about impending loss of network connection. The set of steps taken as a result of listening to power monitor listener differs from the set of steps taken during network interruption handling. Before the network interruption is handled, certain services inform the network about losing connectivity, and hence overall service to the end user. Upon notification of the system sleep, all of the services mentioned below also receive network disruption through their ISuspendable interface.
| Service |
Action taken before sleep |
Notes |
| SIP Registration |
Unregister |
Done to ensure that SIP proxy servers do not offer incoming calls towards the endpoint that is about to go on standby/hibernation. |
| SIP Presence publish |
Remove last auto presence update |
Done to ensure that (stale) automatic presence data sent by the application that is about to go to sleep, does not get factored into the availability calculation. |
| SIP Subscriptions |
- |
|
| SIP Shared Control |
- |
|
| SIP Existing call |
- |
True for active or held audio/video point to point calls as well as conference calls. |
| WCS (if sharing) |
End WCS sharing |
|
| WCS (if not sharing) |
- |
|
| BFCP (if sharing) |
End BFCP based sharing |
|
| BFCP (if not sharing) |
- |
|
| PPM |
- |
All pending operations are cancelled as a result of network disruption handling. |
| ACS-based services |
- |
All pending operations are cancelled as a result of network disruption handling. |
| AMM Messaging |
- |
The system closes the AMM websocket as a result of removing the network interface before the sleep. |
| XMPP Messaging |
- |
The system closes the XMPP as a result of removing the network interface before the sleep. |
| LDAP requests |
- |
Delete pending LDAP requests (no need to send cancel to the server) The system closes the LDAP socket as a result of removing the network interface before the sleep. |
When the system wakes up and the network interface becomes available:
| Service |
Action taken after system wake |
Notes |
| SIP Registration |
Re-register |
Re-registration ensures that incoming SIP requests can be routed to the local endpoint. |
| SIP Presence publish |
Publish current presence state |
|
| SIP Subscriptions |
Refresh subscriptions. If the dialog no longer exists, create brand new subscription |
Done for each subscription type by Client SDK. |
| SIP shared control |
Refresh the shared control dialog. If the dialog no longer exists, create brand new shared control dialog |
|
| SIP existing call |
Refresh the call and restore media paths. If the call cannot be refreshed, end the call |
|
| WCS sharing |
Re-establish live session connection to WCS server. Note that sharing does not start automatically |
|
| BFCP |
BFCP socket connection is re-established as a result of SDP re-negotiation during call restoration. |
Note that sharing does not start automatically. |
| PPM |
Any previously cancelled PPM request is not automatically retried |
|
| ACS-based services |
Any previously cancelled request is not automatically retried |
|
| AMM |
Re-establish web socket or start long polling. Sync up the state of the conversations |
|
| XMPP |
Re-establish the XMPP socket connection |
|
| LDAP |
Pending LDAP requests that are cancelled as sleep/hibernation is not retried |
|
