Office Communications Server

How Presence Powers OCS 2007

Rajesh Ramanathan

At a Glance:

• Authorization and directory services
• Messaging options in OCS 2007
• Routing communications with presence

Microsoft Office Communication Server (OCS) 2007 builds upon the strengths of the Live Communication Server (LCS) 2005 release. LCS 2005 delivered enterprise-class instant messaging

(IM) and presence. It also introduced telephony integration with existing PBX installations via Remote Call Control (RCC).

OCS 2007 further enhances the presence and IM capabilities in LCS 2005 and adds advanced media and phone capabilities with Office Communicator 2007, making it a full-fledged "softphone." Microsoft has also developed conferencing servers and edge servers for media that enable you to fulfill all the communication needs of your organization along with an existing PBX or independently as a complete solution in itself.

Office Communicator 2007 provides "softphone" capabilities that allow your users to choose the USB devices they like and provides a rich end-user experience to make common call control features such as hold and transfer discoverable and easy to use. Users no longer need to remember telephone numbers or use a dial pad. Instead, they can easily click to make a call from a desktop application or create a conference call by dragging and dropping people or distribution lists into a conversation.

For those who need actual desk phones, Office Communicator Phone Edition (or Tanjay phone) acts as just another endpoint for the user, using touch-screen-enabled context menus and the familiar presence experience of Office Communicator.

These OCS system capabilities are built around the concept of user presence. OCS 2007 uses user availability, communication endpoints, and user relationships to connect people using the most appropriate medium at any point in time. And since OCS ties together voice, e-mail, IM, and other communication paths, it can help you route messages in the most productive way possible.

In this article, I will give an overview of the OCS 2007 solution and explain how various pieces fit together. I will also cover how presence is used as an important ingredient in the unified communication recipe and how it can be utilized for routing voice calls more effectively.

Authorization and Directory Services

An enterprise voice system must be able to verify the identities of the people who are allowed to make calls. It also should be able to apply restrictions or policies on a call-by-call basis. In a Voice over IP (VoIP) system, clients need to authenticate against the server to initiate calls. This is similar to a traditional PBX system where access to the physical line was sufficient to enforce identity.

The OCS 2007 system, shown in Figure 1, uses Active Directory® for the authentication and storage of access policies, and OCS authorizes calls by validating them against the policies for a user in Active Directory. Because OCS uses the same Active Directory information used by other Microsoft applications such as Exchange Server or Microsoft® Outlook®, you can simply add voice capabilities to existing users in Active Directory by extending a user's properties and policies (via Active Directory schema extensions) and providing a unified directory that can be used for real-time apps such as voice or IM.

Figure 1** OCS unified communication components **(Click the image for a larger view)

In Active Directory, the most important property related to unified communication is the Session Initiation Protocol (SIP) address (also known as SIP URI), which is very similar in nature to the user's e-mail address. For example, a user in Active Directory with the e-mail address someone@contoso.com would be assigned a SIP address sip:someone@contoso.com. Since the SIP address is tied to the user object, you can provide a single identity where the same credentials that the user uses for logging onto their desktop computer or Exchange server can be used to sign into their OCS server.

Another important property is the user's phone number. The OCS server internally retargets calls sent to phone numbers to a user's SIP URI to be able to route the call.

OCS 2007 provides an Address Book Service (ABS) interface that is available for directory look-up within an organization. As an offline version of the address book, it allows client endpoints to avoid hitting Active Directory every time a search operation is performed at the client end.

In addition to ABS, OCS 2007 makes distribution lists more useful by providing a Distribution List Expansion (DLX) service that allows users to view the same distribution list in Office Communicator that they see in Outlook and to expand the distribution list in Communicator as well. Users can set up conference calls with members of these distribution lists from Office Communicator directly or start a group IM chat.

Voice and Messaging Services

Additional OCS Resources

For more information, see the following resources:

• Unified Communications Events and Webcasts
• Office Communications Server TechCenter
• TechNet Virtual Lab: Enabling Users and Installing Office Communicator 2007

