< Back to Package Overview
Network Considerations
Disruption Handling
The phrase disruption handling is used to describe the network events that occur and have an impact on the services provided by your application. In the most general sense the most common type of disruptions that occur are:
- Acquisition or loss of a network interface (e.g. turn WiFi on / off, plug/unplug a network interface, walk out of range of your WiFi network, ...)
- IP address changes
For audio / video applications in most cases network disruptions impair media streams for a period of time and therefore have a direct impact on audio / video for the duration of that time.
Some common scenarios are discussed below to illustrate what can be expected and recommendations for how you can design your application user interfaces to best support your users through these events.
Roaming from Wifi AP to AP
In enterprise deployments where multiple Access Points (AP's) share the same service set ID (SSID) movement of the device between AP's will be largely transparent to applications built on Client SDK. If the enterprise network is properly engineered devices will complete the process of roaming between AP's in less than 150ms so even for active voice or video calls any media packets that are lost during the roaming process will not be perceptible to end users.
In cases where the device takes more than 150ms to roam between AP's the probability increases that artifacts may be introduced into the audio / video stream that become perceptible to the end user. For this reason if you are targeting users that will be commonly on audio / video calls while in motion throughout an enterprise proper engineering of the WiFi network to support voice / video is an important planning step to prepare for deployment of your application.
Roaming between WiFi and Cellular Data networks
When a device transitions from a Wifi network to the cellular data network (e.g. you walk out of the office to the parking lot) or from the cellular data network to a Wifi network (e.g. you walk into the office from the parking lot) in addition to the network interface change on the device the key event that occurs is that the IP address of the device changes as a result of the network transition.
The Client SDK automatically detects a change in network, and it will automatically reconnect with the appropriate network elements. Application Developers are not required to provide specific handling for changes in networks or IP Addresses.
Getting SDK service notifications
The Client SDK should notify your application about services availability changes caused by network interruption. If some service is affected by disruption, the Client SDK will generate special notification about service outage. Some services can also generate capabilities changed notification. Application Developers can use these notification to update user experience based on received information.
The sequence diagram below shows the expected Client SDK service notifications when a change in networking is detected.
![Network Considerations]()
To get notifications of some service or object, Application needs to add a listener to required service or object. For example, PresenceService has method to add PresenceServiceListener as listener.
import com.avaya.clientservices.presence.PresenceServiceListener;
import com.avaya.clientservices.presence.PresenceService;
import com.avaya.clientservices.user.User;
import com.avaya.clientservices.presence.Presence;
public class PresenceServiceUser implements PresenceServiceListener {
private final PresenceService presenceService;
public PresenceServiceUser(User user) {
presenceService = user.getPresenceService();
if (presenceService != null) {
presenceService.addListener(this);
}
}
@Override
public void onPresenceServiceAvailable(PresenceService presenceService) {
// some logic
}
@Override
public void onPresenceServiceUnavailable(PresenceService presenceService) {
// some logic
}
// implement other listener methods
