Multiple Points of Presence (MPOP)

 

For my first blog – I decided to write about Multiple Points of Presence (MPOP) and the underlying technology that supports it.

 

Lets examine some terminology that will be useful to us to understand MPOP. The user that publishes presence information is a presentity, whereas the users that consume this presence information are called watchers.

 

A point of presence is a client that explicitly provides presence information on behalf of a user (presentity). OCS2007 supports a variety of clients ranging from the soft-client Office Communicator 2.0 to Office Communicator Phone Experience.

 

With Single Point of Presence (SPOP), only a single device could be logged in at one time. The user experience was such that a user who moved from a desktop to their laptop, then back to the desktop would actually have to log into the desktop twice: once for the first time and again when the user switches back to that device because the laptop would have “kicked-off” the desktop. This is an annoying experience for the user as they find themselves constantly logging into devices as they switch from one to the other. This pain point was addressed by MPOP. The user can log into as many devices as they want (within an administrator defined limit) and switch between them at will without re-logging in each time

 

In MPOP, the presentity is allowed to log in from a multitude of endpoints and provide presence information to the server. The server will aggregate this presence information and provide all ‘watchers’ a unified view of the presentities presence. MPOP and the server side aggregation (also called the aggregation script) are central to providing the right user experience.

 

In case some of the details become difficult to comprehend, I would strongly urge readers to check out the example and then (re)read the details.

 

Presence Aggregation

Presence in OCS 2007 draws input from several ‘sensors’ and aggregates this information – the sensors are:

· User state – set explicitly by the user.

· Machine/Device state – derived from the state of the user’s machine – examples would be in a full screen application, screen lock, etc.

· Calendar state – here the user’s calendar provides information that affects the users availability.

· Phone state – if the user has a legacy PBX phone on the desk that’s integrated with the OCS2007 over the CSTA link – the current state may be reported. Voice/Video calls affect Phone state too. Example: In a call.

 

All of these inputs are aggregated at the server by the ‘aggregation script’ and a single unified view of the user’s state is provided to his watchers.

 

Presence states are integers which rank from the most available (lower integer value) to the least available (higher integer value). These integer values are mapped to icons by the clients.

 

While it may be argued that allowing watchers to see discrete presence values of each of the user’s devices may be useful – ‘people-centric’ communication is all about abstracting the details and allowing communication to flow to the endpoint where the user is the most likely to accept communication at the current time.

 

The following sections detail the algorithm used by the OCS2007 server to provide the aggregated presence information for a presentity.

Machine State

 

 

 

 

 

The aggregation script is responsible for processing each device’s machine state and deriving a single machine state for the most active device. In order to do this, we sort all the device states published and choose the device(s) that is most available (lowest availability number).

 

If two devices have the same state, the device that published most recently should be considered most active. For example, if one device has an Active machine state published at 1:00 PM and another has an Active machine state published at 1:03 PM, the second device should be considered most active. Tie’s (if-any) are broken by taking the lowest endpoint value (each client has a unique value attributed to it).

 

If the user does not have any published machine states, the script should aggregate the user’s availability by inferring a machine state of Offline.

 

Availability

 

 

 

 

 

 

 

From an availability aggregation standpoint, there are only two types of values, those that are user set and those that are automatically set. Availability values set explicitly by Users are given priority and are allowed to override automatic (sensor derived) availability values.

 

Each activity has the following attributes associated with it:

 

Attribute	Description
Availability	How busy this activity would make the user
Publication Time	When the activity was published
Manual	Whether or not the state was manually set by the user
StartTime	Used for calendar states to indicate when this state became valid

 

 

In order to calculate availability, the aggregation script first creates a set of all the states 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 there are multiple states that are manually user set, use the most recent manually set state for this pruning. If a state has been set explicitly by the user (manual attribute equals true), the aggregation script needs to remove all states older (based on publication time) than the manually set state.

 

The aggregation script should then sort the set by availability and extract the availability value from the least available state (highest availability value). This is the value that is published as a user’s aggregated presence information.

 

Example

 

Let us use an example (albeit contrived) to show how the aggregation script works. Patrick Smith has 4 clients simultaneously logged onto the OCS2007 server. They are:

· Office Communicator on laptop – OC1

· Office Communicator on desktop – OC2

· Office Communicator Phone Experience (OCPE)

· Communicator Mobile (CoMo)

 

Now let us examine the data published from each of these multiple endpoints:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Let us now apply the algorithm for MPOP as detailed in the sections above:

· Step 1: Take the Machine states and sort by availability. Take the most available machines. In case of multiple machines in the same state take the machine that has been active most recently.

o Step 1 result: OC1 à Active

· Step 2: Take all availability values (discard all Machine states except the one chosen from Step1). User set states take precedence (if more than one user set state available take most recent one). Sort by availability value, take the least available state and create a set with derived machine state:

o Step 2 result: set (OC1 Machine state à Active, User state à Busy)

· Step 3: take the lowest availability (i.e. highest availability integer value) and publish that as the users presence.

o Step 3 result: thus MPOP calculations will provide a single value for Patrick Smith and publish that to all his watchers. Patrick Smith is Busy.

 

- Sriram Parameswar

  Program Manager – Presence

Comments

• Anonymous
  January 01, 2003
  A great post on MPOP in OCS is available at the UC Team blog... Lets examine some terminology that will

• Anonymous
  January 01, 2003
  Veel gestelde vraag: Het is in Communications Server mogelijk om met meerdere devices/clients tegelijkertijd

• Anonymous
  January 01, 2003
  Sriram Parameswar in his first post explains Multiple Points of Presence using Microsoft Unified Communications

• Anonymous
  January 01, 2003
  So this is what the future looks like. Microsoft released Mac Messenger 7.0 yesterday. The big deal about this release is its support for OCS 2007. In fact, if you're not an OCS user, there aren't a lot of...

• Anonymous
  March 22, 2007
  Wow!  Some first post!  Thanks for the explanation.  I am just beginning to understand all this UC stuff.

• Anonymous
  March 23, 2007
  Hi, unfortunately the pictures are cut. Good article though.

• Anonymous
  March 26, 2007
  Great info!