Office Communications Server 2007 provides the infrastructure to enable client applications to publish and subscribe to extended, or enhanced, presence information. The enhanced presence infrastructure includes categories and containers. Categories are individual pieces of presence information, such as status, location, note, contact information, or calendar data. Containers are logical buckets into which clients publish instances of various categories of presence information. (See Tables Table 18-1 and Table 18-2.) When change occurs, clients can publish an individual category instance instead of an entire presence document, as is the case with Live Communications Server 2005.
Table 18-1. Types of Presence Information in Office Communications Server 2007
Presence Information | Detailed Description |
|---|---|
Basic Presence (Always Visible) | Displays the following presence information:
|
Name/E-mail | Name E-mail address |
Basic Contact Information | Title Company |
Detailed Contact Information | Work phone Work address Office number SharePoint site Free/Busy schedule Notes (for example, out of office) Notes (personal) |
Additional Numbers | Mobile phone Home phone Other phone |
Location | Current location Time away Working hours |
Table 18-2. Examples of Presence Containers in Office Communications Server 2007
Container | Description | Can See |
|---|---|---|
Personal | Family and friends who can contact you at any time |
Basic contact information Detailed contact information Additional numbers Location |
Public | General public whom you have limited contact with | Name/E-mail address Basic contact information |
Team | Members of your team or work-group | Name/E-mail address Basic contact information Detailed contact information Additional numbers Location Meeting details |
Company | Employees | Name/E-mail address Basic contact information |
For example, if a fictitious user named Tim is watching the presence of Joe, Joe can control what presence information Tim sees. If he places Tim in his Public container, Tim can see only Joe's name, e-mail address, and basic contact information. If Joe places Tim in his Personal container, Tim can see additional categories, such as detailed contact information, additional numbers, and location.
Office Communications Server 2007 notifies watchers of presence changes, depending on the containers for which each watcher has permission. For example, as a sales representative moves from one part of town to another, his supervisor and wife might be notified of his movements, whereas individuals without the necessary permission for that container are not notified. Office Communications Server 2007 supports this functionality through the use of rich access control lists (ACLs) that are based on containers and categories. ACLs contain the following:
URI List (per user)
Domain List
Same Enterprise
Federated Users
Public Cloud Users
Administrators can also define custom states for a user or group, and Office Communicator retrieves these custom states with custom activities from a Web site. For example, an administrator might want to provide a way for a recruiter in the recruiting department to remain uninterrupted while conducting an interview. In this case, the administrator can create a custom state consisting of the Do Not Disturb icon and associate it with a string "interviewing" to define this activity. Office Communications Server also allows you to customize your presence states. There are a total of four possible custom states, which are policy driven and can be deployed company-wide.
Additional customizations allow application developers to create custom clients for publishing and subscribing to other publications from different clients.
Presence in Office Communications Server 2007 has the following characteristics:
Presence information from multiple sensors
Machine state
User state
Phone state
Calendar state
Server-side aggregation
Extensible activities
MPOP support
Figure 18-6 shows an overview of how enhanced presence works. The following sections describe this model in more detail.
Office Communications Server 2007 uses a publish/subscribe model to publish and subscribe to more granular pieces of data that are assigned to different categories for each presence entity. Categories identify the types of data being published, such as presence note, presence state, and devices. Each category describes how to interpret the data. For example, a presence note category might have the data "I'm currently out of office" stored with it. Having a category abstraction allows more extensibility for third-party clients—because clients can access new types of data and users can subscribe to more granular data. For example, if Joe wants to subscribe only to Tim's presence note, Joe can do so without having to receive all other types of data about Tim, such as all of his devices and calendar information.
An application can publish multiple instances of a category. The subscriber receives all instances of this category. Multiple instances are usually published by different endpoints of a given application, one instance for each endpoint. This is also known as Multiple Points of Presence (MPOP).
Each publication, which is an instance of a category in a specific container, has a version associated with it. Each version starts with 1, and each time the data is changed the version increases by 1. If there is no version number specified by the client or the version number does not match the version maintained by the server, the data is rejected by the server. This is done so that data is kept in sync across multiple devices. For example, if Joe is logged in to multiple devices—such as a laptop and a desktop—each device will have the most up-to-date information.
Publications can also be time bound. For example, a publication can live forever, expire after some amount of time (such as calendar information), expire after a particular registered endpoint expires (such as logging off of your desktop computer), or expire after all the registered endpoints expire (such as when a user logs off or is disconnected on all devices). In the case that the publication expires, the subscriber gets put back into the default container. For example, [email protected] is a subscriber of Cindy's presence, and he fits into container 400. If Cindy disconnects from all of her devices, [email protected] now sees only the presence information published to everyone else until Cindy logs back in. When Cindy logs back in, [email protected] gets re-evaluated and put back into the correct container, as it pertains to Cindy. A subscriber can also get re-evaluated at any time if any memberships, containers, or categories change.
Containers are identified by a number. A number is used, as opposed to a general string name, because the concept of ordering is applied to containers. Also, Office Communications Server 2007 knows only of a container number, and it is up to the client to assign the container number to a name. Container 0 is also assigned special status as a "default" container, and by default everyone is placed in this container. Subscribers are unaware of the containers that they are receiving information from.
Subscribers can fall into multiple containers. For example, [email protected] might fall into my same domain container as well as my personal container. If Tim has different presence notes for each container, the server needs to figure out which presence note Joe will see because a subscriber gets a category subscription satisfied only from one container. If a subscriber is placed into multiple containers, there are a set of rules followed to determine which information should be given to the subscriber. First, the server looks at the category the user wants to subscribe to. If Joe wants to subscribe only to Tim's presence note, the server first looks only at the containers that contain presence notes.
After the server determines which containers to look at, the server looks at the membership in each container. As mentioned previously, there are five types of membership characteristics for ACLs. These characteristics are numbered for a reason. The server starts with the first characteristic, SIP URI, and then works its way down to the last characteristic, public cloud users. As soon as the server finds a match for the subscriber, it stops searching, and this is the container the subscriber will be placed into. For example, we see that [email protected] has been put in the personal container, which is higher ranked than the same domain membership characteristic, so the server gives the presence note for the personal container to [email protected] instead of the presence note given to other people with the same domain. Let's say that [email protected] still fits into two containers and the server did not know which presence note to publish. In this case, the server then looks at the container number. The highest container number wins.
As mentioned previously, a container holds a set of published items and a membership list describing who can see those items. An example of containers is shown in Figure 18-7.
Container 0 shows default publications given to anyone who does not fall into the membership of higher containers. For example, public cloud and federated users are not specified anywhere else, so those users (except for [email protected]) get data from this default container.
Container 200 is the set of categories published to people in the same enterprise as the publisher, unless those people are satisfied by a higher container or a lower container with a more restrictive membership (such as being on a URI or domain list). For example, Joe is also in container 400, so he receives the published information for status, phone, and note, which are published to everyone in container 400. He also receives the meeting information published to everyone else in the enterprise.
Container 400 shows a more detailed view of phone and note information for the specific URIs that fall into the personal container. [email protected] receives presence information published in this container instead of the default container.
Container 3200 has been set up to give two people a blocked view of status. The presence status these users see is an offline status. They can still, however, receive categories from other containers. Office Communicator publishes all categories with empty data to the block container to make sure blocked users do not receive any data from other containers.
The following is an example of the presence state set to online:
<categories xmlns="http://schemas.microsoft.com/2006/09/sip /categories" uri="sip:[email protected]"> <category name="state" instance="1" publishTime= "2007-08-14T06:05:43.783"> <state xsi:type="aggregateState" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2006/09/ sip/state"> <availability>3500</availability></state> </category> </categories>
The following is an example of the presence state set to Do Not Disturb and published to the team watchers:
<categories xmlns="http://schemas.microsoft.com/2006/09/sip /categories" uri="sip:[email protected]"> <category xmlns="http://schemas.microsoft.com/2006/09/sip /categories" name="state" instance="1" publishTime="2007-08-14T21:37:33.723"> <state xsi:type="aggregateState" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2006/09/sip/state"> <availability>6900</availability> <activity token="urgent-interruptions-only" /> <meetingSubject>Test Status</meetingSubject> <meetingLocation>TBD</meetingLocation> </state> </category> </categories>