Figure 19-6 illustrates the internal component architecture of Office Communications Server 2007.
The Office Communications Server process of the front-end server contains the following components:
The following sections will describe each of these components in more detail.
The two core components that make up Office Communications Server are RTCsrv.exe and RTChost.exe. RTCsrv.exe is the core process of the Office Communications Server, and RTChost.exe hosts several different applications that sit on top of the Server API module. Both RTCsrv.exe and RTChost.exe are explained in more detail in the following sections.
The rtcsrv.exe component is the core process of Office Communications Server. (See Figure 19-7.) This process includes the User Services (ES) module, server API module, archiving module, and the SIP Proxy. As shown in Figure 19-7, all these modules sit on top of the SIP Proxy, and a message dispatcher is used to send messages back and forth between the modules and the SIP Proxy.
Understanding the SIP Proxy The SIP Proxy (also known as the protocol stack or SIP stack) is the core protocol platform on which all other services are built. It provides the basic structure for networking and security, and it performs connection management, message header parsing, routing, authentication, and state management.
Understanding User Services Module The User Services module provides closely integrated IM, presence, and conferencing features built on top of the SIP Proxy. It also includes the Focus and Focus Factory, which are explained in more detail in the "Examining Conferencing Components" section later in the chapter.
As shown in Figure 19-7, all the presence and conferencing data is stored in a SQL Server back end. The data passed from the User Services module is passed through the Database Queuing Layer (ODBC). Open Database Connectivity (ODBC) provides a standard API that is used to run SQL queries against the SQL Server back end.
The user replicator, shown as UR in Figure 19-10, is used to update the user database to be synchronized with Active Directory. The Address Book Server uses information provided by the user replicator to update information from the global address list.
Also, as shown in Figure 19-7, the User Services module on each front-end server communicates with other front-end servers using remote procedure calls (RPCs) to the same process.
Understanding the Archiving Module The archiving module is an agent that connects to the Archiving Server using MSMQ. The Archiving Server either has its own database or connects to a database on a different computer that stores all the archived data. Figure 19-8 illustrates the archiving architecture in Office Communications Server 2007.
The Enterprise Pool, Standard Edition server (or the Proxy Server if configured for archiving) activates the archiving agent. The archiving agent then checks all outgoing SIP messages on the Office Communications Server to determine whether it should be archived and in what form. This requires the archiving agent to look up the archiving settings for the sender and receiver of the message (set per user). Based on these archiving settings, the archiving agent takes one of the following actions:
Do not archive.
Send message for archiving.
When messages are sent for archiving, the archiving agent queues the message to the configured MSMQ. The archiving service is listening to the destination message of the MSMQ and on receiving this message, it writes it to the designated SQL server.
Understanding the API Module The server API module provides basic scripting capability for creating custom message filters and routing applications. The scripts can either run in process or, where required, can be dispatched to a managed code application that is running in a separate process. Figure 19-9 shows what the managed server API architecture looks like.
The core Proxy Platform performs various core SIP-message processing tasks such as parsing, transports, compression, authentication, and transaction state management. The message-processing duties are further extended using three native extension modules: User Services (responsible for Message Authorization, Registration and Presence services, and Conferencing services), the API Extension Module (responsible for hosting and managing managed server applications and shown as APIEM in Figure 19-8), and Content Logging (archiving service). These extension modules run in-process inside RTCSRV.exe, and they use a proprietary internal COM API to communicate with the Proxy Platform.
There are managed applications written using the managed API that run out of process to Office Communications Server. These are full-fledged SIP-aware applications that use the Server API to perform various message-processing tasks. The Managed Server API is exposed via the Microsoft.Rtc.Sip namespace and is implemented in the ServerAgent.dll assembly. Each managed application loads the ServerAgent.dll and executes in its own process space. Applications are isolated from each other in the sense that a faulty application is guaranteed not to affect other applications. The ServerAgent.dll uses a proprietary shared-memory message passing, Inter-Process Communication (IPC), to communicate with the APIEM, and this is completely abstracted from the application developer.
The two major components of the Server API are the application manifest and the Microsoft.Rtc.Sip class library. The application manifest is a script written using Microsoft SIP Processing Language (MSSPL), and it describes an application to the server. It is presented to the server when the application registers itself with the server via the ServerAgent class. It fulfills multiple roles, which include providing details about the type of application and the state it needs the server to maintain. This allows the server to optimize its efforts for that application. The application manifest contains a message filter script that allows an application to specify, to a fine grain, which messages (requests and/or responses) it is interested in seeing. For messages that the application decides it cares about, it has a set of built-in actions it can invoke. For applications in which the built-in actions are not sufficient for all their needs, there is the ability to call out to managed code in a separate application process, passing all or parts of the relevant message to the code in the application process. The intent is to avoid cross-process calls to do simple if/then/else processing that will decide to not handle the message. The application manifest provides the application writer the ability to specify a fair amount of logic that is executed by an interpreter inside the APIEM. Only when the functionality of the interpreter is insufficient does a cross-process call occur, and then it occurs once and contains only the portions of the message the application cared about. The application manifest contains an Application URI that uniquely identifies this application to Office Communications Server. This URI is expected to be an HTTP URL, but the resource referred by the HTTP URL is not validated.
The Microsoft.Rtc.Sip class library contains various classes to help with SIP message and transaction processing. In addition, the class library contains the ServerAgent class that implements the bulk of the logic needed to manage sessions with the server. The ServerAgent class is the entry point for the managed Server API. Each application instantiates an instance of ServerAgent and supplies an ApplicationManifest instance to it. The ServerAgent is responsible for managing the application's session with the server. It compiles the ApplicationManifest and registers itself with the Office Communications Server 2007 server. If the registration succeeds, it sets up the environment necessary to receive and process SIP messages from the server. Application-specified event handlers are invoked by the ServerAgent for various events such as message events and transaction events. When the application decides to exit, it disposes of the ServerAgent object, which in turn closes the session with the server. At any point in the lifetime of the application, there is exactly one ServerAgent object that is managing the application's session with the Office Communications Server 2007 server.
Understanding WMI Consumers Windows Management Instrumentation (WMI) consumers are the final layer in the WMI infrastructure. A consumer can be a script, an enterprise management application, a Web-based application, or some other administrative tool such as the MMC that accesses and controls management information available through the WMI infrastructure. When you administer your Office Communications Server deployment, these settings get pushed through WMI, then get sent to the Message Dispatcher for message processing.
RTChost.exe hosts sit on top of the Server API module and host several applications that run inside it. These applications fall under five categories: the Intelligent IM Filter, Client Version, VoIP Applications, the Conferencing Server Factory, and the RTC Aggregate Application.
Understanding the Intelligent IM Filter The Intelligent IM Filter filters incoming IM traffic by using administrator-specified criteria. It is used to block unsolicited or potentially harmful IM items from unknown endpoints outside the corporate firewall.
Understanding the Client Version The client version application is responsible for checking the version in the header information. It checks version information to decide which client applications are allowed to talk to the server. It can be configured using the user interface available as part of the management snap-in.
Understanding the RTC Aggregate Application The RTC aggregate application handles the aggregation of presence information across multiple endpoints. When a user is logged on to multiple devices, each device publishes presence information for its device. The RTC aggregate application ensures that it takes all presence information and aggregates it to produce one presence status that represents all devices. More information on presence and aggregation can be found in the "Examining Presence Components" section.
Understanding the Conferencing Server Factory All conferencing servers register themselves with the Conferencing Server Factory. When the focus requests a particular conferencing server for a meeting, the Focus sends the request to the Conferencing Server Factory, which determines which conferencing server is available to service the request and returns its URL to the Focus. More details on the Conferencing Server Factory can be found in the Examining Conferencing Components section.
Understanding the VoIP Applications The VoIP applications can be divided into the following three types of applications: inbound routing, translation services, and outbound routing. Each of these applications is discussed in the Examining VoIP Components section.
In the "Examining Core Components" section, we discussed the User Services module. One of the responsibilities of the User Services module is to process registration requests as well as presence information. The User Services module comprises the registration and presence components. See Figure 19-10.
Every time a user sends a REGISTER request, the REGISTER subcomponent caches the endpoint route information so that we can avoid a database lookup while routing requests. The SERVICE subcomponent processes all SERVICE requests. The SUBSCRIBE subcomponent processes all SUBSCRIBE requests, and the NOTIFY subcomponent generates and sends NOTIFYs from the User Services module. Each of these subcomponents goes through the ODBC to store the registration and presence data in a SQL Server back-end database.
When a user is logged on to multiple devices, each device publishes presence information for its device. The RTC aggregate application, a managed, server application that runs on top of the Server API module, ensures that it takes all presence information from all endpoints, aggregates it, and produces one presence status that represents all devices. The SPL Access Layer provides the RTC aggregation application access to the database for user information that is exposed by this SPL script.
This section describes the conferencing components and the relationship between these components. It will also show the proposed process boundaries for the various components.
The main conferencing components of Office Communications Server are the Focus instances, Focus Factory, Conferencing Server Factory, and conferencing servers (also known as MCUs) for each media type. SQL Server databases are used for storing the persistent state. (See Figure 19-11.)
The Focus Factory and Focus components run in the main conferencing process, which is also the SIP proxy process. The Conferencing Server Factory is a fairly lightweight component that is accessed by the Focus once for each media type when that media type needs to be activated for the conference. The Conferencing Server Factory is an application running on each front-end server and uses an HTTP interface. Communication between the Focus and conferencing servers and between the Conferencing Server Factory and conferencing servers is HTTP based.
The Focus is the central policy and state manager for a conference and acts as the coordinator for all aspects of the conference. A Focus is responsible for enforcing the conference control policy, managing the overall security for a conference, managing conference participant roles and privileges, sending conference state notifications to the clients, and providing a conduit for control commands to flow between clients and the conferencing servers. Figure 19-12 shows what the internal components of the Focus look like inside the User Services module.
When a new media type needs to be activated for a conference, the Focus also instantiates the conference on the appropriate conferencing server, communicates with the conferencing server about adding a new user, fetches the authorization credentials so that the client can connect to that conference, and then sends the media information to the client. The same sequence is repeated for all clients who want to add this media. When a new media type is added to the conference, the sequence is repeated with the new conferencing server for that media type. By centralizing the security enforcement and roster management, the Focus relieves each of the conferencing servers of this duty.
The Focus Factory is a SIP entity that creates, deletes, and modifies meetings in the conferencing database. The Focus Factory manipulates meetings in the conferencing database according to C3P commands issued by clients.
The Conferencing Server Factory is responsible for provisioning a conference for a particular media type on a conferencing server. The Conferencing Server Factory can also take into account the current load on the conferencing servers before assigning a conferencing server to a conference. There is one Conferencing Server Factory instance on each front-end server that handles all media types.
A Focus holds important information for the entire conference, including all conference participants. If a Focus instance fails, it must be possible to restart the conference. To support this, any state information needed to resume the conference persists in a conferencing database, which runs on the SQL Server back end. In Office Communications Server, presence/registrar information and conferencing information are stored in different tables of the same physical database.
The important metadata associated with a conference in the conferencing database includes the following:
Conference ID
Expiration date and time of the conference
A list of meeting participant roles and the privileges associated with those roles
Conference key for participants without an identity in Active Directory
Supported media types
Authorization types, such as closed, open, and anonymous
As mentioned in the Understanding the Focus section, a conferencing database contains the metadata for a conference but does not contain calendar information. Supporting a meeting start time and end time, recurrence schedule, and exceptions to recurrence are all important for a prescheduled conference, but that information is maintained outside of the conferencing database. Instead, conference calendar information is maintained by scheduling clients, as appropriate, typically as a Microsoft Exchange Server calendar item.
The principal VoIP components on the front-end server are as follows:
Each of these components runs inside the rtchost.exe, which resides on top of the server API module. Each of these components is an application that helps with the routing of VoIP calls. Each of these components is discussed in more detail in the following sections. The architecture diagram in Figure 19-13 shows the translation service, inbound routing, and outbound routing components.
The Translation Service is the server component that is responsible for translating a dialed number into E.164 format according to the normalization rules that are defined by the administrator.
Phone number normalization is the process of translating number strings that are entered in various formats into a single standard format. Enterprise Voice requires normalized phone numbers to do the following:
Provide a consistent reference for reverse number lookup. Reverse number lookup is the process of mapping a user's number to a corresponding SIP-URI for the purpose of routing calls over the IP network to multiple user endpoints, including Office Communicator, the Office Communicator Telephone Experience, and call-handling options such as call forwarding and call answering.
Identify and apply phone usage authorization (comparable to traditional "class of service" options) for the calling party.
Route calls to the appropriate media gateway.
Communications Server 2007 normalizes numbers prior to performing reverse number lookup. If the normalized number matches the designated primary work number of a user with an Active Directory identity, the call is forked to the endpoints associated with that user's SIP-URI. If the server does not find a match, which means the target number is probably outside the enterprise, the Outbound Routing component checks the caller's phone usage to determine if a call to that number is authorized, and then either directs the call to the appropriate media gateway or notifies the caller that the call is not allowed.
The Inbound Routing component handles incoming calls largely according to preferences that are specified by users on their Enterprise Voice clients. For example, users specify whether unanswered calls are forwarded or simply logged for notification. If call forwarding is enabled, users can specify whether unanswered calls should be forwarded to another number or to an Exchange 2007 Unified Messaging server that has been configured to provide call answering. The Inbound Routing component is installed by default on all Standard Edition servers and Enterprise Edition front-end servers.
The Outbound Routing component routes calls to PBX or PSTN destinations. It applies call authorization rules to callers and determines the optimal media gateway for routing each call. The Outbound Routing component is installed by default on all Standard Edition and Enterprise Edition servers and on Enterprise Edition front-end servers.
The routing logic that is used by the Outbound Routing Component is in large measure configured by network or telephony administrators according to the requirements of their organizations.