Office Communications Server 2007 R2 Technical Reference Guide

(1)

Microsoft Office Communications

Server 2007 R2

Technical Reference

Published: July 2009 Updated: October 2009 Updated: April 2010

For the most up-to-date version of the Technical Reference documentation and the complete set of the Microsoft® Office Communications Server 2007 R2 online documentation, see the Office Communications Server TechNet Library at http://go.microsoft.com/fwlink/?LinkID=132106. Note: In order to find topics that are referenced by this document but not contained within it, search for the topic title in the TechNet library at http://go.microsoft.com/fwlink/?LinkID=132106.

(2)

This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. Copyright © 2010 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Outlook, SQL Server, Visio, Visual C++, Windows, Windows Media, Windows PowerShell, Windows Server, and Windows Vista are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.

(3)

Table Details... 165 ClientVersions Table... 165 Computers Table... 166 ContentTypes Table... 166 Dialogs Table... 166 Pools Table... 167 Users Table... 167 Conferences Table... 167 ConferenceMessageRecipientList Table...168 ConferenceMessages Table...169 SessionDetails Table...170 Messages Table... 172 CDR Database Schema... 173 List of Tables... 173 Static Tables... 173 Supporting Tables...173

Tables Specific to Conference CDR Records...174

Tables for Messages in IM Conferences...174

Tables for Peer-to-Peer Sessions...175

Table for VoIP Call Details...175

Tables for Troubleshooting...175

Tables for Internal Use by Office Communications Server...176

Table Details... 176 MediaList Table... 176 Roles Table... 177 UserAuthTypes Table...177 ClientVersions Table... 178 Computers Table... 178 Pools Table... 178 Dialogs Table... 178 Gateways Table... 179 Mcus Table... 179 Users Table... 180 Phones Table... 180 Conferences Table... 180 FocusJoinsAndLeaves Table...182

(7)

McuJoinsAndLeaves Table...183 ConferenceMessageCount Table...184 SessionDetails Table...185 FileTransfers Table...187 Media Table... 188 VoipDetails Table... 188 Application Table... 190 ErrorDef Table... 190 ErrorReport Table... 191 ProgressReport Table... 191

Sample Database Queries...192

QoE Database Schema...193

List of Tables... 193

Table Details... 194

Sample Database Queries...217

Message Queuing Architecture and Configuration for Archiving...218

Message Stamping... 220

Creating a Third-Party QoE Solution...220

Infrastructure Requirements and Prerequisites of Monitoring Server...220

Deploying a Custom QoE Solution...224

WMI Reference for QoE Solutions...224

Enabling or Disabling an HTTP Proxy for QoE Solutions...226

Edge Servers Drilldown... 227

Response Group Client Web Service Drilldown...227

Service Descriptions...227

Client DNS Queries Drilldown...228

Application Server Drilldown...228

Characteristics of the Office Communications Server 2007 R2 Application Server...229

Architecture... 229

Other Key Application Server Characteristics...231

Application Server Configuration...231

Application Server Application Configuration...232

Global Settings... 232

Pool Settings... 232

SIP Trunking Drilldown... 232

SIP Trunking Drilldown: Supported Scenarios...233

SIP Trunking Drilldown: Supported Topologies...233

SIP Trunking Drilldown: Security Considerations...235

SIP Trunking Drilldown: Bandwidth Considerations...236

SIP Trunking Drilldown: Protocol Flow and Details...237

SIP Call Flow and State Machine...237

Call Hold... 237

Dual-tone multifrequency (DTMF)...238

Early Media... 238

Uniform Resource Identifier (URI) Formatting...238

(8)

SIP Trunking Drilldown: High Availability...239

Address Book Server Drilldown...239

Address Book Server Introduction...241

Introduction... 241

Address Book Server: File and Database Generation...242

Address Book Server Data Flow...242

Address Book Server Process...242

Address Book Server: Address Book File Download Service...245

File Generation... 245

Organizational Unit and Address Book File Generation...248

Client and Address Book Server Communication...248

Address Book and Office Communicator...249

Client Download Process...250

Internet Explorer Dependencies...251

File Store Recommendations and File Size Guidelines...251

Office Communicator Local Address Book Database Files...251

Address Book and Office Communicator Phone Edition...252

Address Book Web Query Service...252

Address Book Server: Address Book Web Query Service...252

Office Communicator Address Book Queries ...254

Queries on Display Name ...256

Queries on Phone Numbers ...257

Sorting Query Results... 258

Predictive Text Queries... 258

Address Book Web Query Database...259

Address Book Web Query Database Language Support...259

Address Book Web Query Server Performance...260

Address Book Server: Advanced Address Book Features...260

Management of Office Communications Server 2007 R2...266

Administrative Tools Overview...266

Administrative Tools...267

Permissions... 270

Installation and Use of Administrative Tools...270

Version Restrictions... 271

Remote Administration Requirements...271

Installing Administrative Tools...272

Troubleshooting for Office Communications Server 2007 R2...274

Load Balancers for Office Communications Server 2007 R2...274

Prerequisites for a Load Balancer Connecting to a Pool...274

Load Balancer Requirements...275

Supported Load Balancer Configurations...277

Media Ports... 278

Mediation Server for Office Communications Server 2007 R2...278

Media Gateway... 279

(9)

Minimum Number of Ports...279

Server Port Allocation...286

Voice Quality of Service (QoS)...287

QoS with Office Communications Server 2007 R2...287

Enabling DSCP Marking...288

Enabling QoS... 289

Installing the QoS Packet Scheduler on Computers...292

Verifying Group Policy Settings on Computers...293

WMI Settings for Office Communications Server 2007 R2...294

