Front End Server

RTCSrv.exe

The RTCSrv.exe process is the core Office Communications Server process and therefore runs on every Office Communications Server. RTCSrv.exe hosts the User Services module, the server API module, the archiving module, and the SIP Proxy. The User Services module, server API module, and archiving module sit on top of the SIP Proxy. A message dispatcher mediates by sending messages to and from the modules and the SIP Proxy.

Figure 4.   RTCSrv.exe process

SIP Proxy. The SIP Proxy is the core protocol platform on which all other Office Communications Server services are built. The SIP Proxy provides the basic structure for networking and security, and performs connection management, message header parsing, routing, authentication, and state management.

The SIP Proxy, also known as the SIP stack, forms the basis for all other Office Communications Server services. Signaling connections, authentication, message routing, and state management all rely on the SIP Proxy.

User Services. The User Services module enables the instant messaging (IM), presence, and conferencing features of Office Communications Server. The presence components of the User Services module are explained in more detail in the Presence Components section later in this topic. The User Services module includes the Focus and Focus Factory, which are explained in more detail in the Conferencing Components section later in this topic. The following table describes the functionality provided for User Services.

Table 1   User Services

Archiving. The Archiving and CDR module, also known as the archiving and CDR agent, is installed on every Front End Server when you deploy Office Communications Server Standard Edition server or Enterprise Edition server.

The Archiving and CDR module connects to the Archiving and CDR Server (running in one of several possible physical topologies) using Message Queuing (MSMQ) technology. The Archiving and CDR Server receives instant messages and call data from the archiving and CDR agent and stores the information in a SQL database. For more information about archiving, see the Archiving and CDR section later in this guide.

API. The Office Communications Server API is built on the SIP proxy platform and implemented using the following:

• Server API module (Apiem.dll), which is an extension that provides the basic scripting capability for creating custom message filters and routing applications. The scripts can either run in process with Office Communications Server (Rtcsrv.exe) or can be incorporated in a managed server application that is running in a separate process.

• Managed server API platform (ServerAgent.dll), which is used to implement both Microsoft and non-Microsoft managed server applications. Managed server applications that are written using the managed server API run as separate processes.

• Local shared-memory IPC (Queue.dll), which is the interface between the server API module and managed applications.

• Internal COM API to communicate with the SIP proxy platform.

Figure 5 shows how the API architecture is implemented for Front End Servers.

Figure 5.   Server API architecture on Front End Servers

SIP-aware managed server applications that are developed using the managed server API platform extend the core services available in Office Communications Server. Managed server applications include both of the following:

• Office Communications Server 2007 applications implemented using RTCHost.exe. This includes including filtering applications, VoIP applications, Conferencing Server Factory, RTC Aggregate application, and other applications (non-Microsoft applications). For more information about the managed server applications implemented with RTCHost.exe, see the RTCHost.exe section later in this topic.

• Non-Microsoft applications developed in-house, by vendors, or using other resources.

The managed server API for implementing these applications functions as follows:

• Is exposed through the Microsoft.Rtc.Sip namespace.

• Uses the server API to perform specific SIP message processing tasks.

• Is implemented using the managed server application platform (ServerAgent.dll assembly). Each managed application loads the ServerAgent.dll and executes in its own process space. Managed applications are isolated from each other in a way that prevents a faulty application from affecting other applications.

The two major components of the server API module (Apiem.dll) that support implementation of managed server applications are the following:

• Application manifest, which is a script that is written using Microsoft SIP Processing Language (MSPL) and describes an application to the server. When a managed server application registers with the server using the ServerAgent class, it provides this script to the server. The application manifest serves the following purposes:

  • Provides details about the application type and the state that the server needs to maintain for the application to run, so the server can optimize processing for the application.

  • Contains a message filter script to communicate detailed information about which messages (requests and responses) the application needs to see. To filter messages, the application manifest has a set of built-in actions that it can invoke. For any other actions required by a specific message (that cannot be handled by the built-in actions), the application manifest can invoke managed code in a separate application process by passing all or parts of the message to the code in the application process. Using the built-in actions helps avoid cross-process calls for simple processing (such as basic if, then, and else functions).

  • Makes it possible for the application developer to specify moderate amount of logic to be executed by an interpreter inside the server API module. If the functionality of the interpreter is not sufficient, a cross-process call is made as a single call containing only the portions of the message that are appropriate to the message filtering used.

  • Uses an application URI to uniquely identify the application to the server. The application URI is expected to be an HTTP URL, but no validation is performed.

• Microsoft.Rtc.Sip class library, which contains the following classes:

  • SIP message and transaction processing classes.

  • ServerAgent class. This class implements most of the logic needed to manage sessions with the server. It is the entry point for the managed server API. Each application initiates an instance of ServerAgent.dll and supplies an application manifest instance to it. The ServerAgent.dll assembly manages the session with the server, including compiling the application manifest and registering with the server. If the registration succeeds, the ServerAgent class sets up the environment necessary to receive and process SIP messages from the server. The ServerAgent.dll assembly invokes application-specific event handlers for specific events, such as message events and transaction events. For each instance of the application, a single ServerAgent.dll object manages the applications session with the server. To exit, the application releases the ServerAgent.dll object, which causes the session with the server to end.

    You can use the Office Communications Server 2007 Software Development Kit (SDK) to develop applications using the Microsoft.Rtc.Sip class library. You can download the SDK at https://r.office.microsoft.com/r/rlidOCS?clid=1033&p1=sdk. For information about using the SDK, see Microsoft Office Communications Server 2007 SDK at https://r.office.microsoft.com/r/rlidOCS?clid=1033&p1=sdkdoc.