An enterprise voice solution must provide the call control features that users are most familiar with. With that in mind, OCS 2007 provides popular features such as call hold, call transfer and consultative transfer, forwarding, and simultaneous ring, plus non-voice modes such as IM.

OCS 2007 is at the core of the voice call routing, providing both outbound and inbound call routing functions. Outbound call routing involves translating numbers, applying policies (such as international call restriction) related to a user, and routing the call to the appropriate endpoints or out to the public switched telephone network (PSTN). Inbound call routing functions take care of a user's selected call forwarding or time of day/presence preferences and routes the incoming call appropriately.

OCS does not terminate incoming calls itself. In SIP parlance, it acts like a SIP registrar and a SIP proxy. Signaling and media are provided point-to-point entirely by the client endpoints in the system. Endpoints in the system such as Office Communicator 2007 provide a wideband audio codec (called RTAudio) that is adaptive and resilient to network conditions.

OCS 2007 provides on-premise Web conferencing using the Conferencing Server roles for all modes of communication: audio/video, IM, and data. OCS-based Conferencing Servers allow client endpoints to provide seamless transition from peer-to-peer to multi-participant, multi-modal communication with capabilities such as mute, eject participant, and lock. It can scale to hundreds of participants for scheduled conferences and up to a hundred for ad hoc discussions. You can schedule conferences through Outlook add-ins or make in-call escalation to a conference. The conferencing solution also provides tools such as file sharing, whiteboarding, and recording.

Of course, you must be able to provide connectivity to outside PSTN networks and phone numbers and to federated enterprises or existing PBX installations within the organization. OCS 2007 integrates with SIP-to-PSTN gateways offered by common gateway providers that allow connection to PSTN or to an existing PBX. A Mediation server can be configured for codec and signaling translation. Mediation servers are optional and are configured for gateways that do not support the Microsoft codecs.

Exchange Server 2007 Unified Messaging is the voicemail solution for OCS 2007. Exchange Unified Messaging provides call answering for inbound voice and fax calls and will place the received message in the user's Exchange mailbox. Additionally, Exchange Unified Messaging provides corporate auto-attendants for outside callers looking for a specific individual or department.

OCS provides real-time IM as an alternative to using voice, and it also allows users to engage in multimodal conversations that involve voice, video, and IM at the same time. Furthermore, Office Communicator 2007 allows rich text and formatting in IM. Plus, audio and video can be added any time to the IM session, seamlessly escalating the IM conversation to an audio conversation.

Accounting, logging, and troubleshooting are additional components. Accounting is provided using the OCS 2007 Call Detail Recording server functionality. For every call that is made in the system, a record is created of the time that the call came in, the destination that answered the call, and various other parameters such as whether the call was transferred. OCS also provides archiving servers that log IM conversations to meet compliance requirements. The Quality of Experience (QoE) Monitoring server stores information about the quality of calls that were made and can be used for troubleshooting voice quality issues in the network.

Registration and Initialization

Every client endpoint in the OCS system needs to register or sign on to OCS as the first step in initialization of the client. Registration is the process of connecting to the OCS server, and this step advertizes the existence of the client. The process of registration involves authentication of the user identity by the server; this also creates a security association between the client instance and the server. This security association is used for subsequent calls that the client makes through the server and is refreshed periodically by the client by re-registering. The re-registration duration varies depending on the server topology. For instance, client endpoints registered from outside the enterprise through a Microsoft AccessTM edge server refresh their registration more frequently than clients inside the enterprise firewall.

Note that only those client endpoints that need a persistent authenticated channel with OCS to receive incoming notifications such as voice calls or presence change notifications need register. Live Meeting is a client endpoint that needs a connection to OCS only for joining a meeting and therefore it does not need to register with OCS.

To better understand the details of client interaction within OCS 2007, let's take a closer look at Office Communicator as a client endpoint. (Most of the signaling flows that relate to Office Communicator are identical to those used for other client endpoints such as Office Communicator Phone Edition or Office Communicator Mobile.) Once registration completes, Office Communicator retrieves configuration information that is critical to the operation of the client endpoint. This information includes:

• Self information such as contact card, e-mail address, SIP URIs, display name, and telephone number
• Capabilities that are enabled on the client and policies
• Server addresses such as AV edge server SIP address and voicemail server address
• Buddy list of contacts stored on the server
• Number formatting rules for the client's location

This mechanism for retrieving all provisioning information using the existing SIP channel to the server is called inband provisioning. This lets the client endpoints auto configure and refresh their configuration whenever the clients sign on and also from outside the network or firewall.

The registration sequence proceeds from registering with the server to initialization, getting and setting presence, and finally to entering a ready state (see Figure 2). Note that OCS allows multiple client endpoints to be registered for the same user or SIP URI. During registration, the server returns a unique SIP address to the client so that any incoming signal can be targeted to the specific client. This address is also known as the Globally Routable User URI (GRUU). Each of the client endpoints that register with OCS get assigned a separate GRUU address by the OCS server, uniquely identifying the client endpoint.

Figure 2** Registration procedure **(Click the image for a larger view)

To keep registration under control, there is a limit of eight active registrations allowed by the server for any user. When multiple clients are registered for the same user, the configuration is known as multiple points of presence (MPOP). When only a single client is registered, it is referred to as single point of presence (SPOP).

The concept of MPOP is core to the OCS system. It lets the user receive incoming calls or IM notifications from any endpoint, essentially allowing the user to have multiple phone or IM endpoints. It introduces interesting dynamics for answering IM or even for depicting presence accurately for a user.

For example, a remote user might be signed on to a Communicator Phone Edition IP Phone (an SPOP endpoint) that cannot receive IM. This capability of the endpoint is published by the IP Phone along with the presence information. The user's presence status on the phone is online. Another user can view the online presence status and attempt to send an IM using Communicator. However, since presence has already published the device capability, a notification is shown that the remote user is not on an IM-capable device and therefore may not receive the message.

Another example is for auto-accepting IM. Whenever an IM conversation is started, the message is auto-accepted immediately if the remote user is on a single Communicator instance (again, an SPOP endpoint). But if the remote user is signed on to two Communicator instances (say a laptop and a desktop), then a 10-second delay is provided to allow the user to accept the instant message from one device. When there is no answer, the instant message is auto-accepted on the most active Communicator instance.

Presence

Presence has an important role to play in unified communications. It allows a user to know beforehand about the availability of the remote user to communicate via a given mode. Thus, the OCS states, such as "busy—in a call," are associated with a user's busy state rather than a device or a line being busy. Additionally, OCS 2007 provides an enhanced presence infrastructure that allows the user to share information such as location, working hours, and meeting times.

In addition, OCS allows the user to specify permissions so that different groups of people can have access to different sets of presence information based on their access level. OCS also employs a user's presence state, such as "Do Not Disturb," as well as the calendar working hours and the permission level provided to the caller to make routing decisions on whether the call should ring the user or should be sent to voicemail.

The phone numbers that are displayed in click to call in Office Communicator are sourced from three locations—two are directory-based (Global Address List/Address Book Server and Outlook contacts), and the third is through presence. Using presence, users have the flexibility to publish the phone numbers that they want other people to see.

Presence plays a key part in a lot of voice routing scenarios as well. For example, if the presence for a remote user indicates Busy and shows the text In a Meeting, then the likelihood the user will pick up a voice call is low. In that case, the caller may prefer to use IM or e-mail. Similarly, when the presence for a remote user is Do Not Disturb, then it is an indication that alternate means of communication may be preferred.

Presence also carries information about a user's current meeting title and calendar location, and this details is published to users in the Team container. Presence carries information about the preferred endpoint for a certain capability, and this is used to elect an endpoint that will take a default action. For example, calendar data publication (which is essentially the same at all endpoints) will be done only from a preferred endpoint for calendar capability. OCS has the logic to elect preferred endpoint.