Client Registry Keys/GPO for Office Communications Server 2007 R2...294

In-Band Provisioning over SIP...294

Why Use In-Band Provisioning?...296

Office Communicator 2007 R2 Group Policy Precedence...297

Policy transport... 297

(10)

Office Communications Server 2007 R2

Technical Reference Guide

This document provides detailed technical reference information for administrators who are deploying, have deployed, or are administering Microsoft Office Communications Server 2007 R2. This information is not necessary for day-to-day management of your Office Communications Server deployment, but it can be useful if you are troubleshooting an issue, or if you are

implementing a solution or developing an application that requires more technical detail than the basic documentation provides.

The information in this document supplements and should be used in conjunction with the rest of the Office Communications Server 2007 R2 documentation set. Additional resources for technical questions that are not covered here are as follows:

• The Technical Overview in the Getting Started documentation.

• The Microsoft TechNet portal for Office Communications Server at

http://go.microsoft.com/fwlink/?LinkID=144770, which includes technical forums where you can ask specific questions.

If you have specific questions, comments, or suggestions for this Technical Reference, please contact us at [email protected]. We are always glad to hear from you.

Note:

You can download the Office Communications Server 2007 R2 Technical Reference Guide as a Word file from the Microsoft Download Center at

http://go.microsoft.com/fwlink/?LinkID=159649. In This Document

• Office Communications Server 2007 R2 Architecture

• Scenarios for Office Communications Server 2007 R2

• Technical Drilldowns

• Management of Office Communications Server 2007 R2

Office Communications Server 2007 R2

Architecture

After providing a brief overview of the Office Communications Server 2007 R2 topology and component architecture, this section describes the architecture of the pool components in detail and the protocols that the components use to interact with each other.

In This Section

(11)

• Topology and Component Architecture

• Pool Components for Office Communications Server 2007 R2

• Communication Protocols for Office Communication Server 2007 R2

Topology and Component Architecture

The following figure shows a sample Office Communications Server 2007 R2 topology and the protocol flow in that topology.

Office Communications Server can be installed in several configurations, starting with a single Standard Edition server for simple/common installations to multiple Enterprise Edition servers where high availability at scale is a requirement.

Standard Edition (Single Server Installation)

Office Communications Server 2007 R2, Standard Edition contains the same server components as Enterprise Edition. However, in this configuration all the server components required to provide presence, instant messaging (IM), multiparty Web conferencing and desktop sharing, and

audio/video (A/V) conferencing are installed on a single computer. All voice components and applications are also installed on the same computer. In a Standard Edition configuration, the Back-End Database Server also runs on the single physical server. Thus, all elements share the same server resources.

(12)

This configuration is designed to support a small number of users and concurrent meetings and is not designed to scale to larger deployments. Ease of installation and server management are the primary goals for this type of server installation.

Enterprise Edition

An Enterprise Edition server can provide an organization with scaling and high availability. Enterprise Edition servers are deployed in a pool regardless of whether there is one server or multiple servers. An organization can deploy Enterprise Edition configuration by using a single Enterprise Edition server, with or without a hardware load balancer, or multiple Enterprise Edition servers behind a hardware load balancer. Multiple servers provide high availability such that, if one Front End Server fails, clients can detect the failure and automatically reconnect to one of the other Front End Servers.

Consolidated Configuration

Consolidated configuration is the recommended topology for most organizations, both in terms of scaling and simplified administration.

In Office Communications Server, each Front End Server in an Enterprise Edition consolidated configuration includes registration, presence, routing, conferencing, and enterprise telephony functionality. Each Front End Server runs an instance of the Focus, Focus Factory, Conferencing Server Factory, and all conferencing servers. Each Front End Server also runs an instance of all voice applications (for example, Voice Inbound and Outbound Routing, Outside Voice Control, Response Group Service, Communicator 2007 R2 Attendant, and Conferencing Announcement Service). The most important aspect of this architecture is that all Front End Servers are equivalent in functionality. The same software components (that is, Focus, Focus Factory, Conferencing Server Factory, conferencing servers, and voice applications) are installed on all the Front End Servers. A consolidated configuration helps simplify setup and management, while still providing high scalability, availability, and failure recovery.

Expanded Configuration

Expanded configuration was introduced in Office Communications Server 2007. The primary advantage of the expanded configuration in Office Communications Server 2007 was its ability to scale in very large deployments. However, the scalability limitations of consolidated configuration, which is simpler to deploy, have been removed in Office Communications Server 2007 R2, and consolidated configuration is now the preferred topology for most organizations.

In an Enterprise Edition expanded configuration, the A/V Conferencing Server and Web Conferencing Server server roles are distributed and run on separate servers. Expanded configuration is no longer a recommended scenario and requires command-line installation and configuration in Office Communications Server 2007 R2.

(13)

Pool Components for Office Communications

Server 2007 R2

In This Section

This section includes the following topics:

• Overview of Pool Components

• Common Infrastructure Components

• Conferencing Components

• Voice Components

Overview of Pool Components

Office Communications Server supports the following three scenarios or workloads: instant messaging (IM) and presence, conferencing (including Web conferencing, desktop sharing, audio/video conferencing), and Enterprise Voice, which encompasses telephony. This section describes all of the architectural components of an Office Communications Server 2007 R2 Standard Edition server or Enterprise pool. Collectively, these components support all three workloads.

This section focuses on the services that run on the core Office Communications Server roles, the components within those services, and relationships between them. This section does not cover network architecture or deployment architecture, which complement component

architecture. For details about those aspects of architecture, see the Planning And Architecture documentation.