RTCHost.exe

RTCHost.exe sits on top of the server API module. The following applications run inside the RTCHost.exe process:

• Intelligent IM Filter

• Client Version Filter

• VoIP applications: Inbound Routing application, Translation Service, and Outbound Routing application

• Conferencing Server Factory

• RTC Aggregate application

The Intelligent IM Filter helps to prevent unsolicited marketing that targets instant messaging programs. The Intelligent IM Filter uses settings configured by the administrator, in order to filter incoming instant messages received by the server from outside the organizations firewall. You can configure the Intelligent IM Filter by using the user interface in the server management snap-in (MMC).

The Client Version Filter enables the server to deny client connections based on a clients version number. The Client Version Filter compares a clients version number with the version settings specified by the administrator by reading the clients SIP User-Agent header. You can configure the Client Version Filter by using the user interface in the server management snap-in (MMC).

The VoIP applications that run inside RTCHost.exe are the Inbound Routing application, Translation Service, and Outbound Routing application. Together, these applications assist the server in routing VoIP calls. The Inbound Routing application determines how incoming calls to the server should be routed based on settings configured on the client. The Translation Service uses administrator-specified phone number normalization rules in order to translate a dialed number into an E.164 format that can be consumed by the PBX or PSTN gateway. The Outbound Routing application uses call authorization rules in order to route each call to the appropriate media gateway. For more information about the VoIP applications that run inside RTCHost.exe, see the Voice Components section later in this topic.

The Conferencing Server Factory handles registration of all Office Communications Server conferencing servers and then coordinates with the Focus in order to assign a conferencing server to a particular conference. For more information about the Conferencing Server Factory, see the Conferencing Components section later in this topic.

The RTC Aggregate application manages the multiple points of presence (MPOP) feature for Office Communications Server by aggregating the presence information published by multiple client endpoints into one presence status that best represents the user's current availability. For more information about the RTC Aggregate application, see the Presence Components section later in this topic.

Back-End

In Office Communications Server, the back-end database stores presence information for users and any state information required to resume a conference. Presence data and conferencing data are stored in different tables of the same physical database.

In a Standard Edition configuration, all server components are installed on the same computer, including the back-end database. The back-end database on a Standard Edition server uses Microsoft SQL Server 2005 Express Edition with Service Pack 2.

In an Enterprise Edition configuration, the back-end database must be configured as a separate dedicated computer. In an Enterprise pool, all servers in the pool share a central Microsoft SQL Server database This database runs on Microsoft SQL Server 2005 with Service Pack 1 (SP1) (32 bit or 64 bit) or SQL Server 2000 with SP4 or later, and it can be clustered in an active-passive configuration for higher availability.

Focus

The Focus is the central policy and state manager for a conference and acts as the coordinator for all aspects of the conference. The 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 clients and providing a conduit for control commands to flow between clients and conferencing servers.

When a new media type must 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, obtains the authorization credentials so 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.

Focus Factory

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.

Conferencing Server Factory

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, which handles all media types.

Conferencing Database

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. In order 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 and 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:

• Conference ID

• Expiration date and time of the conference

• 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

The conferencing database contains the metadata for a conference but does not contain calendar information. Conference calendar information, such as meeting start and end times, the 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 an Exchange Server calendar item.

The Focus stores all conference state information on the Back-End Database Server to ensure that state information is accessible to all Front End Servers. With this model, if a client loses connectivity to the conferencing server, the client can reconnect, and its request can be handled by any Front End Server. This provides a natural failover model for front end failures, as well as temporary loss of network connectivity from client to server. Similarly, information about conferencing server load persists on the Back-End Database Server, so that it is available to a Conferencing Server Factory instance running on any Front End Server. This data is written by a Conferencing Server Factory to the database, but any conferencing server for a particular media type under the control of the Conferencing Server Factory can read the database.

Inbound Routing

The Inbound Routing application determines how incoming calls to the server should be routed. If an Enterprise Voice client specifies settings for handling missed calls, the Inbound Routing application acts accordingly. For example, if a client is configured for call forwarding, the Inbound Routing application can forward incoming calls either to a specified number or to an Exchange Server 2007 Unified Messaging server that can answer the call.

Translation Service

The Translation Service applies administrator-specified phone number normalization rules in order to translate a dialed number into an E.164 format that can be more easily consumed by a PBX or PSTN gateway. Enterprise Voice in Office Communications Server employs the Translation Service to normalize phone numbers into a single format. Normalized phone numbers assist the server with reverse number lookup, outbound call routing, and call authorization rules.

Reverse number lookup is a process whereby a user's phone number is mapped to the appropriate SIP URI. By performing reverse number lookup, the server can route calls to all endpoints associated with a particular users SIP URI. Reverse number lookup also enables advanced call handling features, such as call forwarding.

After a dialed number is normalized by the Translation Service, the Outbound Routing application can apply call authorization rules to route the call.

Outbound Routing Component

The Outbound Routing application uses call authorization rules configured by the administrator to route each call to the appropriate media gateway. Call authorization rules in Office Communications Server are similar to traditional telephony "class of service" options. If the Outbound Routing application determines that a caller is not authorized to dial a particular number (for example, numbers outside the organization or international numbers), the Outbound Routing application can inform the caller that the call cannot be completed.