Article
01/30/2017

The Aggregation Script

Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

The aggregation script produces the following values:

Machine State Used in multiple points of presence (MPOP) scenarios to determine which endpoint is most active.
Availability Considers all states across all endpoints. The aggregation script must produce a value to display.
Current Activity Only one activity is shown in client user interfaces, such as in a Communicator Contact Card, and therefore needs to be aggregated, because a contact can be engaged in more than once activity at the same time.
Last Active Indicates to contacts how long the user has been away, in order to give contacts greater detail about the user's availability.

Machine State

Each endpoint publishes, at most, one Machine state. When a Machine state is published, the server stamps the state with a publication time. This prevents time skew issues that occur if clients whose clocks are not synchronized attempt to timestamp Machine state. The aggregation script is responsible for processing each device's Machine state and notifying the devices of the single Machine state for the most active device. In order to do this, a total ordering of (Active < Inactive < Unknown < Away < Off) should be used.

Availability

There are seven availability classes, each with its own presence status icon, as shown below in Table 8.

Table 8. Availabilities

Class	Range	Description
Available	3xxx	User is reachable.
Busy	6xxx	User is reachable but engaged in another task.
DND	9xxx	User is reachable but does not want to be interrupted.
Inactive	12xxx	User is temporarily or probably not reachable.
Busy (Inactive)	12xxx	User is temporarily or probably not reachable.
Away	15xxx	User is probably not reachable.
Offline	18xxx	User is not reachable.

Availability dictates which presence icon is displayed for a user. The aggregation script is responsible for producing a single availability for each user. The script does this by considering the activities in which a user is engaged. From an availability aggregation standpoint, there are only two types of activities, those that are set by the user and those that are set automatically. User-set activities are treated differently to allow users to override automatic activities. Table 9 below shows the attributes associated with an activity.

Table 9. Activity and attributes

Attribute	Description
Availability	How busy this activity makes the user.
Publication Time	When the activity was published.

Activities can have additional attributes used by the client, but the aggregation script is primarily interested in the attributes listed in the preceding table. In order to calculate availability, the aggregation script first creates a set of all the activities that are currently valid. Only the aggregated Machine state from the previous step is included. All other Machine states are removed from the set.

If a user (or custom) state exists, the aggregation script extracts the publication time of the User state, sorts the set of all activities by publication time, and removes any states earlier than the User state from the set. The aggregation script sorts the set by Availability, and then extracts the Availability value from the least available state. As shown below in Figure 15, each Availability is assigned an integer value, with the highest Availability associated with the lowest integer value.

Figure 15. Availability ranked (from top to bottom) by most available to least available

d99f6aa9-f70a-4c35-a72d-7e334f9c758e

Availability is seen by any contact that has access to the user's Personal, Team, Company, or Public containers.

Current Activity

In addition to availability and publication time, activities can also have an associated activity token. For example, the Calendar activity generally has an In a Meeting activity token, as shown in Figure 16.

Figure 16. Activities and associated status indicators

145c1080-913a-49cf-b24a-64ab8551b75a

Custom activities have activity strings instead of tokens. However, with the presence model system, not all states have activities, so the process is not as simple as taking the least available state.

In order to calculate current activity, the aggregation script takes the sorted set from the end of the Availability step. If a User (or Custom) state exists in the Offline availability class, the script removes any non-User (or Custom) states that have a Device or User expireType.

The script then removes any activities from this set that lack a token or string. If the set is now empty, the Availability class is used as the current activity. Otherwise, the activity from the least available state is used as the current activity.

The current activity is seen only by contacts that have access to the user's Personal or Team containers. Contacts in the Public container see the availability class as the user's current activity. Contacts in the Blocked or Default containers do not see any current activity for the user.

Last Active

The aggregation script outputs a lastActive attribute for the aggregated state in the container. The value of lastActive is based on the publication time of the state that resulted in the aggregated state. The lastActive value is used to determine the Inactive and Away states. When a contact is in the Inactive state, the contact is available but the activity is Inactive, meaning no input has been sensed for the past five minutes. After 15 minutes, Inactive status transitions to Away status.

Aggregation Examples

This section discusses the aggregation of presence inputs published from multiple devices with User state, Phone state, and Calendar state. This aggregation process is triggered whenever any element that contributes to a user's presence status is newly published. First, all of the published states are collected. All Device states are aggregated into a single Device state that corresponds to the most active computer, as described earlier in this paper. Any state that was published before the most recent state change is cleared. Then all the states are sorted and the least available state is selected, as shown below in Figure 17.

Figure 17. Aggregation of Availabilities

cba11597-2bef-46ef-b747-1380a4e3b8bc

The examples shown in Figure 18, below, are intended to clarify how presence status aggregation works.

Figure 18. Aggregation examples

997f76dc-0731-483c-870e-1d6bd7a8573e

The user is using Communicator Mobile on his or her phone. No input has been sensed on this device for more than 15 minutes. Because the Communicator Mobile device is the only active device, the Away state displays.
The user signs in to his laptop and manually sets his presence status to Available. The manually set User state overrides the Away state on the mobile device and the Available state on the laptop takes precedence.
The user changes the status on his laptop from Available to Do Not Disturb. The manually set Do Not Disturb User state takes precedence over the Away state on the Communicator Mobile client.
The user's status is Do Not Disturb, but the Calendar state publishes a Busy state. In this case, the Do Not Disturb status takes precedence, because it is the least available status.
The user's presence continues to be Do Not Disturb, but a Machine state of Inactive is published to the server. In this case, the Do Not Disturb state takes precedence, because it is the least available state.
The user has not provided input into his computer for over 15 minutes, so the client publishes an Away Machine state. Because the Away status is less available than the Do Not Disturb status, the Away status takes precedence.