While this section describes components in the context of an Enterprise pool, it also applies to most aspects of a Standard Edition server. All server components (that is, services, database, and so on) described in this section run together on a single instance of a Standard Edition server. This is a typical configuration for simple or relatively small deployments (that is, up to a few thousand users) where high availability is not a requirement.

Conceptually, a pool consists of one or more Front End Servers and one or more databases on the Back-End Database Server with a single SQL Server. In a pool, all persistent states are stored in the database on the Back-End Database Server, so that when a Front End Server component fails, failover can be quick. Figure 1 shows a sample Enterprise pool.

(14)

Figure 1. Sample Enterprise pool

Figure 1 illustrates the components of Front End Servers and the Back-End Database Server. There is a hardware load balancer for the Front End Servers, which are required for an Enterprise pool that has more than one Enterprise Edition server. (If your pool consists of only one Front End Server, which is connected to a separate Back-End Database Server running SQL Server, a load balancer is not required.) All Front End Servers in a consolidated configuration pool are

homogeneous and identical to each other. Therefore, all relevant Office Communications Server services and applications are installed on all Front End Servers in this type of a pool.

On each Office Communications Server 2007 R2 Front End Server, the main components can be classified as follows:

• Common infrastructure components. These components are required for the operation of any Office Communications Server workload, and provide a foundation for conferencing and voice components. The common infrastructure components include:

• RTCSrv. This is the main Office Communications Server service that runs the Office Communications Server Session Initiation Protocol (SIP) stack, performs presence functions, performs directory replication functions and interfaces with the database, hosts

(15)

application interfaces, and has modules to capture archiving and call detail recording (CDR) data.

• Back-end database. This is a SQL persistent store with information on user identities and capabilities that are replicated from Active Directory, user contact lists, and dynamic presence and conferencing data.

• RTCHost. This process hosts several Office Communications Server applications for presence, conferencing, and Enterprise Voice that are required for core functioning of these scenarios.

• OCS Application interfaces. These interfaces enable the applications on RTCHost (as well as third-party applications built on the same API) to interface with the main server process RTCSrv (for example, to inspect the SIP stream).

• Web Components infrastructure. This infrastructure, which is built on Microsoft Internet Information Server (IIS), hosts various HTTP components required for presence, conferencing, and Enterprise Voice functions.

• UCAS infrastructure. The Unified Communications Application Services (UCAS) infrastructure enables Office Communications Server to host robust, scalable, middle-tier server endpoint applications. Several UCAS applications for Enterprise Voice are hosted by this infrastructure.

• Conferencing components. These components include various conferencing-specific components hosted by the common infrastructure discussed previously (for example, an RTCHost application, several web components), as well as a set of conferencing servers which perform mixing functions for IM conferencing, Web conferencing, desktop sharing conferencing, and audio/video conferencing.

• Voice components. These are the additional Office Communications Server components required for enterprise telephony functions. These components include

RTCHost applications for inbound telephony routing, outbound telephony routing, and phone number normalization, as well as UCAS applications for dial-in conferencing, response groups (that is, similar to Automatic Call Distribution for Voice), and Outside Voice Control (which extends enterprise telephony functionality to cellular phones).

Each of these classes of components is described in the topics that follow.

Common Infrastructure Components

The common infrastructure components are required for the operation of any Office Communications Server workload, and provide a foundation for conferencing and voice components. The common infrastructure components include RTCSrv, Office Communications Server application interfaces, RTCHost, the back-end database, presence components, Web components, archiving and monitoring components, and Unified Communications Application Services (UCAS) infrastructure.

In This Section

This section contains the following topics:

(16)

• Office Communications Server Application Programming Interface (API)

• RTCHost

• Back-End Database

• Presence Components

• Web Components Services for Office Communications Server 2007 R2

• Archiving and Monitoring for Office Communications Server 2007 R2

• Unified Communications Application Services (UCAS) Infrastructure

RTCSrv

The RTCSrv.exe process is the core Office Communications Server 2007 R2 process. RTCSrv runs on every Standard Edition server and Front End instance of Office Communications Server 2007 R2. RTCSrv.exe hosts the User Services module, the server application programming interface (API), archiving and call detail recording (CDR), Quality of Experience (QoE), and the Session Initiation Protocol (SIP) Proxy. The User Services module, the server API, archiving and CDR, and QoE sit on top of the SIP Proxy. A message dispatcher mediates by sending messages between these components and the SIP Proxy.

The following figure shows the RTCSrv.exe process. Figure 1. The RTCSrv.exe process

(17)

SIP Proxy

The SIP Proxy is the core protocol platform on which all other Office Communications Server 2007 R2 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 2007 R2 services. Signaling connections, authentication, message routing, and state management all rely on the SIP Proxy.

User Services

User Services enables the instant messaging (IM), presence, and conferencing features of Office Communications Server 2007 R2. For details about the presence components of User Services, see Presence Components. User Services includes the Focus and Focus Factory, which are explained in more detail in Conferencing Components. The following table describes the functionality provided for User Services.

Table 1. User Services

Component Function

User Replicator User Replicator is the component of Office Communications Server 2007 R2 that is responsible for keeping the presence store in the SQL database synchronized with user and contact objects in Active Directory Domain Services (AD DS). User Replicator monitors the data in AD DS and then sends the data through RTCSrv.exe to the SQL database on the Back-End Database Server for storage. User Replicator also monitors user, contact, and group objects to provide content for the Address Book Server files.

RPC between Front End Servers The User Services module on each Front End Server communicates with the same process running on other Front End Servers by using Remote Procedure Call (RPC).