Figure 3 highlights the various capabilities that presence brings to the OCS system. Presence, as stated earlier, is a combination of availability and willingness to communicate. The Online state represents the state where the user is most willing to communicate, and Do Not Disturb is the presence state where the user is least willing to communicate. Except for Do Not Disturb, which has to be manually set, all the other states are automatically captured by Communicator based on various conditions such as whether the user is in a meeting (busy) or is away from the computer (inactive, then away), as shown in Figure 4.

Figure 3 How presence information is set

Figure 4** Presence as a mix of availability and willingness **(Click the image for a larger view)

Note that availability can be driven by various different devices that the user is currently signed on to. Because there are several devices for the same user and each device publishes presence information and user data from the device, there needs to be an aggregation logic that presents one view to watchers. OCS has such an aggregation logic that computes the presence based on various parameters, devices, and inputs that are received by the presence system.

Before delving into aggregation, it is worth taking a look at how the aggregated information is published to users. OCS 2007 introduced the concept of containers, which are somewhat analogous to access levels associated with social circles. Each container provides a different amount of information, and people who are added to a specific container only have access to information that is made available to that container. Everyone in the user's buddy list has to be present in one of the available containers. Office Communicator allows the user to assign people to containers or move them to different containers based on the level of the relationship. Office Communicator uses smart heuristics to select the default container (listed in Figure 5) automatically.

Figure 5 Presence containers

Presence aggregation in OCS determines the correct presence for the user based on various presence states that devices report to the server. Figure 6 illustrates how presence is aggregated from a variety of sources. Note that some information, such as presence state and user activity, is sent through the OCS presence aggregation mechanism before the information is made available in the containers, and other information, such as contact details, is added by the client endpoints to the respective containers. The blocked container is missing because no information other than the membership information is published to that container.

Figure 6** Presence aggregation and publishing **(Click the image for a larger view)

In the OCS system, a presence relationship is established when one user adds another user to the contact list (buddy list). But the OCS system also allows you to see the presence of other users in the corporate directory without having to add these users individually to your contacts.

The simplest way to get presence for someone is by searching for someone in Office Communicator. This generates a single query on the server and does not subscribe to notifications from the server about remote users' presence status changes. However, when a user adds another user to his buddy list, he subscribes for notifications on the presence status changes so OCS automatically sends alerts whenever there is a change.

IM and Audio

IM takes advantage of both registration and presence. In the OCS system, messages travel peer to peer and the OCS server performs as a proxy that shuttles the messages between Office Communicator clients.

The first message that a user initiates to another user is an important one. It establishes the session, in SIP parlance. Part of establishing the session is to find the right MPOP client from the registered clients, and this is where OCS plays an important role as a proxy. Once the user accepts the incoming IM session, or if one of the user's MPOP endpoints auto-accepts, then subsequent messages travel smoothly end to end without requiring OCS to find an appropriate client.

Users can leave their IM conversation windows open on their desktops, and Office Communicator 2007 will end the SIP session if there is no activity within a 10-minute interval (though the IM window will stay open). Either side can also terminate the IM session. Whenever the IM session is terminated, Office Communicator 2007 will automatically create a history item for the conversation that records the entire conversation in the Outlook Conversation History folder. This is a special folder that is created in Outlook by Office Communicator. This client-side logging capability is optional and is turned off by default. Conversation History is used by Office Communicator in restarting a conversation with the same user; thus, users that turn on this feature will have a better experience for continuing the IM conversation after the IM window is closed.

Note that the IM constructs presented here for forking and MPOP pretty much apply to the voice scenario as well. Instead of the invitation containing an IM session description, it would contain a voice session description indicating audio capability. OCS would apply forking to the voice call to all endpoints, similar to what it applies for IM.

Voice signaling derives a lot from the concepts of IM, but it introduces the need to handle media. I plan to cover this more in a future article.

Rajesh Ramanathan has worked in the communications space for 14 years and currently works as Lead Program Manager on the Office Communicator team. He can be reached at rajeshra@microsoft.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.