ODBC-based Database Access Layer The User Services module sends presence, registration, and conferencing data to the SQL Server running on the Back-End Database Server through a database queuing layer that uses the Microsoft Open Database Connectivity interface (ODBC). ODBC provides a standard API that Office Communications Server 2007 R2 uses to run SQL queries against the SQL

(18)

Component Function

Server back-end database. Archiving, CDR, and QoE

The archiving and CDR components, are installed on every Front End Server when you deploy Office Communications Server 2007 R2 Standard Edition server or Enterprise Edition server. Similarly, QoE is installed on every Front End Server.

Archiving and CDR, and QoE connect to the Archiving Server and the Monitoring Server (that is, running in one of several possible physical topologies) using Message Queuing (previously known as MSMQ) technology. The Archiving Server receives instant messages from the archiving and CDR agent and stores the information in a SQL database. The Monitoring Server receives call data from the archiving and CDR agent, and QoE data from the QoE agent. For details about archiving and monitoring, see Archiving and Monitoring Drilldown.

Office Communications Server Application Programming Interface (API)

The Office Communications Server 2007 R2 application programming interface (API) is built on the Session Initiation Protocol (SIP) proxy platform and implemented using the following:

• Server API module (Apiem.dll). 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 2007 R2 (Rtcsrv.exe) or can be incorporated in a managed server application that is running in a separate process.

• Managed server API platform (ServerAgent.dll). A platform that you use to implement both Microsoft and non-Microsoft managed server applications. Managed server applications that are written by using the managed server API run as separate processes.

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

• Internal COM API. An API used to communicate with the SIP proxy platform. The following figure shows how the API architecture is implemented for Front End Servers.

(19)

Figure 1. API architecture for Front End Servers

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

• Office Communications Server 2007 R2 applications implemented by using

RTCHost.exe. This includes the following filtering applications: Voice over Internet Protocol (VoIP) applications, conferencing server Factory, Real-time Communications (RTC)

Aggregate application, and other applications (that is, non-Microsoft applications). For details about the managed server applications implemented with RTCHost.exe, see RTCHost.

• Non-Microsoft applications developed in-house, by vendors, or by using other resources. The managed server API for implementing these applications functions as follows:

• Exposed through the Microsoft.Rtc.Sip namespace.

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

• Implemented by using the managed server application platform (that is, 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.

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

• Application manifest. A script that is written by using Microsoft SIP Processing Language (MSPL) and describes an application to the server. When a managed server

(20)

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 (that is, 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 is, those actions 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 you avoid cross-process calls for simple processing (for example, basic if, then, and else functions).

• Enables 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 Uniform Resource Identifier (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. 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 (for example, 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 R2 Software Development Kit (SDK) to develop applications by using the Microsoft.Rtc.Sip class library. You can download the SDK at http://go.microsoft.com/fwlink/?LinkId=144480. For details about using the SDK, see “Communications Server 2007 R2 Server SDK Documentation” at

(21)

RTCHost

RTCHost.exe runs on each Front End server and can be accessed through the Managed Server application programming interface (API) library. The following applications run inside the

RTCHost.exe process:

• The Client Version Filter enables the server to deny client connections based on a client’s version number. The Client Version Filter compares a client’s version number with the version settings specified by the administrator by reading the clients Session Initiation Protocol (SIP) User-Agent header. You can configure the Client Version Filter by using the Office Communications Server Management Microsoft Management Console (MMC).snap-in.

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

• The Intelligent IM Filter helps prevent unsolicited marketing that targets instant messaging (IM) programs. The Intelligent IM Filter uses settings configured by the administrator to filter incoming instant messages received by the server from outside the organization’s firewall. You can configure the Intelligent IM Filter by using the Office Communications Server Management snap-in.

• The Conferencing Server Factory is required for conferencing. For details, see

Conferencing Components.

• The User Pin Service authorizes dial-in conferencing participants that enter in a conference personal identification number (PIN) when joining a conference by using the public switched telephone network (PSTN).

• The VoIP applications that run inside RTCHost.exe are the Inbound Routing application, Translation Service, and Outbound Routing application. Together, these applications enable the server to route VoIP calls. For details, see Voice Components.

• The Exchange UM Routing component handles redirection of missed calls to Exchange Unified Messaging. For details, see Voice Components.

Back-End Database

In Office Communications Server 2007 R2, the back-end database stores configuration

information, contact lists and 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 (SP2) or later.

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 2008 (32-bit or 64-bit) or SQL

(22)

Server 2005 with Service Pack 2 (SP2) or later (32-bit or 64-bit), and you can cluster it in an active-passive configuration for higher availability.

Presence Components

This section describes the presence components and the relationship between these components. It also shows the process boundaries for the various components.

The primary presence components of Office Communications Server 2007 R2 are the User Services module that runs inside the RTCSrv.exe process and the RTC Aggregate application that runs inside the RTCHost.exe process. The User Services module processes registration requests received by a Front End Server and sends presence, registration, and conferencing data to the Back-End Database Server to keep the presence store in the SQL database synchronized with user and contact objects in Active Directory. The RTC Aggregate application aggregates presence information from multiple client endpoints into one presence document.

The following figure shows the presence components. Figure 1. Presence components

Web Components Services for Office Communications Server 2007 R2

The Web Components Services run on Microsoft Internet Information Server (IIS), and enable Office Communications Server clients to perform the following functions:

• Download Address Book Server files to provide Office Communicator with global address list (GAL) information.

• Expand membership in distribution groups and other data that is used by the Web Conferencing Server.

(23)

• Access meeting presentations and other content from Web conferences.

• Host software packages for device updates.

• Host administration for Response Group Service.

Archiving and Monitoring for Office Communications Server 2007 R2

Office Communications Server 2007 R2 includes Archiving and Monitoring functionality as follows:

• Archiving. Designed for enterprise compliance needs, enables the capture and storage of instant messaging (IM) content.

• Monitoring. Designed for enterprise operational needs and enables the following:

• The capture of call detail recordings (CDRs) that include IM, conferencing, and voice and video calls. CDRs include usage information related to voice calls, audio/video (A/V) conversations, application sharing, remote assistance, and Web conferences.

• The capture and viewing of detailed Quality of Experience (QoE) metrics to monitor voice and video quality. QoE data includes statistics about voice and video quality, both for individual calls and aggregate reports.

The following figure shows the archiving and monitoring architecture in Office Communications Server 2007 R2.

Figure 1. Archiving and monitoring architecture in Office Communications Server 2007 R2

The Front-End server hosts an archiving and CDR agent, which is part of the RTCSrv process, to capture archiving and CDR data which is transferred over Message Queuing (also known as MSMQ) to the Archiving Server and Monitoring Server respectively. The Archiving Server and Monitoring Server are separate Office Communications Server roles.

Similarly, the Front End contains a QoE agent, which is part of the RTCQMS process, to capture QoE data. The QoE data is transferred over Message Queuing to the Monitoring Server.

In Office Communications Server 2007 R2, the CDR function moves to the Monitoring Server from the Archiving Server with which it was a co-located in Office Communications Server 2007. CDR data accumulation and reporting requirements have characteristics more in common with QoE data than Archiving data, which drove the evolution in architecture.

(24)

Unified Communications Application Services (UCAS) Infrastructure

Unified Communications Application Server (UCAS) is a platform introduced in Office

Communications Server 2007 R2 that makes it easier to build server-side applications that run on Standard Edition servers or Enterprise pool servers. Each Front-End Server in a pool runs an instance of an Application Server host. Applications developed by using the Unified

Communication Managed APIs (UCMA) 2.0 can use the UCAS platform as a common framework that leverages Office Communications Server capabilities such as deployment, trust,

administration, load balancing and routing, monitoring, and so on. UCAS is designed to host server applications that act as Session Initiation Protocol (SIP) endpoints.

Similar to Office Communications Server conferencing servers, UCAS is another server role. When you deploy UCAS on an Enterprise Edition server consolidated pool topology, each UCAS application runs on all servers in the pool and together they share the overall workload of the application. UCAS consists of a single Windows service, called Application Host

(OCSAppServerMaster.exe), and one or more instances of another Windows service called OCSAppServerHost.exe. Each instance of OCSAppServerHost.exe on a server hosts a UCAS application unique to that server.

Several new features in Office Communications Server 2007 R2 are implemented as UCAS applications, including dial-in conferencing, Response Group Service, and Outside Voice Control. For details, see Voice Components.

For details about Application Server architecture, see Application Server Drilldown.

Conferencing Components

Conferencing functionality in Office Communications Server 2007 R2, which includes instant messaging (IM) conferencing, Web conferencing, audio/video conferencing, desktop sharing, and control of third-party audio conferencing services, is supported by the following:

• Conferencing infrastructure components. Includes conference control entities such as the Focus, Focus Factory, and so on.

• Conferencing servers. Handle media, including mixing functions for media.

Together, these two components support conferences over across a broad range of modalities. In This Section

• Conferencing Infrastructure Components

• Conferencing Servers for Office Communications Server 2007 R2

Conferencing Infrastructure Components

The main conferencing infrastructure components of Office Communications Server 2007 R2 are the Focus instances, Focus Factory, Conferencing Server Factory and conferencing servers for each media type. SQL Server databases are used for storing the persistent state.

(25)

Figure 1. Conferencing component interrelationships

The Focus Factory and Focus components run in the main conferencing process, which is also the Session Initiation Protocol (SIP) Proxy process (RTCSrv). The Conferencing Server Factory is a fairly lightweight component (hosted by the RTCHost process) that is accessed by the Focus once for each media type when that media 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.

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.

(26)

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 Centralized Conferencing Control Protocol (C3P) commands that are 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. To support this, any state information that is needed to resume the conference persists in a conferencing database, which runs on the SQL Server back-end database. In Office Communications Server 2007 R2, 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 the following:

• Conference ID.

• PSTN Meeting 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 (for example, closed, open, and anonymous).

The conferencing database contains the metadata for a conference but does not contain calendar information. Conference calendar information (for example, 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,

(27)

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.

Conferencing Servers for Office Communications Server 2007 R2

A conferencing server is responsible for mixing and managing one or more media types. The following types of conferencing servers are included in Office Communications Server 2007 R2:

• Web Conferencing Server for data collaboration.

• A/V Conferencing Server for audio and video.

• Instant messaging (IM) Conferencing Server for multiparty IM.

• Telephony Conferencing Server for interfacing with audio conferencing providers.

• Application Sharing Server for multiparty or Communicator Web Access-based application sharing.

The architecture allows the addition of other conferencing servers as needed in the future. The IM Conferencing Server, Application Sharing Server, and Telephony Conferencing Server can only be installed as part of a Front End Server, but you can install A/V Conferencing Servers and Web Conferencing Servers independently of other components.

Web Conferencing Servers, A/V Conferencing Servers, and IM Conferencing Servers each have two logical components: a media controller and a media processor.

MC (Media Controller)

The media controller on a conferencing server is responsible for managing the control commands between a Focus and a conferencing server.

MP (Media Processor)

The media processor is responsible for media management (for example, mixing, relaying, and transcoding). In a Web Conferencing Server, the media processor is a software component that is responsible for managing data collaboration for Office Communications Server. In an A/V

Conferencing Server, the media processor mixes audio streams, switches video streams, and converts the media for clients who are on slow links. Of all the conferencing components, the media processor can be the most CPU and network intensive component. In our architecture, a media controller and media processor are collocated on the same computer to simplify

(28)

A/V Conferencing Server

The A/V Conferencing Server enables multiparty audio and video mixing and relaying capabilities. It is built on industry standard real-time transport protocol (RTP) and real-time transport control protocol (RTCP).

The A/V Conferencing Server also incorporates elements of the Internet Engineering Task Force (IETF) drafts for Interactive Connectivity Establishment (ICE) as a means to enable the exchange of media between two or more clients that are using Network Address Translators (NATs). ICE is an extension to Session Description Protocol (SDP) that enables media streams to traverse NATs by including in the SDP multiple IP address and port combinations for a particular transport protocol, known as candidate transport addresses, that the client can use to communicate with other clients. In an Office Communications Server environment, a client uses Session Traversal Utilities for NAT (STUN) and Traversal Using Relay NAT (TURN) protocols to obtain its candidate transport addresses from the Office Communications Server A/V Conferencing Edge Server. During negotiation, clients on either end exchange SDPs and then test candidate addresses for peer-to-peer connectivity. After the connectivity checks, clients renegotiate by including only the candidate transport address that succeeded in the SDP for a SIP re-INVITE request and response.

For details about IETF drafts for ICE, see “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols” at

http://go.microsoft.com/fwlink/?LinkId=144408. Web Conferencing Server

The Web Conferencing Server adds data collaboration functionality to Office Communications Server. The Web Conferencing Server is built on the same Persistent Shared Object Model (PSOM) technology that is used by the Live Meeting service. Both signaling and media are sent to and from a Web Conferencing Server using the PSOM protocol. The Web Conferencing Server supports Live Meeting features, such as Microsoft Office PowerPoint presentations, document presentations, chat, voting, white boarding, and application sharing.

The Web Conferencing Server uses shared folders on a file system to store conference state and conference contents. Universal Naming Convention (UNC) paths are configured on the Web Conferencing Server to refer to the shared folders, which are created by an administrator during Office Communications Server deployment. These folders for conference metadata and

conference content can be located on the same computer as the Web Conferencing Server or, preferably, on a dedicated computer.

For information about the way that a Web Conferencing Server works, see Web Conferencing Server for Office Communications Server 2007 R2.

IM Conferencing Server

The IM Conferencing Server is installed automatically on the Front End Server. The IM Conferencing Server enables multiparty instant messaging (IM). The IM Conferencing Server uses SIP for signaling and media.

(29)

Telephony Conferencing Server

The Telephony Conferencing Server is installed automatically on the Front End Server. The Telephony Conferencing Server enables Office Communications Server to communicate with audio conferencing providers.

Application Sharing Server

The Application Sharing Server is a new conferencing server role introduced in Office

Communications Server 2007 R2, and is used specifically for multiparty desktop sharing from the Office Communicator client and desktop sharing from the Communicator Web Access client. The Application Sharing Server uses the Remote Desktop Protocol (RDP), with RTP as the transport for remote access scenarios.

Although the Web Conferencing Server also supports Application Sharing (that is, by using the PSOM protocol and the Live Meeting client), the Application Sharing Server provides desktop sharing functionality that users can access directly in Office Communicator and Communicator Web Access, instead of requiring users to start the Live Meeting client separately.

Voice Components

Office Communications Server 2007 R2 provides a rich set of Enterprise Voice features suitable for global voice (that is, telephony) deployments. This section describes the voice components and the relationship between these components. It also describes the process boundaries for the various components.

Other topics in the Technical Reference describe common infrastructure and conferencing infrastructure that enable certain key functions for Enterprise Voice. For example, Session Initiation Protocol (SIP) registration, performed by RTCSrv.exe and the User Services module, enables the fundamental call switching aspect of Enterprise Voice. The key additional components specific to enabling Enterprise Voice are either hosted on RTCHost.exe (that is, Inbound Routing, Translation Service, Outbound Routing, Exchange UM) or hosted as Unified Communications Application Services (UCAS) applications (that is, Conferencing Attendant, Conferencing Announcement Service, Response Group Service, and Outside Voice Control). In This Section

• RTCHost Voice Components

• Unified Communications Application Services (UCAS) Voice Applications

RTCHost Voice Components

The core voice components of Office Communications Server 2007 R2 are the Inbound Routing application, the Translation Service, and the Outbound Routing application that run inside the RTCHost.exe process on each Front End Server. 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 to translate a dialed number into an E.164 format that can be consumed by other components in the system, such as the private branch exchange (PBX) or public switched telephone network

(30)

(PSTN) gateway. The Outbound Routing application uses call authorization rules to route each call to the appropriate media gateway.

The following figure shows the architecture of the core components: Translation Service, Inbound Routing, and Outbound Routing.

Figure 1. Core component architecture

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 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 2007 R2 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.

(31)

Reverse number lookup is a process whereby a user's phone number is mapped to the appropriate SIP Uniform Resource Identifier (URI). By performing reverse number lookup, the server can route calls to all endpoints associated with a particular user’s 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

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 2007 R2 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.

Unified Communications Application Services (UCAS) Voice Applications

Unified Communications Application Services (UCAS) Enterprise Voice applications were added in the Office Communications Server 2007 R2 release to provide key Enterprise Voice features, such as dial-in conferencing (Conferencing Attendant and Conferencing Announcement Service), basic Automatic Call Distribution (that is, Response Group Service), and Office Communications Server server-side functions to extend Enterprise Voice to cellular telephones (that is, Outside Voice Control).

Dial-in conferencing allows callers to use standard public switched telephone network (PSTN) telephones to dial in to audio conferences hosted on Office Communications Server. (In Office Communications Server 2007, only Office Communications Server enterprise-enabled users who connect over Internet Protocol (IP) audio could join audio conferences hosted on Office

Communications Server.) Dial-in conferencing is enabled by the Conferencing Attendant and Conferencing Announcement Service UCAS applications. For details, see Dial-In Conferencing Scenario.

Conferencing Attendant

The Conferencing Attendant is an auto-attendant service (that is, a bot) that authenticates and joins dial-in participants to audio conferences. Office Communications Server 2007 R2

Conferencing Attendant supports 14 different languages. The Conferencing Attendant prompts the caller for conference IDs and passcode (that is, if the caller is calling in as an anonymous participant) or extension number and personal identification number (PIN) (that is, if the caller is joining as a Enterprise User), plays on-hold music when enterprise users have not yet joined the meeting, requests authentication from a front-end service, and joins authenticated callers to the Focus and A/V Conferencing Server for the requested conference ID.

The Conferencing Attendant Service on each Front End Server listens on Transmission Control Protocol (TCP) port 5072 for incoming calls. These requests normally come from a Mediation Server and are proxied by the Mediation Server’s next hop pool.

(32)

Conferencing Announcement Service

The Conference Announcement Service is another trusted bot that participates in all dial-in enabled audio conferences. It monitors the conference roster and plays entry and exit tones to all dial-in attendees when other dial-in attendees join or leave, and also tells attendees when their microphone has been muted or unmuted in the language that they chose when they connected to the Conferencing Attendant. No configuration is required for this service.

The Conference Announcement Service on each Front End Server listens on TCP port 5073 for requests from a Focus that is running on one of the Front End Servers in the pool.

Response Group Service

The Office Communications Server 2007 R2 Response Group Service enables administrators to create and configure one or more response groups for the purpose of routing and queuing incoming phone calls to one or more designated agents. These response groups can be

deployed in departmental or workgroup environments and in entirely new telephony installations. Typical usage scenarios include an internal helpdesk, a customer service desk, or a general external call handler. Response Group Service can increase response group usage and reduce the associated overhead by pushing the tasks of response group maintenance down to the users who directly benefit from them.

The Response Group Service functionality is enabled by the Response Group Service

application, which is a UCAS application that implements standard response group call-routing algorithms (that is, including serial, longest-idle, parallel, and round robin), interactive voice response (IVR), call queuing, on-hold music, presence-based routing, and so on.

Outside Voice Control

The Office Communications Server 2007 R2 Outside Voice Control feature enables users to use their enterprise telephone number for inbound and outbound calls on their personal mobile phone.

To use this feature, the user must have Office Communicator Mobile (2007 R2 release) installed on a Windows Mobile phone and must be able to use data packet communication between the mobile phone and the mobile phone provider (for example, General Packet Radio Source (GPRS)) that allows SIP messages to be transmitted. The user must also be enabled for Enterprise Voice.

For inbound calls, Office Communications Server 2007 R2 sends a SIP Invite to all registered SIP endpoints of the user including the user’s Communicator Mobile (2007 R2 release) client running on the phone, over the data channel. Office Communications Server 2007 R2 subsequently initiates an outbound PSTN/mobile network call through Office Communications Server 2007 R2 Mediation Server to the user’s mobile phone number.

For an outbound call from a mobile phone, the user has the option to enter the phone number to be dialed into Communicator Mobile (2007 R2 release) or to initiate a call to a SIP contact using Communicator Mobile (2007 R2 release). The user receives an incoming mobile phone call from Office Communications Server using the mobile phone provider’s cellular network. After the user accepts the call from Office Communications Server, Office Communications Server sets up a second call leg to the designated called party and then join the two connections. The called party

(33)

receives a call from the user’s company using the user’s office phone number despite the fact that the user is actually on a mobile phone.

The Outside Voice Control application on each Front End Server listens on TCP port 5074.

Communication Protocols for Office

Communication Server 2007 R2

In This Section

This section includes the following topics:

• Protocols Overview

• Conferencing Protocols

Protocols Overview

While Session Initiation Protocol (SIP) is still the primary control protocol used by Office

Communications Server 2007 R2, Web Conferencing Server, A/V Conferencing Server, and their subcomponents, they also employ other protocols to set up and modify conferences and to set up and break down media streams between different elements in the Office Communications

Server2007 R2 network. The following protocols are employed by Office Communications Server 2007 R2:

• Session Initiation Protocol (SIP). The industry standard protocol described in IETF RFC 3261 that defines a standard for session setup, termination, and media negotiation between two parties. It is widely used for Voice over IP (VoIP) call signaling.

• Asynchronous JavaScript And XML (AJAX). Used in Communicator Web Access to ensure efficient client-server interaction, while keeping the Web user interface (UI)

responsive.

• Centralized Conferencing Control Protocol (C3P). Used to encode Conferencing Control commands in Office Communications Server.

• HTTPS. The set of rules for exchanging files (that is, text, graphic images, sound, video, and other multimedia files) on the World Wide Web. Relative to the Transmission Control Protocol (TCP)/Internet Protocol (IP) suite of protocols, the basis for information exchange on the Internet, HTTP is an application-layer protocol. HTTPS is the HTTP protocol over Secure Sockets Layer (SSL)/Transport Layer Security (TLS).

• Interactive Connectivity Establishment (ICE). Used to provide media connectivity across firewalls and Network Address Translation (NAT) devices, thereby enabling audio/video anywhere.

• Persistent Shared Object Model (PSOM). A proprietary protocol for the transport of real-time data, including audio and video. PSOM uses TCP or TLS as the underlying transport.

• Remote Desktop Protocol (RDP). The Microsoft protocol that is used in Office Communications Server 2007 R2 for desktop sharing. This is the protocol that is used for Microsoft Remote Desktop Services.

(34)

• Real-time transport protocol/real-time control protocol (RTP/RTCP). The industry standard protocol for the transport of real-time data, including audio and video.

• Session Description Protocol (SDP). Used to negotiate capabilities between SIP endpoints during call initiation.

• Secure real-time transport protocol/secure real-time control protocol (SRTP/SRTCP). Encrypted versions of RTP/RTCP.

• Scale secure real-time transport protocol (SSRTP). Scale secure RTP/RTCP, used for efficient media sessions for multi-point audio/video conferences.

• Simple Traversal of UDP through NAT (STUN). Used by endpoints to determine the public IP addresses allocated to them by the NAT (if applicable).

• Transport Layer Security (TLS). Used to encrypt SIP or HTTP trafficin addition to server authentication.

• Third Party Control Protocol (TPCP). Used for Outside Voice Control.

• Traversal Using Relay NAT (TURN). A protocol for allocating a public IP address and port on a globally reachable server for the purpose of relaying media from one endpoint to another.

For detailed specifications for Office Communications Server protocols, including several of those listed in this topic, see “Microsoft Office Protocol Documents” at http://go.microsoft.com/fwlink/? LinkId=158438.

Conferencing Protocols

The following table shows the protocols that are used between conferencing components. Table 1. Conferencing Protocols

Client Focus Focus Factory Conferencing Server Factory Conferencing server Client X Session Initiation Protocol (SIP), Centralized Conferencing Control Protocol (C3P)

SIP, C3P X SIP, real-time

transport protocol (RTP), Persistent Shared Object Model (PSOM) and so on Focus SIP, C3P X X HTTPS, C3P HTTPS, C3P

Focus Factory SIP, C3P X X X X

Conferencing Server Factory

X HTTPS, C3P X X HTTPS, C3P

(35)

Client Focus Focus Factory Conferencing Server Factory Conferencing server Server PSOM and so on

The following figure provides an overview of the protocols and the components that use them to communicate.

Figure 1. Office Communication Server 2007 R2 conferencing protocols and component relationships

(36)

Interfaces in the diagram identify a specific link, based on the transport and purpose, between two logical elements. The same protocol can be used in different ways over the various interfaces. For example, SIP/3CP is used to communicate C3P commands over SIP INFO messages and conference event package notifications over SIP SUBSCRIBE and NOTIFY messages.

Centralized Conferencing Control Protocol (C3P)

C3P is a conference manipulation protocol used by the Office Communications Server 2007 conferencing servers. C3P is used to modify the conference state. The channels over which C3P can be used in an Office Communications Server 2007 deployment are shown in Figure 1. C3P has request/pending response/final response semantics similar to SIP. The following table lists C3P commands. Table 2. C3P Commands Conference Level addConference deleteConference modifyConference getConference getMCU modifyConferenceLock modifyUsersMediaFilters User Level addUser deleteUser modifyUser modifyUserRoles setUserAccess Scheduling getAvailableMcuTypes getConferencingCapabilities getEncryptionKey

(37)

Scheduling

getConferences

Endpoint Level

modifyEndpointRole

Endpoint Media Level

addEndpointMedia deleteEndpointMedia modifyEndpointMedia

High Availability (HA)/Load Balancing

ping

getConference

PSOM

PSOM is the media protocol for data collaboration. PSOM uses Transport Layer Security (TLS) as the underlying transport. Conferencing clients can use PSOM to establish media channels with the Web Conferencing Server to negotiate or transfer media.

RTP/RTCP

RTP/RTCP is the standard protocol for the transport of real-time data, including audio and video.

SIP/SDP

Session Initiation Protocol (SIP) is the industry standard protocol described in IETF RFC 3261 that defines a standard way for session setup, termination, and media negotiation between two parties. It is widely used for Voice over IP (VoIP) call signaling.

Session Description Protocol (SDP) is the industry standard protocol described in IETF RFC 4566 that defines a standard way to convey media details, transport addresses, and other session description metadata to the participants when initiating multimedia teleconferences, Voice over IP calls, streaming video, or other sessions.

Office Communications Server 2007 R2 Technical Reference Guide

Microsoft Office Communications

Server 2007 R2

Technical Reference

Contents

Office Communications Server 2007 R2

Technical Reference Guide

Office Communications Server 2007 R2

Architecture

Topology and Component Architecture

Standard Edition (Single Server Installation)

Enterprise Edition

Consolidated Configuration

Expanded Configuration

Pool Components for Office Communications

Server 2007 R2

Overview of Pool Components

Common Infrastructure Components

RTCSrv

Office Communications Server Application Programming Interface (API)

RTCHost

Back-End Database

Presence Components

Web Components Services for Office Communications Server 2007 R2

Archiving and Monitoring for Office Communications Server 2007 R2

Unified Communications Application Services (UCAS) Infrastructure

Conferencing Components

Conferencing Infrastructure Components

Conferencing Servers for Office Communications Server 2007 R2

Voice Components

RTCHost Voice Components

Unified Communications Application Services (UCAS) Voice Applications

Communication Protocols for Office

Communication Server 2007 R2

Protocols Overview

Conferencing Protocols

Centralized Conferencing Control Protocol (C3P)

PSOM

RTP/RTCP

SIP/SDP