Office Communications Server 2007 R2

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. 1 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. 2 Contents Office Communications Server 2007 R2 Technical Reference Guide ............................................ 1 Office Communications Server 2007 R2 Architecture ..................................................................... 1 Topology and Component Architecture ....................................................................................... 2 Standard Edition (Single Server Installation) ............................................................................ 2 Enterprise Edition...................................................................................................................... 3 Consolidated Configuration ...................................................................................................... 3 Expanded Configuration ........................................................................................................... 3 Pool Components for Office Communications Server 2007 R2 ................................................... 4 Overview of Pool Components ................................................................................................. 4 Common Infrastructure Components........................................................................................ 6 RTCSrv .................................................................................................................................. 7 Office Communications Server Application Programming Interface (API) .......................... 10 RTCHost .............................................................................................................................. 12 Back-End Database............................................................................................................. 13 Presence Components ........................................................................................................ 13 Web Components Services for Office Communications Server 2007 R2 ........................... 14 Archiving and Monitoring for Office Communications Server 2007 R2 ............................... 14 Unified Communications Application Services (UCAS) Infrastructure ................................ 15 Conferencing Components ..................................................................................................... 16 Conferencing Infrastructure Components ........................................................................... 16 Conferencing Servers for Office Communications Server 2007 R2 .................................... 19 Voice Components.................................................................................................................. 21 RTCHost Voice Components .............................................................................................. 21 Unified Communications Application Services (UCAS) Voice Applications ........................ 23 Communication Protocols for Office Communication Server 2007 R2 ...................................... 25 Protocols Overview ................................................................................................................. 25 Conferencing Protocols .......................................................................................................... 26 Centralized Conferencing Control Protocol (C3P) .............................................................. 29 PSOM .................................................................................................................................. 30 RTP/RTCP........................................................................................................................... 30 SIP/SDP .............................................................................................................................. 30 Signaling and Control Protocol ............................................................................................ 30 Media Protocols ................................................................................................................... 31 Scenarios for Office Communications Server 2007 R2 ................................................................. 31 Conferencing Scenario for Office Communications Server 2007 R2 ......................................... 31 Core (Focus, Focus Factory, and Conferencing Server Factory) ........................................... 32 Conferencing Lifecycle ........................................................................................................ 32 Conferencing Data Flow ...................................................................................................... 32 Conference Creation and Activation.................................................................................... 34 Joining a Conference .......................................................................................................... 39 3 Adding Participants to the Conference ................................................................................ 43 Notification Document ......................................................................................................... 46 Conference Deactivation ..................................................................................................... 48 Conference Expiration ......................................................................................................... 48 Web Conferencing Server for Office Communications Server 2007 R2 ................................ 48 Web Conferencing Architecture .......................................................................................... 49 File Structure ....................................................................................................................... 50 Metadata Folder .................................................................................................................. 51 Organizer Folder.................................................................................................................. 52 Conference Folder ............................................................................................................... 52 Types of Slides .................................................................................................................... 54 Content Upload and Download over PSOM ........................................................................ 55 Content Upload over PSOM and Download over HTTPS ................................................... 56 Slide Set Files ...................................................................................................................... 58 Handouts (File Transfers) .................................................................................................... 65 PersistData Folder (Shared Notes) ..................................................................................... 66 Content Folder ..................................................................................................................... 67 Conference Content Folder ................................................................................................. 68 File Size Restrictions ........................................................................................................... 70 Compliance .......................................................................................................................... 70 Conferencing Scenario Call Flows in Office Communications Server 2007 R2 ..................... 73 Lock or Unlock a Conference .............................................................................................. 73 Dial In to a PSTN Conference Using SIP C3P (Telephony Conferencing Server) ............. 73 Dial Out to Device Using addUser (Audio Conferencing Provider) ..................................... 74 Remove a Participant .......................................................................................................... 74 Mute or Unmute ................................................................................................................... 75 Make Presenter ................................................................................................................... 76 Dial-In Conferencing Scenario ................................................................................................... 77 Server-Based Dial-In Conferencing Components .................................................................. 79 Active Directory–Based Configuration Data ........................................................................ 79 Office Communications Server Front End Server Components ......................................... 82 Client-Based Dial-in Conferencing Components .................................................................... 87 Conferencing Add-in for Microsoft Office Outlook ............................................................... 88 Live Meeting Client .............................................................................................................. 88 Office Communicator ........................................................................................................... 89 Call Flows ............................................................................................................................... 89 Meeting Set-up .................................................................................................................... 89 To create an Anonymous-Allowed Live Meeting with Dial-In Conferencing support .......... 89 Connecting to the Meeting .................................................................................................. 90 Desktop Sharing Scenario ......................................................................................................... 95 Office Communications Server 2007 R2 Desktop Sharing Architecture ................................ 96 Architectural Overview ........................................................................................................ 96 Protocols Used By Desktop Sharing ................................................................................... 97 Desktop Sharing Components ............................................................................................ 99 Desktop Sharing Call Flows .................................................................................................. 104 Creating a Desktop Sharing Conference........................................................................... 104 4 Adding a User to a Desktop Sharing Conference ............................................................. 105 Desktop Sharing Session Control ..................................................................................... 108 Communicator Web Access Scenario...................................................................................... 110 Functionality Overview .......................................................................................................... 110 New Communicator Web Access Features ...................................................................... 111 Office Communicator and Web Access Feature Comparison .......................................... 112 Communicator Web Access Core Architecture .................................................................... 114 UCMA Layer Functions ..................................................................................................... 116 Application Logic Layer Functions ..................................................................................... 116 Client Functions ................................................................................................................. 117 Communicator Web Access Audio ....................................................................................... 119 Communicator Web Access Audio Scenarios ................................................................... 120 Call Deflection Session Initiation Protocol (SIP) Tracing .................................................. 123 Add Audio Session Initiation Protocol (SIP) Tracing ......................................................... 129 Outside Voice Control Scenario ............................................................................................... 144 Outside Voice Control Architecture ....................................................................................... 146 Architectural Overview .......................................................................................................... 148 Protocols Used By Outside Voice Control ......................................................................... 149 Call Flows ............................................................................................................................. 149 Outbound Call.................................................................................................................... 149 Inbound Call ...................................................................................................................... 152 Group Chat Feature Scenario .................................................................................................. 154 Group Chat Services ............................................................................................................ 154 Channel Service ................................................................................................................ 154 Lookup Service .................................................................................................................. 155 Web Service ...................................................................................................................... 156 Compliance Service........................................................................................................... 156 Key Protocols and Windows Services Used by Group Chat ................................................ 157 Session Initiation Protocol (SIP) ........................................................................................ 157 Windows Communication Foundation (WCF) ................................................................... 157 HTTPS ............................................................................................................................... 157 Message Queuing ............................................................................................................. 158 Group Chat Call Flows .......................................................................................................... 158 Group Chat Client Sign In ................................................................................................. 158 Subscribing to a Chat Room and Posting a Message....................................................... 161 Technical Drilldowns .................................................................................................................... 163 SIP Processing Drilldown ......................................................................................................... 163 SIP Processing and GRUU ................................................................................................... 163 GRUU Creation ..................................................................................................................... 164 How GRUU Is Used by Office Communications Server ....................................................... 164 User Replicator Drilldown ......................................................................................................... 165 Archiving and Monitoring Drilldown .......................................................................................... 167 Archiving and Monitoring Servers ............................................................................................ 167 Archiving Server ................................................................................................................ 167 Monitoring Server .............................................................................................................. 167 5 Archiving Database Schema ................................................................................................ 168 List of Tables ..................................................................................................................... 168 Supporting Tables ............................................................................................................. 168 Tables for Messages in IM Conferences ........................................................................... 168 Tables for Peer-to-Peer IM Archiving ................................................................................ 169 Tables for Internal Use by Office Communications Server ............................................... 169 Table Details ...................................................................................................................... 169 ClientVersions Table ......................................................................................................... 169 Computers Table ............................................................................................................... 170 ContentTypes Table .......................................................................................................... 170 Dialogs Table..................................................................................................................... 170 Pools Table ........................................................................................................................ 171 Users Table ....................................................................................................................... 171 Conferences Table ............................................................................................................ 172 ConferenceMessageRecipientList Table .......................................................................... 173 ConferenceMessages Table ............................................................................................. 173 SessionDetails Table ......................................................................................................... 174 Messages Table ................................................................................................................ 176 CDR Database Schema ....................................................................................................... 177 List of Tables ..................................................................................................................... 177 Static Tables ...................................................................................................................... 177 Supporting Tables ............................................................................................................. 178 Tables Specific to Conference CDR Records ................................................................... 178 Tables for Messages in IM Conferences ........................................................................... 179 Tables for Peer-to-Peer Sessions ..................................................................................... 179 Table for VoIP Call Details ................................................................................................ 179 Tables for Troubleshooting ................................................................................................ 180 Tables for Internal Use by Office Communications Server ............................................... 180 Table Details ...................................................................................................................... 180 MediaList Table ................................................................................................................. 181 Roles Table ....................................................................................................................... 181 UserAuthTypes Table ........................................................................................................ 181 ClientVersions Table ......................................................................................................... 182 Computers Table ............................................................................................................... 182 Pools Table ........................................................................................................................ 183 Dialogs Table..................................................................................................................... 183 Gateways Table................................................................................................................. 183 Mcus Table ........................................................................................................................ 184 Users Table ....................................................................................................................... 184 Phones Table .................................................................................................................... 185 Conferences Table ............................................................................................................ 185 FocusJoinsAndLeaves Table ............................................................................................ 186 McuJoinsAndLeaves Table ............................................................................................... 187 ConferenceMessageCount Table...................................................................................... 188 SessionDetails Table ......................................................................................................... 189 FileTransfers Table............................................................................................................ 191 6 Media Table ....................................................................................................................... 193 VoipDetails Table .............................................................................................................. 193 Application Table ............................................................................................................... 194 ErrorDef Table ................................................................................................................... 195 ErrorReport Table .............................................................................................................. 195 ProgressReport Table ....................................................................................................... 196 Sample Database Queries ................................................................................................ 197 QoE Database Schema ........................................................................................................ 198 List of Tables ..................................................................................................................... 198 Table Details ...................................................................................................................... 199 Sample Database Queries ................................................................................................ 222 Message Queuing Architecture and Configuration for Archiving .......................................... 224 Message Stamping ............................................................................................................... 225 Creating a Third-Party QoE Solution .................................................................................... 225 Infrastructure Requirements and Prerequisites of Monitoring Server ............................... 226 Deploying a Custom QoE Solution .................................................................................... 229 WMI Reference for QoE Solutions .................................................................................... 229 Enabling or Disabling an HTTP Proxy for QoE Solutions ................................................. 232 Edge Servers Drilldown ............................................................................................................ 232 Response Group Client Web Service Drilldown ...................................................................... 232 Service Descriptions ............................................................................................................. 233 Client DNS Queries Drilldown .................................................................................................. 233 Application Server Drilldown .................................................................................................... 234 Characteristics of the Office Communications Server 2007 R2 Application Server ............. 235 Architecture ....................................................................................................................... 235 Other Key Application Server Characteristics ................................................................... 236 Application Server Configuration .......................................................................................... 237 Application Server Application Configuration ....................................................................... 237 Global Settings .................................................................................................................. 237 Pool Settings ..................................................................................................................... 238 SIP Trunking Drilldown ............................................................................................................. 238 SIP Trunking Drilldown: Supported Scenarios ..................................................................... 238 SIP Trunking Drilldown: Supported Topologies .................................................................... 239 SIP Trunking Drilldown: Security Considerations ................................................................. 240 SIP Trunking Drilldown: Bandwidth Considerations ............................................................. 241 SIP Trunking Drilldown: Protocol Flow and Details .............................................................. 242 SIP Call Flow and State Machine ...................................................................................... 242 Call Hold ............................................................................................................................ 243 Dual-tone multifrequency (DTMF) ..................................................................................... 243 Early Media ........................................................................................................................ 243 Uniform Resource Identifier (URI) Formatting ................................................................... 243 Codec Support................................................................................................................... 244 SIP Trunking Drilldown: High Availability .............................................................................. 244 Address Book Server Drilldown ............................................................................................... 245 Address Book Server Introduction ........................................................................................ 246 Introduction ........................................................................................................................ 246 7 Address Book Server: File and Database Generation .......................................................... 247 Address Book Server Data Flow ....................................................................................... 247 Address Book Server Process .......................................................................................... 248 Address Book Server: Address Book File Download Service .............................................. 251 File Generation .................................................................................................................. 251 Organizational Unit and Address Book File Generation.................................................... 253 Client and Address Book Server Communication ............................................................. 253 Address Book and Office Communicator .......................................................................... 254 Client Download Process .................................................................................................. 255 Internet Explorer Dependencies ........................................................................................ 256 File Store Recommendations and File Size Guidelines .................................................... 257 Office Communicator Local Address Book Database Files .............................................. 257 Address Book and Office Communicator Phone Edition ................................................... 257 Address Book Web Query Service .................................................................................... 258 Address Book Server: Address Book Web Query Service ................................................... 258 Office Communicator Address Book Queries ................................................................... 260 Queries on Display Name ................................................................................................. 262 Queries on Phone Numbers .............................................................................................. 263 Sorting Query Results ....................................................................................................... 264 Predictive Text Queries ..................................................................................................... 264 Address Book Web Query Database ................................................................................ 264 Address Book Web Query Database Language Support ................................................. 265 Address Book Web Query Server Performance ............................................................... 265 Address Book Server: Advanced Address Book Features ................................................... 266 Management of Office Communications Server 2007 R2 ........................................................... 271 Administrative Tools Overview ................................................................................................. 272 Administrative Tools.............................................................................................................. 272 Permissions .......................................................................................................................... 276 Installation and Use of Administrative Tools ............................................................................ 276 Version Restrictions .............................................................................................................. 277 Remote Administration Requirements .................................................................................. 277 Installing Administrative Tools .............................................................................................. 277 Troubleshooting for Office Communications Server 2007 R2 ................................................. 279 Load Balancers for Office Communications Server 2007 R2 .................................................. 280 Prerequisites for a Load Balancer Connecting to a Pool ...................................................... 280 Load Balancer Requirements ............................................................................................... 280 Supported Load Balancer Configurations ............................................................................. 282 Media Ports .............................................................................................................................. 283 Mediation Server for Office Communications Server 2007 R2 ............................................. 283 Media Gateway.................................................................................................................. 284 Media Port Range for Office Communications Server 2007 R2 ........................................... 284 Minimum Number of Ports ................................................................................................. 284 Server Port Allocation ........................................................................................................ 292 Voice Quality of Service (QoS) ................................................................................................ 292 QoS with Office Communications Server 2007 R2 ............................................................... 292 8 Enabling DSCP Marking ....................................................................................................... 294 Enabling QoS .................................................................................................................... 294 Installing the QoS Packet Scheduler on Computers ......................................................... 297 Verifying Group Policy Settings on Computers ................................................................. 298 WMI Settings for Office Communications Server 2007 R2 ...................................................... 299 Client Registry Keys/GPO for Office Communications Server 2007 R2 .................................. 299 In-Band Provisioning over SIP ................................................................................................. 300 Why Use In-Band Provisioning? ........................................................................................ 301 Office Communicator 2007 R2 Group Policy Precedence ................................................ 302 Policy transport .................................................................................................................. 302 Provisioning Groups .......................................................................................................... 306 9 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 ocsdoc@microsoft.com. 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 This section includes the following topics: 1  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 2 Back-End Database Server also runs on the single physical server. Thus, all elements share the same server resources. 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. 3 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. 4 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 5 functions, performs directory replication functions and interfaces with the database, hosts 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: 6  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 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. 7 Figure 1. The RTCSrv.exe process 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. 8 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 BackEnd 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 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. 9 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. 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: 10  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 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 11 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 http://go.microsoft.com/fwlink/?LinkId=144482. 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. 12  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 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. 13 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.  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. 14  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. 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 15 (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 This section contains the following topics:  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. The following figure shows the conferencing component interrelationships. 16 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 17 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 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 18 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. 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 19 media controller and media processor are collocated on the same computer to simplify deployment. 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. 20 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. 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 This section contains the following topics:  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 21 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 (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. 22 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. 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 23 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. 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. 24 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 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. 25  Persistent Shared Object Model (PSOM). A proprietary protocol for the transport of realtime 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.  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 Client X Focus Session Initiation Protocol (SIP), Centralized Conferencing Control Protocol (C3P) Focus Conferencing Conferencing Factory Server Factory server SIP, C3P X SIP, real-time transport protocol (RTP), Persistent Shared Object Model (PSOM) and so on 26 Client Focus Focus Conferencing Conferencing Factory Server Factory server 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 Conferencing Server SIP, RTP, PSOM and so on HTTPS, C3P X HTTPS, C3P X The following figure provides an overview of the protocols and the components that use them to communicate. 27 Figure 1. Office Communication Server 2007 R2 conferencing protocols and component relationships 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. 28 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 getConferences 29 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. Signaling and Control Protocol This section describes the protocols supported by the various server components and the functionality supported by each of those protocols. Clients and servers use signaling and control protocols for session setup and conference management. For each media in a conference or an audio/video call, different media protocols are used. 30 SIP, as specified in RFC 3261, is used for session setup and termination in Office Communications Server 2007. SIP messages use Transmission Control Protocol (TCP) or TLS as the underlying transport layer for client-to-server communications and mutual TLS (MTLS) for server-to-server communications. Conferences and call control are established within the context of existing SIP sessions using C3P protocol. C3P commands are sent using SIP INFO messages. A separate SUBSCRIBE/NOTIFY dialog is used to subscribe to conference packages, state change notifications, and the conference participant list. Media Protocols The Web Conferencing Server uses PSOM as the media protocol for data collaboration. PSOM uses TLS as the underlying transport. As the client for the Web Conferencing Server, Live Meeting functionality also relies on PSOM. RTP and RTCP are used to transport audio/video and desktop sharing data. By default, Office Communications Server 2007 uses secure real-time transport protocol (SRTP) and secure realtime transport control protocol (SRTCP) to secure and encrypt both media types. RTP/RTCP can use either TCP or User Datagram Protocol (UDP) as the underlying transport for audio/video, but will use only TCP for desktop sharing. Scenarios for Office Communications Server 2007 R2 This part of the Technical Reference provides details about architecture and call flows that enable specific end-user scenarios. In This Section This section includes the following topics:  Conferencing Scenario for Office Communications Server 2007 R2  Dial-In Conferencing Scenario  Desktop Sharing Scenario  Communicator Web Access Scenario  Outside Voice Control Scenario  Group Chat Feature Scenario Conferencing Scenario for Office Communications Server 2007 R2 This section describes how conferencing works. It contains a detailed discussion about how conferencing components interact and includes call flows for various conferencing scenarios. Together with the Focus and the Focus Factory, the Web Conferencing Server, A/V Conferencing Server, and Application Sharing Service (ASMCU) provide conferencing functionality 31 In This Section This section includes the following topics:  Core (Focus, Focus Factory, and Conferencing Server Factory)  Web Conferencing Server for Office Communications Server 2007 R2  Conferencing Scenario Call Flows in Office Communications Server 2007 R2 Core (Focus, Focus Factory, and Conferencing Server Factory) Every Office Communications Server 2007 R2 conference has a similar lifecycle, which is described at a high level in this section. In This Section This section includes the following topics:  Conferencing Lifecycle  Conferencing Data Flow  Conference Creation and Activation  Joining a Conference  Adding Participants to the Conference  Notification Document  Conference Deactivation  Conference Expiration Conferencing Lifecycle A meeting begins when the first participant of any type joins the conference. A participant can join a conference when the conference is not locked and when the participant can be authenticated, based on the participants Active Directory identity or supplied meeting key. A meeting ends when all participants leave, when a presenter terminates the conference, or when ten minutes have lapsed since the last authenticated participant left the conference. When a conference ends, the conference is deactivated, which means that any remaining participants are ejected and that realtime media stops streaming in the meeting. Then, the meeting state and meeting content are purged at the time the conference expires, as defined when the meeting was scheduled. If a meeting is a recurring meeting, the meeting can be reactivated after the previous instance has been deactivated, if it has not already expired. Any content that was uploaded previously is available when the recurrent meeting starts again. Conferencing Data Flow This figure shows the data flow between participating components when an intranet client creates and joins a conference. 32 This is a description of the data flow between conferencing components when an intranet client creates and joins a conference:  Step 1. The scheduling client communicates with the Focus Factory using Domain Name System (DNS) lookup or the manually configured server address. The scheduling client sends information required for creating a meeting, such as the conference ID, participant list, user role information, and expiration date in a SERVICE request.  Step 2. The Focus Factory creates a conference record in the conferencing database on the Back-End Database Server. The Focus Factory also creates and returns a SIP URI that represents the conference to the client.  Step 3. The conferencing client connects to the Focus and establishes two dialogs with it, an INVITE dialog to join a conference and carry additional command traffic from the client to the Focus and a SUBSCRIBE/NOTIFY dialog to get conference state change notifications.  Step 4. The Focus connects to the Back-End Database Server to retrieve the conference record and to query the conferencing database to verify that the client joining the meeting is valid. Policy checks are also performed at this time.  Step 5. The Focus requests information from the Conferencing Server Factory about how to contact a conferencing server.  Step 6. The Conferencing Server Factory finds the conferencing server of the type requested by the Focus and then tries to provision a conference on that conferencing server, in order to allocate resources for the conference. If provisioning succeeds, the Conferencing Server Factory returns to the Focus an HTTP URL that allows the Focus to establish a control link with the conferencing server.  Step 7. The Focus communicates with the conferencing server to issue commands that begin or end the conference, change the participant list, or otherwise change the conference state.  Step 8. The conferencing client communicates with the conferencing server. If the server is an A/V Conferencing Server, the signaling protocol is SIP and the media is transported over RTP/RTCP. If the server is a Web Conferencing Server, both signaling and media are sent using the PSOM protocol. If the server is an Application Sharing Server, the signaling protocol is SIP and the media is transported over RDP encapsulated within RTP. 33 Conference Creation and Activation The scheduling client communicates with the Focus Factory to create a new conference. To create a conference, the Focus Factory on the server creates and configures a conference record. The Focus Factory then sends the URI for the Focus instance to the client. The conference URI includes the organizer of the conference and a unique conference identifier. The syntax is as follows: sip:<organizer>@<domain.com>;gruu;opaque=app:conf:focus:id: <unique ID>. For instance: sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:3ICYEOLHDKOE3ZP5K9QO56XN70D8X CDW. There is however a unique conference identifier that is especially reserved for reservationless meetings. The unique id is 3814A82809A34ED0958CFDB60957BDF. This meeting never expires. When a client creates a conference using the SIP SERVICE mechanism, the client first makes a SERVICE request, which requests a summary of conferencing capabilities supported in the server, and then passes all the information that it needs regarding the conference, media types, privileges, and participants as part of a second SERVICE request to the Focus Factory. The Focus Factory creates the conference record and then sends the connection information to the client in the 200 OK response to the SERVICE request. This figure shows the message flow between conferencing components when a client creates a conference using the SIP SERVICE mechanism. The following is a description of the message flow between conferencing components when a client creates a conference using the SIP SERVICE mechanism: Step 1. The client sends a SERVICE request to the Focus Factory with information requesting conferencing capabilities. These capabilities include a list of media capabilities, PSTN support 34 and important policy information a client should know before scheduling a conference. For example: SERVICE sip:Ted@contoso.com;gruu;opaque=app:conf:focusfactory To: sip:Ted@contoso.com;gruu;opaque=app:conf:focusfactory From: sip:client1@contoso.com;tag=f7588dc66124429ab736 Call-ID: 3412asdsss CSeq: 1 SERVICE Content-Type: application/cccp+xml SIP headers... <XML body> Step 2. After the getConferencingCapabilities SERVICE request has been sent and the response parsed by the client so that it can be aware of the capabilities available, the client sends a SERVICE request to the Focus Factory to have the conference created. Step 3. The Focus Factory parses the create conference information in the SERVICE request and writes it to the conferencing database in the Database. Step 2.2. After the Focus Factory writes to the conferencing database on the Back-End Database Server, the Focus Factory sends a 200 OK response to the client with the conference information. The following figure shows the message flow between conferencing components when a client joins a conference. The following is a description of the message flow between conferencing components when a client joins a conference: Step 1. The client sends an INVITE request to the Conference URI to join the conference. The purpose of the INVITE dialog is two-fold. The INVITE dialog indicates that the client wishes to join the conference. The INVITE dialog is also used by the client to send an INFO request in the context of the dialog, in order to set up control of the conference, as follows: 35 INVITE sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234 To: sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234 From: sip:joe@contoso.com;tag=f7588dc66124429ab736 Call-ID: adfsfasdfasdfds CSeq: 1 INVITE Content-Type: application/cccp+xml SIP headers... <addUser C3P request> The C3P addUser request in the body of the INVITE can be used to specify specific client attributes, such as its Display Name. Step 2. The client will use the SUBSCRIBE/NOTIFY dialog for watching the conference state, as follows: SUBSCRIBE sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234 To: sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234 From: sip:joe@contoso.com;tag=f7588dc66124429ab736 Call-ID: adfsfasdfasdfds CSeq: 1 SUBSCRIBE Event: conference Accept: application/conference-info+xml Content-Length: 0SIP headers... The Focus processes and accepts the subscription and notifies subscribers of any conference state changes. The conference state includes the state maintained by the Focus itself, the conference policy, and the media policy/information. Step 2.1. The initial conference state document can be included in the 200 OK of the SUBSCRIBE, if the client expresses support for this extension, as follows: SIP/2.0 200 OK To: sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234 From: sip:joe@contoso.com;tag=f7588dc66124429ab736 Call-ID: adfsfasdfasdfds CSeq: 1 SUBSCRIBE Event: conference Accept: application/conference-info+xml Content-Type: application/conference-info+xml SIP headers... <conference-state version="0" state="full" 36 entity="sip:confuri"> <conference-info> <conf-uris> <entry> <uri>sip:Ted@contoso.com;gruu;opaque=app:conf:audiovideo:id:1234</uri> <display-text>audio-video</display-text> <purpose>audio-video</purpose> </entry> <entry> <uri>sip:Ted@contoso.com;gruu;opaque=app:conf:meeting:id:1234</ uri> <display-text>meeting</display-text> <purpose>meeting</purpose> </entry> <entry> <uri>sip:Ted@contoso.com;gruu;opaque=app:conf:chat:id:1234</uri > <display-text>chat</display-text> <purpose>chat</purpose> </entry> <entry> <uri>sip:Ted@contoso.com;gruu;opaque=app:conf:phoneconf:id:1234</uri> <display-text>phone-conf</display-text> <purpose> phone-conf</purpose> </entry> </conf-uris> </conference-info> <....Other conf Info...> </conference-state> The following figure shows the message flow between conferencing components when the Focus bootstraps the Web Conferencing Server. 37 The following is a description of the message flow between conferencing components when the Focus bootstraps the conferencing server: Step 1. The client joins the conference, as described previously. Step 2. The MCU Factory is selected based on the MCU Type and Vendor configured at scheduling time. The Focus then makes a getMcu call to the MCU Factory. Step 2.1. If the MCU Factory finds a suitable MCU, then it responds to the Focus with a success getMcu response. Step 3. When the MCU Server URL has been obtained by the Focus, it then makes an addConference call to the MCU. The MCU can choose to accept or reject the request. However, when failing the call the MCU must place a reason element inside the addConference response element that contains an indicator of why the request was failed. This reason is an enumeration defined in the C3P schema. If the conference exists already, the MCU must respond with conferenceExistsAlready.  The Conf-Uris section lists the MCU Conference URI for this conference. The MCU needs to use this information to correlate incoming media-INVITE requests to the conference.  The Service-Uris section contains two URIs – one is an HTTPS URL that gives the Focus Pool URL for use in sending C3P notifications. This URL is indicated by the ms-notification purpose parameter. The second URL is a SIP URL that specifies the outbound-proxy for use by the MCU when it sends a SIP request. This outbound-proxy is usually the Focus itself but it may be different. We use the purpose value of ms-sip-outbound-proxy to indicate this.  Conference attributes (for example, organizer, user count, admission policy, and expiration time) are communicated in the addConference call.  Entity-Policy information applicable to the MCU is also conveyed in the addConference call (this is discussed in a previous section). Step 3.1. If the MCU accepts the addConference request, it then responds to the addConference call with a success parameter. It can optionally request Focus to send conference notifications by setting the notification parameter appropriately. 38 Joining a Conference After a client joins the conference and the conference is created, the client must establish a media session with a conferencing server responsible for that media type. For each conferencing server that is involved in a conference, the Focus assigns a virtual SIP URI that is routable to the Focus itself. The initial notification from the Focus to the client contains the URIs for all conferencing servers in the conference. A client can join itself to the conference in one of the following two ways:  To join to an IM Conferencing Server or an A/V Conferencing Server (Conferencing Servers that communicate using SIP), a client issues a direct media INVITE to the conferencing server URI.  To join to a Web Conferencing Server (which does not use SIP), a client issues an addUser C3P dial-in command targeted at the conferencing server URI. (All C3P commands are carried inside a SIP INFO.) A presenter client will typically invite another participant into a conference by first sending an appINVITE directly to the other participant. (An appINVITE is an INVITE between client endpoints in which the body of the request contains the Focus URI for the conference.) If that participant client supports C3P, it will join itself to the conference using one of the preceding methods. If the participant is a client with aversion of Office Communications Server prior to 2007, the presenter client will receive a 415 error that will cause the presenters client to issue an addUser C3P dial-out command to the conferencing server URI, to have the conferencing server directly connect to the legacy client. In This Section This section includes the following topics:  Direct Media INVITE Conference Join Method for Office Communications Server 2007 R2  C3P addUser dial-in Conference Join Method Direct Media INVITE Conference Join Method for Office Communications Server 2007 R2 Clients can join a conference by sending a direct media INVITE. This method can only be used with conferencing servers that use SIP to establish sessions, such as the A/V Conferencing Server and the IM Conferencing Server. A media INVITE is an INVITE where the To: line contains the conferencing server URI. Clients can join a conference by sending a direct media INVITE. This method can only be used with conferencing servers that use SIP to establish sessions, such as the A/V Conferencing Server and the IM Conferencing Server. A media INVITE is an INVITE where the To: line contains the conferencing server URI. A client can send the media session INVITE to the conferencing server URI directly, without any prior addUser call. The INVITE is routed to the Focus. The Focus checks if the connection information is a routable SIP address and forwards the INVITE directly to the conferencing server. The Focus also sends the addUser command to the conferencing server on the client's behalf. The conferencing server authorizes the request and responds with the connection information. 39 The following figure shows the message flow between conferencing components when a client joins a conference by sending a direct media INVITE. Client sending the media session INVITE to the conferencing server directly * The BENOTIFY is sent to all clients subscribed to the conference state. The following is a description of the message flow between conferencing components when a client joins a conference by sending the media session INVITE to the conferencing server URI directly: Step 1. The client sends an INVITE to the focus/conference URI it received in the notification document. This INVITE is routed to the focus. The client might have included a session description for media negotiation. Since the focus recognizes that the INVITE was addressed to a particular conferencing server, it safely ignores any session description in the body of the INVITE. Step 2. The Focus then sends an HTTP request to the conferencing server assigned by the Conferencing Server Factory to this conference asking it to expect a new participant (addUser). Any bootstrapping requests that the Focus sends to initialize the conference on the conferencing server are not included in the call flow diagram. Step 2.1. The conferencing server sends a successful response for the addUser call. The response includes the actual URL that it wants the participant to use to communicate with the conferencing server. If the server sending the response is an A/V Conferencing Server, the URL indicates that the participant can communicate with the conferencing server using SIP. Step 1.1. After the Focus receives the successful response for the addUser request, the Focus forwards the INVITE to the A/V Conferencing Server. 40 Step 1.2. The conferencing server sends a successful response to the client. Step 1.3. The client sends an ACK to the conferencing server to complete the INVITE dialog. The same INVITE dialog is also used for media negotiation with the conferencing server. Note: Although the client establishes the INVITE dialog directly with the conferencing server, the SIP requests traverse the Focus. Step 3. After the client successfully joins the conferencing server, it sends a participant joined event to the Focus. Step 4. The Focus sends a participant joined conferencing server state change notification to all clients subscribed to the conference state. Step 5. Direct media negotiation occurs between the client and the conferencing server. With an A/V Conferencing Server, the media are RTP/RTCP streams. C3P addUser dial-in Conference Join Method A client can connect to a non-SIP based conferencing server, such as a Web Conferencing Server, by issuing an addUser C3P dial-in command. When a client issues an addUser dial-in C3P command, the Focus forwards the command to the Web Conferencing Server. The Web Conferencing Server authorizes the command and returns the appropriate connection information. The client then establishes a direct media session with the conferencing server. The Following figure shows the message flow between conferencing components when a client joins a conference by issuing an addUser C3P dial-in command. Client joining media with a Web Conferencing Server using addUser dial-in 41 The following is a description of the message flow between conferencing components when a client joins a conference by sending an addUser C3P command to the Web Conferencing Server: Step 1. The client sends an INFO request with an addUser dial-in command to the Focus. The client uses the focus/conference URI it received in the notification document. Step 2. The Focus determines if a conferencing server has been assigned to support this particular media type for this conference. If a conferencing server has not been assigned, the Focus sends an HTTP request to the Conferencing Server Factory asking it to allocate a conferencing server for this conference. In the diagram, it is assumed that the conferencing server has been assigned to the conference. The Focus then sends an HTTP request to the designated conferencing server asking it to expect a new participant (addUser). Any bootstrapping requests that the Focus sends to initialize the conference on the conferencing server are not included in the call flow diagram. Step 2.1. The conferencing server sends a successful response for the addUser request. The response contains the actual URL it wants the conference participant to use to talk to the conferencing server. If the client is joining a Web Conferencing Server, the URL is a PSOM URL. Authorization information, if any, is also included in the response. Step 3. The Focus sends the PSOM connection information to the client. Step 4. The client directly establishes a PSOM channel with the Web Conferencing Server. Step 5. After the client successfully joins the Web Conferencing Server, it sends a participant joined event to the Focus. Step 6. The Focus sends a participant joined conferencing server state change notification to all clients subscribed to the conference state. BENOTIFY sip:client1@contoso.com SIP/2.0 SIP headers... <conference-state version="1" state="partial" entity="sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234" > <user entity="bob@contoso.com" state="full"> <display-text>Bob Kelly</display-text> <endpoint entity="addf"> <state>connected</state> <!-MEDIA --> <media entity="2" state="full"> <display-text>data collab</display-text> <proto>dataCollab</proto> 42 </media> </endpoint> </user> <....Other conf Info...> </conference-state> Adding Participants to the Conference This section describes the different ways that participants can be added to a conference. In This Section This section includes the following topics:  Adding Participants Using an AppINVITE  C3P addUser dial-out Conference Join Method Adding Participants Using an AppINVITE This method of adding participants to a conference is used by clients that support C3P and can therefore join both the Media and the media conferencing server. After a client has joined a conference successfully, the client can send an app INVITE to another participant. The app INVITE displays as a message prompt in the user's client and contains a conferencing URL and meeting key. After the participant accepts (clicks) the message prompt, it will launch the conferencing client, which then dials the participant in to the conference. The following figure shows the message flow between conferencing components when a client adds a participant to a conference using an appINVITE. Ad hoc invitation to another participant 43 The following is a description of the message flow between conferencing components when a client adds a participant to the conference using an appINVITE: Step 1. The client sends an app INVITE to another participant. The invitation contains information the participant needs in order to dial in to the conference, including authorization information, if any exists. After the participant accepts the invitation, the conferencing client is launched, which enables the client to dial in to the conference. Step 2. After the client successfully dials in to the conference, the Focus sends a participant list update notification to all clients subscribed to the conference state. C3P addUser dial-out Conference Join Method The primary way that legacy clients, such as Office Communicator (2005 release), are invited to join conferences is through a C3P addUser dial-out command. When the presenter client issues an addUser dial-out C3P command, the Focus forwards the command to the conferencing server. The conferencing server authorizes the command, dials out to the legacy client specified in the addUser command, and then establishes a direct media session with the legacy client. This appINVITE mechanism can be used with new clients that support the app INVITE and the new C3P protocol. However, legacy clients can also be invited to conferences. To invite a legacy client to a conference, the client sends an addUser dial-out to another client. The following figure shows the message flow between conferencing components when a client adds a participant to a conference using a C3P addUser dial-out command. 44 Client joining media with A/V Conferencing Server using addUser dial-out The following is a description of the message flow between conferencing components when a client adds a participant to the conference using an addUser dial-out command: Step 1. The client sends an INFO request addUser dial-out command to the Focus. The client uses the focus/conference URI it received in the notification document. Step 2. The Focus determines if a conferencing server has been assigned to support this particular media type for this conference. If a conferencing server has not been assigned, the Focus sends an HTTP request to the Conferencing Server Factory asking it to allocate a conferencing server for this conference. In the diagram, it is assumed that the conferencing server has been assigned to the conference. The Focus then sends an HTTP request to the designated conferencing server asking it to dial out to the user. Any bootstrapping requests that the Focus sends to initialize the conference on the conferencing server are not included in the call flow diagram. Step 3. The conferencing server dials out an INVITE to the client using an outbound SIP proxy, which is usually running on the same server as the Focus. Step 4. The client directly establishes a RTP media channel with the conferencing server. Step 5. After the client successfully joins the conferencing server, it sends a participant joined event to the Focus. 45 Step 6. The Focus sends a participant joined conferencing server state change notification to all clients subscribed to the conference state. Notification Document For each media type used in the conference, the Focus assigns a virtual SIP URI that routes to the Focus. The initial notification from the Focus to the client contains the list of SIP URIs for all the conferencing servers in the conference. The client uses the conference URI to identify the conferencing server it into which it wants to dial or to which it wants to issue a control command. The conference state package data model has the following elements:  Conference description. Conference title and description.  Conference View. Conference-specific information for each entity involved in the conference (for example, the Focus, A/V Conferencing Server, and IM Conferencing Server). This information includes capabilities, current state, settings, and policy information.  Users. Roster of the conferences, the users, corresponding endpoints, and the media sessions to which they are connected. The following is an example of a conference state notification document with two conferencing servers: <conference-info > <conference-description> <msci:conference-view ci:state="full"> <msci:entity-view entity="avMcuConfUri" ci:state="full"> <!—MCU specific data, media-specific states go here --> </msci:entity-view> <msci:entity-view entity="dataMcuConfUri" ci:state="full"> <!—MCU specific data, media-specific states go here --> </msci:entity-view> <msci:entity-view entity="acpMcuConfUri" ci:state="full"> <!—MCU specific data, media-specific states go here --> </msci:entity-view> </msci:conference-view> <users> <user entity="sip:user1@contoso.com" state="full" > <endpoint entity="sip:user1@contoso.com" > <status>on-hold</status> </endpoint> </user> <user entity="sip:user2@contoso.com" state="full" > 46 <endpoint entity="sip:user2@contoso.com" > <status>on-hold</status> </endpoint> </user> <user entity="sip:user3@conf.fabrikam.com" state="full" > <roles><entry>presenter</entry> </roles> <endpoint entity="sip:user1@conf.fabrikam.com" > <status>connected</status> </endpoint> <endpoint entity="{guid}" session-type="audio-video" > <status >connected</status> </endpoint> </user> <user entity="sip:user4@conf.fabrikam.com" state="full" > <roles><entry>participant</entry> </roles> <endpoint entity="sip:user2@conf.fabrikam.com" > <status>connected</status> </endpoint> </user> </users> <display-text>brownbag </display-text> <conf-uris> <entry> <uri>sip:organizer@contoso.com;ms-app=conf/meeting;ms-conf-id=cd</uri> <display-text>Data MCU</display-text> <purpose>meeting</purpose> </entry> <entry> <uri>sip:organizer@contoso.com;ms-app=conf/audio-video;ms-confid=cd/uri> <display-text>AV MCU</display-text> <purpose>audio-video</purpose> 47 </entry> </conf-uris> </conference-description> <conference-info> Conference Deactivation A presenter can terminate a conference that is in progress at any point. When a presenter terminates a conference, the client sends a SIP INFO request with a C3P deleteConference command to the Focus, which includes the conference URI. The Focus performs authorization to verify that the user is a presenter with privileges to end the conference. The Focus then generates an update to the participant list by sending a SIP NOTIFY message to all users with an active INVITE dialog associated with the conference. The conferencing server sends a SIP BYE to each client that has an active media dialog. At this point, the conference has effectively ended. A conference is deactivated in the following scenarios:  When no new participant has joined a conference (meaning the conference is idle) in 24 hours.  10 minutes after all authenticated participants have left the conference. Conference Expiration When a conference is created, an expiration date is typically passed to the server for the conference. When the expiration date arrives, the Focus is responsible for deleting all information about the conference from the conferencing database and the Web Conferencing Server is responsible for deleting the conference content. Web Conferencing Server for Office Communications Server 2007 R2 A discussion of the Web Conferencing Server must necessarily include a discussion of the interactions between the components: conferencing client, Focus, Focus Factory, Conferencing Server, and Conferencing Server Factory. Definitions of the conferencing components are as follows:  Conferencing Client. A SIP endpoint capable of joining and participating in a conference.  Scheduling Client. A SIP endpoint that is responsible for scheduling the conference. For example, the Conferencing Add-in for Microsoft Office Outlook messaging and collaboration client is a scheduling client for scheduled conferences and Office Communicator can be a scheduling client for ad-hoc conferences.  Focus. A Focus is a SIP endpoint that represents a conference. It is responsible for managing the state of the conference, enforcing security, managing roles and privileges and providing conference state updates to the clients. A Focus instance runs on a Front End Server. 48  Focus Factory. An entity that creates, modifies, or deletes a conference in the conferencing database. Clients use SIP SERVICE messages to send C3P commands to and receive C3P commands from the Focus Factory.  Conferencing Server. An entity responsible for a specific media types. This can also be referred to as an MCU. Examples include: Audio/Video, Web Conferencing (data collaboration), IM Conferencing Server, and Telephony Conferencing Server. The Web Conferencing Server enables data collaboration among multiple participants. Conferencing data collaboration features can include application sharing, white boarding, chat, polling, question and answer, Web sharing, multimedia content, file transfer, and PowerPoint support.  Conferencing Server Factory. An entity responsible for allocating a conferencing server to a conference for a specific media type. In the Office Communications Server architecture, all conference control commands are sent by clients to the focus, which then relays these commands to the appropriate conferencing servers after verifying that the client that sent the request has the privileges to perform that operation. Media is then exchanged directly between a client and the conferencing servers. In This Section This section includes the following topics:  Web Conferencing Architecture  File Structure  Metadata Folder  Organizer Folder  Conference Folder  Types of Slides  Content Upload and Download over PSOM  Content Upload over PSOM and Download over HTTPS  Slide Set Files  Handouts (File Transfers)  PersistData Folder (Shared Notes)  Content Folder  Conference Content Folder  File Size Restrictions  Compliance Web Conferencing Architecture Office Communications Server Web conferencing requires that Live Meeting clients can connect to a Standard Edition server or an Enterprise pool, a Web Conferencing Server, and a Web Components Server (IIS). Furthermore, the Web Conferencing Server and Web Components Server must have access to the shared folders that the administrator created during deployment, in order to store meeting information (metadata) and meeting content. The Web Conferencing 49 Server must have read/write access to the metadata folder and write access to the content folder. The Web Components Server must have read access to the content folder. The following figure shows the required topology for Web conferencing with Office Communications Server. You can install and run these servers on the same physical computer or on different computers. However, it is recommended that a dedicated file server hosts the conferencing metadata and content folders. File Structure At a minimum, the Web Conferencing Server is configured with two UNC paths that indicate where the server stores conference state (that is, metadata) and conference content. The first UNC path is where the server stores the conference metadata files. The second UNC path is where the server stores conference content. These folders are also referred to as the metadata folder and the content folder. The following paths can be configured using either the MMC or the Windows Management Instrumentation (WMI) MSFT_SIPDataMCUCapabilitySettings class:  MeetingMetadataLocation property for metadata file location.  MeetingPresentationContentLocation property for content location. In addition to these folders, the Web Conferencing Server can also be configured with a third UNC path for a compliance folder. Regulatory compliance is not enabled by default, but if your 50 organization needs to retain data exchanged in Web conferences to satisfy regulatory compliance requirements, you can configure a UNC path to the compliance folder using either the MMC or the WMI MSFT_SIPDataComplianceSettingClass class. These UNC paths can point to a file system running on the same computer or, preferably, on a dedicated file server. The administrator manually creates these folders when deploying Office Communications Server. Metadata Folder The metadata folder stores the conference metadata (for example, the number of slides, the slide names, and the slide types) that is shared by the Web Conferencing Server with clients over Persistent Shared Object Model (PSOM). Under the metadata folder root, the Web Conferencing Server creates the following structure of subfolders:  For each conference organizer, the Web Conferencing Server creates a separate folder below the metadata folder root. The organizer folder name is a hash value computed using the organizer URI.  For each conference, the Web Conferencing Server creates a separate folder below the organizer subfolder. The conference folder name is the same as the conference ID.  Metadata files for a conference are stored in the conference folder. The following figure shows the structure of metadata folders for m organizers and n conferences for the first organizer. The Web Conferencing Server creates these folders and subfolders when it receives a C3P addConference request from the Focus. If a folder for an organizer does not exist, the Web Conferencing Server creates a new organizer folder. If a folder for an organizer already exists, the Web Conferencing Server creates the conference subfolder below the existing organizer 51 folder. If a folder for a conference does not exist, the Web Conferencing Server creates a new conference folder. If a conference folder already exists, the Web Conferencing Server saves the metadata files in the existing conference folder. Sensitive information about conferences, including each conferences encryption key, is stored in the metadata folder. As a result, it is recommended that, during deployment, the administrator grants Read/Write permissions for the metadata folder only to the user group that will administer the Web Conferencing Server. Contentmgr.xml File In the metadata folder root, the Web Conferencing Server creates an XML file (Contentmgr.xml) that is used to coordinate the mechanism that cleans up the expired content. For example, if your organization deployed multiple instances of the Web Conferencing Server and all instances share the same metadata and content folders, the Contentmgr.xml file is used to monitor and determine which Web Conferencing Server is responsible for running the clean-up mechanism. In the Contentmgr.xml file, you can find the fully qualified domain name (FQDN) of the Web Conferencing Server responsible for removing expired content from the folders. The Web Conferencing Server responsible for removing expired content periodically updates the Contentmgr.xml file with its own FQDN and a time stamp indicating the last time it updated the file. Meanwhile, other Web Conferencing Servers in the topology periodically read the file and verify the time stamp. If more than 10 minutes have passed since the last update, another Web Conferencing Server attempts to lock the file and write its own FQDN in the file to become the new owner of the clean-up process. Organizer Folder When a Web Conferencing Server needs to create a metadata folder for a conference, it extracts the organizer URI from the addConference XML. The URI is passed as input for a hash function. The result of this call is used to search through the subfolders of the metadata root folder to determine whether there is already an existing organizer subfolder. If no organizer subfolder exists, the Web Conferencing Server creates a new one. Having a separate folder for each organizer allows the administrator to easily move the conferences owned by a particular user. The resource kit has a tool, DMHash.exe, which allows an administrator to input an URI and obtain the hash. For example, if you need to change the URI for a user and continue to have the content available, you need to:  Run DMHash.exe with the old URI and get the name for the organizer folder.  Run DMHash.exe with the new URI and get the name for the new organizer folder.  Rename the old folder using the new hash value. Conference Folder When a Web Conferencing Server needs to create a metadata folder for a conference, after the server has created or identified the appropriate organizer folder, the server extracts the conference ID from the XML in the C3P addConference request, and then searches the subfolders below the organizer folder for a folder with the same name as the conference ID. If a 52 matching folder does not exist, the Web Conferencing Server creates a new folder below the organizer folder. The conference folder contains all the information that is used by Web Conferencing Server to recreate the content of a conference. The following figure shows the structure of the files that are stored in a conference folder. 53 The conference folder has one subfolder named for presentations. In this subfolder, the Web Conferencing Server creates all the conference files. Conference.xml File For each conference, a conference.xml file is created. The conference.xml file contains the following information about the conference:  Conference ID. The same as the conference folder name.  Organizer URI. The same URI used to build the organizer hash.  Conference expiration time. The time and date used by the clean-up mechanism to determine when the content should be removed.  Encryption key. The master encryption key. The Web Conferencing Server randomly generates an encryption key using Advanced Encryption Standard (AES) as the encryption algorithm. This key is used to encrypt the metadata XML files for the slide sets in the conference. This encryption is an additional layer of protection on top of the access permissions on the root metadata folder. SSMaxId Each slide set has a unique identifier. In the preceding illustration, the identifiers start with aaa and end with zzz. The SSMaxId file stores the latest allocated ID for saved slide sets. The file is updated by the Web Conferencing Server when a new slide set is created. The file is read by the Web Conferencing Server when the content of the conference needs to be recovered. Types of Slides The Web Conferencing Server enables conference participants to share content that has been uploaded to the conference. If Persistent Shared Object Model (PSOM) was used to upload all content to the conference, content can be downloaded from the Web Conferencing Server to a participant's Live Meeting client using either PSOM or HTTPS. If content is uploaded using HTTPS, then the download is performed by the IIS server instead of the Web Conferencing Server. The following table describes the protocols that can be used to upload and download each type of slide that a Live Meeting presenter can create. Slide Type Upload over PSOM Download over PSOM Download over HTTPS Whiteboard Yes - Yes Snapshot Yes - Yes Poll Yes Yes - Text Yes Yes - Web Yes Yes - Application sharing Yes Yes 54 Slide Type Upload over PSOM Download over PSOM Download over HTTPS PowerPoint Yes - Yes Microsoft Office Word documents Yes - Yes Handouts (file transfer) Yes - Yes Content Upload and Download over PSOM Persistent Shared Object Model (PSOM) offers the most basic mechanism for uploading and downloading content to a conference. Uploading and downloading over PSOM involves only the Live Meeting clients, the Web Conferencing Server, and the file server where the Web conferencing metadata and content folders reside. Using PSOM, the presenters Live Meeting client uploads a slide and its content. The Web Conferencing Server checks the presenter's permissions and then creates the state for the new slide. The Web Conferencing Server saves the state on the file server and then shares the new slide state with all clients in the conference. The following figure shows the upload and download process for conference content. For all slide types except poll slides, the content is sent with the first PSOM message. For poll slides, the content (that is, questions and choices) is sent after an initial create slide has been sent. 55 Content Upload over PSOM and Download over HTTPS When the actual content for a slide is uploaded to the Web Conferencing Server, the client uses a stream to send the data from the local computer to the Web Conferencing Server. The stream mechanism is built on top of Persistent Shared Object Model (PSOM) to send, in real-time, a large amount of data. (PSOM is typically used to send only small pieces of data, such as integers and short strings.) When the content of slides uploaded to the server over PSOM must be accessed by conference participants, HTTPS is used to download the content. For example, PowerPoint slides, Word documents, and handout slides (that is, file transfers) all require participants to transfer from the Web Conferencing Server a significant amount of data, including images and original documents. For these types of slides, the data is transferred to clients using the Web Components Server. First, the Web Conferencing Server writes the content to the shared folder for conferencing content. (The folders where the content is saved are encrypted.) Then, the Web Conferencing Server sends clients in the conference the URL and the encryption key for the content files. Each participant uses this URL to download the content from the Web Components Server. Using the encryption key, each participant decrypts the content and displays it in the Live Meeting window. The following figure shows the data flow when clients download conference content over HTTPS. 56 The upload process is similar to the one whereby the content is downloaded over PSOM. The difference is that the Live Meeting client always sends content to the Web Conferencing Server in a separate step, as a stream over PSOM. After the Web Conferencing Server receives the content stream from the presenter, the Web Conferencing Server generates a random encryption key and file name for the content and saves the content into the content folder on the shared file system. After the content is saved to the file server, the Web Conferencing Server sends the encryption key and file name to the client. The client sends a GET request to the Web Components Server. Since the Web Components Server is configured to use the same content folder, Internet Information Services (IIS) is able to resolve the request and send the client the encrypted content. The Live Meeting client then decrypts the content and displays it. 57 Slide Set Files For each slide set created, the Web Conferencing Server saves two encrypted XML files. The encryption algorithm is AES and the encryption key is the master key stored in the conference.xml file. Because the files are encrypted, their file names use an .exml file name extension. Each slide set has a unique identifier. The slide set file names are created using the following patterns: set-<unique_identifier>.exml and set-s-<unique_identifier>.exml For example, for a slide set with the unique identifier abc, the file names are set-abc.exml and set-s-abc.exml. The content of the two files is the same. The second file is provided for backup purposes. When the Web Conferencing Server needs to save new changes in the slide set with the unique identifier aaa, the server opens the first file—set-aaa.exml—and attempts to save the changes to that file. If the original write operation succeeds, the Web Conferencing Server creates a copy of set-aaa.exml and renames the copy slide-s-aaa.exml. If the write operation fails, the Web Conferencing Server deletes set-aaa.exml, creates a copy of set-s-aaa.exml, and renames the copy set-aaa.exml. The following figure shows the logical flow of the update operation. 58 The update procedure for slide sets is called every five minutes. This value is hard coded and cannot be changed. If an update operation fails, the changes made to a slide set in the past five minutes are not saved. If the Web Conferencing Server stops running during this period, changes to the slides can be lost. However, the Web Conferencing Server continually tries to update the files every five minutes. As a result, if one attempt fails, the Web Conferencing Server can attempt to save the content later. Each slide set file contains the XML serialization of the data required to recreate the slide set content. The generic layout for this XML is as follows:  A root node that contains information about the slide set (for example, the name, creator, and time when the slide set was created).  A child node for each slide in the slide set. This node contains the information about the slide (for example, the name, creator, time when the slide was created, type of slide, a link to the original document, and a link to the images representing the slide).  Based on the type of slide, there can be child nodes. For example, there can be a child node for the annotations in a PowerPoint slide or a child node for the question and answer choices in a poll slide. 59 The file is a snapshot of the current content for a given slide set. The file does not store historical information such as deleted slides or the values for attributes before they have been updated. There are two types of slides:   Slides for which all the slide content is shared between Web Conferencing Server and meeting clients using only the PSOM channel. The following table lists the slide types for which all content is shared over PSOM. Slide Type Slide Content Shared over PSOM Web slide Name, URL Poll Slide Name, question, answer choices Text Slide Name, content Application Sharing Slide Name, type of sharing (that is, Desktop or Application), color depth, process ID Slides for which some part of the content is shared between the Web Conferencing Server and meeting clients over PSOM and some other part of the content is shared between the Web Components Server and meeting clients over HTTPS. The following table lists the slide types for which content is partially shared over PSOM and partially shared over HTTPS. Slide Type Slide Content Shared over Slide Content Shared over PSOM HTTPS Whiteboard Name, annotations Background image (white rectangle) Snapshot Name, annotations Background image (the desktop screen capture from the conference presenter) PowerPoint Name, annotations PNG files for the large slide image and for the slide thumbnail; original PPT document Word Document Name, annotations PNG files for the big image and for thumbnail; original MDI document Multimedia Name Original multimedia file; the chunk files For slides for which some content is shared over PSOM and some is shared over HTTPS, the content that is shared over HTTPS is stored in the conference content folders. The conference 60 metadata file for the slide set stores only the link to the conference content file and the encryption key. For example, if you have a slide generated from a PowerPoint slide, under the XML node for that slide you find the:  Randomly generated name for the original uploaded PPT file.  Encryption key for the PPT file.  Randomly generated name for the large image of the slide in PNG format.  Encryption key for the PNG file.  Randomly generated name for the thumbnail image of the slide in PNG format.  Encryption key for the PNG file. You can use the names of these PPT and PNG files to search for the slide content in the conference content folders. Metadata File for Poll Slide The following is an example of the XML content for a Poll slide. <poll-slide name="[ Poll 1 ]" recording-id="" createdby="sip:vw01@rtcdev.nttest.contoso.com [vw01]"> <question>What day is today?</question> <choice>MON</choice> <choice>TUE</choice> <choice>WED</choice> <choice>THU</choice> <choice>FRI</choice> <choice>SAT</choice> <choice>SUN</choice> </poll-slide> Metadata file for Text Slide The following is an example of the XML content for a Text slide. <text-slide name="[ Text Slide 1 ]" recording-id="" createdby="sip:vw01@rtcdev.nttest.contoso.com [vw01]" > <current-text> 61 This is the content of a text slide I've just typed </current-text> </text-slide> Metadata File for Web Slide The following is an example of the XML content for a Web slide. <web-slide name="[ Web Slide 1 ]" recording-id="" createdby="sip:vw01@rtcdev.nttest.contoso.com [vw01]" url="http://microsoft.com"> </web-slide> Metadata File for Whiteboard Slide The following is an example of the XML content for a Whiteboard slide. <image-slide name="[ White Board 1 ]" recording-id="" createdby="sip:vw01@rtcdev.nttest.contoso.com [vw01]" image-width-attr="704" image-height-attr="528" page-number="-1" rich-slide-type="Whiteboard" thumbnail-aspect="1.33333337"> <ann COLOR="0" AUTHOR="vw01" TYPE="1" recording-id=""> 01000000000a0075007a00af007100cc009c00c000ba009d00b0009b009d00f40084011 400980116009901160099 </ann> <ann COLOR="0" AUTHOR="vw01" 62 TYPE="23" recording-id=""> 17000000009700fa01090144 </ann> </image-slide> Metadata File for Snapshot Slide The following is an example of the XML content for a Snapshot slide. <image-slide name="[ Snapshot 1 ]" recording-id="" createdby="sip:vw01@rtcdev.nttest.contoso.com [vw01]" image="x8d51284585d1.epng" key="a51fe0f3e26813761e12435a9c2c5d89" image-filesize-attr="52865" image-width-attr="388" image-height-attr="369" page-number="-1" rich-slide-type="Image" thumbnail-image="xe31d11b0506d.epng" thumbnail-key="a51fe0f3e26813761e12435a9c2c5d89" thumbnail-aspect="1.0" compliance-image="xcb4de1d7b784-aae.png"> <ann COLOR="0" AUTHOR="vw01" TYPE="1" recording-id=""> 01000000000a0075007a00af007100cc009c00c000ba009d00b0009b009d00f40084011 400980116009901160099 </ann> <ann COLOR="0" AUTHOR="vw01" 63 TYPE="23" recording-id=""> 17000000009700fa01090144 </ann> </image-slide> Metadata File for Word Document Slide The following is an example of the XML content for a Word document slide. <image-slide name="Page 1" slideset-name="test.txt" recording-id="" createdby="sip:vw01@rtcdev.nttest.contoso.com [vw01]" image="xebc7f400248d.epng" key="ce3de85a37a8a6fc6b3b702b70a1a925" image-filesize-attr="6778" image-width-attr="816" image-height-attr="1056" document="x9838edc7b0d2.emdi" document-key="8ca685d4bcfb9afe94cc27ea4bd0a2e1" document-filesize-attr="1537" rich-slide-type="Modi" thumbnail-image="x908006115ceb.epng" thumbnail-key="40d224ca035ee8f77ba9c7342da17b1b" thumbnail-aspect="0.772727251" thumbnail-filesize-attr="748" compliance-image="xf3ae96bf86cd-aag-pngimage0.png" compliance-document="xbe356497761b-aag-x.mdi"> </image-slide> Metadata File for Application Sharing Slide The following is an example of the XML content for an Application Sharing slide. <demo-slide name="Command Prompt - vw01" recording-id="" createdby=sip:vw01@rtcdev.nttest.microsoft.com [vw01] 64 shareProcInfo=sip:vw01@rtcdev.nttest.contoso.com - 01C7E74B9137AC70 shareHwnd="262300" shareSpeed="1" sharePid="4592" slideHotKey="19" slideColor="24" shareTitle="Command Prompt" slideCtrl="1" shareType="1"> </demo-slide> Handouts (File Transfers) You can think of file transfers, also known as handouts, as another type of slide set. Handouts can be considered slide sets that contain only one slide of a single type: a transferred file. The Web Conferencing Server follows the same process to save and update handout slides that it uses for other slide sets. First, the server saves two encrypted XML files for each handout. The content of the two files is the same. The second file is provided for backup purposes. The update procedure for a handout is called every five minutes. If an update operation fails, the changes made to a handout in the past five minutes are not saved. If the Web Conferencing Server stops running during this period, changes to the handout can be lost. However, the Web Conferencing Server continually tries to update the XML files every five minutes. As a result, if one attempt fails, the Web Conferencing Server can attempt to save the content later. The only differences in the save and update process for handouts are the location where the files are saved and updated, the naming convention used to name the files, and the file that keeps track of the IDs for the slide set for handouts. The files are saved under a separate subfolder (named ft) in the conference folder for the organizer. The FTMaxID files contain the last used ID. The names of the files in which the slide set information is saved take the following form: fileset-<id>.exml. The files are encrypted using the master encryption key. The file content represents the XML serialization of handout information. Because handout slides are shared over HTTPS in the XML, there is an encryption key and the randomly generated name for the file that is saved in the content folder. Metadata File for a Handout (File Transfer) The following is an example of the XML content for a handout (file transfer). <fileset name="a8f5689f4866.blb" size="37" key="48d9dd6ebe2ca367478da698493edc21" 65 UploadedOnDate="8/25/2007 12:20 PM" UploadedOn="1188069617459" UploadedBy="sip:vw01@rtcdev.contoso.microsoft.com" file_deleted="false" original_filename="test.txt" creation_date="128325431784134388" CreatedOnDate="1/18/8441 5:22 PM" modification_date="128325431917125620" ModifiedOnDate="1/20/8441 6:18 AM"> </fileset> PersistData Folder (Shared Notes) In the PersistData folder, the Web Conferencing Server stores only one file. The file contains the XML serialization of the shared notes information. The file is encrypted using the conference master encryption key. The file contains the XML serialization for rich text. Metadata File for Shared Notes The following is an example of the XML content for shared notes. <PersistentData> <ScopeManager /> <SharedNotes> <RichString> <PlainText>This is the content of the shared notes pane I've just edited </PlainText> <StyleData> <Character> <FormatTable> <Format fontface="Arial" fontsize="9.0" bold="false" italic="false" underline="false" /><Format fontface="" fontsize="9.0" bold="false" italic="false" underline="false" /> </FormatTable> <FormatRunTable> <FormatRun format="0" length="62" /> </FormatRunTable> </Character> 66 <Paragraph> <FormatTable> <Format bullets="0" numbering="0" /><Format bullets="1" numbering="0" /> <Format bullets="0" numbering="1" /> </FormatTable> <ParaFormats> <Paragraph format="0" /> </ParaFormats> </Paragraph> </StyleData> </RichString> </SharedNotes> </PersistentData> Content Folder The content folder stores the content that is shared between the Web Conferencing Server and clients using the Web Components Server. The content folders structure is similar to other subfolders. The content folder contains the following:  A separate subfolder for each organizer; the folder name is a hash based on the organizer URI.  Under the organizer subfolder, there is a separate folder for each conference; the folder name is the same as the conference ID. The following figure shows the structure of the content folder. 67 Conference Content Folder The conference content folder stores all the conference content that is shared between the Web Conferencing Server and meeting clients. The following figure shows the structure of the files that are stored in a conference folder. Slidefiles Folder The Slidefiles folder stores all the slide content that is shared over HTTPS. All files are encrypted using AES and a randomly generated key. A new encryption key is used for each content file. The key is stored in the metadata file (set-xxx.exml) for the slide set that includes the slide with the content that will be shared over HTTPs. The names of the files are randomly generated and stored in the same metadata file as the encryption key. The following table describes file name extensions for the types of slides that the Slidefiles folder contains. Extension Description EPNG An encrypted PNG image; for example, this can be the larger image in a PowerPoint slide or the slide thumbnail image. EPPT An encrypted original PPT document. 68 Extension Description EMDI An encrypted MDI document – the console converts the Word document into a MDI before it is sent to the Web Conferencing Server. WAV An encrypted WAV document. The following table lists the types of slides that the Slidefiles folder contains and the content each slide type contains. Slide Content Snapshot EPNG for the larger image. EPNG for the thumbnail. PowerPoint slide EPNG for the larger image. EPNG for the thumbnail. EPPT for the original PPT. (There is one copy of this file. For example, if you have a PPT with two slides, you only see a single EPPT file.) Word Document Slide EPNG for the larger image. EPNG for the thumbnail. EMID for the original MDI file. WAV WAV for the original WAV file. Chunks generated by the presenter client from original WAV file. Files Transferred Folder (ft) The ft folder stores all the handouts (transferred files) that are shared over HTTPS. All files are encrypted using AES and a randomly generated key. A new encryption key is used for each content file. The key is stored in the metadata file (fileset-xxx.exml) created for the transferred file that will be shared over HTTPS. The names of the files are randomly generated and stored in the same metadata file as the encryption key. The following table describes the file name extension for the handout slides contained in the ft folder. Extension Description BLB The encrypted transferred file 69 File Size Restrictions Size restrictions are enforced by the Web Conferencing Server for certain documents uploaded to the Web Conferencing Server, such as PowerPoint documents, Word documents, multimedia, snapshot slides, and handout slides. The following table describes the values that the Web Conferencing Server enforces. Value Description PowerPoint Documents, Handout Slides Word Documents, Multimedia, or Snapshot Slides File size The size of a file must not exceed this value. 50 MB 25 MB Total size The total size of all files in a conference must not exceed this value. 100 MB 100 MB Number of files The total number of files in a conference must not exceed this value. 8052 30000 The values for the total size and number of files refer to the files in a conference. It is recommended that you reserve 100 MB for each conference created on the Web Conferencing Server. The file restriction values can be configured using the WMI MSFT_SIPDataMCUCapabilitySetting class. File size policies are enforced each time a new slide or file is added to a conference or an existing slide or file is removed. If the presenter is trying to upload or transfer a new file that results in a violation of file size restrictions, the operation fails. The Web Conferencing Server also provides performance counters that indicate each time an upload or transfer exceeds one of these limits. Compliance If meeting compliance is enabled, compliance folders are created on the file server. The compliance folder stores the content that is shared between the Web Conferencing Server and meeting clients through the Web Components Server in a clear unencrypted format. The compliance folder structure is similar to the structure of subfolders in the metadata and content folders. The compliance folder contains the following:  A subfolder for each organizer. The folder name is a hash value computed using the organizer URI.  A subfolder for each conference under each organizer subfolder. The folder name is the conference ID. 70 The following figure shows the structure of the compliance folder. Ensure that only authorized users have read or write permissions and that the Web Conferencing Server has write permissions to the compliance folder. Compliance Folder The compliance folder stores unencrypted metadata and content files. The following table lists the compliance subfolders and the types of files stored in those subfolders. Subfolder Description Content Stores the copies of metadata files. Content-upload Stores the copies of content files. Chat Stores the logs for Chat sessions. Poll Stores the logs with the votes for Poll slides. Qna Stores the logs for Question and Answer sessions. Unlike the metadata and content folders, the compliance folder also stores all deleted slides. The metadata and content folders only store the most recent conference content. The following figure shows the structure of compliance subfolders. 71 72 Conferencing Scenario Call Flows in Office Communications Server 2007 R2 This section describes the logical sequence of events and call flow for various conferencing scenarios. Lock or Unlock a Conference A presenter can lock a conference at any point to prevent new users from joining or being added to the conference. When a presenter locks a conference, the client sends a SIP INFO request with a C3P modifyConferenceLock command to the Focus that includes the conference URI. The Focus performs authorization to verify that the user has privileges to lock the conference. The Focus then relays the modifyConferenceLock command to all conferencing servers. The focus then sends a C3P response to the client indicating success. The following figure shows the message flow between conferencing components when a client locks or unlocks a conference. The call flow when a presenter unlocks the conference is similar, except the locked value in the command body is set to false. Dial In to a PSTN Conference Using SIP C3P (Telephony Conferencing Server) Office Communications Server 2007 R2 enables PSTN (that is, telephone) conferences to provide the audio portion of a Web conference. Any user with a valid PIN can join a PSTN conference by dialing the audio conferencing provider. (An audio conferencing provider is a conferencing bridge offered by a telephone carrier with whom your organization has contracted.) The audio conferencing provider authorizes the PIN and sends a SIP NOTIFY to the Telephony Conferencing Server indicating that a new user is joining the conference. This NOTIFY is sent to the Focus, which then proxies the NOTIFY to all other users in the conference. 73 Note that this scenario is distinct from the new Dial-In Conferencing functionality introduced in Office Communications Server 2007 R2, where the conference resides on an Office Communications Server, as opposed to a conferencing bridge offered by a telephone carrier. When using the Office Communications Server 2007 R2 PSTN capabilities (where the conference resides on an Office Communications Server), the client simply needs to dial the PSTN access number. The Communicator 2007 R2 Attendant handles authentication and joins the PSTN user into the audio conferencing server. In order for clients to join using PSTN, the organizer client must have requested PSTN capabilities when creating a conference. The following figure shows the message flow between conferencing components when a client dials in to a PSTN conference hosted on a conferencing bridge offered by a telephone carrier. Dial Out to Device Using addUser (Audio Conferencing Provider) For a presenter to invite his own phone or another participant's phone into the conference, the presenter's client sends a SIP INFO request to the Focus with a SIP C3P addUser command. The Focus verifies that the client sending the request is a presenter, and then relays the addUser command to the conferencing server with information about the endpoint to call. (Participants cannot dial out to other users.) The conferencing server forwards the INFO message to the audio conferencing provider. The ACP responds to the conferencing server. The conferencing server forwards the response from the ACP to the Focus. The ACP calls out to the user's phone and sends a SIP NOTIFY to the conferencing server. The conferencing server sends a NOTIFY to the Focus indicating that the user has connected. The Focus then sends an updated participant list to all clients in the conference. Remove a Participant Participants can choose to leave a conference or presenters can choose to remove or eject other participants. When a participant leaves a conference, the participant's client sends a SIP INFO request to the Focus with a C3P deleteUser command indicating which participant to remove. The Focus validates the request and then sends a SIP BYE in the join dialog. The join dialog is terminated. The subscription dialog is also terminated after the join dialog is terminated. The Focus relays the deleteUser command to all conferencing servers in the conference. Each conferencing server sends a media BYE to the participant to terminate media streams to the 74 participant. The Focus sends a SIP NOTIFY with an updated participant list to all participants with an active INVITE dialog in the conference. The conferencing server sends a SIP BYE to the participant who is leaving the conference. If a presenter has removed multiple participants from the conference, the conferencing server sends a SIP BYE to all ejected participants. If a participant is joined to a conference using multiple endpoints, the conferencing server deletes each endpoint. The following figure shows the message flow between conferencing components when a participant is removed from a conference. Mute or Unmute At any time during a conference, a participant can mute or un-mute his media stream and presenters can do the same for other participants. When a participant wants to mute or unmute his audio, the participant's client sends a SIP INFO request with a C3P modifyEndpointMedia command to the Focus. The INFO request indicates the client to mute or unmute. The Focus validates the command and sends it to the conferencing server responsible for the media type that the client wants to mute or unmute. The Focus performs authorization to verify the type of participant. (Only conference presenters have the authority to submit a request to mute or unmute another participant.) If the participant is authorized to perform the mute or un-mute operation she requested, the Focus sends a 202 Accepted response. The Focus then sends a SIP INFO request with the C3P response to the client. The conferencing server sends a C3P NOTIFY to the Focus. When the Focus receives the C3P NOTIFY from the conferencing server, the Focus updates the conference participant list and sends the updated list to all participants with an active INVITE dialog in a SIP NOTIFY message. 75 If a participant connected to an Audio/Video conferencing server is muted, the Audio/Video Conferencing Server renegotiates audio media with the client so as to stop receiving audio from that client. This is done as an optimization to prevent the client from unnecessarily sending audio media that would have been dropped by the conferencing server in any case when the participant is muted. Similarly when a user is unmuted, the Audio/Video conferencing server renegotiates the audio media to now start receiving audio from that client. The following figure shows the message flow between conferencing components when a participant mutes or unmutes his media stream. Make Presenter A presenter can choose to promote any attendee to the presenter role. This is a privilege available to presenters only and is implemented using the modifyUserRoles C3P command. When a presenter promotes an attendee, the presenter's client sends a SIP INFO request to the Focus with a C3P modifyUserRoles command. The Focus validates that the participant making the request is a presenter, and then sends a 202 Accepted. The Focus relays the modifyUserRoles command to all conferencing servers to inform the conferencing servers of the change in participant role. The Focus sends a SIP INFO with the C3P response to the client that made the request. The Focus sends a SIP NOTIFY request with an updated participant list to all participants with an active INVITE dialog. The following figure shows the message flow between conferencing components when a presenter promotes another participant to the presenter role. 76 Dial-In Conferencing Scenario The following figure shows the relationships among the components that are required to support dial-in conferencing. The figure shows a single Front End Server and a single Mediation Server. In practice, there will probably be multiple load-balanced Front End Servers, each of which will be running all the shaded components, for each Enterprise Edition pool. There will also probably be multiple Mediation Servers. 77 In This Section The following topics describe these components and relationships in detail:  Server-Based Dial-In Conferencing Components  Client-Based Dial-in Conferencing Components 78  Call Flows Server-Based Dial-In Conferencing Components Dial-in conferencing is supported by Office Communications Server 2007 R2 Standard and Enterprise Editions, and the functionality is identical on both editions. For organizations that deploy Enterprise Edition for its greater scalability and availability, the consolidated topology is now recommended for most installations of Office Communications Server 2007 R2. For detailed information about the consolidated topology, see the Enterprise Edition Consolidated Topology section of the Microsoft Office Communications Server 2007 R2 Supported Topologies and Infrastructure Requirements guide. In a consolidated Enterprise Edition topology, each member of a pool of Front End Servers runs a set of components: the SIP Proxy/Registrar, the Focus Factory, the Conferencing Factory, all of the conferencing servers (that is, IM, Web Conferencing, A/V, and Application Sharing), and hosts two applications on the Unified Communications Application Server (Application Server) platform that are required for dial-in conferencing: the Conferencing Attendant service and the Conferencing Announcement service. Note: Conferencing Servers were formerly known as multipoint control units (MCUs): The Conferencing Server Factory is also known as the MCU Factory, the A/V Conferencing Server is the same as the AV MCU, and so on. Conferencing servers are actually services of the Microsoft Windows operating system that run as independent processes separate from the Rtcsrv.exe front-end service. In addition to the Office Communications Server 2007 R2 Front End Servers, dial-in conferencing requires at least one Mediation Server integrated with a media gateway and/or a PBX, as well as Communicator Web Access (2007 R2 release). (Communicator Web Access is required for dial-in conferencing even if you are not providing your users with a browser-based client.) Active Directory–Based Configuration Data Because nearly all of the settings that are used by dial-in conferencing apply to the entire organization, Office Communications Server 2007 R2 stores them with other global configuration data in Active Directory Domain Services (AD DS). The Active Directory schema for Office Communications Server 2007 R2 adds new Contact objects that are specific to dial-in conferencing, as well as location profile–access number contact object mappings, additional global meeting policy attributes, new Trusted Service objects for the Conferencing Attendant service and the Conferencing Announcement service, and URLs for internal and external access to the Communicator Web Access server or server farm. Contact Objects Office Communications Server 2007 R2 adds a new msRTCSIP-ApplicationContacts container class to the configuration container under the RTC Service object. Like the Subscriber Access and Auto Attendant Contact objects that are used by the Microsoft Exchange Server 2007 Unified Messaging service, these instances have an objectClass of top; person; organizationalPerson; 79 contact. Unlike the Exchange Contact objects, dial-in conferencing Contact objects are stored in the Configuration container rather than in a Domain container, and dial-in conferencing Contact objects do not appear in the Active Directory Users and Computers snap-in. Unlike users, Contact objects do not have their own authentication credentials. Services running under the identity of a Contact object must either be flagged in AD DS as trusted or else impersonate the identity of the user who called the service. There will be multiple Contact objects in this container that are related to dial-in conferencing: one for each dial-in number, plus one for the Conferencing Attendant service (CAAPrivateContactObject) and one for the Conference Announcement service of each pool. Each contact is a SIP User Agent that acts as a robotic endpoint for processing and routing dial-in conference callers and for playing conference announcements. Administrators manage dial-in contact objects using the Conferencing Attendant Properties tab of the Forest Properties dialog box in the Office Communications Server management snap-in. For each Conferencing Attendant phone number added, an Application Contact object is created that contains the phone number, the pool name affiliated with the number, a SIP URI (for example, sip:Microsoft.RTC.Applications.CAA-<GUID>@contoso.com), the primary spoken language that is played to the caller by the Conferencing Attendant service, and a list of up to four secondary languages that will be presented as alternates to users who dial into the Communicator 2007 R2 Attendant. However, the Conference Announcement Service and CAAPrivateContactObject objects are configured during product activation, and neither is exposed through the snap-in. If you change the name of your organization’s main SIP domain after you install Office Communications Server 2007 R2, you need to change the msRTCSIP-PrimaryUserAddress attribute for both objects to reflect your new primary SIP domain. (Both use the form sip:RtcApplication-<GUID>@<SIP Domain>.) You can edit this attribute by using ADSIEdit, or you can use the WBEMTest utility to edit the PrimaryURI attribute of the corresponding Windows Management Instrumentation (WMI) Conference Announcement Service and CAAPrivateContactObject instances, which are located in the MSFT_SIPApplicationContactSetting top-level class. Dial-in Contact objects cannot be shared across pools; each must be bound to an Enterprise pool or one Standard Edition server. Location Profile to Access Number Mappings Another new AD DS schema change in Office Communications Server 2007 R2 is the Location Contact Mappings container. This container contains instances of the msRTCSIPLocationContactMapping class, and each instance binds a dial-in contact to a location profile. Just as each user who is enabled for Enterprise Voice is assigned a corresponding location profile, either explicitly or by default, each Conferencing Attendant dial-in contact also must be assigned a location profile. The Regions tab of the Conferencing Attendant Properties dialog box of the Office Communications Server management snap-in is used to manage these assignments. A region is a group of dial-in access numbers that belong to single Office Communications Server Enterprise Voice location profile. Users assign a region to the dial-in meetings and conferences they create, 80 thereby setting the dial-in numbers that are used by the conference. Users who are enabled for Enterprise Voice are assigned a default region. They can, however, manually override this default, for example, if dial-in attendees would be better served by access numbers in another geographic region. Global Meeting Policy Authorizing users to create dial-in conferences is managed through the global Meeting Policy tab. This tab is not new, but in Office Communications Server 2007 R2 the schema is extended with two more settings, Enable PSTN conference dial-in and PSTN conference dial-in requires passcode. Either a single meeting policy can be assigned to all users in the organization, or different policies can be assigned to individual user accounts. These meeting policies are stored in Active Directory Domain Services as instances in the Configuration Container under Services, RTC Service, and then Policies. Each instance has an msRTSIP-PolicyContent attribute that contains flags for EnablePSTNConferencing and TrustedConferencingPinRequired. Trusted Services In addition to the Contact objects described previously, both the Conference Announcement Service and Conferencing Attendant Service are represented by multiple objects (class type = msRTCSIP-TrustedService) in the Configuration Container under Services, RTC Service, and then Trusted Services container of Active Directory Domain Services (AD DS). For each pool supporting Dial-in Conferencing services, there must be one instance of each type for each pool name (msRTCSIP-TrustedServerFQDN = <pool name FQDN>), plus instances for each server in those pools (msRTCSIP-TrustedServerFQDN = <server FQDN>). For Standard Edition servers, there are only two objects, since the pool name and server name are the same. These trusted service instances will have an RTCSIP-TrustedServiceType attribute of either Microsoft.RTC.Applications.CAA or Microsoft.RTC.Applications.CAS. Communicator Web Access URLs Communicator Web Access serves an auxiliary role for Dial-in Conferencing unrelated to its primary role as a Web server for hosting browser-based Communicator clients—to serve Web pages that are linked to by Office Communicator 2007 R2 client, the Communicator 2007 R2 Attendant, the Conferencing Add-In for Office Outlook, and the Live Meeting client. These Web pages allow users to view dial-in numbers for various locations and to provide them with an interface to reset their dial-in corporate PIN numbers and personal conference IDs. One Communicator Web Access server or server farm normally serves the Dial-in Conferencing Settings Web pages for all users across all pools, as shown in the following figure. 81 To launch this page, Office Communicator, Communicator Attendant, the Conferencing Add-In for Office Outlook, and the Live Meeting client obtain the internal and external URLs of the Communicator Web Access server from the Office Communications Server Front End Server through in-band provisioning when a user signs in. Because the Communicator Web Access path is a global rather than pool-specific setting by default, the Front End Server obtains these values from Active Directory Domain Services (AD DS) through a WMI call to MSFT_SIPGlobalCWAServerConfigSetting for the InternalURL, ExternalURL, PhoneConfURLSuffix, and WebJoinURLSuffix attributes. (In Active Directory Domain Services, these values are stored in the RTC Services, Global Settings container object as msRTCSIPDefaultCWAInternalURL, msRTCSIP-DefaultCWAExternalURL, and msRTCSIPGlobalSettingsData.) If an administrator needs to change either of the Communicator Web Access paths, he can use the Communicator Web Access administrative snap-in to republish a new path. You can also configure the Communicator Web Access URL at a pool level and this value overrides the global value. The pool level WMI property is MSFT_SIPCWAServerConfigSetting. To publish this value you need to do it manually using WBEMTest.exe and assign a GUID and back-end database path to it. Office Communications Server Front End Server Components To support conferences with dial-in users, each Office Communications Server 2007 R2 Enterprise Edition server in a consolidated front end topology runs the following required 82 components: SIP Proxy, Conferencing Attendant, Conference Announcement Service, Focus Factory, Conferencing Server Factory, and the Audio/Video Conferencing Server. A Standard Edition server runs the same components, but it uses a local SQL Server Express Edition database rather than a remote SQL Server database. The Focus Factory is responsible for handling conference creation and deletion, and stores this information in the back-end database. After a conference is activated, it is hosted by a Focus instance, which manages conference state, user roles, and privileges; enforces security; and provides conference state to participating clients. The Conferencing Server Factory provisions conferencing servers (that is, MCUs) as requested by the Focus and manages their state during the duration of the conference. Even though each pool server in a consolidated topology runs all of these components, many operate in their own process space. Although the Focus will always be running on the same server as the Conferencing Server Factory that is managing the conferencing servers for the meeting, the Conferencing Attendant, Conference Announcement Service, and A/V Conferencing Server can be running on other Front End Servers in the pool. This architecture allows individual server roles and unified communications applications to be load-balanced independently of one another. For example, in a load balanced pool consisting of five servers, a dial-in caller coming into the system from a Mediation Server could be routed by the SIP Proxy service on Server1 to the Conferencing Attendant running on Server2, which then hands off the caller to the meeting’s Focus running on Server3, which in turn connects the caller’s audio to an A/V Conferencing Server running on Server4, which is being monitored and announced by a Conference Announcement Service running on Server5. In fact, the Conferencing Attendant Service that answers a dial-in attendee might be running in a pool separate from the one that hosts the meeting. If one of these services became unavailable, the load balancer would detect the failure and redirect new service requests to one of the other pool servers. If one of those servers fails or is taken offline during a conference already in progress, Office Communications Server can detect the failure and regenerate the terminated component (in the case of the Focus) or assign the conference to another conferencing server in the pool and reconnect participants. The sections that follow describe in more detail the role each application or server role plays in supporting Dial-in Conferencing. Conferencing Attendant The Communicator 2007 R2 Attendant is an auto-attendant service (a bot) that authenticates and joins dial-in participants to audio conferences. Communicator 2007 R2 Attendant supports 14 different languages. The Conferencing Attendant prompts the caller for Conference IDs and passcodes (if calling in as an anonymous participant) or extension number and PIN (if 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 TCP port 5072 for incoming calls. These requests normally come from a Mediation Server and are proxied by the 83 Mediation Server’s next hop pool. If a load balancer is used, it listens on TCP port 5072 as well and redirects requests to a Conferencing Attendant service running on one of the pool servers. There are only a few pool-level settings stored in the back-end SQL Server database. The Office Communications Server administrative snap-in exposes the settings for minimum PIN length, retry lockout count, and PIN aging policy settings through the PSTN Conferencing tab in the Front End Properties dialog box of the selected pool. These settings can also be accessed through the MSFT_SIPPSTNConferencingSetting WMI object, in addition to the PINExpiration, PINLength, and PINRetries property values. Note: The pool-level MSFT_SIPPSTNConferencingSetting WMI object also contains values for InternalURL and ExternalURL properties. These last two settings are left-over artifacts of an earlier development build and can be disregarded. They refer to a Web component named PhoneConferencing that was used during development and did not get removed from the final release of Office Communications Server 2007 R2 product. This component is visible from the Internet Information Services (IIS) Manager connected to Front End servers, but it is superfluous. 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 Communicator 2007 R2 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. If a load balancer is used, it also listens on TCP port 5063 and redirects requests to the Conferencing Attendant service on one of the pool servers. Focus Factory The Focus Factory is responsible for scheduling meetings and writing them to the back-end database. When a user creates a new meeting, the meeting client sends a SIP SERVICE message to a Focus Factory, which creates a new instance of the meeting in the database and returns information about the newly created meeting to the client. The Focus Factory functionality has been enhanced in Office Communications Server 2007 R2 to support dial-in conferences. When a client (which could be Office Communicator, the Conferencing Add-in for Outlook, or the Live Meeting client) creates a scheduled or unscheduled meeting, if the meeting creator requests and is permitted to include dial-in participants, the Front End Server communicates with a Focus Factory to generate a dial-in Conference ID. Conference IDs are short numeric conference identifiers that are entered by dial-in attendees (by using the phone keypad) to indicate the meeting that they want to join. Conference IDs consist of a non-unique pool ID concatenated with a unique portion generated by the hosting pool when the 84 meeting is created. The pool portion of the Conference ID routes the dial-in caller to the specific pool where the meeting is hosted. Although Meeting IDs (16 to 32 character hexadecimal identifiers used in the Conference URI to uniquely identify meetings), the short Conference IDs of expired conferences can be reused and are unique only within the scope of a single Office Communications Server organization. The mappings between the Conference IDs and Meeting IDs are stored in the RTC database. Users do not normally need to enter Meeting IDs manually, but dial-in users manually enter Conference IDs using their keypads to tell the Conferencing Attendant Service which meeting they want to join. The overall length of Conference IDs not fixed and will expand as needed to support the number of pools in the organization and the number of unexpired meetings in the pool, and the pool portion (that is, the pool ID) will be at least two digits. As a minimum security consideration to minimize effortless guessing of consecutive Conference IDs, after the complete conference ID is generated, it is obfuscated by Office Communications Server (that is, the number the user sees cannot be parsed into a pool portion and a meeting portion). The Conference ID is generated at the home pool of the user who schedules it, and it designates the pool that will host the meeting. However, since the conference creator’s pool always hosts the conference, this means that conference IDs must be released and reissued whenever a conference’s creator has been moved to another pool. This action is automatically taken by Office Communications Server. Unlike Meeting IDs, Conference IDs may be reused after the conference mapped to has been deleted or moved. The Front End Server passes the Conference ID back to the conference client, where it is conveyed to dial-in participants through some other means, such as in an e-mail message. Focus An instance of the Focus for each active meeting exists on one of the servers in the pool that is hosting the meeting, and it maintains the conference state and can be monitored by other components. For example, the Conference Announcement Service monitors the Focus to determine when users arrive or leave the meeting and when users have been muted or unmuted. The Focus publishes the meeting roster, which has been updated in Office Communications Server 2007 R2 to include dial-in callers. If the caller has an Active Directory Domain Services account and has provided his or her extension number and corporate PIN, he or she will be listed in the roster lists of Live Meeting clients under the display name assigned to their user account. However, if the caller has provided only the Conference ID (and passcode if required), he or she will be listed in the roster by Caller ID (if the number is passed to the Mediation Server by the PBX or gateway). If not, such callers will be listed as Unidentified Participant 1, Unidentified Participant 2, and so forth. From the roster list in the Live Meeting client, presenters can forcibly mute, unmute, and eject dial-in participants just as if they were Live Meeting client users. 85 Conferencing Server Factory Although the Conferencing Server Factory is essential to support dial-in conferencing by provisioning the A/V Conferencing Server that is needed for the meeting, it does not exhibit any special behavior when dial-in conferencing attendees are involved. Audio/Video Conferencing Server An A/V Conferencing Server acts as a relay hub for audio and video used by the meetings assigned to it. Dial-in callers appear to the A/V Conferencing Server as just another audio endpoint. After a dial-in caller has been authenticated, the Conferencing Attendant signals the A/V Conferencing Server in the pool hosting the meeting to establish an audio leg with the Mediation server handling the dial-in participant. When a dial-in user is connected to the A/V Conferencing Server, it in turn invites a Conference Announcement Service in its pool to the meeting (unless one is already running), which in turn joins the Focus as a trusted participant. The Conference Announcement Service monitors the Focus, and announces certain state change events to all dial-in participants, such as when a participant enters or leaves the meeting, or to individual dial-in participants, such as when his or her microphone has been muted. Mediation Servers In order for the Dial-in Conferencing feature to service PSTN callers, the organization must have either one or more Mediation Servers connected to the PSTN using a Media Gateway connected to the PSTN or to a PBX, or Direct SIP Integration with a PBX or external SIP Trunking service provider. As with Enterprise Voice user Direct Inward Dialing (DID) numbers and Exchange Auto Attendant and Subscriber Access numbers, calls from the PSTN to the published dial-in access numbers must also be routed to a Mediation Server. Inbound routing normalizes the called-party number according to the default location profile rules on the Mediation Server and routes calls to the address of the next-hop pool. No special Mediation Server configuration is required to support dial-in conferencing, but the normalization rules for the Mediation Server’s default location profile must normalize the dialed number to a form (typically E.164) matching the Line URI of a Conferencing Attendant contact object. Routing of Conferencing Attendant contact numbers to a Mediation Server may also require additional routing rules on the PBX and/or Media Gateway if the phone number patterns differ from those of Enterprise Voice users (or if Enterprise Voice has not been deployed). When planning for dial-in conferencing, keep in mind that each dial-in user will consume a channel on a trunk connecting the PBX and/or Media Gateway to the PSTN. For organizations who size their number of PSTN trunks and Mediation servers to accommodate normal levels of inbound and outbound call volumes, this means they may not be able to support large numbers of dial-in users; however, for such meetings they could still use an audio conferencing provider (ACP) or the Web-hosted Live Meeting Service. In Office Communications Server 2007 R2, it is not possible to link an ACP conferencing bridge to an Office Communications Server A/V Conferencing Server. 86 Communicator Web Access Server As noted earlier, the 2007 R2 release of Communicator Web Access serves a role in dial-in conferencing that is unrelated to its primary role of hosting a browser-based client for Office Communications Server. Using the InternalURL and ExternalURL attributes of the MSFT_SIPGlobalCWAServerConfigSetting object, which are provisioned to the client during sign-in, the Office Communicator, Outlook Conferencing Add-In, and Live Meeting clients expose links to new Communicator Web Access Web pages that display dial-in access numbers for various locations and languages and that give users an interface to reset their personal dial-in conference codes and PIN numbers. Piggy-backing this functionality on Communicator Web Access spares Office Communications Server customers from dedicating a separate server to this role and—because the function is used very lightly—it does not significantly degrade overall Communicator Web Access performance. This approach also makes it easier for organizations to provide Internet-based access to these Web pages, because most organizations that deploy Communicator Web Access also publish the service to the Internet. The Dial-in Conferencing Settings Web site is accessed by appending /dialin to the internal or external Communicator Web Access URLs. The site consists of two separate pages:  Publish Dial-in Conference Numbers. The home page of the Dial-in Conferencing Settings Web site. This page does not require authentication and is read-only. It publishes the Conferencing Attendant access numbers for various languages and regions, and the page itself is available in 14 languages. (Support for non-English versions of the page requires installation of the Communicator Web Access Multilanguage Pack.)  Change per-user dial-in settings. From the Dial-in Conferencing Settings home page, a user can click a sign-in link that brings up a site that enables him or her to reset dial-in conference PIN numbers and personal conference IDs. This page is available in the same languages as the home page. Communicator Web Access does not store data locally. All dial-in conferencing data is extracted from the pool that is assigned to the logged-on user, which retrieves data from the pool’s database and from Active Directory Domain Services (AD DS). Note: Communicator Web Access support for dial-in conferencing is also unrelated to the new PSTN dial-out feature, which allows Communicator Web Access users to participate in voice calls by calling them back on a PSTN phone or PBX extension. Client-Based Dial-in Conferencing Components To create a dial-in–enabled meeting, the user must be authorized and be using the 2007 R2 release of the Microsoft Conferencing Add-in for Microsoft Office Outlook, or the Live Meeting client. 87 Conferencing Add-in for Microsoft Office Outlook The 2007 R2 release of the Conferencing Add-in for Microsoft Office Outlook has some new functionality for scheduling dial-in conferences.  Users can connect directly from Outlook to the Dial-In Conferencing Settings Web page on the Communicator Web Access server.  Meeting creators can enable dial-in conferencing as an audio option. When Outlook starts, the internal and external URLs of the Communicator Web Access server are provisioned to Outlook from the pool by using the connection information that is configured in the Live Meeting client. When the Outlook user selects Dial-In Conferencing Settings from the Conferencing menu, Outlook first tries to open the \dialin site on the external URL of the Communicator Web Access server. If this fails, then it retries on the internal URL. To enable dial-in conferencing for users, the meeting creator must enable dial-in conferencing for the meeting using the Conferencing Add-in Audio options menu. When an Outlook user clicks Schedule a Live Meeting, the client makes a SIP request to the user’s pool stipulating that it wants to schedule a dial-in enabled meeting and generates a 32character hexadecimal Meeting ID. The pool checks that it has the capability to support a dial-in meeting and obtains from the Focus Factory the dial-in numbers that are assigned to the user’s pool, a Conference ID, and sends it back to the client. The Add-in inserts this information into the meeting invitation. If the meeting is set to allow anonymous participants and if meeting policy mandates use of passcodes or if the meeting creator chooses to use one, the client will also generate a random passcode and send it (encrypted) to the Focus Factory. This passcode is also included in the meeting invitation. If the Outlook clicks Schedules a Conference Call (instead of a Live Meeting) and the invitation’s audio option is set to Use my assigned conference ID for each conference, the same process occurs, except that the conference ID and passcode (if mandated by meeting policy) are the ones that were previously generated by the Dial-In Conferencing Settings Web site. The result will be an audio-only meeting, to which non-phone participants access using Office Communicator instead of Live Meeting. If the audio option is Use a new conference ID for each conference, the Focus Factory will assigna new Conference ID. Live Meeting Client The Meet Now feature of the Live Meeting 2007 client enables users to create unscheduled conferences that support dial-in users. If dial-in conferencing is enabled, the Focus Factory assigns the meeting a Conference ID and the client generates a random passcode (if forced by meeting policy or if the meeting creator chooses to use one). This information, and the dial-in numbers, is displayed in the client when the meeting organizer clicks View Call-In Details on the Meeting list or on the Options menu of the Voice & Video list. However, unlike the Conferencing Add-In for Outlook, the Live Meeting client does not automatically distribute this information to participants. Even if the meeting organizer 88 uses the By E-mail menu option in the client (under the Attendees menu, under Invite) to create an e-mail invitation, the organizer must manually insert the meeting’s dial-in information into the body of the message. Office Communicator Although Office Communicator 2007 R2 does not provide a means for users to create scheduled meetings, it does enable users to create unscheduled audio/video meetings. However, Office Communicator does not contain provisions for inviting dial-in attendees to these meetings. (Office Communicator-based participants can use the client’s dial-out feature to add phone users to these meetings.) Nevertheless, Office Communicator users can click a menu option that links them to the Communicator Web Access server to view and modify their dial-in conferencing settings. Office Communicator obtains the internal and external Communicator Web Access URLs using in-band provisioning upon sign-in and uses these to open the Dial-In Conferencing Settings Web page in a separate browser window. Call Flows There are two separate flows to dial-in conferencing: creating a dial-in conferencing–enabled meeting and joining the meeting as a dial-in participant. Meeting Set-up Office Communications Server 2007 R2 introduces a new Centralized Conference Control Protocol (C3P) command: getConferencingCapabilities. The client sends a SIP SERVICE request containing a getConferencingCapabilities request to the Focus Factory to discover capabilities of the hosting pool. The Focus Factory returns information that the client uses to form AddConference and ModifyConference requests. For dial-in conferencing to be offered to the person scheduling the meeting, the Pstn-bridging Enabled value must be set to True. The client will use this information when it issues subsequent AddConference and ModifyConference SERVICE requests. To create an Anonymous-Allowed Live Meeting with Dial-In Conferencing support 1. The client (that is, either the Conferencing Add-In for Outlook for scheduled meetings or the LiveMeeting client for unscheduled meetings) sends a SIP SERVICE request containing a GetConferencingCapabilities request that gets proxied to a Focus Factory globally-routable User Agent URI (GRUU) in the pool where the user is homed. 2. The Focus Factory extracts meeting capability information from its database and returns the information to the client. This information includes all of the dial-in conferencing dial-in access numbers categorized by region. The user’s location profile region determines the access numbers for the conference. 89 3. The client sends a SIP SERVICE request containing an AddConference request to the Focus Factory with an msci:pstn-access attribute tag. If the user’s Meeting Policy requires that anonymous meetings have passcodes, the client generates a passcode, encrypts it, and sends it as part of the request. 4. The Focus Factory creates a meeting instance in the pool database, assigns it a Conference ID, and then returns this information to the client. A SIP SERVICE GetConference request to the Focus Factory is required to complete the meeting creation process. 5. If the meeting is scheduled from the Conferencing Add-in for Outlook, the user sends a meeting invitation that contains the dial-in information to the other attendees. If the meeting is created by using the Meet Now button in the Live Meeting client, the meeting creator has to copy the dial-in information and send it to other attendees by using an instant message or an e-mail message. The following figure shows the sequence of data exchanges between the components involved. Connecting to the Meeting Authenticated Office Communicator and Live Meeting users (including federated users) who have a computer with audio capability can connect to the conference as they did in Office Communications Server 2007. Assuming dial-in attendees call in from the PSTN on an ISDN-PRI trunk that is connected to the hosting organization’s PBX and a media gateway is employed in the solution, the call flow for joining the meeting is as follows: 1. The first Office Communicator or Live Meeting–based attendee joins the meeting, which activates the meeting and causes RTCSrv.exe to instantiate a meeting Focus on a Front End Server in the pool that is hosting the meeting. The Focus, in turn, requests the Conferencing Server Factory on that server to assign an A/V Conferencing Server to the meeting (and other Conferencing Servers). 2. A dial-in attendee dials the conference access number listed in his or her e-mail invitation, and the PSTN routes the call to the organization’s PBX. 90 3. The PBX uses the called-party number to route the call to the media gateway. The media gateway then transforms the call from ISDN-PRI to SIP/RTP and routes the call to an Office Communications Server Mediation Server. (The media gateway may not be required if the organization has an IP-PBX that can transform the call from ISDN-PRI to SIP/RTP and route the call directly to the Mediation Server.) 4. If the number passed to the Mediation Server is not in E.164 format, the configured next-hop Office Communications Server Front End (that is, SIP proxy) server performs inbound normalization by using the Mediation Server’s default location profile. It performs a reverse number lookup against the user database on the normalized called number and finds a match with the Conferencing Attendant contact object’s msRTCSIP Line URI. 5. The Front End Server routes the call to the Conferencing Attendant Service on the pool bound to the Conferencing Attendant Contact object. 6. The Conferencing Attendant Service on that pool automatically answers the call, and a Secure Real-time Transport Protocol (SRTP) media connection is established between the Mediation Server and the Conferencing Attendant Service. 7. The Conferencing Attendant Service prompts anonymous users for their conference IDs and passcodes (if assigned), or if the user is an enterprise user (that is, has an identity in the Active Directory Domain Services) the user’s extension number and PIN. The following flow chart illustrates the prompt sequence that the Conferencing Attendant service follows. Callers enter responses from their phone keypad. 91 8. The Conferencing Attendant Service passes the Conference ID back to the Front End Server in a SIP SERVICE request. The Front End Server looks up the conference ID from the database and responds back to the Conferencing Attendant Service with the conference URI of the Focus, the meeting ID, and the organizer’s SIP address. 9. The Conferencing Attendant requests and encryption key from the Focus. If the caller is an Enterprise User, the Conferencing Attendant encrypts the caller’s internal phone extension and PIN and sends it in a request to the Front End Server to validate the caller’s identity. If the caller is an anonymous user and a passcode is required, the Conferencing Attendant sends the passcode (encrypted) to the Front End Server for validation. 10. If an enterprise user has not yet entered the meeting and the caller is joining the meeting as an anonymous attendee, the Conferencing Attendant Service plays its on-hold music to the caller until an enterprise user joins the conference. 92 11. When user authentication is complete, the Conferencing Attendant adds the user to the Focus (which adds the user in the meeting rosters of on-line participants), and the Focus adds the user to the A/V Conferencing Server. The A/V Conferencing Server invites the Mediation Server and establishes an audio connection with it, and tells the Mediation Server to drop its connection with the Conferencing Attendant. 12. When the first dial-in user joins the meeting, the A/V Conferencing Server invites a Conferencing Announcement Service in its pool and a media connection is established between it and the A/V Conferencing Server. (This step is done only once for any particular meeting.) The Conferencing Announcement Service is trusted by the Focus and by the A/V Conferencing Server, so additional authentication is not required. The Conferencing Announcement Server joins the Focus and listens for state changes. It plays an entry tone for other dial-in participants to announce that a participant has just joined or left the meeting, and it plays a spoken announcement message for each dial-in participant when that participant’s line has been muted or unmuted. The following diagram shows a simplified call flow on an anonymous user dialing into a meeting that requires a passcode. In this example, the Conferencing Attendant is in the same pool as the meeting Focus. 93 If the appropriate normalization and routing rules are in place in Office Communications Server, the PBX, and media gateway, then PBX phones can also be used to access dial-in conferences in the same manner. Office Communicator Phone Edition device users can also be used to dial into meetings, and since they have already authenticated, they only need enter the Conference ID and they are never placed on hold. 94 Desktop Sharing Scenario Microsoft Office Communications Server 2007 R2 includes a new feature, desktop sharing, which allows others to view a user’s entire desktop remotely and, with the user’s permission, to take control of the user’s mouse and keyboard. The inclusion of this feature may seem puzzling to those familiar with the history of the product, because the on-premises Live Meeting feature introduced in Office Communications Server 2007 already includes this capability and much more, and this functionality remains available with Office Communications Server 2007 R2. There are several reasons for adding a new separate desktop sharing feature:  Microsoft already has a very mature and efficient technology in which it continues to invest and develop, the Remote Desktop Protocol (RDP), already at the core of the Remote Assistance, Remote Desktop, and Terminal Services features of the Microsoft Windows operating system. However, the Live Meeting technology used in Office Communications Server uses a legacy application sharing protocol rather than RDP. In Office Communications Server 2007 R2, Microsoft has begun a transition toward adopting RDP as the universal protocol for application sharing (of which desktop sharing is a subset) for Office Communications Server.  To use the Live Meeting application sharing feature, users had to install the full Live Meeting client. Even though it is available from Microsoft as a free download, in many cases— particularly for external participants who were not employees of the organization—installing this client by end users could be problematic and time consuming, and without prior familiarity it sometimes confused users. Furthermore, since the Live Meeting client ran only on Windows, Apple Macintosh and Linux users were unable to participate in these meetings.  If the Live Meeting session was between only two participants, application sharing traffic was still relayed by a Web Conferencing Server (formerly known as a multipoint control unit or MCU). Additionally, if both users were connecting from the Internet, each packet of desktop sharing data had to traverse the Web Conferencing Edge Server twice. This architecture imposed unnecessary workloads on these servers when the viewing/sharing traffic need only communicate directly between the two endpoints.  Users often want to add desktop sharing to an existing Office Communicator-based voice call or multiparty meeting, but because the Share Information Using Live Meeting menu option in Office Communicator launched a new client, it often created confusion as to which of the two clients was controlling the audio/video. The approach taken in Office Communications Server 2007 R2 was to leave the on-premises Live Meeting capability as it was in the 2007 release but to add a new entirely separate desktop sharing feature that gives users an easier and more efficient way to share their entire desktop remotely with others. Office Communications Server 2007 R2 also adds Web browser–based desktop sharing support for users who do not have any Office Communications Server client, even anonymous (unauthenticated) users connecting from the Internet. This section of the Office Communications Server 2007 R2 Technical Reference explores in detail the architecture and protocol flows of the desktop sharing feature. The following information can be useful in troubleshooting and correcting problems: 95 Note: Documentation for end users of desktop sharing is available at http://go.microsoft.com/fwlink/?linkid=145800. By default, the Office Communications Server 2007 R2 documentation installer file (UCDocumentation.msi) installs this document to the %ProgramFiles%\Microsoft Office Communications Server 2007 R2\Documentation\Dial-in Conferencing folder on the user’s computer. In This Section This section includes the following topics:  Office Communications Server 2007 R2 Desktop Sharing Architecture  Desktop Sharing Call Flows Office Communications Server 2007 R2 Desktop Sharing Architecture To support desktop sharing, Office Communications Server 2007 R2 introduces several new or enhanced architectural components:  Application Sharing Conferencing Server. The Application Sharing Conferencing Server runs as a service on each Front End Server in a consolidated front-end topology and acts as a relay hub for desktop sharing sessions involving more than two participants or Communicator Web Access clients. Furthermore, the Conferencing Server Factory and Focus have been enhanced to communicate with and manage the Application Sharing Conferencing Server.  Enhanced Office Communicator client. Office Communicator 2007 R2 includes RDP client and server support and adds user interface elements for launching, viewing, and taking control of desktop sharing sessions.  Enhanced Communicator Web Access Server. With Communicator Web Access (2007 R2 release), anyone with a supported browser can join a desktop sharing session. Communicator Web Access now supports anonymous users, which allows them to send and receive instant messages and view the meeting roster in addition to viewing the shared desktop.  Add-On for Communicator Web Access. New add-ons for the Internet Explorer and Firefox (for Windows) browsers gives users without the desktop Office Communicator client the ability to share their desktop with others. These components are discussed in detail in the sections that follow. Architectural Overview The following figure shows how the components that support desktop sharing communicate with each other. 96 Protocols Used By Desktop Sharing Similar to how Office Communications Server handles audio and video, desktop sharing uses SIP for session control, but it uses a different protocol to carry the media—in this case, display data and keyboard and mouse inputs. 97 HTTPS/C3P In the same way as with other types of meetings, inter-server control communications between the Focus, the Application Sharing Conferencing Server, and the Conferencing Server Factory occur over HTTPS/C3P over TCP Port 444. SIP/SDP and SIP/C3P The Office Communicator client and the Communicator Web Access server use SDP and C3P commands embedded in SIP messages in order to initiate and respond to desktop sharing requests. If the session is between only two parties and both are using Office Communicator, one or more SIP proxies relay the control traffic to the other client. As with IM or audio/video, if three or more participants are in the meeting, it becomes a conference, and the Focus Factory generates a Focus for the meeting and assigns it a conference URI. The Focus is instantiated as a SIP User Agent on one of the Front End Servers of the pool assigned to the person who initiated the meeting. When a user initiates a multiparty meeting flagged for desktop sharing or when a user in a multiparty IM session escalates it to include desktop sharing, the Focus uses HTTP/C3P to request an Application Sharing Conferencing Server for the meeting from the Conferencing Server Factory, after which desktop sharing sessions between all participating clients and the Application Sharing Conferencing Server can be established. Note: If one or both of the participants in a two-party desktop sharing session are using Communicator Web Access as a client, the call is treated as a conference and incorporates a Focus and an Application Sharing Conferencing Server. RDP After the control information for the desktop sharing session has been exchanged and sharing has been initiated, the Remote Desktop Protocol (RDP) carries the stream of bitmaps (or JPEG images, in the case of Communicator Web Access communicating with the Application Sharing Conferencing Server) from the sharer’s desktop to the other meeting participants. If another participant takes control, RDP carries the controller’s keyboard and mouse inputs back to the sharer’s desktop. SRTP/SRTCP Because desktop sharing was designed to support peer-to-peer sharing when the session is between only two parties, it faces the same challenges as audio/video media with network address translation (NAT) devices and communication between endpoints on the internal network and others on the Internet. To address this issue, Microsoft decided to use the same Office Communications Server infrastructure to handle both audio/video data and desktop sharing data. This infrastructure includes the Interactive Connectivity Establishment (ICE) support built into the Office Communicator clients and the Office Communications Server Edge Server, and the use of Secure Real-time Protocol (SRTP) and Secure Real-time Control Protocol (SRTCP) for carrying the data, which in the desktop sharing case is RDP data instead of RTAudio or RTVideo media. 98 Encapsulating RDP in SRTP packets means that desktop sharing can reuse a great deal of existing functionality and security already implemented in Office Communications Server and Office Communicator to support audio and video, and it means that Edge Servers require no additional functionality to support desktop sharing with remote and federated users. However, RDP-over-SRTP differs from RTAudio/RTVideo-over-RTP in that the underlying transport protocol for SRTP is always TCP rather than the UDP normally used for audio and video streams. This choice also means that much of the packet overhead imposed by SRTP/SRTCP provides little or no benefit to the RDP data that is carried over it. For example, SRTP/SRTCP provides sequence numbering and delivery monitoring, which duplicates a process already handled by the TCP transport, and RTP/RTCP time stamping function (to allow synchronization and jitter calculation) is unnecessary because desktop sharing can tolerate much more latency and dropped packets than voice/video and still remain intelligible. Note: If the Security Settings under the Pool Properties:Media menu for pools are set to Do not support encryption, both A/V and desktop sharing data to and from users and Conferencing Servers in that pool will tunnel through RTP/RTCP rather than SRTP/SRTCP. Although RTP/RTCP provides all the same functions as SRTP/SRTCP sans encryption, this means that desktop sharing data carried over RTP/RTCP is no longer inherently secure from eavesdropping. Even though RDP offers native encryption (enabled by default on Windows server and client operating systems), RDP encryption is turned off in Office Communications Server 2007 R2 and Office Communicator 2007 R2 to eliminate the overhead of needless double-encryption. HTTPS/AJAX DHTML Because desktop sharing is designed to support browser-based clients on a variety of operating systems, Communicator Web Access renders desktop sharing data into AJAX-based Dynamic HTML so that it can be displayed on a variety of browsers and operating system platforms without requiring special add-ins. Users can even send keyboard and mouse movements back to the Communicator Web Access server over DHTML, thereby enabling them to remotely control sharer’s desktops without needing an RDP client. However, to share display data from a browser connected to Communicator Web Access, the browser must be running a special add-on that provides the required RDP-over-RTP and ICE support. At present this add-on is available only for Internet Explorer and Firefox for Windows. Desktop Sharing Components The following section discusses the key components of Desktop Sharing in more depth. Application Sharing Conferencing Server As with the other Office Communications Server Conferencing Servers (for example, IM, Web Conferencing, A/V, and Telephony Conferencing), the Application Sharing Conferencing Server (Asmcusvc.exe) is a Windows service that runs on each front end server in a consolidated topology independently of the Front End Service (RTCSRV.EXE) that hosts the SIP Proxy, 99 Registrar, Focus Factory, and Focus instances. In an Enterprise pool, the hardware load balancer distributes requests for an Application Sharing Conferencing Server, which listens on TCP port 5065, among the pool servers. An Application Sharing Conferencing Server is used only when the application sharing session contains three or more participants or whenever one of the participants is using Communicator Web Access. An Application Sharing Conferencing Server communicates with clients, whether Office Communicator or Communicator Web Access, using SIP/SDP and SIP/C3P for signaling and RDP-over-SRTP for the display and remote control data. The SIP communications are secured by MTLS, and they use the same SSL server certificate that is assigned to the Front End Server. As with A/V traffic, the RDP/SRTP traffic does not use a certificate and instead uses Advanced Encryption Standard (AES) and a shared key, which is negotiated and exchanged securely over the signaling channel, to encrypt and decrypt the RDP traffic that it transports. The Application Sharing Conferencing Server also communicates with the Focus and Conferencing Server Factory over HTTPS/C3P using the same SSL certificate that is assigned to the other Office Communications Server services on the Front End Server. The Application Sharing Conferencing Server retrieves its configuration data by using Windows Management Instrumentation (WMI), but the only configurable settings for the service are the listening port and IP address, the range of media ports that RTP/SRTP can use, the maximum number of users across all meetings, the maximum number of meetings, and the maximum meeting size. Focus and Conferencing Server Factory The Office Communications Server 2007 R2 Focus and Conferencing Server Factory have been updated to be aware of the Application Sharing Conferencing Server and to communicate with it in the same manner as the other conferencing servers, primarily over HTTPS/C3P. Office Communicator Office Communicator 2007 R2 has been extended to support desktop sharing so that users can participate in desktop sharing sessions without installing the Live Meeting client or any special plug-ins, and if the user has been assigned a global meeting policy that includes the Enable Program and Desktop Sharing option, there is nothing more for the user or the administrator to do. Because Office Communicator 2007 R2 is an ICE-enabled client, it can find the most efficient way to establish peer-to-peer desktop sharing sessions with other Office Communicator 2007 R2 clients. The new version of Office Communicator also adds RDP support needed for desktop sharing. (This RDP support is completely independent of the RDP support in Windows.) The user interface for invoking and responding to desktop sharing is described in the Office Communicator Help and in the Office Communicator 2007 R2 Technical Reference. 100 Communicator Web Access Microsoft has extensively enhanced the 2007 R2 release of Communicator Web Access in order to provide support for participants who do not have access to a computer with either the Office Communicator or Live Meeting client. The addition of dial-in and dial-out conferencing allows users with access to a phone to participate in the audio portion of Office Communicator-based meetings, and new anonymous sign-in support in Communicator Web Access desktop sharing allows even an anonymous user with access to a browser to participate in online meetings that involve desktop sharing (if permitted by Office Communications Server global Meeting policy). In order to support Macintosh and Linux users, Communicator Web Access displays the sharer’s desktop in the user’s browser window using AJAX Dynamic HTML (DHTML) over HTTPS. The Communicator Web Access server gets the sharer’s RDP stream from the Application Sharing Conferencing Server, which knows it is communicating with a Communicator Web Access Server and converts the bitmaps normally used for Office Communicator viewing into JPEG format before streaming them to the Communicator Web Access server over RDP/SRTP (there is only one stream no matter how many users viewing the particular desktop sharing session are connected to that Communicator Web Access server). The Communicator Web Access server translates this stream into AJAX DHTML and sends it over HTTPS to each participating browser, thereby enabling many non-Windows systems to display it properly. (The JPEG conversion that occurs on the Application Sharing Conferencing Server is the reason why two-party calls involving a Communicator Web Access client do not route desktop viewing and control data directly to the other client.) In addition to viewing shared desktops, users connecting from any supported browser can also take control of the sharer’s desktop (that is, if permission has been granted by the sharer) without requiring any special browser add-ins or controls. In order to view desktop sharing sessions from Internet Explorer or Firefox, the client computer needs to resolve two DNS CNAMES, as.<CWAserverFQDN> and download.<CWAserverFQDN>. This requirement exists because these browsers will open no more than two connections per URL (for example, https://cwa.contoso.com); however, for optimum performance, desktop viewing requires additional open connections. The two CNAME records allow the browsers to open four more connections. If Communicator Web Access is published to the Internet, the external DNS must be able to resolve these CNAME records to the IP address of the reverse proxy relaying external traffic to the Communicator Web Access server. Furthermore, because the connections to the Communicator Web Access server or its associated reverse proxy are over HTTPS, the certificates on both servers must include the two CNAMES in its Subject Alternate Name (SAN) field. To allow users without Active Directory credentials to join the meeting, Communicator Web Access was also enhanced in Office Communications Server 2007 R2 to support anonymous sign-in upon receipt of a meeting invitation, and these participants get the same access to the roster, IM, and desktop sharing capabilities as do authenticated users. If the organization has 101 published Communicator Web Access to the Internet, then users with any of the supported Web browsers can view desktop sharing sessions over the Internet. Add-On for Internet Explorer and Firefox for Windows If a meeting participant who is using Communicator Web Access wants to share his or her desktop, he or she must be using Windows XP SP2 or Vista and either Internet Explorer 6 SP2, Internet Explorer 7, or Firefox 3.0.x with the CWAPlugin.exe add-on installed on it. This add-on provides the required support for ICE, SRTP/SRTCP, and RDP. If the user’s computer does not already have this add-on, upon the user’s first attempt to share their desktop the browser will prompt him or her to download it from the Communicator Web Access server as shown in the following: The user interface of the add-on setup program is available in 15 different languages. By default, the browser’s current language setting will determine the language that the user sees. Users do not need to have administrative privileges to install the add-in, but on Vista systems, the user must have User Account Control enabled. After CWAPlugin.exe is downloaded, it installs and registers a set of files into the user’s Windows profile. CWAPlugin.exe registers the AppSharingHostClass and AsVersionQueryClass ActiveX controls in Internet Explorer or the npCwaAppSh.dll plug-in in Firefox. Note: The add-on is not supported on 64-bit versions of Internet Explorer; users of 64-bit Windows must launch the 32-bit version of Internet Explorer in order to install and use the add-in. The add-on does not install on Windows Server 2008. Following are the browser management dialog boxes that indicate (in highlight) successful installation (the one on the left is for Internet Explorer and the right for Firefox). 102 The add-in files get installed into the user’s Windows profile as shown in the following (the installation folder for Internet Explorer is shown in the top screen shot and the Firefox install folder in the bottom screen shot). 103 From Office Communicator, if you have multiple monitors you can choose to share just one monitor. However, when using the Communicator Web Access with the browser add-in on a computer with multiple monitors, you have to share your entire desktop across all monitors. Desktop Sharing Call Flows The following topics describe how the signaling and media flows are established in several basic desktop sharing examples. Creating a Desktop Sharing Conference As noted earlier, a desktop sharing session between two Office Communicator clients is a peerto-peer session from the point of view of the RTP remote display and keyboard/mouse data; however, SIP control data still is proxied by each user’s Front End Server. The following figure shows a call flow between two Office Communicator clients. Both clients in the example are on the internal network, and both belong to the same Office Communications Server pool. The clients have already established an IM session with each other, and then User1 clicks the Share Desktop control. This action causes User1’s Office Communicator client to send a SIP INVITE message containing the following Session Description Protocol (SDP) data, including a list of ICE candidates, to User2’s Office Communicator client to indicate that User1 wants to share his or her desktop with User2: 104 v=0 o=- 0 0 IN IP4 192.168.100.20 s=session c=IN IP4 192.168.100.20 b=CT:99980 t=0 0 m=applicationsharing 4636 TCP/RTP/AVP 127 a=ice-ufrag:Ze3C a=ice-pwd:s0a6z9xeF6+wQvu6lCDen9oG a=candidate:1 1 TCP-PASS 2120613887 192.168.100.20 18608 typ host a=candidate:1 2 TCP-PASS 2120613374 192.168.100.20 18608 typ host a=candidate:2 1 TCP-ACT 2121006591 192.168.100.20 4636 typ host a=candidate:2 2 TCP-ACT 2121006078 192.168.100.20 4636 typ host a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:7Qze/34RrnOBYwHVlcXWGdmlBYX7yvehzzoV4k3p|2^31|1:1 a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:3t/fXZ5Fjho3/lkMea1c2xNhTfJxYGAM2KU/VGdu|2^31|1:1 a=setup:active a=connection:new a=rtcp:4636 a=mid:1 a=rtpmap:127 x-data/90000 a=x-applicationsharing-session-id:1 a=x-applicationsharing-role:sharer a=x-applicationsharing-media-type:rdp If User2 accepts the invite, his or her Office Communicator client sends back an OK with a list of ICE candidates. Both clients evaluate the ICE candidate pairs. User1 then sends a new SIP INVITE message containing the winning IP address for his or her computer, and User2 returns a 200 OK message with the winning IP address for his or her computer. By using this information, the two Office Communicator clients establish an SRTP session over TCP between the two negotiated endpoints, and User1 sends an RDP stream that mirrors his or her desktop to User2 over the SRTP channel. Adding a User to a Desktop Sharing Conference Continuing on with this same example, User1 needs to add a third participant, User3, to the existing desktop sharing meeting with User2. (In this example, User3 is also in the same pool as User1 and User2.) User1 clicks the Invite button, clicks Invite a Contact, and then clicks User3. 105 At this point, the meeting must transition from a peer-to-peer session to a multiparty conference, with IM traffic routed through an IM Conferencing Server and the desktop sharing traffic through an Application Sharing Conferencing Server. This transition starts when User1’s client sends a SIP SERVICE message to its Front End service specifying a new conference ID and a request for a Focus and conferencing servers for the possible meeting modalities (IM, Web conferencing, A/V conferencing, and application sharing). The Focus Factory provisions a meeting Focus and writes it to the back-end database. User1 then sends a SIP INVITE to the Focus. The Front End Server instantiates the Focus on one of the Front End Servers in its pool, which in turn communicates with an Conferencing Server Factory in that pool to have specific conferencing servers assigned to it. In this example, only the IM Conferencing Server and the Application Sharing Conferencing Server are required. The Focus communicates with both, adds a conference to each, and then registers a channel in each for User1. Meanwhile, User1’s client sends a SIP SUBSCRIBE message to the Focus, which returns the details of the conference. Subsequent SIP INFO messages sent to the Focus return additional provisioning data to User1’s client. At this point User1’s client send a SIP INVITE message to the IM Conferencing Server, thereby establishing a session with it, and it also sends a SIP INVITE to the Application Sharing Conferencing Server containing an SDP message with its ICE candidates. As described earlier for the peer-to-peer session, User1’s client and the Application Sharing Conferencing Server evaluate the candidates, after which User1’s client sends a new SIP INVITE message containing its winning candidate and the Application Sharing Conferencing Server then replies with its winning candidate. The SRTP session is then established over TCP between the two negotiated endpoints. Next, User1’s client sends a new SIP INVITE message, which contains the URI of the meeting Focus, to User2’s client. User 1’s client also exchanges SIP BYE messages with Client2, causing it to drop the earlier TCP/SRTP/RDP session. Now User2’s client sends a SIP INVITE to the Focus, obtains the conference information, and requests that the Focus add User2 to the IM Conferencing Server and the Application Sharing Conferencing Server. User2’s client sends a SIP SUBSCRIBE request to the Focus and then invites the IM Conferencing Server and the Application Sharing Conferencing Server in the same manner as User1’s client. In the last stage of the process, User1’s client sends a SIP INVITE message, which contains the URI of the meeting Focus to User3’s client, and then ends the session with a SIP BYE. User3’s client uses the obtained URI to send a SIP INVITE message to the Focus and joins the meeting and conferencing servers in exactly the same way as User2’s client did. As this point, all three users are connected to the Focus, the IM Conferencing Server, and the Application Sharing Conferencing Server. User1 is sharing his or her desktop, which is sent over the TCP/SRTP channel to the Application Sharing Conferencing Server, where it is repeated back to the clients of User2 and User3. The Focus publishes the meeting roster to the clients, which now shows User1 currently sharing his or her desktop. 106 Note: In the following diagrams, the SIP ACKs and some other traffic have been skipped for readability. 107 Desktop Sharing Session Control The user who initiates desktop sharing has full control over his or her computer, and by default the other participants can only view the shared desktop or selected monitor. If the sharer wants to give another participant control, he or she can give that individual control, while other participants can only view the desktop. The user who initiates sharing can also choose to share control with all participants, but there is no way to allow a subset of participants to have control; it is granted either to one participant at a time or to all participants. If the sharer clicks Share Control with All Participants, it requires communication and cooperation between the participants, because any attendee can seize control at any time. The sharer, however, can rescind shared control at any time, which again gives him or her sole control of the desktop. The following flow chart shows how control of sharing works. 108 Office Communications Server 2007 R2 permits only one participant’s desktop to be shared at a time. If another participant shares his or her desktop, the original sharer’s desktop session is closed and replaced by a view of the new sharer’s desktop. This is not something the meeting leader can control. All meeting participants whose meeting policy settings include Enable program and desktop sharing can cause an existing sharing session to terminate and be replaced with their own shared desktop or monitor. 109 Note: Communicator Web Access users have a similar sharing and remote control experience, except that users with multiple monitors cannot select a single monitor; they can share their entire desktop only. Also, the sharer’s assigned meeting policy determines whether anonymous users can take control of his or her desktop. Communicator Web Access Scenario Communicator Web Access (2007 R2 release) is a browser-based application that provides access to the instant messaging (IM), audio, and desktop sharing capabilities of Office Communications Server 2007 R2. Using only an Internet connection and a Web browser, Communicator Web Access enables you to take advantage of Office Communications Server 2007 R2 features even when you are away from your personal computer. Communicator Web Access is similar to Office Communicator 2007 R2, making it easy to switch between the two applications. Both applications provide you access to the same contact list and similar IM, call management, and desktop sharing capabilities. Audio functions in Communicator Web Access (2007 R2 release) enable you to place voice calls to both yourself and a remote contact by using the Office Communications Server 2007 R2 to create an audio channel for conferencing. In This Section This section contains the following topics:  Functionality Overview  Communicator Web Access Core Architecture  Communicator Web Access Audio Note: Communicator Web Access (2007 R2 release) includes desktop sharing. Communicator Web Access users can share their main monitor with other Communicator Web Access users or with Office Communicator 2007 R2 users. For details about desktop sharing, including the Communicator Web Access (2007 R2 release) desktop sharing scenario, see Desktop Sharing Scenario. Functionality Overview Communicator Web Access (2007 R2 release) improves communication for branch office employees, or business travelers and telecommuters who work at Internet kiosks, which effectively reduces geographic barriers that can hinder productivity. Communicator Web Access provides instant messaging (IM), presence, audio dial out, and desktop sharing capability for users when they are away from the office. The experience of using the browser-based Communicator Web Access is similar to using the desktop-based Office Communicator 2007 R2. The functionality of the Communicator Web Access (2007 R2 release) focuses on presence information, IM, desktop sharing, and dial-out experience to ensure usability across as many platforms and browsers as possible. Users can still use tools such as corporate directory integration, support for distribution groups, and the ability to manage contact lists. 110 The desktop sharing capability gives users the ability to share their desktop on a Windows-based computer. Anyone who is a part of the desktop sharing sessions can be given access to view and control the desktop, which means that the flexibility to work as a team is not hindered by distance. Resizing and panning controls enable participants to view the conversation in comfort and audio dialogue can be added to the sharing sessions. Communicator Web Access can also place the call for the user. The Communicator Web Access servers are deployed within the corporate network and form part of the Office Communications Server 2007 R2 deployment. No Active Directory schema extensions are required when you deploy Communicator Web Access. In This Section  New Communicator Web Access Features  Office Communicator and Web Access Feature Comparison New Communicator Web Access Features Communicator Web Access (2007 R2 release) and Office Communicator 2007 R2 provide the following new features:  Collaborate with external organizations. Communicator Web Access (2007 R2 release) provides customers and business partners outside of your organization the ability to join conferencing and collaboration sessions easily and inexpensively. Invite anyone with a Web browser to join a conversation that you are hosting, share your desktop with a vendor to discuss a project, or start a conference call with a stakeholder and route the call to your mobile device.  Desktop sharing. Users can see everything happening on someone else’s computer, and can even be given the right to control that computer. People running Microsoft Windows and a supported Web browser can share their desktops with others. Anyone running a supported Web browser (including people using Macintosh or Linux computers) can view and control a shared desktop.  Dial-out conference audio. You can add audio conferencing (that is, using standard telephones, including cell phones) to any existing instant messaging (IM) or desktop sharing session. You supply the names of each person to take part in the audio conference, and Communicator Web Access calls each person, and sets up and manages the conference call.  Support for distribution groups. Users can add distribution groups to their contact list and exchange instant messages with all (or some) of the members of those groups.  Customize the login screen and links. Your IT department has the ability to customize login screen and links.  Support for browsers other than Internet Explorer. While not strictly a new feature, the list of alternate browsers is expanded in Communicator Web Access (2007 R2 release). The following table outlines the supported browsers. 111 Table 1. Supported Browsers Operating system Browser Microsoft Windows 2000 with Service Pack 4 (SP4)  Internet Explorer 6.0 with SP1 Windows XP with SP2  Internet Explorer 6.0 with SP2  Internet Explorer 7.0  Firefox 3.0.X  Internet Explorer 7.0  Firefox 3.0.X  Safari 1.3.X  Firefox 3.0.X  Safari 1.3.X  Firefox 3.0.X Red Hat Linux 2.16  Firefox 3.0.X HP UX  Firefox 3.0.X IBM AIX  Firefox 3.0.X Sun Solaris  Firefox 3.0.X Windows Vista Macintosh OS 10.3.9 Macintosh OS 10.5.4 Office Communicator and Web Access Feature Comparison Office Communicator Web Access (2007 R2 release) and the Office Communicator 2007 R2 client have many of the same features. However, the feature set is not an exact duplication. By familiarizing yourself with the differences between them, you can troubleshoot more effectively, and provide better user support and training. Feature Comparison Feature Office Communicator 2007 R2 Communicator Web Access (2007 R2 release) Rich presence Yes Yes Call forwarding Yes Yes Instant messaging Yes Yes Click-to-call audio Yes No 112 Feature Office Communicator 2007 R2 Communicator Web Access (2007 R2 release) Audio conferencing Yes Yes Anonymous join Yes Yes Attendant console support Yes Yes Admin support Yes No Response group support Yes No Team Call Yes Yes Video Yes No Live Meeting Yes No Distribution groups Yes Yes Extensible tabs Yes Yes Custom logon screen and menus No Yes Custom authentication No Yes Zero download No Yes Non-Windows/across platforms no Yes Call deflection Yes Yes Location Yes No Custom states Yes Yes Personal note Yes Yes Contact card Yes Yes Public instant messaging (IM) connectivity Yes Yes Federation Yes Yes Suggestive search Yes No Outlook contact search Yes No Global address list (GAL) contact search Yes, using Address Book Server Yes, using Active Directory Desktop sharing Yes Yes 113 Communicator Web Access Core Architecture Communicator Web Access (2007 R2 release) is comprised of three main components: the zero download browser-based client, the application logic layer, and the Unified Communications Managed Application Interface (UCMA) layer. The application logic layer and the UCMA layer are hosted on the Communicator Web Access (2007 R2 release) server and form a web site that is hosted by Internet Information Server (IIS) 6.0 or 7.0. The Communicator Web Access (2007 R2 release) server is a middle tier between the browser client and the Office Communications Server 2007 R2 pool. The Communicator Web Access server does not provide any functionality without the pool. Users with accounts homed on an Office Communications Server 2007 pool are not supported. However, you can configure the Communicator Web Access (2007 R2 release) server to redirect users who are homed on an Office Communications Server 2007 pool to a Communicator Web Access (2007 release) server. IIS provides the authentication services for Communicator Web Access (2007 R2 release). IIS provides this service either through integrated authentication in the case of a domain-joined workstation or through forms-based authentication in the case of an external user, or Safari or Firefox users. Communicator Web Access (2007 R2 release) server does not provide authentication services. After the authentication token is passed from IIS to the Communicator Web Access (2007 R2 release) server, the server does not attempt or perform any further authentication. When the client browser contacts the Communicator Web Access (2007 R2 release) Web site, a compressed JavaScript client is downloaded from the Communicator Web Access (2007 R2 release) server (that is, by using IIS) to the client browser. In the case of a domain-joined workstation that uses Internet Explorer, integrated authentication occurs. In the case of a nondomain joined Windows-based workstation that uses Internet Explorer, Safari, or Firefox, the client displays a forms-based authentication screen where the user enters a valid Session Initiation Protocol (SIP) address and password. The client browser must accept pop-up windows from the Communicator Web Access (2007 R2 release) server. As can be seen in the following figure, the Communicator Web Access (2007 R2 release) server is a virtual Web site that is hosted by an IIS server. The browser-based client communicates with IIS through the HTTPS protocol. The IIS passes the data packets to the client communication component which translates the incoming XML packet and sends the packet to the application logic layer. The application logic layer performs actions based on the XML header and, through the UCMA, passes those results to the Office Communications Server 2007 R2 pool through SIP. The path from the pool server to the client is the reverse as follows: pool to UCMA, UCMA to the application logic layer, application logic layer to the client communication component, and finally through HTTPS to the browser-based client. 114 Figure 1. Communicator Web Access (2007 R2 release) server architecture The Communicator Web Access (2007 R2 release) server components are nearly stateless. The application logic layer maintains persistent states for the HTTPS to client link and the (that is, through the UCMA) registered user endpoints. The client posts a Get request after each receive packet to establish the ability for the server to send more data without a specific client request. The Get request is necessary so that the server can send the browser client data, such as conversation requests or contact list presence changes. The open Get request cycle is controlled by the Communicator Web Access (2007 R2 release) server load control function which can request that clients delay posting the next open Get request. 115 UCMA Layer Functions The UCMA layer of the Communicator Web Access (2007 R2 release) server uses the UCMA application programming interface (API) to do the following:  Create and manage all of the communications between the Communicator Web Access (2007 R2 release) server and the Office Communications Server 2007 R2 pool.  Create and manage a UserEndpoint, registered with the Office Communications Server 2007 R2 pool, for each user of the Communicator Web Access (2007 R2 release) server.  Create and manage all sessions, such as IM sessions, between the users of the Communicator Web Access (2007 R2 release) server and the Office Communications Server 2007 R2 pool.  Subscribe to presence information about the user (that is, self information) and the user’s contacts.  Publish presence information on behalf of the users of the Communicator Web Access (2007 R2 release) server. Application Logic Layer Functions The application logic layer is a translator between the pool and the Asynchronous JavaScript And XML (AJAX) and facilitates communication with the JavaScript client. The application logic layer provides the following basic functions:  Registers user endpoint. Logically, the Office Communications Server 2007 R2 pool sees the application logic layer user endpoint as the client, not the actual client on the browser.  Manages proxy client communications to and from the pool. The client browser is never in direct contact with the Office Communications Server 2007 R2 pool.  Maintains the registered user endpoint for each user connected to Communicator Web Access 2007 R2. The UserEndpoint is the object that the Communicator Web Access (2007 R2 release) server uses to support all the operations between the client running in the user’s browser and the Office Communications Server 2007 R2 pool. The UserEndpoint is used to do the following:  Subscribe to the self-presence information for the registered user, including:  List of contacts  Published phone numbers  Call handling settings (that is, forwarding, simultaneous ring, and so on)  Publish presence information for the user.  Register for incoming session requests from the Office Communications Server 2007 R2 server.  Create outgoing sessions requested by the client using their browser. The Communicator Web Access (2007 R2 release) server attempts to minimize the amount of state that it maintains for each registered user. As requests and data are received by the application layer from the Office Communications Server 2007 R2 pool, they are forwarded to the 116 user’s browser session. As requests and data are received from the user’s browser session, they are forwarded to the Office Communications Server 2007 R2 pool. Client Functions The client functionality for Communicator Web Access (2007 R2 release) is implemented by a set of JavaScript libraries that are downloaded to the browser when the user’s session with the Communicator Web Access (2007 R2 release) server starts. These code libraries are sent from the Communicator Web Access (2007 R2 release) server in a compressed form to the browser and provide the communications functions and logic of the Communicator Web Access (2007 R2 release) client. The libraries also provide the user interface (UI) of the Communicator Web Access (2007 R2 release) client along with the DHTML in the Web pages. The following figure shows the architecture of the browser-based client. All communication with the Communicator Web Access (2007 R2 release) server is by HTTPS. The data packets are XML. The overall layout has three layers: the proxy layer, the data and logic layer, and the UI layer. The UI layer consists of the visual components that are presented to the user in the form of browser windows. The sole exception to this paradigm is the system alert which appears in the form of a small pane sliding open from the system tray. 117 Figure 2. Communicator Web Access (2007 R2 release) client architecture The proxy Layer is the only component of the client to communicate with the server. It is responsible for sending HTTP requests and receiving HTTP responses from the server. The data and logic layer is responsible for managing data and logic for the user endpoint. The UI layer provides all user input and screen that the user sees. The client provides all user interface functions. After the user logs on, the client performs the following actions automatically with requiring user input:  The client uses the registered user endpoint to publish a set of endpoint capabilities with the Office Communications Server 2007 R2 pool.  The client requests self data from the pool. Self data includes contacts, end points, client configuration, and calendar data. 118 The data and logic layer consists of the user session, the presence manager, the contact list manager, the options manager, the conversation manager, the system alert manager, the search manager, and the component store. In the UI layer, there is a one-to-one relationship between the UI component and the manager in the data and logic layer. For Example, the system alert manager controls the UI system alerts and included functions, and the conversation manager affects the UI conversation window. A use case example of an IM conversation would use the server communicator (proxy layer), the user session, the presence manager (that is, to report to the pool that the user state has changed), and then the component store invokes the conversation manager, which opens a conversation window. During the course of the conversation, if the user receives a data packet that needs open a system alert to notify the user of an audio call, the component store will invoke the system alert manager which then opens a system alert. In each case where you use the component store to control the UI experience, the headers in the data packet contain information from Office Communications Server 2007 R2 that determine which function is being called, while the data and logic layer determines how to respond to the XML packet header. The previous conversation example is duplicated for each component manager. The XML packet is received, the XML header indicates the action(s) to be taken, and the component store either triggers a new conversation instance or adds components to the existing conversation windows. Communicator Web Access Audio There are two basic audio scenarios for Communicator Web Access (2007 R2 release). Both of the following scenarios enable Communicator Web Access (2007 R2 release) to control audio calls, although Communicator Web Access (2007 R2 release) clients do not have audio capability:  Scenario 1: Enterprise Voice-enabled Communicator Web Access (2007 R2 release) user has an incoming voice call.Office Communications Server 2007 R2 forks the call to all registered endpoints. The Communicator Web Access (2007 R2 release) endpoint that is maintained in the Communicator Web Access (2007 R2 release) data logic layer is a valid registered endpoint, but the Communicator Web Access (2007 R2 release) client cannot perform audio function. Therefore, when the data logic layer in Communicator Web Access (2007 R2 release) receives the call notification, the data logic layer shows the user a system alert with call deflection options that are obtained from self-data and the data logic layer enables the user to input a custom number. The path through the client is proxy layer, user session, component store, system alert manager, and finally the system alert. The data logic layer receives the response from the client and passes this data back to Office Communications Server 2007 R2, which takes the action dictated by the user. The calling party is placed on hold for the amount of time that it takes to respond to the system alert. After the data packet from the client is returned to the data logic layer, the data logic layer passes the data back to the Office Communications Server 2007 R2 pool for action.  Scenario 2: Communicator Web Access (2007 R2 release) user with an open instant messaging (IM) conference wants to add audio.From an existing IM conference, the 119 Communicator Web Access (2007 R2 release) user adds audio. The user selects a number from the displayed self-data or the user enters a custom number. The client sends this information along with the request to add audio to the Communicator Web Access (2007 R2 release) data logic layer. The data logic layer signals to the other conference users that audio is being added and it takes one of the following actions:  If the called party is Enterprise Voice, the connection is made to a valid registered endpoint or to an Office Communicator instance.  If the called party is a Communicator Web Access (2007 R2 release) user, the Communicator Web Access (2007 R2 release) server invokes the call deflection scenario. Office Communications Server 2007 R2 can call any global or local number that is allowed by the Communicator Web Access (2007 R2 release) user’s location profile. For example, if the Communicator Web Access (2007 R2 release) user inputs a telephone number that is not reachable by Office Communications Server 2007 R2 because of routing restrictions or phone usages, the call fails. In This Section This section contains the following topics:  Communicator Web Access Audio Scenarios  Call Deflection Session Initiation Protocol (SIP) Tracing  Add Audio Session Initiation Protocol (SIP) Tracing Communicator Web Access Audio Scenarios Communicator Web Access (2007 R2 release) does not support the initiation of a direct audio call from the contact list or any direct audio device. Communicator Web Access (2007 R2 release) supports the following two-party and multiparty audio scenarios. Each scenario is accomplished with either call deflection or adding audio to an existing conversation. Several scenarios are outlined to show that Communicator Web Access (2007 R2 release) participates in the scenarios even though there is no action taken by the Communicator Web Access (2007 R2 release) user. Communicator Web Access (2007 R2 release) can also add instant messaging (IM) or desktop sharing to existing audio. However, this action results in two completely different sessions: one for the original audio and one for the new IM or desktop sharing session. Each scenario is illustrated as a conversation between an Office Communicator 2007 R2 client (or clients) and a Communicator Web Access (2007 R2 release) session. Two-Party Audio Scenario Receive new two-party audio only call (call deflection): If Office Communicator 2007 R2 calls a Communicator Web Access (2007 R2 release) user, the Communicator Web Access (2007 R2 release) user sees the audio system alert and can select to redirect the call to a phone device. The redirected call is sent to the phone device and has no association with Communicator Web Access (2007 R2 release) after the redirection. The redirection selection list comes from the Office Communications Server 2007 R2 user self-information data. The user may also enter a 120 custom number. In either case, Office Communications Server 2007 R2 must be able to place calls to the redirection number. If the user enters a phone number that is not allowed due to location profile, phone usages, or route settings, the call fails. Receive request to add audio conversation to an existing IM-only conversation (call deflection): Communicator Web Access (2007 R2 release) is in an existing IM conversation with Office Communicator 2007 R2. Office Communicator 2007 R2 adds audio. Communicator Web Access (2007 R2 release) receives an audio system alert. Communicator Web Access (2007 R2 release) user can choose to redirect the audio call to a phone device. The redirected call is not associated with Communicator Web Access 2007 R2 after deflection. The Communicator Web Access (2007 R2 release) presence does not change to In a Call. In existing two-party audio conversation and the other user adds IM: Communicator Web Access (2007 R2 release) is in an existing audio conversation where the Communicator Web Access (2007 R2 release) user is on cell phone (that is, with no associated conversation window) with an Office Communicator 2007 R2 user. The Office Communicator 2007 R2 user sees the Communicator Web Access (2007 R2 release) user in his roster and chooses to add IM. Communicator Web Access (2007 R2 release) user sees a system alert and a conversation window opens with the instant message. The audio conversation window and the Communicator Web Access (2007 R2 release) IM conversation are not associated. There is no connection in Communicator Web Access between the original audio conversation and the new IM window. Communicator Web Access (2007 R2 release) user is in an existing two-party audio conversation and sends IM to the other user: A Communicator Web Access (2007 R2 release) user is in an existing two-party audio conversation with Office Communicator 2007 R2. The Communicator Web Access (2007 R2 release) user now wants to communicate with the same Office Communicator 2007 R2 user by using IM. The Communicator Web Access (2007 R2 release) finds the Office Communicator 2007 R2 user in the contact list and clicks to start IM. The Office Communicator 2007 R2 user sees a new window open for the new IM invitation. The Office Communicator 2007 R2 user has two windows open with the Communicator Web Access (2007 R2 release) user. There is no connection in Communicator Web Access between the original audio conversation and the new IM window. Conference (Multiparty) Audio Scenario Initiate three or more party audio-only conference from the contact list (add audio): A Communicator Web Access (2007 R2 release) user can initiate an audio conference from the contact list by multi-selecting two or more contacts in the contact list. After choosing the conference members, the Communicator Web Access (2007 R2 release) user can select the phone icon, and direct Office Communications Server 2007 R2 to call the selected phone number to initiate the audio portion of the conference. After the audio call is placed to the Communicator Web Access (2007 R2 release) user, the other participants are invited to join the audio conference. Add audio to existing IM-only conference (add audio): A Communicator Web Access (2007 R2 release) user is in a conference with other users where IM is the only modality. The Communicator Web Access (2007 R2 release) user wants to add audio to the conference. The Communicator Web Access (2007 R2 release) user clicks the phone icon to add audio. An audio 121 setup pane appears where the Communicator Web Access (2007 R2 release) user selects the self-information phone number he wants to use. The Office Communicator Server 2007 R2 A/V conferencing server initiates the audio call to the Communicator Web Access user and sends audio invitations to the other participants. Receive new audio-only conference invitation (call deflection): Communicator Web Access (2007 R2 release) user can receive and join an audio-only conference. The Communicator Web Access (2007 R2 release) user can select which phone number she wants to use for the conference by selecting the number from the conference system alert. A conversation window appears with all of the conference participants in the roster. The Communicator Web Access (2007 R2 release) user’s phone rings and the user can communicate by using audio with all of the conference participants. Receive request to add audio to existing IM-only conference (call deflection): A Communicator Web Access (2007 R2 release) user is in an existing IM-only conference and a participant in the conference adds audio. The Communicator Web Access (2007 R2 release) user receives an audio system alert. The Communicator Web Access (2007 R2 release) user accepts the call by specifying a self-information phone number to receive the call. There is no connection between the original IM conversation and the new audio call. Receive new audio and IM conference invitation (call deflection): The Communicator Web Access (2007 R2 release) user receives an invitation to join a conference with IM and audio. The system alert is a conference system alert that enables the Communicator Web Access (2007 R2 release) user to join the conference. In the conference window, under join audio conference, the Communicator Web Access (2007 R2 release) user selects one of the self-information phone numbers from which he wants to redirect the audio call. IM is also enabled. Receive new audio, IM, and application sharing conference invitation (call deflection): Other than the addition of the desktop sharing feature, this scenario is identical in function to the previous scenario. Escalation In an existing two-party audio conversation and the Office Communicator 2007 R2 user adds another participant: A Communicator Web Access (2007 R2 release) user is in an existing two-party audio conversation with an Office Communicator 2007 R2 user. The Office Communicator 2007 R2 user is using the rich client Voice over Internet Protocol (VoIP) functions and the Communicator Web Access (2007 R2 release) user is on a phone device (that is, there is no Communicator Web Access (2007 R2 release) UI associated with the call). The Office Communicator 2007 R2 user sees the Communicator Web Access (2007 R2 release) user in her roster as joined to the audio conversation. The Office Communicator 2007 R2 user chooses to add another participant to the audio conversation. The other participant is successfully added and joined to the audio conversation. All three participants appear in the Office Communicator 2007 R2 user’s roster and they can all hear each other. In this scenario, the Communicator Web Access (2007 R2 release) user takes no action and the Office Communications Server 2007 R2 A/V conferencing server is controlling the audio bridge that allows the audio conference to reach all participants. 122 In existing two-party audio conversation and Office Communicator 2007 R2 user adds desktop sharing: The Communicator Web Access (2007 R2 release) user is in existing twoparty audio conversation with an Office Communicator 2007 R2 user. The Communicator Web Access (2007 R2 release) user is on a phone device and the Office Communicator 2007 R2 user is terminating audio through Office Communicator 2007 R2. The Office Communicator 2007 R2 user sees the Communicator Web Access (2007 R2 release) user in the roster. The Office Communicator 2007 R2 user chooses to add desktop sharing to the conversation. The Communicator Web Access (2007 R2 release) user sees a system alert for desktop sharing and clicks the system alert to accept the invitation. The Communicator Web Access (2007 R2 release) user sees a browser open with the Office Communicator 2007 R2 user and himself listed in the roster. The audio call is still active and there is no connection between the audio call and the desktop sharing session. The Office Communicator 2007 R2 user now adds another participant: The Communicator Web Access (2007 R2 release) user is using a phone device for an audio conversation with the Office Communicator 2007 R2 user and has a browser window open for desktop sharing with the same Office Communicator 2007 R2 user. Now a third person is invited to the application sharing session. The third person is joined to the audio conversation and desktop sharing session. All three users can speak with each other. As noted previously, the Communicator Web Access (2007 R2 release) user takes no action and the audio conversation and the desktop sharing session have no connection. The Communicator Web Access (2007 R2 release) user adds another participant: The Communicator Web Access (2007 R2 release) user adds another participant to the audio conversation and desktop sharing session. The Focus Factory knows that audio and desktop sharing are enabled, so the Focus Factory sends the appropriate invitations to the new participant. The new participant is joined to the audio conversation and desktop sharing session. Communicator Web Access (2007 R2 release) still does not connect the audio conversation and the desktop sharing session. Call Deflection Session Initiation Protocol (SIP) Tracing The following Session Initiation Protocol (SIP) packets illustrate the pertinent data between an Office Communications Server 2007 R2 pool Front End Server and a Communicator Web Access (2007 R2 release) server for the call deflection scenario. The Communicator Web Access (2007 R2 release) user deflects the incoming call to voice mail. All incoming calls to Communicator Web Access (2007 R2 release) sessions meet this scenario. An audio call is forked to all valid endpoints. Regardless of the source of the call, if the incoming call is directed at the Communicator Web Access (2007 R2 release) session, the deflection scenario is valid. Call Deflection SIP Tracing Scenario In this scenario, a Communicator Web Access (2007 R2 release) session exists. User1 is on Communicator Web Access (2007 R2 release) and User2 is on Office Communicator 2007 R2. User2 on Office Communicator 2007 R2 initiates an audio call to a phone number. An invitation from Office Communicator 2007 R2 is sent to the pool Front End Server. 123 TL_INFO(TF_PROTOffice Communicator 2007 R2 OL) [1]0A2C.0A9C::06/22/2009-17:58:48.922.0009935d (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018A2F9 Direction: incoming Peer: 192.0.2.143:1331 Message-Type: request Start-Line: INVITE sip:+12065550101@litwareinc.com;user=phone SIP/2.0 From: <sip:User2@litwareinc.com>;tag=ea1b3cab6b;epid=213be0ea4a To: <sip:+12065550101@litwareinc.com;user=phone> CSeq: 1 INVITE Call-ID: a9c2eb61a37944979e6ba90adbf869ce Via: SIP/2.0/TLS 192.0.2.143:1331 Max-Forwards: 70 Contact: <sip:User2@litwareinc.com;opaque=user:epid:Ub31lldjtFyGH5ijiRSAgAA;gruu> User-Agent: UCCAPI/3.5.6907.9 Office Communicator 2007 R2 /3.5.6907.34 (Microsoft Office Communicator 2007 R2) Ms-Conversation-ID: AcnzYxWcvyhU/nzkQQK09Es13ht5ug== Supported: timer Supported: histinfo Supported: ms-safe-transfer Supported: ms-sender Supported: ms-early-media Supported: Replaces Supported: 100rel ms-keep-alive: UAC;hop-hop=yes Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REfront end R, NOTIFY, BENOTIFY, OPTIONS P-Preferred-Identity: <sip:User2@litwareinc.com>, <tel:+14255550190> Supported: ms-conf-invite Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="24C84179", targetname="sip/ocs.litwareinc.com", crand="2137c1d9", cnum="73", 124 response="602306092a864886f71201020201011100ffffffff1e132d0f694dca10627 59f1ba2b2538c" Content-Type: multipart/alternative;boundary="---=_NextPart_000_0A41_01C9F328.696A8600" Content-Length: 4786 Message-Body: ------=_NextPart_000_0A41_01C9F328.696A8600 Content-Type: application/sdp $$end_record The pool server determines that the phone number is a contact, and that the only registered endpoint is Communicator Web Access (2007 R2 release). The pool Front End Server sends the invitation to Communicator Web Access (2007 R2 release). In a situation where there is more than one registered endpoint, the Front End Server forks the call to all valid endpoints. In this case, Communicator Web Access (2007 R2 release) is the only endpoint. TL_INFO(TF_PROTOffice Communicator 2007 R2 OL) [1]0A2C.0A9C::06/22/2009-17:58:48.953.0009939f (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018A302 Direction: outgoing Peer: cwa.litwareinc.com:5061 Message-Type: request Start-Line: INVITE sip:cwa.litwareinc.com:5061;transport=Tls;msopaque=303a446bf296e5e2 SIP/2.0 From: "User2"<sip:User2@litwareinc.com>;tag=ea1b3cab6b;epid=213be0ea4a To: <sip:+12065550101@litwareinc.com;user=phone>;epid=454BF77D78 CSeq: 1 INVITE Call-ID: a9c2eb61a37944979e6ba90adbf869ce ms-user-data: ms-publiccloud=true;ms-federation=true Record-Route: <sip:ocs.litwareinc.com:5061;transport=tls;opaque=state:T:F;lr>;tag=04E 32C63BB6B7CF14891AD3423F629A0 Via: SIP/2.0/TLS 192.168.5.28:2507;branch=z9hG4bK41780D13.6D1B53BD01D5FDC8;branched=TRUE Max-Forwards: 69 ms-application-via: backend_token;ms-server=ocs.litwareinc.com;mspool=ocs.litwareinc.com;ms-application=AB072FF0-C918-424c-AC127C100E91front end 3E 125 Content-Length: 4786 Via: SIP/2.0/TLS 192.0.2.143:1331;ms-received-port=1331;ms-receivedcid=58200 P-Asserted-Identity: "User2"<sip:User2@litwareinc.com>,<tel:+14255550190> Contact: <sip:User2@litwareinc.com;opaque=user:epid:Ub31lldjtFyGH5ijiRSAgAA;gruu> User-Agent: UCCAPI/3.5.6907.9 Office Communicator 2007 R2 /3.5.6907.34 (Microsoft Office Communicator 2007 R2) Ms-Conversation-ID: AcnzYxWcvyhU/nzkQQK09Es13ht5ug== Supported: timer Supported: histinfo Supported: ms-safe-transfer Supported: ms-sender Supported: ms-early-media Supported: Replaces Supported: 100rel ms-keep-alive: UAC;hop-hop=yes Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REfront end R, NOTIFY, BENOTIFY, OPTIONS Supported: ms-conf-invite Content-Type: multipart/alternative;boundary="---=_NextPart_000_0A41_01C9F328.696A8600" History-Info: <sip:User1@litwareinc.com>;index=1 Message-Body: ------=_NextPart_000_0A41_01C9F328.696A8600 Content-Type: application/sdp $$end_record The Front End Server sends 101 Progress Report to the caller (that is, on Office Communicator 2007 R2). TL_INFO(TF_PROTOffice Communicator 2007 R2 OL) [0]0A2C.0E7C::06/22/2009-17:58:48.953.000993fb (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018A306 Direction: outgoing;source="local" Peer: 192.0.2.143:1331 126 Message-Type: response Start-Line: SIP/2.0 101 Progress Report From: "User2"<sip:User2@litwareinc.com>;tag=ea1b3cab6b;epid=213be0ea4a To: <sip:+12065550101@litwareinc.com;user=phone> CSeq: 1 INVITE Call-ID: a9c2eb61a37944979e6ba90adbf869ce Proxy-Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFF356BB0D9D7DF7A14FB5F 5B03B945C688", srand="ED8D8237", snum="118", opaque="24C84179", qop="auth", targetname="sip/ocs.litwareinc.com", realm="SIP Communications Service" Content-Length: 0 Via: SIP/2.0/TLS 192.0.2.143:1331;ms-received-port=1331;ms-receivedcid=58200 ms-diagnostics: 13004;reason="Request was proxied to one or more registered endpoints";source="ocs.litwareinc.com";appName="InboundRouting" Server: InboundRouting/3.5.0.0 Message-Body: – $$end_record The Front End Server receives 303 Proxy Should Redirect message from the Communicator Web Access (2007 R2 release) server. This is the result of the Communicator Web Access (2007 R2 release) user selecting the redirect to voice mail option in the system alert. TL_INFO(TF_PROTOffice Communicator 2007 R2 OL) [1]0A2C.059C::06/22/2009-17:59:01.766.0009a336 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018A485 Direction: incoming Peer: cwa.litwareinc.com:5061 Message-Type: response Start-Line: SIP/2.0 303 Proxy Should Redirect From: "User2"<sip:User2@litwareinc.com>;tag=ea1b3cab6b;epid=213be0ea4a To: "User1"<sip:+12065550101@litwareinc.com;user=phone>;tag=ba51cb6d68;epid =454BF77D78 CSeq: 1 INVITE 127 Call-ID: a9c2eb61a37944979e6ba90adbf869ce VIA: SIP/2.0/TLS 192.168.5.28:2507;branch=z9hG4bK41780D13.6D1B53BD01D5FDC8;branched=TRUE ,SIP/2.0/TLS 192.0.2.143:1331;ms-received-port=1331;ms-receivedcid=58200 CONTACT: <sip:User1@litwareinc.com;opaque=app:voicemail> CONTENT-LENGTH: 0 SERVER: RTCC/3.5.0.0 CWA/3.5.0.0 Message-Body: – $$end_record The Front End Server sends ACK for the 303 message to Communicator Web Access (2007 R2 release) to notify the Communicator Web Access (2007 R2 release) user that the call was actually redirected to voice mail by the Front End Server. TL_INFO(TF_PROTOffice Communicator 2007 R2 OL) [1]0A2C.059C::06/22/2009-17:59:01.766.0009a34d (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018A486 Direction: outgoing;source="local" Peer: cwa.litwareinc.com:5061 Message-Type: request Start-Line: ACK sip:cwa.litwareinc.com:5061;transport=Tls;msopaque=303a446bf296e5e2 SIP/2.0 From: "User2"<sip:User2@litwareinc.com>;tag=ea1b3cab6b;epid=213be0ea4a To: "User1"<sip:+12065550101@litwareinc.com;user=phone>;tag=ba51cb6d68;epid =454BF77D78 CSeq: 1 ACK Call-ID: a9c2eb61a37944979e6ba90adbf869ce Via: SIP/2.0/TLS 192.168.5.28:2507;branch=z9hG4bK41780D13.6D1B53BD01D5FDC8;branched=FALS E Max-Forwards: 70 Content-Length: 0 Message-Body: – $$end_record 128 Add Audio Session Initiation Protocol (SIP) Tracing The following Session Initiation Protocol (SIP) trace packets illustrate the call flows to accomplish the Communicator Web Access (2007 R2 release) Add Audio scenario. The initial state is that User1 and User2 are in an instant messaging (IM) session and User1 asks to add audio to the session. User1 is using Communicator Web Access (2007 R2 release) and User2 is using Office Communicator 2007 R2. Note: Example packets have been redacted to increase clarity. Communicator Web Access (2007 R2 release) User1 sends a SERVICE packet to ask for the conferencing capabilities of the Office Communications Server 2007 R2. TL_INFO(TF_PROTOCOL) [1]0A2C.059C::06/22/2009-18:18:42.695.0009ef1d (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Peer: cwa.litwareinc.com:3380 Instance-Id: 0018CF11 Direction: incoming Message-Type: request Start-Line: SERVICE sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory SIP/2.0 From: <sip:User1@litwareinc.com>;epid=B90980A18B;tag=7fc74f8252 To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory> CSeq: 1500 SERVICE Call-ID: 5e652d08e0da4327b873797f1e15ab7d MAX-FORWARDS: 70 VIA: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bKd8b3b93f CONTENT-LENGTH: 395 USER-AGENT: RTCC/3.5.0.0 CWA/3.5.0.0 CONTENT-TYPE: application/cccp+xml Message-Body: <?xml version="1.0" encoding="utf-8"?><request requestId="1" from="sip:User1@litwareinc.com" to="sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory" C3PVersion="1" xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions " xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" xmlns="urn:ietf:params:xml:ns:cccp"><getConferencingCapabilities /></request> $$end_record 129 The pool server responds with the capability set. TL_INFO(TF_PROTOCOL) [1]0A2C.0F78::06/22/2009-18:18:42.695.0009ef2c (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018CF12 Direction: outgoing;source="local" Peer: cwa.litwareinc.com:3380 Message-Type: response Start-Line: SIP/2.0 200 OK From: "User1<sip:User1@litwareinc.com>;epid=B90980A18B;tag=7fc74f8252 To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory>;tag=04E32C 63BB6B7CF14891AD3423F629A0 CSeq: 1500 SERVICE Call-ID: 5e652d08e0da4327b873797f1e15ab7d Content-Length: 2089 Via: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bKd8b3b93f;ms-receivedport=3380;ms-received-cid=136F00 Content-Type: application/cccp+xml $$end_record Communicator Web Access (2007 R2 release) sends a SERVICE request to get the conference key. TL_INFO(TF_PROTOCOL) [1]0A2C.059C::06/22/2009-18:18:43.335.0009f028 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018CF6B Direction: incoming Peer: cwa.litwareinc.com:3380 Message-Type: request Start-Line: SERVICE sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory SIP/2.0 130 From: <sip:User1@litwareinc.com>;epid=B90980A18B;tag=44f970267e To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory> CSeq: 1501 SERVICE Call-ID: a44fe317039844478b3879e2dfeb66f2 MAX-FORWARDS: 70 VIA: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bK5fb7f10 CONTENT-LENGTH: 384 USER-AGENT: RTCC/3.5.0.0 CWA/3.5.0.0 CONTENT-TYPE: application/cccp+xml Message-Body: <?xml version="1.0" encoding="utf-8"?><request requestId="2" from="sip:User1@litwareinc.com" to="sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory" C3PVersion="1" xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions " xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" xmlns="urn:ietf:params:xml:ns:cccp"><getEncryptionKey /></request> $$end_record The pool server (that is, the conf:focusfactory) responds with the key. TL_INFO(TF_PROTOCOL) [1]0A2C.059C::06/22/2009-18:18:43.335.0009f037 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018CF6C Direction: outgoing;source="local" Peer: cwa.litwareinc.com:3380 Message-Type: response Start-Line: SIP/2.0 200 OK From: "User1<sip:User1@litwareinc.com>;epid=B90980A18B;tag=44f970267e To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory>;tag=04E32C 63BB6B7CF14891AD3423F629A0 CSeq: 1501 SERVICE Call-ID: a44fe317039844478b3879e2dfeb66f2 Content-Length: 1893 131 Via: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bK5fb7f10;ms-receivedport=3380;ms-received-cid=136F00 Content-Type: application/cccp+xml $$end_record Communicator Web Access (2007 R2 release) requests that a conference be created. TL_INFO(TF_PROTOCOL) [1]0A2C.059C::06/22/2009-18:18:43.663.0009f07b (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018CF87 Direction: incoming Peer: cwa.litwareinc.com:3380 Message-Type: request Start-Line: SERVICE sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory SIP/2.0 From: <sip:User1@litwareinc.com>;epid=B90980A18B;tag=435df06b43 To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory> CSeq: 1502 SERVICE Call-ID: 0c7c4e19ed654a39843622a26395cdc2 MAX-FORWARDS: 70 VIA: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bKa9722575 CONTENT-LENGTH: 1708 USER-AGENT: RTCC/3.5.0.0 CWA/3.5.0.0 CONTENT-TYPE: application/cccp+xml $$end_record The server (that is, the conf:focusfactory) responds with the conference Uniform Resource Identifier (URI). TL_INFO(TF_PROTOCOL) [1]0A2C.0F78::06/22/2009-18:18:43.663.0009f08a (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018CF88 Direction: outgoing;source="local" Peer: cwa.litwareinc.com:3380 Message-Type: response Start-Line: SIP/2.0 200 OK 132 From: "User1<sip:User1@litwareinc.com>;epid=B90980A18B;tag=435df06b43 To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory>;tag=04E32C 63BB6B7CF14891AD3423F629A0 CSeq: 1502 SERVICE Call-ID: 0c7c4e19ed654a39843622a26395cdc2 Content-Length: 1262 Via: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bKa9722575;ms-receivedport=3380;ms-received-cid=136F00 Content-Type: application/cccp+xml Message-Body: <response xmlns="urn:ietf:params:xml:ns:cccp" <addConference> <conference-info xmlns="urn:ietf:params:xml:ns:conference-info" entity="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQ XXSHEUZ2M0KVHY1C006F0T5D" state="partial" version="1"/> </addConference> </response> $$end_record Communicator Web Access (2007 R2 release) sends a SERVICE to request information for conferences that are owned by User1 (with key). TL_INFO(TF_PROTOCOL) [1]0A2C.059C::06/22/2009-18:18:43.976.0009f09b (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018CF91 Direction: incoming Peer: cwa.litwareinc.com:3380 Message-Type: request Start-Line: SERVICE sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory SIP/2.0 From: <sip:User1@litwareinc.com>;epid=B90980A18B;tag=3b9871199e To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory> CSeq: 1503 SERVICE Call-ID: a24d629e06d24842a91fbafb752fc8c6 MAX-FORWARDS: 70 VIA: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bK9ac7efa1 CONTENT-LENGTH: 1329 133 USER-AGENT: RTCC/3.5.0.0 CWA/3.5.0.0 CONTENT-TYPE: application/cccp+xml $$end_record The pool server (that is, the conf:focusfactory) responds with encrypted information. TL_INFO(TF_PROTOCOL) [1]0A2C.0F78::06/22/2009-18:18:43.976.0009f0aa (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018CF92 Direction: outgoing;source="local" Peer: cwa.litwareinc.com:3380 Message-Type: response Start-Line: SIP/2.0 200 OK From: "User1<sip:User1@litwareinc.com>;epid=B90980A18B;tag=3b9871199e To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory>;tag=04E32C 63BB6B7CF14891AD3423F629A0 CSeq: 1503 SERVICE Call-ID: a24d629e06d24842a91fbafb752fc8c6 Content-Length: 4916 Via: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bK9ac7efa1;ms-receivedport=3380;ms-received-cid=136F00 Content-Type: application/cccp+xml Message-Body: <response xmlns="urn:ietf:params:xml:ns:cccp" from="sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory" to="sip:User1@litwareinc.com" code="success"> <getConference> <conference-info xmlns="urn:ietf:params:xml:ns:conference-info" entity="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQ XXSHEUZ2M0KVHY1C006F0T5D" state="full" version="1"> <conference-description> <conf-uris> <entry> <uri>http://schemas.microsoft.com/2008/05/confxmlenc#content</uri> <purpose>web-internal</purpose> </encrypted-uri> </entry> 134 </conf-uris> <conference-id xmlns="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions">W52 Q3KCQXXSHEUZ2M0KVHY1C006F0T5D</conference-id> $$end_record Communicator Web Access (2007 R2 release) sends an INVITE to cause the Focus Factory to join User1 to the conference by calling her. TL_INFO(TF_PROTOCOL) [1]0A2C.059C::06/22/2009-18:18:44.413.0009f0d0 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018CFA6 Direction: incoming Peer: cwa.litwareinc.com:3380 Message-Type: request Start-Line: INVITE sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ2 M0KVHY1C006F0T5D SIP/2.0 From: "User1<sip:User1@litwareinc.com>;epid=B90980A18B;tag=44aeda4dc To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ 2M0KVHY1C006F0T5D> CSeq: 1504 INVITE Call-ID: 6d078771-8bad-41e9-a085-22323848d0c7 MAX-FORWARDS: 70 VIA: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bK5cace8f5 CONTACT: <sip:User1@litwareinc.com;opaque=user:epid:5C9sAvigE1KvpTRTqTSSgAA;gruu>;text;audio;video;applicationsharing CONTENT-LENGTH: 947 SUPPORTED: ms-dialog-route-set-update SUPPORTED: gruu-10 SUPPORTED: timer SUPPORTED: 100rel USER-AGENT: RTCC/3.5.0.0 CWA/3.5.0.0 CONTENT-TYPE: application/cccp+xml ALLOW: UPDATE Session-Expires: 1800 135 Min-SE: 90 ALLOW: Ack, Cancel, Bye,Invite,Message,Info,Service,Options,BeNotify Message-Body: <request requestId="5" from="sip:User1@litwareinc.com" to="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSH EUZ2M0KVHY1C006F0T5D" C3PVersion="1" xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions " xmlns="urn:ietf:params:xml:ns:cccp"> <addUser> <conferenceKeys confEntity="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q 3KCQXXSHEUZ2M0KVHY1C006F0T5D" /> <user entity="sip:User1@litwareinc.com" xmlns="urn:ietf:params:xml:ns:conference-info"> <display-text>User1)</display-text> <roles> <entry>attendee</entry> </roles> <endpoint entity="{0ef76ba1-7890-44b3-aeaa-3a26e3e0e29e}" msci:endpointuri="sip:User1@litwareinc.com;opaque=user:epid:5C9sAvigE1KvpTRTqTSSgAA;gruu"> <joining-method>dialed-in</joining-method> </endpoint> </user> </addUser> </request> $$end_record After User1 is in the conference, Communicator Web Access (2007 R2 release) invites User2 to the conference. 136 TL_INFO(TF_PROTOCOL) [1]0A2C.059C::06/22/2009-18:18:46.414.0009f842 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018D038 Direction: incoming Peer: cwa.litwareinc.com:3380 Message-Type: request Start-Line: INVITE sip:User2@litwareinc.com;opaque=user:epid:Ub31lldjtFyGH5-ijiRSAgAA;gruu SIP/2.0 From: "User1<sip:User1@litwareinc.com>;epid=B90980A18B;tag=29ff66d021 To: <sip:User2@litwareinc.com;opaque=user:epid:Ub31lldjtFyGH5ijiRSAgAA;gruu> CSeq: 1513 INVITE Call-ID: 784928e7-ab13-4853-a0f0-ba1cf93192b3 MAX-FORWARDS: 70 VIA: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bK7bfeabdf CONTACT: <sip:User1@litwareinc.com;opaque=user:epid:5C9sAvigE1KvpTRTqTSSgAA;gruu>;text;audio;video;applicationsharing CONTENT-LENGTH: 247 SUPPORTED: ms-dialog-route-set-update SUPPORTED: gruu-10 SUPPORTED: 100rel USER-AGENT: RTCC/3.5.0.0 CWA/3.5.0.0 CONTENT-TYPE: application/ms-conf-invite+xml ALLOW: UPDATE Ms-Conversation-ID: b45631df64ae40b880183043ca424cef ALLOW: Ack, Cancel, Bye,Invite Message-Body: <Conferencing version="2.0"> <focusuri>sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSH EUZ2M0KVHY1C006F0T5D</focus-uri> <subject /> <im available="true" additional="false"> <first-im /> 137 </im> </Conferencing> $$end_record User2 sends the INVITE to the Focus requesting to join the conference. TL_INFO(TF_PROTOCOL) [1]0A2C.0A9C::06/22/2009-18:18:46.429.0009f8d1 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018D048 Direction: incoming Peer: 192.0.2.143:1331 Message-Type: request Start-Line: INVITE sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ2 M0KVHY1C006F0T5D SIP/2.0 From: <sip:User2@litwareinc.com>;tag=9dde023949;epid=213be0ea4a To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ 2M0KVHY1C006F0T5D> CSeq: 1 INVITE Call-ID: b4a3fe5a51c84d8e960874dbc88d3a68 Via: SIP/2.0/TLS 192.0.2.143:1331 Max-Forwards: 70 Contact: <sip:User2@litwareinc.com;opaque=user:epid:Ub31lldjtFyGH5ijiRSAgAA;gruu> User-Agent: UCCAPI/3.5.6907.9 OC/3.5.6907.34 (Microsoft Office Communicator 2007 R2) Supported: timer Supported: histinfo Supported: ms-safe-transfer Supported: ms-sender Supported: ms-early-media ms-keep-alive: UAC;hop-hop=yes Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="24C84179", targetname="sip/u2r2ocs.litwareinc.com", 138 crand="20d8c1a6", cnum="210", response="602306092a864886f71201020201011100ffffffffe5ad48b79ad8d562fa8 656e4d7e23dd3" Content-Type: application/cccp+xml Content-Length: 736 Message-Body: <?xml version="1.0"?> <request xmlns="urn:ietf:params:xml:ns:cccp" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" C3PVersion="1" to="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSH EUZ2M0KVHY1C006F0T5D" from="sip:User2@litwareinc.com" requestId="0"><addUser><conferenceKeys confEntity="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q 3KCQXXSHEUZ2M0KVHY1C006F0T5D"/><ci:user xmlns:ci="urn:ietf:params:xml:ns:conference-info" entity="sip:User2@litwareinc.com"><ci:roles><ci:entry>attendee</ci:entr y></ci:roles><ci:endpoint entity="{AB2AAE94-59A9-494C-9537948C1182F595}" xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions "/></ci:user></addUser></request> $$end_record Session progress 200 OK and an invitation dialog box is created. TL_INFO(TF_PROTOCOL) [0]0A2C.059C::06/22/2009-18:18:46.429.0009f96d (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018D052 Direction: outgoing;source="local" Peer: 192.0.2.143:1331 Message-Type: response Start-Line: SIP/2.0 200 Invite dialog created From: "User2"<sip:User2@litwareinc.com>;tag=9dde023949;epid=213be0ea4a To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ 2M0KVHY1C006F0T5D>;tag=4C0E0080 CSeq: 1 INVITE Call-ID: b4a3fe5a51c84d8e960874dbc88d3a68 139 ms-keep-alive: UAS; tcp=no; hop-hop=yes; end-end=no; timeout=300 Record-Route: <sip:u2r2ocs.litwareinc.com:5061;transport=tls;opaque=state:F:T:Ci.R582 00;lr;ms-route-sig=he2YH1WGjERb6-ZiSxIlSV7l4oPU-dL1uKOYGPpwAA> Proxy-Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFFE6E06C49850126316052 75E9A1B82B0B", srand="71F9906F", snum="285", opaque="24C84179", qop="auth", targetname="sip/u2r2ocs.litwareinc.com", realm="SIP Communications Service" Content-Length: 1322 Via: SIP/2.0/TLS 192.0.2.143:1331;ms-received-port=1331;ms-receivedcid=58200 Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE Contact: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ 2M0KVHY1C006F0T5D>;isfocus Content-Type: application/cccp+xml Session-Expires: 7200;refresher=uac Require: timer Supported: timer Message-Body: <response xmlns="urn:ietf:params:xml:ns:cccp" xmlns:msacp="http://schemas.microsoft.com/rtc/2005/08/acpconfinfoextens ions" xmlns:msas="http://schemas.microsoft.com/rtc/2005/08/asconfinfoextensio ns" xmlns:tns="http://schemas.microsoft.com/rtc/2005/08/avconfinfoextension s" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions " xmlns:msdata="http://schemas.microsoft.com/rtc/2005/08/dataconfinfoexte nsions" xmlns:msim="http://schemas.microsoft.com/rtc/2005/08/imconfinfoextensio ns" xmlns:msci2="http://schemas.microsoft.com/rtc/2008/12/confinfoextension s" xmlns:msendpt="http://schemas.microsoft.com/rtc/2008/12/endpointinfoext ensions" xmlns:ci="urn:ietf:params:xml:ns:conference-info" xmlns:cis="urn:ietf:params:xml:ns:conference-info-separator" xmlns:msls="urn:ietf:params:xml:ns:msls" requestId="0" C3PVersion="1" 140 from="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXX SHEUZ2M0KVHY1C006F0T5D" to="sip:User2@litwareinc.com" code="success"> <addUser> <conferenceKeys confEntity="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q 3KCQXXSHEUZ2M0KVHY1C006F0T5D"/> <ci:user entity="sip:User2@litwareinc.com"> <ci:roles> <ci:entry>attendee</ci:entry> </ci:roles> </ci:user> </addUser> </response> $$end_record INFO from User2 to the Focus with key. TL_INFO(TF_PROTOCOL) [1]0A2C.0A9C::06/22/2009-18:18:46.460.0009f9a3 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018D05B Direction: incoming Peer: 192.0.2.143:1331 Message-Type: request Start-Line: INFO sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ2 M0KVHY1C006F0T5D SIP/2.0 From: <sip:User2@litwareinc.com>;tag=9dde023949;epid=213be0ea4a To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ 2M0KVHY1C006F0T5D>;tag=4C0E0080 CSeq: 2 INFO Call-ID: b4a3fe5a51c84d8e960874dbc88d3a68 Via: SIP/2.0/TLS 192.0.2.143:1331 Max-Forwards: 70 Route: <sip:u2r2ocs.litwareinc.com:5061;transport=tls;opaque=state:F:T:Ci.R582 00;lr;ms-route-sig=he2YH1WGjERb6-ZiSxIlSV7l4oPU-dL1uKOYGPpwAA> 141 User-Agent: UCCAPI/3.5.6907.9 OC/3.5.6907.34 (Microsoft Office Communicator 2007 R2) Supported: ms-dialog-route-set-update Supported: timer Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="24C84179", targetname="sip/u2r2ocs.litwareinc.com", crand="ad9e7d8b", cnum="215", response="602306092a864886f71201020201011100ffffffff981e07e5ea0f130ba57 cc2ed92da58b2" Content-Type: application/cccp+xml Content-Length: 1285 Message-Body: <?xml version="1.0"?> $$end_record 202 accepted from User2 to conf:focus. TL_INFO(TF_PROTOCOL) [1]0A2C.0F80::06/22/2009-18:18:46.460.0009f9b1 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018D05C Direction: outgoing;source="local" Peer: 192.0.2.143:1331 Message-Type: response Start-Line: SIP/2.0 202 Accepted From: <sip:User2@litwareinc.com>;tag=9dde023949;epid=213be0ea4a To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ 2M0KVHY1C006F0T5D>;tag=4C0E0080 CSeq: 2 INFO Call-ID: b4a3fe5a51c84d8e960874dbc88d3a68 Proxy-Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFFE0E9F269C783FF8AECB6 BF67028DDC0F", srand="89D8A03F", snum="287", opaque="24C84179", qop="auth", targetname="sip/u2r2ocs.litwareinc.com", realm="SIP Communications Service" Via: SIP/2.0/TLS 192.0.2.143:1331;ms-received-port=1331;ms-receivedcid=58200 Content-Length: 0 142 Message-Body: – $$end_record The pool server (that is, conf:focus) sends out INFO with details of the conference and the participants. TL_INFO(TF_PROTOCOL) [1]0A2C.0F80::06/22/2009-18:18:46.460.0009f9f5 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin _record Instance-Id: 0018D065 Direction: outgoing;source="local" Peer: 192.0.2.143:1331 Message-Type: request Start-Line: INFO sip:192.0.2.143:1331;transport=tls;msopaque=6fe2ccfaed;ms-received-cid=58200;grid SIP/2.0 From: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ 2M0KVHY1C006F0T5D>;tag=4C0E0080 To: <sip:User2@litwareinc.com>;tag=9dde023949;epid=213be0ea4a CSeq: 8 INFO Call-ID: b4a3fe5a51c84d8e960874dbc88d3a68 Via: SIP/2.0/TLS 192.168.5.28:5061;branch=z9hG4bK2CBE513C.E418D77A2630C466;branched=FALS E Proxy-Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFF01B326A85CB03EB72670 27B3BCF95F4F", srand="BFC9387F", snum="289", opaque="24C84179", qop="auth", targetname="sip/u2r2ocs.litwareinc.com", realm="SIP Communications Service" Max-Forwards: 70 Content-Length: 7893 Supported: ms-dialog-route-set-update Content-Type: application/cccp+xml Message-Body: <response xmlns="urn:ietf:params:xml:ns:cccp" from="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXX SHEUZ2M0KVHY1C006F0T5D" to="sip:User2@litwareinc.com" code="success"> <getConference> 143 <ci:conference-info entity="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQ XXSHEUZ2M0KVHY1C006F0T5D" </msci:cms-data> </msci:conference-key> <msci:admission-policy>anonymous</msci:admission-policy> <msci:notification-data/> </ci:conference-description> <ci:users state="full"> <ci:user entity="sip:User1@litwareinc.com" state="full"> <ci:display-text>User1</ci:display-text> <ci:roles> <ci:entry>presenter</ci:entry> </ci:roles> <ci:endpoint entity="{0ef76ba1-7890-44b3-aeaa-3a26e3e0e29e}" msci:session-type="focus" </ci:endpoint> </ci:user> <ci:user entity="sip:User2@litwareinc.com" state="full"> <ci:display-text>User2</ci:display-text> <ci:roles> <ci:entry>attendee</ci:entry> </ci:roles> $$end_record Outside Voice Control Scenario Mobile phones are a key facet of information worker communications. Accordingly, incorporating mobility into a unified communications plan is essential for true unification of communications. Although the e-mail, instant messaging (IM), and federated telephony worlds are already becoming unified by having a single Session Initiation Protocol (SIP) address (which is typically the e-mail address) be the single point of contact for a person, this unification has not yet extended to the mobile phone space. Information workers still end up exchanging mobile phone numbers in addition to their work phone numbers as part of their contact information. This has led to a suboptimal user experience. For example, a caller from the public switched telephone network (PSTN) tries to reach a certain user by dialing the user’s office phone number. If she cannot reach the user at his office phone, she bypasses the corporate voice mail system by disconnecting the original call and dialing the user’s mobile phone number. If the caller cannot 144 reach the user on his mobile phone, the caller leaves a message on the user’s voice mail box in the mobile phone network. As a result, the recipient ends up checking his Outlook inbox for emails, corporate voice mail system for some voice mails, and his mobile phone provider’s voice mailbox for other voice mails. A unified communications solution needs to provide means for the user to control any communication stream in a unified fashion at all times. By giving out a mobile phone number, a secondary access channel to the user has been opened that currently bypasses the user’s unified communications solution in the company. With Office Communications Server 2007 R2 a new feature has been introduced, called Outside Voice Control, that enables users to hide their mobile phone number for inbound and outbound calls. This feature is sometimes referred to as outside voice. To use this feature, a user needs to install Office Communicator Mobile (2007 R2 release) on a Windows Mobile phone, and a data service such as General Packet Radio Service (GPRS) to provide IP data communication between the mobile phone and the Internet. This network carries SIP messages (that is, but not audio media) between the Office Communications Server 2007 R2 system (that is, by using the organization’s Edge Server) and the Communicator Mobile client. The user also needs to be enabled for Enterprise Voice. If the user receives an incoming call on his SIP Uniform Resource Identifier (URI), either from the PSTN or from other Office Communications Server 2007 R2 users or from a federated contact, Office Communications Server 2007 R2 sends a SIP INVITE to all of the user’s registered SIP endpoints (for example, Office Communicator 2007 R2, Office Communicator Phone Edition) as well as to the user’s Communicator Mobile client running on the Windows Mobile device. After this SIP INVITE message reaches the Communicator Mobile client using the data channel of the mobile phone, Communicator Mobile automatically accepts the incoming call and changes the user’s presence to In a Call. Next, Office Communications Server 2007 R2 initiates an outbound call to user’s mobile phone number by using an Office Communications Server 2007 R2 Mediation Server and PSTN access point (that is, by using a gateway, PBX, or SIP Trunk service provider). The user receives a second incoming call through the mobile phone provider’s cellular network and is able to accept the call. Note that the actual mobile phone call is not a Voice over IP (VoIP) call where audio has been transmitted by using the mobile phone provider’s data packet network to Communicator Mobile. Instead, it is a normal mobile phone call that uses the mobile phone provider’s cellular network. For an outbound call from her mobile phone, the user has the option to enter the phone number to be dialed in Communicator Mobile or to initiate a call to a SIP contact using Communicator Mobile. If the user chooses the Call menu option in Communicator Mobile, the call is placed by the mobile phone by using the mobile phone network. However, if the user chooses the Call via work option in Communicator Mobile, the phone first sends a SIP INVITE to Office Communications Server 2007 R2. Office Communications Server 2007 R2 establishes a call to the user’s mobile phone number over the PSTN. The user receives an incoming mobile phone call from his company by using the mobile phone provider’s cellular network. Finally, after the user accepts the call from his company, Office Communications Server 2007 R2 sets up a second call leg to the designated called party and joins the two connections. (Note that if the Called Party is on the PSTN, the two call legs can be over separate Mediation Servers that have 145 completely different PSTN break-out locations.) The called party receives a call from the user’s company by using the user’s office phone number as the Calling Party number despite the fact that the user is actually on her mobile phone. Following are some of the benefits for the company and the user associated with this scenario:  The user’s office phone number can become the only phone number that is published on business cards and other business materials. The mobile phone number can be shared with selected people.  Activities on the user’s mobile phone (for example, when participating in a mobile phone call) can be aggregated to the user’s overall presence state.  If the user is enabled for Enterprise Voice and Exchange 2007 SP1 Unified Messaging, the user can disable his mobile phone voice mail box and use Exchange 2007 SP1 Unified Messaging as his only voice mail repository. This has all the advantages of using an Outlook Inbox for all communications (for example, e-mail, missed call notifications, voice mail, team call pick-up notifications, and so on).  By setting up an outbound mobile phone call through Office Communications Server 2007 R2 by using the Outside Voice Control functionality, call charge reductions may occur. For example, if the user wants to call an international phone number from his mobile phone for a longer conference call, call charges can be lowered significantly by placing the call from the company to the international number through the PSTN, bypassing the mobile phone network (despite another call leg being established from the company to the user’s mobile phone number). Office Communications Server 2007 R2 Least-Cost Routing functionality helps save additional costs in these situations. Even more obvious are the savings what occur when the user calls a federated contact who has a phone number based in another country. Instead of calling the international number directly from the user’s mobile phone, Office Communications Server 2007 R2 can use an Office Communications Server Edge Server to connect this federated call leg with the call leg to the user’s mobile phone.  All calls initiated through Office Communications Server 2007 R2 are captured for Call Detail Recording (CDR) and Quality-of-Experience (QoE) as part of the Office Communications Server 2007 R2 Monitoring Server. However, the QoE data is only on the VoIP legs of the call and does not reflect the quality of the PSTN or mobile provider network. Outside Voice Control Architecture To enable the Outside Voice Control scenario, the following prerequisites are required:  As part of the Office Communications Server 2007 R2 installation, all applications are installed by default. During the deployment, the Outside Voice Control application needs to be activated as part of the Office Communications Server 2007 R2 installation.  The unified communications Application Server needs to run on every Office Communications Server 2007 R2 Standard Edition server or Enterprise pool Front End Server. You need to start the Outside Voice Control application by using the Office Communications Server 2007 R2 snap-in. 146  One or more Office Communications Server 2007 R2 Mediation Servers with connected PSTN Gateways, IP PBXs, or SIP Carrier trunks need to be deployed for PSTN access.  Users who want to benefit from this scenario need to be enabled for Enterprise Voice. To benefit from the single voice mail box functionality, which can only be provided by Exchange 2007 Unified Messaging, users need to be enabled for Exchange 2007 Unified Messaging.  Users need to have a Communicator Mobile (2007 R2 release) client installed on their Windows Mobile 6 or Windows Mobile 6.1 smartphone or Pocket PC phone device. Additionally, it is highly recommended that you have an unlimited data usage plan with the mobile phone provider.  The user’s mobile phone needs to be enabled for data packet communication through GPRS, EDGE, CDMA, or other 3G connection, and a screen resolution of 240 x 320 pixels is required.  An Office Communications Server 2007 R2 Access Edge server needs to be deployed to allow Communicator Mobile to exchange SIP messages with the corporate Office Communications Server 2007 R2 pool.  You need to configure a location profile for each pool or user where Outside Voice Control is installed.  To enable this scenario, you need to open the following ports: 147 Table 1. Required and Optional Ports Application Port Number Protocol Place to open Usage ports Communicator Mobile (2007 R2 release) 5060 SIP Transmission Control Protocol (TCP) Load balancer in front of home server (optional) Port range used by Communicator Mobile for SIP communications internally Communicator Mobile (2007 R2 release) 5061 SIP TLS Internal firewall and load balancer in front of home server (required) Port range used by Communicator Mobile for SIP over Transport Layer Security (TLS) communications internally Communicator Mobile (2007 R2 release) 443 TLS/HTTPS External firewall and load balancer in front of external edge of Access Edge Server Used by Communicator Mobile for connecting from outside the intranet for SIP communications Outside Voice Control 5074 TCP Load balancer in front of home server where Outside Voice Control is installed Used by Outside Voice Control for internal communications Architectural Overview The following figure shows the architecture required for the Outside Voice Control scenario. 148 Figure 1. Outside Voice Control architecture Protocols Used By Outside Voice Control Outside Voice Control uses the following protocols:  Session Initiation Protocol (SIP). Communicator Mobile exchanges SIP messages through the Office Communications Server 2007 R2, Access Edge Server with the Office Communications Server 2007 R2 pool.  Third Party Control Protocol (TPCP). This protocol is transported by SIP messages between the Communicator Mobile client and the Office Communications Server 2007 R2 Standard Edition server or Enterprise pool and is used to send call commands between the phone and the user’s Front End Server. Call Flows The following sections contain sample call flows for an outbound call and an inbound call (from the perspective of the Windows Mobile phone user) by using the Enterprise Cellular Voice scenario with a Communicator Mobile (2007 R2 release) client. Outbound Call The following steps occur when User A, who is running Communicator Mobile, establishes an outbound call to User B, who is using Office Communicator, from a mobile telephone by using Communicator Mobile in conjunction with the Outside Voice Control application. User B has multiple endpoints: Office Communicator 2007 R2 and Communicator Mobile (2007 R2 release). 1. On his Communicator Mobile client, User A selects a contact from his contact list, and then selects Call via Work from the calling options. 2. Communicator Mobile uses a data channel to inform Outside Voice Control of the outbound call. This information is transmitted to Outside Voice Control by using SIP/TPCP. The 149 message is passed though the mobile provider’s data packet network through the Internet to their organization’s Office Communications Server 2007 R2 Access Edge server, and from there to their assigned Standard Edition server or Enterprise pool. 3. Outside Voice Control establishes a call to User A’s mobile phone by initiating a request through a Mediation Server to the mobile phone provider’s cellular voice network. 4. User A receives an incoming call on her mobile phone. 5. User A answers the call and the first call leg between the Office Communications Server 2007 R2 environment and User A’s mobile phone has been established. Media is inactive. 6. Outside Voice Control now establishes a second call leg with the home pool of User B, where Office Communicator 2007 or Communicator 2007 R2 has been registered, by sending a SIP INVITE message. 7. A Front End Server in User B’s home pool looks up the User B’s registered endpoints and then forks the SIP INVITE message to all of them. 8. User B gets an incoming call notification. 9. As soon as User B answers the call on one of her registered devices, the second call leg has been established. 10. Outside Voice Control provides call management to bridge the two call legs between the mobile client (that is, User A) and the enterprise Office Communicator user (that is, User B). Media flows between User A’s mobile phone through the mobile phone provider’s cellular network, to the PSTN, then through the Mediation Server (that was selected by Outbound Routing) to Office Communicator 2007 or Communicator 2007 R2 client. 150 Figure 2. Outbound call flow If call forwarding on the mobile telephone has been enabled, outbound calls on Communicator Mobile are not supported. For the normalization of telephone numbers dialed by Communicator Mobile, the user’s userspecific location profile is applied on non RFC3966 compliant called party numbers. 151 Inbound Call To continue with the example above but in the opposite direction, User B (that is, the Office Communicator 2007 or Communicator 2007 R2 user) in the enterprise calls User A. User A has Communicator Mobile installed on her mobile device. In this section, the call flow of this scenario is outlined below. 1. User B initiates a call to User A by clicking on a contact in Office Communicator 2007 or Office Communicator 2007 R2. 2. User A’s Front End Server in the recipient’s home pool looks up User A’s registered endpoints, and then forks the call to all registered endpoints, including User A’s Communicator Mobile client. 3. When the request to establish a signaling channel reaches Communicator Mobile, Communicator Mobile determines that the incoming session is an audio call. Note: Communicator Mobile intercepts the incoming voice call only if the Calling Party number of the voice call matches the Calling Party number that is communicated through the data channel that gets established before the voice call. Otherwise, the incoming voice call is treated as a regular mobile telephone call and Communicator Mobile does not respond. 4. Communicator Mobile automatically accepts the call by using a data signaling channel in the data packet network of the mobile phone provider to pass this message to Outside Voice Control through the Internet and Office Communications Server 2007 R2. 5. Outside Voice Control initiates a call to User A’s mobile phone number. Outbound Routing selects a Mediation Server/gateway to send the call to the PSTN, which ultimately routes to the mobile phone provider’s cellular network. 6. When the user answers the incoming mobile phone call on his mobile phone, Outside Voice Control and Office Communications Server 2007 R2 connect the Office Communications Server 2007 R2 Mediation Server call leg with the originating call leg. Media flows directly between Office Communications Server 2007 R2, Mediation Server and the caller. 7. Outside Voice Control remains in the signaling path to provide call management until the call is terminated. 152 Figure 3. Inbound call flow To redirect the incoming INVITE, Communicator Mobile redirects the INVITE with a 303 SIP response and introduces a new header called CancelForking. This header can have two possible values: Yes or No. The absence of the header, which is consistent with Communicator Mobile (2007 release), means that forks will be cancelled. Therefore, the absence of the header is equal to CancelForking:Yes. 153 Group Chat Feature Scenario The Office Communications Server 2007 R2 Group Chat Server is built on top of the Office Communications Server infrastructure. This infrastructure handles user authentication, presence, security, and routing. Any supported Office Communications Server topology also supports Group Chat functionality, even if users are connecting from the Internet or belong to federated organizations. After you have deployed the Group Chat clients and Group Chat Servers, only the Group Chat Servers require additional configuration before the Group Chat feature is fully operational. You can deploy a Group Chat Server on a single computer or on an array of servers to provide greater scalability and availability. You can also deploy Group Chat Servers at multiple locations if you have a multi-pool Office Communications Server topology. The Group Chat client integrates with the Office Communicator 2007 R2 client and is another Session Initiation Protocol (SIP) endpoint that registers with a Standard Edition server or a Front End Server of an Enterprise pool. The Group Chat Server uses the Unified Communications Managed API (UCMA) 2.0 to communicate with the pool that you select when you install the Group Chat Server. This section of the Office Communication Server 2007 R2 Technical Reference is intended to help Unified Communications administrators and specialists gain a deeper understanding of the Group Chat architecture, protocols, and communication flows, which can be valuable for system design and troubleshooting. In This Section This section contains the following topics:  Group Chat Services  Key Protocols and Windows Services Used by Group Chat  Group Chat Call Flows Group Chat Services Group Chat Server consists of the following: the Channel service, the Lookup service, the Web service, and a dedicated back-end database, which must reside on a separate computer. If you choose to use Compliance service, which is optional, you must install it on a separate computer. The Compliance service requires its own back-end SQL Server database, which can reside on the same computer as the Compliance service or on a separate computer. If it is on a separate computer from the Compliance service, the back-end database can be collocated with the main Group Chat SQL Server database or be placed on a separate database server. The back-end database stores configuration data for the Group Chat Servers and stores the chat message history for each chat room. Channel Service Most of the workload of a Group Chat Server is performed by the Channel service. The Channel service accepts incoming messages, registers and lists the online participants within a channel 154 (known as a Chat Room in the user interface), and retransmits messages to the other channel subscribers. The Channel service also implements logic for channel management, chat room invitations, search, and new content notifications. When the Group Chat feature is provided by an array of Group Chat Servers joined to the same pool, each Channel service communicates with the others to relay new messages to the clients connected to each member of the array, and each ascertains the operational health of the other Group Chat Servers. Because each Channel service gets its configuration information from a common back-end database, all are configured identically. The Channel service registers as a trusted service in the Active Directory Domain Services (AD DS) when the Group Chat Server is activated. When a deployment includes multiple Group Chat Servers, each instance of the Channel service is assigned a unique Session Initiation Protocol (SIP) Uniform Resource Identifier (URI), which is the Globally Routable User Agent URI (GRUU) setting of the corresponding trusted service. These GRUUs allow the Lookup service to assign users to specific Channel service servers. Lookup Service The Lookup service connects clients to a Channel service. If there is more than one Group Chat Server in the deployment, the Lookup service also functions as a load balancer. The Lookup service is represented by a URI that is provisioned to the Group Chat clients before their users sign in. This URI can be the default value (OCSChat@<user’s SIP domain>), it can be supplied to the Group Chat clients by Group Policy, or it can be configured manually. After a user of a Group Chat client successfully signs in to a Front End Server, the Front End Server uses this URI to initiate a session with a Lookup service on behalf of the client. When a deployment includes multiple Group Chat Servers, the servers’ Lookup services can share the same SIP URI. When a Group Chat client initiates a connection, the Lookup services act as multiple points of presence (MPOP) for that SIP address, and the last Lookup service to connect with the client is the one that assigns a Channel service to the client. If a Lookup service instance fails, the Front End Server automatically routes subsequent connection requests to another Lookup service. Even if one server is slower than the others and it is consistently the last one to respond (and thereby gets all of the Lookup service requests), it is of little concern from a scalability standpoint because the process of assigning Channel service URIs to clients is fairly lightweight. The Lookup service assigns Channel service instances so that the workload among all instances is balanced. Every 10 seconds, each Channel service instance communicates its current user load to all Lookup service instances. The Lookup services route new sessions to the least loaded Channel service at the time. If a Channel service fails, existing sessions are cancelled, and the clients contact the Lookup service to receive the URI of a new Channel service. After they reconnect, the new Channel service automatically pushes any missed messages to the clients. When a Channel service resumes operation, the Lookup services do not redistribute existing Group Chat sessions, but the resumed Channel service instance reports itself as available and 155 will get all subsequent new client connections until its workload is balanced with those of the other Channel service instances. Web Service Because files attached to chat messages must be available to multiple users within a channel and from the chat history, peer-to-peer (P2P) file transfer is not sufficient. The Web service provides a mechanism for file exchange within the context of channels. Group Chat clients must provide specific tokens to upload or download files. These tokens are provided in-band by the Channel service to authorized subscribers. When a deployment includes multiple Group Chat Servers, all servers use a Universal Naming Convention (UNC) path that points to a common Windows share where the actual files reside. End users are not permitted direct access to this share. They must go through the Web service. Although Group Chat clients never communicate directly with a Lookup service or Channel service (that is, they are always proxied through one or more Front End Servers), clients connect directly to a Web service instance when they upload and download files to and from a chat room. For the file transfer function to be available to remote users without using a virtual private network (VPN) or to federated users, the Web service URIs must be resolvable and routable from the Internet. Compliance Service The Compliance service uses Microsoft Message Queuing (also known as MSMQ) to collect Group Chat messages and events from Channel service instances and uploaded files from Web service instances. The Compliance service archives these messages as files formatted according to the type of Compliance adapter you selected during installation. The Compliance service comes with a customizable XSLT transform that generates XML files for pickup and further analysis by a custom program. Compliance adapters are also available from Akonix, Assentor, and Facetime that enable the Compliance service to generate output file formats compatible with archiving solutions from those vendors. Before archival, messages are staged in a SQL Server database separate from the one used by the Group Chat Server. The two databases can coexist on the same computer, but if the workloads are high enough to degrade performance they should be located on separate SQL Server instances. Unlike the back-end database for the Office Communications Server 2007 R2 Archiving Server, this database stores the messages for the duration of the archive retention period, the back-end database for the Compliance service stores records only temporarily. The data is extracted according to the Compliance server’s Conversation interval in minutes setting, is written to a file, and then placed in a shared directory, where it can be picked up by the third-party or custom compliance system. After the compliance system has picked up the data, the XML output files and uploaded files can be deleted to prevent loss of available disk space. You can also use the Compliance service to archive uploaded files. 156 The Compliance Server does not archive instant messages, even if the instant messaging (IM) session was launched from the Group Chat client. If your organization wants to archive IM sessions, you must deploy the Archiving Server role on a separate server. Key Protocols and Windows Services Used by Group Chat The Group Chat feature relies on several protocols: Session Initiation Protocol (SIP)/Transport Layer Security (TLS), Windows Communication Foundation (WCF), HTTPS, and Message Queuing (also known as MSMQ). Session Initiation Protocol (SIP) By using SIP over TLS as its key client-server communications protocol, the Group Chat feature harnesses the core real-time communications (RTC) capabilities of Office Communication Server 2007 R2, including the client-side and server side application programming interfaces (APIs), authentication, encryption, registration, presence, and routing. Furthermore, because SIP is a general-purpose signaling protocol that can transport payloads that contain other protocols (for example, Session Description Protocol (SDP) or Centralized Conferencing Control Protocol (C3P)), most of the Group Chat client-server traffic consists of SIP INFO messages containing an XML-based protocol, XCCOS. XCCOS is a proprietary format for transmitting data between Front End Servers and Group Chat clients. In addition to transporting the chat messages, it provides support for federated Group Chat, channel invitations, activity notifications, and posting of files. The Group Chat Lookup and Channel services register as SIP endpoints with an Office Communications Server Front End pool. Clients communicate with them by using SIP INFO messages that contain XCCOS commands and responses. Windows Communication Foundation (WCF) When a deployment includes multiple Group Chat Servers, the Lookup service uses WCF over TLS on each Group Chat Server to monitor the load on each server and determine which Channel service instances should receive new client connections. The Channel services also use WCF to relay messages with each other. Clients are balanced across the available Channel service instance. As a result, when a new message comes in to a Chat Room (channel) on one Channel service instance, in addition to rebroadcasting the message to the other active participants subscribed to that Chat Room over SIP, the Channel service forwards the message over WCF to the other Channel service instances in the array, which in turn forwards the messages to the Chat Room subscribers actively connected to those other instances. HTTPS Uploading and downloading files to and from Group Chat clients and the Web service occurs over HTTPS. This traffic is the only Group Chat client-server communication that does not occur over SIP. 157 Message Queuing For deployments that include the optional Compliance service, each Channel service uses Message Queuing to publish the following events to the Compliance service:  New chat messages  A user entering or exiting a chat room  File uploads and downloads  Queries and searches against the chat history The Compliance service temporarily stores the events and chat messages in its back-end database. In addition to extracting the events and chat messages from the database and writing them to files in a shared directory, the Compliance service also obtains copies of all uploaded files and writes them to an Attachment subdirectory in the shared directory for pickup for pickup by your archiving solution. Group Chat Call Flows This topic describes the call flows of a user signing in from a Group Chat client, subscribing to a chat room, and then posting a message to it. In these examples, the architecture consists of a single consolidated Group Chat Server that is in the same pool as the user. Group Chat Client Sign In Before users can participate in a group chat, they must sign in with the Group Chat client to a Front End Server, be authenticated by the server, and then connect to the Chat Rooms to which they have subscribed. In this example, the Lookup service and the Channel service are already running and registered with the Front End Server. The sequence of steps is as follows: 1. The Group Chat client uses the same techniques as the Office Communicator 2007 R2 client to locate its pool server (that is, Domain Name System (DNS) SRV records in most cases and a Director referral, if used). The client uses either the user’s Windows logon credentials or manually-entered alternate credentials, and then sends a set of SIP REGISTER messages to a Front End Server. If the user’s credentials are valid and the user is authorized to use Group Chat, he or she is authenticated. 2. The Group Chat client sends one or more SIP SUBSCRIBE messages to the Front End Server and then retrieves the user’s contact list. 3. The Group Chat client sends a SIP SERVICE message to the Front End Server to provide information about its endpoint capabilities. From this point onward (that is, in the context of Group Chat), the only function of the Front End Server is to proxy messages between the Group Chat client and one or more Group Chat Servers. 4. The Group Chat client sends a SIP INVITE message to the Uniform Resource Identifier (URI) of the Lookup service. If the client is set to use automatic configuration, this URI defaults to the name OCSChat@<user’s SIP domain>. If the organization has implemented Group Policy Object (GPO)-based configuration of the Group Chat client, it will use the URI that is 158 provided by the Specify lookup server URI GPO policy setting. (Users can also manually supply the URI of the Lookup service.) The Front End Server looks in its registration database and proxies the INVITE message to all Lookup service instances that are registered with it. In this example, there is only one. The INVITE sequence is followed up by the 200 OK and ACK, and the Group Chat client has now opened a SIP session with a Lookup service endpoint. 5. The Group Chat client sends a SIP INFO message containing the XCCOS requri (that is, request URI) command to the Lookup service, which queries the back-end database and returns the URI of the Channel service with the lowest current workload. When the client receives the URI, it sends a SIP BYE message and closes the session with the Lookup service. 6. The Group Chat client sends a SIP INVITE message to the URI of the Channel service that it obtained in the previous step. The INVITE sequence is followed by 200 OK and ACK, and the Group Chat client has now opened a SIP session with a Channel service endpoint. From this point forward, the client communicates with the Channel service by sending SIP INFO messages that contain either chat messages or commands requesting the server to take an action. All of these messages are acknowledged with either 200 OK or 503 Service Unavailable (that is, in the event of heavy server load). If the client receives a 503 response, it will retry the message. (This example does not include a 503 response.) If the server accepts the message or command and sends 200 OK, it will provide a response to the client in the form of a separate SIP INFO message. This response includes a reference to the originating command. 7. The Group Chat client sends a SIP INFO message containing the XCCOS getserverinfo command. The Channel service replies with a new SIP INFO message containing information about the Channel service configuration. 8. The Group Chat client sends a SIP INFO message containing a set of XCCOS getpref (that is, get preferences) commands. The client stores its state on the server in a set of compressed XML documents called preferences. The getpref command is a request from the client to the server for the latest copy of that data. If the client has a local copy of the preferences, it sends the version ID of the local copy in the command. The server responds to this command in a separate SIP INFO message with the requested data. 9. The Group Chat client sends a SIP INFO message containing a XCCOS bjoin (that is, batch join) command that contains a list of chat rooms that the user has previously joined. This list is obtained from the preferences document. The Channel service queries the back-end database, and then returns a separate SIP INFO message containing the user’s channel provisioning data and the contextual message history for those chat rooms. 10. The Group Chat client sends a SIP INFO message containing a XCCOS getinv (that is, get invitation) command to request any open channel invitations. In a separate SIP INFO message, the Channel service returns a list of those channels. The following ladder diagram shows this call flow. 159 Figure 1. Group Chat client sign in call flow 160 Note: Messages from the Group Chat Server to the client are often batched. A single SIP INFO message can contain one or more messages. For example, in the case of a batch join (that is, bjoin) command, the server sends bjoin replies and contextual message history for each chat room that is being joined. But these messages may be delivered to the client as a single SIP INFO message or as multiple SIP INFO messages. After the user of a Group Chat client is signed in and connected to a Channel service, his or her client lists the message history of all currently subscribed chat rooms. If the user’s Office Communications Server account was homed in pool different from that of the Group Chat Server pool, a Front End Server in the user’s home pool would proxy the messages to and from a Front End Server in the pool with which the Channel service is homed. Subscribing to a Chat Room and Posting a Message In this example, two users, User1 and User2, are signed in to a Channel service. User1 wants to subscribe to a new Chat Room, to which User2 is already connected, and then participates by posting a message with a file attachment. The sequence of steps is as follows: 1. From the Group Chat client, User1 clicks Join a Chat Room, clicks Search, and then enters some search criteria. The client sends the Channel service a SIP INFO message containing the XCCOS chansrch (that is, channel search) command, along with the search criteria. The Channel service queries the back-end database and replies in a new SIP INFO message that contains a list of available channels (chat rooms) that meet the search criteria. 2. User1 selects the chat room he or she wishes to join and then clicks Join. The client sends the Channel service a SIP INFO message containing the XCCOS join command and the channel ID of the chat room the user selected. The Channel service replies with a SIP INFO message that contains the provisioning data. 3. The Group Chat client sends the Channel service a SIP INFO message that contains the XCCOS bccontext (that is, backchat context) command. The Channel service retrieves the chat history and returns it to the client in a separate SIP INFO message. At this point, the user enters the chat room and is ready to participate. 4. User1 enters a new message containing a file attachment reference and then clicks Send. The Group Chat client sends the Channel service a SIP INFO message containing the XCCOS getfutok (that is, get file upload token) command. The Channel service inserts a token into the back-end database and issues the token with the URI of the Web service instance to the client in a new SIP INFO message. This token is then used by the Group Chat client to upload the file to the URI of the Web service instance, which validates the token against the back-end database before allowing the upload to proceed. User1’s client simultaneously posts the message with the file attachment link to the chat room in a SIP INFO XCCOS grpchat command. The Channel service stores a copy of this new message in the SQL Server database. 161 5. The Channel service sends a separate copy of the SIP INFO XCCOS grpchat message to User2, who has already entered the chat room. The following ladder diagram below shows the call flow. Figure 2. Group Chat subscription and message posting call flow 162 Technical Drilldowns This section provides deeper drilldowns into specific technical aspects of Microsoft Office Communications Server 2007 R2. In This Section  SIP Processing Drilldown  User Replicator Drilldown  Archiving and Monitoring Drilldown  Edge Servers Drilldown  Response Group Client Web Service Drilldown  Client DNS Queries Drilldown  Application Server Drilldown  SIP Trunking Drilldown  Address Book Server Drilldown SIP Processing Drilldown In versions of Office Communications Server prior to Office Communications Server 2007, the server used a proprietary extension called End-point Identifier (EPID) to address a specific User Agent. Starting with Office Communications Server 2007, Globally Routable User Agent URI (GRUU) replaces EPID where possible. Office Communications Server 2007 R2 supports backwards compatibility with EPID, but to the degree possible, all new applications and clients use GRUU instead. SIP Processing and GRUU GRUU is an extension of Session Initiation Protocol (SIP) that is currently defined in an Internet draft at http://go.microsoft.com/fwlink/?LinkId=144418. GRUU is specifically designed to implement reliable routing to a specific device for an end user. While a plain SIP URI (for example, janedoe@contoso.com), is a URI that refers to a user, GRUU is an URI that refers to a specific device. GRUU can be used within multiple separate SIP dialogs to reach the same device. This works not just for client applications but also server applications (for example, the Mediation Server). The Office Communicator client running on each computer has its own GRUU that allows other applications to route messages specifically to that device. GRUU is widely applied across the server to solve a variety of problems, including, but not limited to, Enterprise Voice call transfer or conference escalation scenarios, which require the ability to establish a new dialog with a specific endpoint in an existing dialog. GRUU is also used to address scenarios where one endpoint in a dialog is server based and, therefore, the To/From header in the dialog cannot be resolved to a specific endpoint. In the original SIP standard, it was 163 not possible to construct an URI which could be routed to from anywhere (including the Internet) and reach a specific device or User Agent. GRUU is a SIP URI that generally follows the form: sip:<user>@<domain or FQDN>;opaque=<private>;grid=<optional cookie>;gruu For example: sip:janedoe@contoso.com;opaque=user:epid:qIIWS2j5AVeD_HxnQdxmlwAA;gruu The opaque parameter, in combination with the address of record (AOR), makes this URI unique even though the prefix of the URI is still the standard user address. The gruu parameter specifies that this URI has all the properties of a GRUU and can be used within multiple separate SIP dialogs to reach the same user agent (device). The grid parameter is optional and is inserted by a user agent instance when the user agent uses the GRUU to route to itself. If the grid is included in a request, it helps the user agent instance determine the context of the request. GRUU Creation The server is responsible for creating a GRUU and returning it to the client through the SIP registration mechanism, if the client requests one at registration time. The GRUU returned to the client during the registration process is not managed or exposed to the administrator in any way. This process is handled entirely by the User Services module and can be inspected only by examining the registration database itself. The GRUU can be used anywhere you would typically use a URI. How GRUU Is Used by Office Communications Server GRUU is used by Office Communications Server in the following ways:  Office Communicator 2007 R2 clients request and receive a GRUU at registration time, which they will use in their Contact header for all subsequent SIP dialogs, such as Enterprise Voice calls, conferencing, and so on.  The Microsoft Office Live Meeting client uses one aspect of GRUU known as the "sip.instance" to create a unique identifier for each meeting client in a conference. This is necessary since the meeting client does not actually register with the server and therefore cannot obtain a genuine GRUU from the server for use in its SIP Contact header.  The client uses the GRUU of the Media Relay Authentication Server (MRAS) application (collocated with the A/V Conferencing Server) to send requests to the MRAS server, without necessarily having to know the FQDN of the server or be able to directly connect to the MRAS server. The client learns the MRAS applications GRUU through in-band provisioning. (The A/V Conferencing Server will use the MRAS application GRUU that is configured in WMI.)  Enterprise Voice endpoints send their Quality of Service (QoS) metric reports to a GRUU, which identifies the metrics collection point. (The Mediation Server and A/V Conferencing Server will use the collection point GRUU configured in WMI.) 164  The voicemail server (generally Exchange Unified Messaging) for a given user will be identified by a GRUU. The client will learn this GRUU through in-band provisioning (for itself) and through presence (for someone else). An application running on the server, ExUM Routing, resolves the GRUU to a specific Exchange Unified Messaging server that handles user voice mailboxes. An application can be written that will resolve the GRUU for nonExchange voice mail systems.  Pools use GRUU to address other pools for batched subscriptions.  The Mediation Server uses GRUU to identify different outbound gateways that are connected to the Mediation Server. This allows Office Communications Server to send messages to a single FQDN/port on the Mediation Server and have the messages routed correctly to the proper outbound IP-PSTN gateway. (This GRUU is not exposed in any way to the client; it is used only for server-to-server communications.) During conference creation, the client addresses the Focus Factory by using a GRUU that is composed in part by the meeting organizers SIP URI. This Focus Factory GRUU is sent to the client through in-band provisioning. User Replicator Drilldown User Replicator uses the Lightweight Directory Access Protocol (LDAP) application programming interface (API) to get information from Active Directory. User Replicator performs searches for user data in Active Directory by using Active Directory directory synchronization (DirSync) control, an LDAP server extension that enables User Replicator to track changes to user, contact, and group objects in Active Directory as the changes are made. User Replicator is a read-only component. It does not write data to Active Directory. There can only be one instance of User Replicator running in an Enterprise pool at any given time. Any errors that User Replicator encounters are logged as events on the Front End Server that is running User Replicator at the time the error occurs. In the event that the Front End Server on which User Replicator is running becomes unavailable, SQL Server dynamically assigns the task of running User Replicator to the next available Front End Server. To keep the presence store synchronized with user, contact, and group objects in Active Directory, User Replicator gives Active Directory a list of attributes about which it wants to be notified. The first time that User Replicator requests attribute changes from Active Directory, User Replicator performs an "initial cycle" during which time it synchronizes all user, contact, and group objects. Subsequently, after the initial cycle is complete, User Replicator requests only new changes from Active Directory every one minute. After User Replicator obtains attribute values that have changed from Active Directory, it sends those values to the SQL database for storage. The DirSync API gives User Replicator a cookie which identifies a point in Active Directory's change list. When User Replicator gives a cookie to DirSync, it gets every change after the point identified by the cookie. Therefore, the only state that User Replicator stores across synchronization is the cookie. The following lists include attributes that User Replicator monitors for change in Active Directory. (User Replicator also monitors all Address Book Server attributes in Active Directory.) When there is a change in the attribute, User Replicator acts accordingly. Some of the attribute values 165 are copied from Active Directory to the SQL store without modification. Other attribute values are processed by User Replicator and then copied to the SQL store. Office Communications Server specific attributes that User Replicator monitors include the following:  msRTCSIP-PrimaryUserAddress  msRTCSIP-PrimaryHomeServer  msRTCSIP-UserEnabled  msRTCSIP-OriginatorSid  msRTCSIP-FederationEnabled  msRTCSIP-InternetAccessEnabled  msRTCSIP-ArchivingEnabled  msRTCSIP-OptionFlags  msRTCSIP-Line  msRTCSIP-LineServer  msRTCSIP-UserLocationProfile  msRTCSIP-UserPolicy  msRTCSIP-ApplicationDestination  msRTCSIP-SourceObjectType  msDS-SourceObjectDN Attributes that are not specific to Office Communications Server that User Replicator monitors include the following:  objectClass  objectSid  isDeleted  displayName  mail  telephoneNumber  proxyAddresses  otherIpPhone  facsimileTelephoneNumber  streetAddress  l  st  c  postalCode  wWWHomePage 166 Archiving and Monitoring Drilldown This section gives a detailed description of archiving and monitoring in Office Communications Server 2007 R2. In This Section  Archiving and Monitoring Servers  Archiving Database Schema  CDR Database Schema  QoE Database Schema  Message Queuing Architecture and Configuration for Archiving  Message Stamping  Creating a Third-Party QoE Solution Archiving and Monitoring Servers Office Communications Server 2007 R2 separates the Archiving and Monitoring roles. Archiving Server The Archiving Server can archive all instant messaging (IM) conversations for all users or for individual users that you specify. Messages from each Office Communications Server configured for archiving are sent over the Windows Server Message Queuing (also known as MSMQ) service to the Archiving Server, which uses a Microsoft SQL Server database to store archived information. Although the archiving and call detail recording (CDR) agent is automatically installed on Front End Servers as part of the core Office Communications Server process, to archive IM traffic and call data you must configure the archiving and CDR agent and install the Archiving Server, to which the archiving and CDR agent connects. The Archiving Server consists of the following three components:  Destination queue, which is managed by Message Queuing.  Archiving Service component.  Archiving back-end database. The Archiving Service component can reside on the same computer as the archiving database or it can connect to a database on a different computer. Monitoring Server The Monitoring Server consists of the following three components:  Destination queue, which is managed by Message Queuing.  CDR and Quality of Experience (QoE) service components. 167  The back-end databases, which consist of separate CDR and QoE databases that run in the same SQL Server instance. Additionally, you can install SQL Server Reporting Services and the Monitoring Server Report Pack to view the reports that are included with Monitoring Server. And if you use System Center Operations Manager, you can configure alerts based on Monitoring Server data, to employ near real-time monitoring of media quality health state for network locations, Mediation Servers, and conferencing servers. Archiving Database Schema This section describes the Archiving Server database schema for Office Communications Server 2007 R2. The schema is subject to change in future releases. List of Tables The database schema consists of the following tables. Supporting Tables Table Description ClientVersions Stores the clients (both client type and version number) of each client involved in a call with information captured in this database. Computers Stores the name of each computer that hosts a Front End Server. ContentTypes Stores the IM content types used in sessions captured in this database. Dialogs Stores information about the DialogID for each peer-to-peer session in the database. Pools Stores the names of pool on which IM messages are captured. Users Stores the user URIs of users who have participated in sessions recorded or archived in this database. Tables for Messages in IM Conferences Table Description Conferences Stores information about all conferences that 168 Table Description were archived or whose details were recorded, including ConferenceURI, and start and end time. ConferenceMessageRecipientList For each message sent in a conference, stores a list of recipients. ConferenceMessages Archives the content of all the messages sent in a conference. Tables for Peer-to-Peer IM Archiving Table Description SessionDetails Stores information about every peer-to-peer session, including start and end time, user ID, response code, and message count for each user. Messages Archives the content of all the messages sent in one-on-one IM sessions. The tables in the following list are used internally by Office Communications Server (their details are not described in this document). Tables for Internal Use by Office Communications Server Table Description DbConfigDateTime For internal use only. DbConfigInt For internal use only. DbErrorMessage For internal use only. Table Details This section details the columns in each of the Archiving database schema tables. ClientVersions Table The ClientVersions table is a supporting table that stores a list of the various client types and versions that have participated in sessions recorded in the database. Each record in the table represents one client version. 169 Column Data Type Key/Index Details VersionId int Primary Unique number identifying this client type and version. Version nvarchar(256) Version name. Computers Table The Computers table is a supporting table that stores information about the various Front End Servers. Each record in the table represents one Front End Server Column Data Type Key/Index Details ComputerId int Primary Unique number identifying this Front End Server. Computer nvarchar(16) Front End Server host name. ContentTypes Table The ContentTypes table is a supporting table that stores information about the various types of IM content. Column Data Type Key/Index Details ContentTypeId int Primary Unique number identifying this IM content type. ContentType nvarchar(256) Content type name (for example, text/plain, text/rtf) or a MIME type. Dialogs Table The Dialogs table is a supporting table that stores the information about DialogIds for peer-topeer sessions. 170 Column Data Type Key/Index Details DialogId int Primary Unique number identifying this SIP dialog instance. ExternalChecksum Int Checksum of the ExternalId. This field is used to increase the speed of database searches. ExternalId varbinary(775) SIP dialog Id, stored as a binary. The format of the binary is: dialog;from-tag;to-tag This data can be converted to text format by using: cast(cast(ExternalId as varbinary(max)) as varchar(max)) Pools Table The Pools table is a supporting table that stores information about the various Pools. Each record in the table represents one Pool. Column Data Type Key/Index Details PoolId int Primary Unique number identifying this Pool. PoolFQDN nvarchar(256) Pool FQDN Users Table The Users table is a supporting table; each record in the table stores information about one user involved in calls or sessions that have records in the database. Column Data Type Key/Index Details UserId int Primary Unique number identifying this user. UserUri nvarchar(450) 171 Conferences Table Each record in this table contains call details about one conference. Column Data Type Key/Index Details ConferenceUri nvarchar(450) Checksum Int Checksum of ConferenceUri; used to increases the speed of database searches. ConfInstance Int Useful for recurring conferences; each instance of a recurring conference has the same ConferenceUri, but will have a different ConfInstance. SessionIdTime datetime Primary Time that the conference request was captured by the Archiving agent. Used only as a primary key to uniquely identify a session. SessionIdSeq int Primary ID number to identify the session. Used in conjunction with SessionIDTime to uniquely identify a session. * ConferenceStartTime datetime ConferenceEndTime datetime PoolId int Foreign Unique number indentifying the pool on which the message is captured, reference to Pools table * For most sessions, SessionIdSeq will have the value of 1. If two sessions start at exactly the same time, the SessionIdSeq for one will be 1, and for the other will be 2, and so on. 172 ConferenceMessageRecipientList Table Each record in this table represents one combination of IM conference message and recipient. A message that is sent to multiple recipients generates one record for each recipient. Column Data Type Key/Index Details MessageId int Primary Unique number identifying this message in an IM conference. SessionIdTime datetime Primary, Foreign Time that the conference request was captured by the Archiving agent. SessionIdSeq int Primary, Foreign ID number to identify the session. Used in conjunction with SessionIDTime to uniquely identify a session. UserId Int Primary, Foreign Unique number identifying this user, referenced from the Users table. Date datetime Message captured time. ConferenceMessages Table This table archives all messages sent in IM Conferences. Each record represents one message. Column Data Type Key/Index Details MessageId uniqueidentifier Primary GUID identifying this message. SessionIdTime datetime Primary, Foreign Time of session request; used in conjunction with SessionIDSeq to uniquely identify a session. Referenced from the Conferences table. SessionIdSeq int Primary, Foreign ID number to identify 173 Column Data Type Key/Index Details the session. Used in conjunction with SessionIDTime to uniquely identify a session. Referenced from the Conferences table. Date datetime FromId int Foreign UserId of the message sender, referenced from the Users table. ContentTypeId Int Foreign IM content type of this message. Referenced from the ContentTypes table. ComputerId int Foreign Id of the Front End Server used for this message. Referenced from the Computers table. Body ntext Content of the message body. Reserved1 tinyint Reserved for Microsoft use. Reserved2 tinyint Reserved for Microsoft use. SessionDetails Table Each record represents one peer-to-peer session, which could be a VoIP-VoIP phone call, 2party IM session, or other type of session. To find the modalities used during a session, you must do a table join with the Media table. Session type is not stored in the SessionDetails table. Column Data Type Key/Index Details SessionIdTime datetime Primary Time of session request; used in conjunction with SessionIDSeq to 174 Column Data Type Key/Index Details uniquely identify a session. SessionIdSeq int Primary ID number to identify the session. Used in conjunction with SessionIDTime to uniquely identify a session. DialogId Int Foreign SIP dialog ID, referenced from the Dialogs table. User1Id Int Foreign Id of one user in the session, referenced from the Users table. User2Id int Foreign Id of the other user in the session, referenced from the Users table. SessionStartedById int Foreign Id of the user who started the session, referenced from the Users table. ComputerId Int Foreign Id of the Front End Server used for this session. PoolId Int Foreign Id of the Pool in which the session was captured. User1ClientVerId Int Foreign Client version used by User1, referenced from the ClientVersions table. User2ClientVerId int Foreign Client version used by User2, referenced from the ClientVersions table. InviteTime datetime ResponseTime datetime ResponseCode Int SIP response code to 175 Column Data Type Key/Index Details the session invitation. SessionEndTime datetime * For most sessions, SessionIdSeq will have the value of 1. If multiple sessions start at exactly the same time, the SessionIdSeq for one will be 1, for another will be 2, and so on. Messages Table This table archives all messages sent during one-to-one IM sessions. Each record represents one message. Column Data Type Key/Index Details MessageIdTime datetime Primary Time the message was sent. MessageIdSeq int Primary ID number to identify the message. Used in conjunction with MessageIdTime to uniquely identify a message. * SessionIdTime datetime Primary, Foreign Time of session request; used in conjunction with SessionIDSeq to uniquely identify a session. SessionIdSeq int Primary, Foreign ID number to identify the session. Used in conjunction with SessionIDTime to uniquely identify a session. FromId int Foreign UserId of the user sending the message, referenced from the Users table. Told int Foreign UserId of the user receiving the message, referenced from the Users table. 176 Column Data Type Key/Index Details ContentTypeId int Foreign Unique number identifying this IM content type, referenced from the ContentTypes table. ComputerId int Foreign Id of the Front End Server used for this message, referenced from the Computers table. Body ntext Content of the message body. Toast bit TRUE is this message was a toast message. ContextNote Bit TRUE is this message was a context note. Reserved1 tinyint Reserved for Microsoft use. Reserved2 tinyint Reserved for Microsoft use. * For most sessions, MessageIdSeq will have the value of 1. If multiple messages are sent at exactly the same time, the MessageIdSeq for one will be 1, for another will be 2, and so on. CDR Database Schema This section outlines the schema for the CDR database. List of Tables The database schema consists of the following tables. Static Tables Table Description MediaList Stores the list of media types that can generate entries in the database (for example, IM, audio, video, and file transfer). Roles Stores the list of possible conference roles (for 177 Table Description example, attendee and presenter). UserAuthTypes Stores the list of possible user authentication type (for example, enterprise, federated, PIC and anonymous). Supporting Tables Table Description ClientVersions Stores the clients (both client type and version number) of each client involved in a call with information captured in this database. Computers Stores the name of each computer that hosts a Front End Server. Dialogs Stores information about the DialogID for each peer-to-peer session in the database. Gateways Stores a list of Mediation Servers that are used for VoIP calls. Pools Stores the names of pool on which IM messages are captured. Phones Stores all the phone numbers used in VoIP calls that were archived or whose call details were recorded. Mcus Stores information about the various conferencing servers and their URIs. Users Stores the user URIs of users who have participated in sessions recorded or archived in this database. Tables Specific to Conference CDR Records Table Description Conferences Stores information about all conferences that were archived or whose details were recorded, including ConferenceURI, and start and end 178 Table Description time. FocusJoinsAndLeaves Stores information about conference joins and leaves, including users’ role and client version. McuJoinsAndLeaves Stores information about conferencing servers that are involved in a conference, and the user join and leave times. Tables for Messages in IM Conferences Table Description ConferenceMessageCount For each IM conference, stores the number of messages that were sent by each user. Tables for Peer-to-Peer Sessions Table Description SessionDetails Stores information about every peer-to-peer session, including start and end time, user ID, response code, and message count for each user. FileTransfers Stores information about file transfer sessions, including file name and result (accepted, rejected, or cancelled). Media Stores information about the different media types involved in peer-to-peer sessions. Table for VoIP Call Details Table Description VoIPDetails For each two-party VoIP/PSTN call, stores information about the call (for example, the phone ID of VoIP phone, gateway used, and which party disconnected). Refers to the SessionDetails table for call start/end times and 179 Table Description response code. Note: If one party on a call is a VoIP user or if a Mediation Server was involved in the call, a record will be created in this table. Information about VoIP/VoIP calls not involving a PSTN phone is captured in the SessionDetails table. Tables for Troubleshooting Table Description Application Stores information about various processes within Office Communications Server that are involved in routing and connections. ErrorDef Stores information about types of errors and their definitions. ErrorReport Stores information about errors that have occurred. ProgressReport Stores information about the progress reports of various steps involved in Office Communications Server processes. The tables in the following list are used internally by Office Communications Server; their details are not described in this document. Tables for Internal Use by Office Communications Server Table Description DbConfigDateTime For internal use only. DbConfigInt For internal use only. DbErrorMessage For internal use only. Table Details This section details the columns in each of the CDR database schema tables. 180 MediaList Table The MediaList table is a static table that stores the list of various media types. Column MediaId Media Data Type tinyint nvarchar(256) Key/Index Primary Static Values 1 IM 2 File Transfer 3 Remote Assistance 4 Application Sharing 5 Audio 6 Video 7 App Invite 8 Meeting 9 Phone Roles Table The Roles table is a static table that stores the list of possible conference roles, such as attendee and presenter. Column RoleId Role Data Type tinyint nvarchar(256) Key/Index Primary Static Values 0 Unknown 1 Presenter 2 Attendee UserAuthTypes Table The UserAuthTypes table is a static table that stores the list of possible user authentication types, such as enterprise, federated, Public IM Connectivity (PIC), and anonymous. 181 Column AuthTypeId AuthType Data Type int nvarchar(256) Key/Index Primary Static Values 0 Unknown 1 Enterprise 2 Federated 3 Anonymous 4 Public IM Connectivity ClientVersions Table The ClientVersions table is a supporting table that stores a list of the various client types and versions that have participated in sessions recorded in the database. Each record in the table represents one client version. Column Data Type Key/Index Details VersionId int Primary Unique number identifying this client type and version. Version nvarchar(256) Version name. Computers Table The Computers table is a supporting table that stores information about the various Front End Servers. Each record in the table represents one Front End Server. Column Data Type Key/Index Details ComputerId int Primary Unique number identifying this Front End Server. Computer nvarchar(16) Front End Server host name. 182 Pools Table The Pools table is a supporting table that stores information about the various Pools. Each record in the table represents one Pool Column Data Type Key/Index Details PoolId int Primary Unique number identifying this Pool. PoolFQDN nvarchar(256) Pool FQDN. Dialogs Table The Dialogs table is a supporting table that stores the information about DialogIds for peer-topeer sessions. Column Data Type Key/Index Details DialogId int Primary Unique number identifying this SIP dialog instance. ExternalChecksum Int Checksum of the ExternalId. This field is used to increase the speed of database searches. ExternalId varbinary(775) SIP dialog Id, stored as a binary. The format of the binary is: dialog;from-tag;to-tag This data can be converted to text format by using: cast(cast(ExternalId as varbinary(max)) as varchar(max)) Gateways Table The Gateways table is a supporting table. Each record stores information about one Mediation Server that is involved in calls that have records in the database. Column Data Type Key/Index Details GatewayId int Primary Unique number identifying this 183 Column Data Type Key/Index Details Mediation Server. Gateway nvarchar(256) Mediation Server name. Mcus Table The Mcus table is a supporting table; each record stores the information about one conferencing server. These can include the IM Conferencing Server and the Telephony Conferencing Server (which run as processes on Front End Servers), and the Web Conferencing Server and A/V Conferencing Server. Column Data Type Key/Index Details McuId int Primary Unique number identifying this MCU server. McuUri nvarchar(450) McuType nvarchar(256) MCU type (for example, chat (for IMs) or audio-video). Users Table The Users table is a supporting table; each record in the table stores information about one user involved in calls or sessions that have records in the database. Column Data Type Key/Index Details UserId int Primary Unique number identifying this user. UserUri nvarchar(450) AuthTypeId Int Foreign Unique number identifying this user’s authentication type. Reference to UserAuthTypes table. 184 Phones Table The Phones table is a supporting table; each record in the table stores information about one phone number involved in VoIP calls that have records in the database. Column Data Type Key/Index Details PhoneId int Primary Unique number identifying this phone. PhoneUri nvarchar(450) Conferences Table Each record in this table contains call details about one conference. Column Data Type Key/Index Details ConferenceUri nvarchar(450) Checksum Int Checksum of ConferenceURi; used to increases the speed of database searches. ConfInstance Int Useful for recurring conferences; each instance of a recurring conference has the same ConferenceUri, but will have a different ConfInstance. SessionIdTime datetime Primary Time that the conference request was captured by the CDR agent. Used only as a primary key to uniquely identify a session. SessionIdSeq int Primary ID number to identify the session. Used in conjunction with SessionIDTime to uniquely identify a session. * 185 Column Data Type Key/Index Details ConferenceStartTime datetime ConferenceEndTime datetime PoolId Int Foreign ID number to identify the pool in which the conference was captured. Reference to Pools table. OrganizerId Int Foreign ID number to identify the organizer URI of this conference. Reference to Users table. * For most sessions, SessionIdSeq will have the value of 1. If two sessions start at exactly the same time, the SessionIdSeq for one will be 1, and for the other will be 2, and so on. FocusJoinsAndLeaves Table Each record in this table contains the CDR information about one user’s join and leave information for one conference. Each conference is represented in this table by one record for each time a user joins and leaves the conference. Column Data Type Key/Index Details UserId int Primary, Foreign Unique number identifying this user, referenced from the Users table. UserInstance Int Primary If a user is logged on at multiple computers or devices at once, UserInstance is used to uniquely identify the user/device combination. IsUserInternal Bit Whether the user logged on from internal or not. UserRole Int This user’s role in the conference. SessionIdTime datetime Primary, Foreign Time of session request; 186 Column Data Type Key/Index Details used in conjunction with SessionIDSeq to uniquely identify a session. Referenced from the Conferences table. SessionIdSeq int UserJoinTime datetime UserLeaveTime datetime ClientVerId int Primary, Foreign ID number to identify the session. Used in conjunction with SessionIDTime to uniquely identify a session. Referenced from the Conferences table. Foreign Version of the user’s client software, referenced from the ClientVersions table. McuJoinsAndLeaves Table Each record in this table contains call details about one combination of a user join or leave and MCU device. For example, if a user joins a conference that includes Web conferencing and audio/video elements, one record would be created for that user’s Web conferencing join, and another record would be created for the user’s audio/video join. Column Data Type Key/Index Details UserId int Primary, Foreign Unique number identifying this user, referenced from the Users table. UserInstance Int Primary If a user is logged on at multiple computers or devices at once, UserInstance uniquely identifies the user/device 187 Column Data Type Key/Index Details combination. IsFromPstn Bit Whether the user is joining from PSTN or not. McuId Int Primary, Foreign Unique number identifying this MCU device, referenced from the Mcus table. SessionIdTime datetime Primary, Foreign Time of session request; used in conjunction with SessionIDSeq to uniquely identify a session. Referenced from the Conferences table. SessionIdSeq int Primary, Foreign ID number to identify the session. Used in conjunction with SessionIDTime to uniquely identify a session. Referenced from the Conferences table. UserJoinTime datetime UserLeaveTime datetime ConferenceMessageCount Table Each record in this table represents one user in one IM conference and includes the number of messages sent by that user. Each conference is represented by multiple records in this table; one record for each user. Column Data Type Key/Index Details SessionIdTime datetime Primary, Foreign Time of session request; used in conjunction with SessionIDSeq to uniquely identify a session. Referenced 188 Column Data Type Key/Index Details from the Conferences table. SessionIdSeq int Primary, Foreign ID number to identify the session. Used in conjunction with SessionIDTime to uniquely identify a session. Referenced from the Conferences table. UserId int Primary, Foreign Unique number identifying this user, referenced from the Users table. MessageCount smallint The number of messages sent by this user during this conference. SessionDetails Table Each record represents one peer-to-peer session, which could be a VoIP-VoIP phone call, 2party IM session, or other type of session. To find the modalities used during a session, you must do a table join with the Media table. Session type is not stored in the SessionDetails table. Column Data Type Key/Index Details SessionIdTime datetime Primary Time of session request; used in conjunction with SessionIDSeq to uniquely identify a session. SessionIdSeq int Primary ID number to identify the session. Used in conjunction with SessionIDTime to uniquely identify a session. * 189 Column Data Type Key/Index Details DialogId Int Foreign SIP dialog ID, referenced from the Dialogs table. CorrelationId uniqueidentifier ReplaceDialogId Int Foreign ID number to identify the dialog which was replaced by current session. Reference to Dialogs table User1Id Int Foreign Id of one user in the session, referenced from the Users table. User2Id int Foreign Id of the other user in the session, referenced from the Users table. TargetUserId Int SessionStartedById int OnBehalfOfId Int ReferredById Int Foreign Id of the user by who the call is referred. ComputerId Int Foreign Id of the Front End Server used for this session. Foreign Id of the Pool in which the session was captured. PoolId A GUID to correlate multiple sessions. The original To user URI in SIP request. Reference to Users table. Foreign Id of the user who started the session, referenced from the Users table. Indicate the Id of the user of who the caller is on behalf. Reference Users table. 190 Column Data Type Key/Index Details User1ClientVerId Int Foreign Client version used by User1, referenced from the ClientVersions table. User2ClientVerId int Foreign Client version used by User2, referenced from the ClientVersions table. IsUser1Internal Bit Whether user1 is logged on from internal or not. IsUser2Internal Bit Whether user2 is logged on from internal or not. InviteTime datetime ResponseTime datetime ResponseCode Int SIP response code to the session invitation. DianosticId Int Diagnostic Id captured from SIP header. User1MessageCount Int Number of messages sent by User1 during the session. User2MessageCount Int Number of messages sent by User2 during the session. SessionEndTime datetime * For most sessions, SessionIdSeq will have the value of 1. If multiple sessions start at exactly the same time, the SessionIdSeq for one will be 1, for another will be 2, and so on. FileTransfers Table Each record represents one file transfer session. 191 Column Data Type Key/Index Details SessionIdTime datetime Primary, Foreign Time of session request; used in conjunction with SessionIDSeq to uniquely identify a session. SessionIdSeq int Primary, Foreign ID number to identify the session. Used in conjunction with SessionIDTime to uniquely identify a session. FileName nvarchar(256) Cookie int Primary Random number between 1 and 4,294,967,295 (2^32 1)). Used to identify every follow-up message as being associated with this one. Accept bit Can be TRUE or NULL. If TRUE, then Reject and Cancel will be NULL. Reject bit Can be TRUE or NULL. If TRUE, then Accept and Cancel will be NULL. Cancel bit Can be TRUE or NULL. If TRUE, then Accept and Reject will be NULL. bit 192 Media Table Each record represents one media type used in a peer-to-peer session. One session would be represented by multiple records in the table, if more than one media type is used. Column Data Type Key/Index Details SessionIdTime datetime Primary, Foreign Time of session request; used in conjunction with SessionIDSeq to uniquely identify a session. SessionIdSeq int Primary, Foreign ID number to identify the session. Used in conjunction with SessionIDTime to uniquely identify a session. MediaId tinyint Primary, Foreign Unique number identifying this media type, referenced from the MediaList table. StartTime datetime Primary EndTime datetime VoipDetails Table Each record represents one two-party call in which at least one user is a VoIP user. Column Data Type Key/Index Details SessionIdTime datetime Primary, Foreign Time of session request; used in conjunction with SessionIDSeq to uniquely identify a session. SessionIdSeq int Primary, Foreign ID number to identify the session. Used in conjunction with SessionIDTime to uniquely identify a 193 Column Data Type Key/Index Details session. FromNumberId int Foreign PhoneId of the caller, referenced from the Phones table. If NULL, the caller was a PSTN user. ConnectedNumberId int Foreign PhoneId of the call receiver, referenced from the Phones table. If NULL, the receiver was a PSTN user. FromGatewayId int Foreign Mediation Server the call is coming from, referenced from the Gateways table. ToGatewayId Int Foreign Mediation Server called is going to, reference to Gateways table. DisconnectedbyURIId int Foreign URI of the user who disconnected the call, if the user has a URI. Referenced from the Users table. DisconnectedbyPhoneId int Foreign ID of the phone that disconnected the call if the call was disconnected from a phone. Referenced from the Phones table. Application Table This table stores information about the various processes within Office Communications Server involved in routing and connections. Column Data Type Key/Index Details ApplicationId int Primary Unique number identifying this 194 Column Data Type Key/Index Details application. Name nvarchar(257) ErrorDef Table This table stores information about each type of error that may occur. Each record is one type of error. ErrorDef Table Column Data Type Key/Index Details ErrorId int Primary Unique ID number identifying this type of error. ResponseCode int Standard SIP response code associated with this error. MsDiagId int Microsoft Diagnostic ID. RequestType varbinary(33) Type of request that failed. This data can be converted to text format by using: cast(cast(RequestType as varbinary(max)) as varchar(max)) ContentType varbinary(257) Content type of the request that failed. This data can be converted to text format using: cast(cast(ContentType as varbinary(max)) as varchar(max)) ErrorReport Table This table stores information about errors that have occurred. Each record is one error occurrence. Column Data Type Key/Index Details ErrorTime datetime Primary Date and time the error occurred. 195 Column Data Type Key/Index Details ErrorId int Primary, Foreign Unique ID of the error type, referenced from the ErrorDef table. FromUserId int Foreign User who originated the request that caused the error. Referenced from the Users table. ToUserId int Foreign Destination user for the request that caused the error. Referenced from the Users table. DialogId int Foreign Referenced from the Dialogs table. MsDiagHeader image More information about the error. This data can be converted to text format using: cast(cast(Detail as varbinary(max)) as varchar(max)) ProgressReport Table Progress reports are based on data uploaded by the client to the database after a call or session is completed. Progress reports will be written only for calls and sessions that Office Communications Server determines might be useful for diagnostic purposes. The ErrorTime and ErrorId fields do not necessarily refer to errors but to messages that indicate the status of calls or messages. Column Data Type Key/Index Details ErrorTime datetime Primary, Foreign Date and time of the progress report. ErrorId int Primary, Foreign Unique ID of the error type, referenced from the ErrorDef table. ProgressReportSeq int Primary ID number to identify the progress report. Used in 196 Column Data Type Key/Index Details conjunction with ErrorTime to uniquely identify a session. ApplicationId int Detail image Foreign The Office Communications Server process that the report is about. Referenced from the Application table. Progress report details, stored in binary format to save space. This data can be converted to text format using: cast(cast(Detail as varbinary(max)) as varchar(max)) bit Sample Database Queries This section contains sample queries for the CDR database. The CDR Reporter tool in the Office Communications Server 2007 Resource Kit has more. To find the total number of PSTN to UC Calls: Select Count(*) as 'Number Of PSTN to UC Calls' From VoipDetails as voipd Join SessionDetails as sd on (voipd.SessionIdTime = sd.SessionIdTime and voipd.SessionIdSeq = sd.SessionIdSeq and sd.User1Id is null) and FromNumberId in (SELECT PhoneId from Phones) and GatewayId is not null To find the total numbers of conferences that used Meeting Console: SELECT count(distinct(c.ConferenceUri)) as DataMCU Conferences from mj inner join as m on (m.McuId = mj.McuId) inner join as as c on (c.SessionIdTime = mj.SessionIdTime and c.SessionIdSeq = mj.SessionIdSeq) where m.McuType=meeting RequestType = PKCS10 To find the total number of redirected calls: SELECT count(*) as Number of Redirected Calls from VoipDetails where ReferredById is not null 197 QoE Database Schema This documents the schema of the QoE database in Office Communications Server 2007 R2. In This Section  List of Tables  Table Details  Sample Database Queries List of Tables The database schema consists of the following tables. Supporting Tables Table Description UserAgent Table Stores SIP User Agent (UA) strings and UA types used in audio and video sessions. User Table Stores user, conference, and phone URIs used in audio and video sessions. Endpoint Table Stores FQDN computer names of endpoints participating in audio and video sessions. Pool Table Stores the names of pools to which metrics data belongs. Device Table Stores capture devices and render devices which are used in an audio/video calls. Conference Table Stores Conference URIs for conference scenarios, or DialogID for other scenarios. SessionCorrelation Table Stores CorrelationID for PSTN calls. Tables for metrics data Table Description Session Table Stores overall information about an audio or audio/video session. A session is defined as an audio or video SIP dialog between two endpoints. MediaLine Table Stores information about each media line in a session. A media line is a collection of one or more audio and video streams. Typically, a 198 Table Description single media line will have two streams, either audio or video. AudioStream Table Stores audio media quality metrics for each audio stream in the media line. VideoStream Table Stores video media quality metrics for each audio stream in the media line. Tables for Internal Use by Monitoring Server Table Description DbConfigDateTime For internal use only. DbConfigInt For internal use only. DbErrorMessage For internal use only. MSFT_SIPQMSDBConfigSetting For internal use only. MSFT_SIPQMSDynamicSubnet For internal use only. MSFT_SIPQMSMonitoredAVMCU For internal use only. MSFT_SIPQMSMonitoredMediationServer For internal use only. MSFT_SIPQMSSingleMaskSubnet For internal use only. MSFT_SIPQMSStaticLocation For internal use only. MSFT_SIPQMSStaticSubnet For internal use only. Table Details These sections detail the columns in each of the QoE database schema tables.  UserAgent Table  User Table  Endpoint Table  Pool Table  Device Table  Conference Table  SessionCorrelation Table  Session Table  MediaLine Table 199  AudioStream Table  VideoStream Table UserAgent Table The UserAgent table is a supporting table that stores a list of the various User Agents that have participated in sessions recorded in the database. Each record in the table represents one User Agent Column Data Type Key/Index Details UserAgentKey int Primary Unique number identifying this user agent. UserAgent nvarchar(256) Unique User Agent string. UAType smallint 1 is Mediation Server. 2 is A/V Conferencing Server. 4 is Office Communicator. 8 is IP Phone. 16 is Live Meeting Console. 32 is Deployment Validation Tool (DVT). 64 is Office Communicator on Macintosh computers. 128 is Office Communications Server R2 Attendant. 256 is Conferencing Announcement Service. 512 is Conferencing Auto Attendant. 1024 is Response Group Service. 2048 is Outside Voice Control. NextUpdateTS Datetime For internal use only. 200 User Table The User table is a supporting table that stores a list of the various users who have participated in sessions recorded in the database. Each record in the table represents one user. Column Data Type Key/Index Details UserKey int Primary Unique number identifying this user. URI nvarchar(450) Unique URI string URIType int 1 is unknown URI type, 2 is user URI, 4 is conference URI, and 8 is phone URI. NextUpdateTS Datetime For internal use only. Endpoint Table The Endpoint table is a supporting table that stores information about the endpoints that have participated in sessions recorded in the database. Each record in the table represents one endpoint Column Data Type Key/Index Details EndpointKey int Primary Unique number identifying this endpoint. Name nvarchar(256) Unique Endpoint name. NextUpdateTS Datetime For internal use only. Pool Table The Pool table is a supporting table that stores information about the various Enterprise pools. Each record in the table represents one pool Column Data Type Key/Index Details PoolKey int Primary Unique number identifying this pool. PoolName nvarchar(256) Pool FQDN NextUpdateTS datetime For internal use only. 201 Device Table The Device table is a supporting table that stores information about the various capture or render devices. Each record in the table represents one device. Column Data Type Key/Index Details DeviceKey Int Primary Unique number identifying this device DeviceName nvarchar(256) DeviceName + DeviceType is unique Device name. DeviceType Bit DeviceName + DeviceType is unique DeviceType, 1 is a capture device, 0 is a render device. NextUpdateTS Datetime For internal use only. Conference Table The Conference table is a supporting table. Each record represents one conference or peer-topeer session. Column Data Type Key/Index Details ConferenceKey Int Primary Unique number identifying this Conference record. ConfURI nvarchar(450) unique Conference URI is this is a conference, or DialogID if this is a peer-to-peer session. NextUpdateTS Datetime For internal use only. SessionCorrelation Table The SessionCorrelation table is a supporting table; each record represents one CorrelationID which is used to correlate multiple sessions. Column Data Type Key/Index Details CorrelationKey int Primary Unique number identifying this conferencing server. CorrelationID nvarchar(256) unique Sessions that are 202 Column Data Type Key/Index Details correlated will have the same CorrelationID. NextUpdateTS Datetime For internal use only. Session Table Each record represents one session which involves audio or audio/video; it contains overall information about the session. A session is defined as an audio or video SIP dialog between two endpoints. Column Data Type Key/Index Details ConferenceDateTime Datetime Primary Time when the QoE agent receives the first report from either caller or callee; used in conjunction with SessionSeq to uniquely identify a session. SessionSeq Int Primary Sequence number to differentiate sessions when they have the same ConferenceDateTime. SessionID varchar(256) Checksum Int Index Checksum of SessionID, for internal use only. ConferenceKey Int Foreign Conference key, referenced from the Conference Table. CorrelationKey Int Foreign Correlation key, referenced from the SessionCorrelation Table. DialogCategory bit Dialog category; 0 is OCS to Mediation Server Leg, 1 is Mediation Server to PSTN gateway leg. StartTime Datetime Call start time. EndTime datetime Call end time. CallerPool Int DialogID which is globally unique. Foreign The pool of the caller, 203 Column Data Type Key/Index Details referenced from the Pool Table. CalleePool Int Foreign The pool of the call receiver, referenced from the Pool Table. CallerPAI Int Foreign SIP URI in the SIP passerted identity (PAI) from the calling endpoint, referenced from the User Table. CalleePAI int Foreign SIP URI in the SIP passerted identity (PAI) of the receiving endpoint, referenced from the User Table. CallerURI Int Foreign Caller’s URI, referenced from the User Table. CalleeURI int Foreign Call receiver’s URI, referenced from the User Table. CallerEndpoint Int Foreign Caller’s endpoint, referenced from the Endpoint Table. CalleeEndpoint int Foreign Call receiver’s endpoint, referenced from the Endpoint Table. CallerUserAgent Bit Foreign Caller’s user agent, referenced from the UserAgent Table. CalleeUserAgent Bit Foreign Call receiver’s user agent, referenced from the UserAgent Table. MediaLine Table Each record represents one media line. (One audio session usually contains one audio media line. One audio/video session usually contains one audio media line and one video media line, 204 although the session might contains two video media lines if the Microsoft RoundTable conferencing device is used) Column Data Type Key/Index Details ConferenceDateTime Datetime Primary Referenced from Session Table. SessionSeq Int Primary Referenced from Session Table. MediaLineLabel tinyint Primary 0 is main audio, 1 is main video, and 2 is panoramic video. This label must be unique within a single session. ConnectivityIce tinyint Information about media path, such as direct or relayed. 1 is DIRECT 2 is RELAY 4 is HTTP 8 is FAILED CallerIceWarningFlags Int Information about ICE process described in bits flags. For more details, refer to the Quality of Experience Monitoring Server Protocol Specification, available for download. CalleeIceWarningFlags int Same as CallerIceWarningFlags, but on Callee side. For more details, refer to the Quality of Experience Monitoring Server Protocol Specification, available for download. Offerer bit Not used. Answerer bit Not used. 205 Column Data Type Key/Index Details Security Tinyint The security profile in use. 0 os NONE, 1 is SRTP, 2 is V1. Transport Tinyint 0 is UDP, 1 is TCP. CallerIPAddr Int IP Address of the caller. CallerPort Int Port used by the caller. CallerSubnetMask int The subnet mask of the caller. CallerInside bit 1 means caller is inside the enterprise network, 0 means the caller is outside the network. CallerRelayIPAddr int IP Address of the A/V Edge service used by the caller. CallerRelayPort Int Port used on the A/V Edge service by the caller. CallerRelaySubnetMask Int Subnet Mask of the A/V Edge service used by the caller. CallerRelayInside bit Not used. CallerCaptureDev int foreign Capture device used by the caller, referenced from the Device Table CallerRenderDev Int foreign Render device used by caller, referenced from Device table. CallerCaptureDevDriver varchar(256) Driver for the caller’s capture device. CallerRenderDevDriver varchar(256) Driver for the caller’s render device . CallerNetworkConnectionType tinyint The caller's network connection type; 0 is Wired, 1 is wireless. 206 Column Data Type Key/Index Details CallerVPN bit The Caller's link; 1 is virtual private network (VPN), 0 is non-VPN. CallerLinkSpeed decimal(18,0) The network link speed in bps for the caller's endpoint. CalleeIPAddr bit IP Address of the call receiver. CalleePort Bit Port used by the call receiver. CalleeSubnetMask bit Subnet Mask of the A/V Edge service used by the call receiver. CalleeInside Bit 1 means call receiver is inside the enterprise network, 0 means the call receiver is outside the network. CalleeRelayIPAddr Int IP Address of the A/V Edge service used by the call receiver. CalleeRelayPort Int Port used on the A/V Edge Service by the call receiver. CalleeRelaySubnetMask Int Subnet mask of the A/V Edge service used by the call receiver. CalleeRelayInside Bit Not used, CalleeCaptureDev Int foreign Capture device used by the call receiver, referenced from the Device Table. CalleeRenderDev Int foreign Render device used by the call receiver, referenced from the Device Table. 207 Column Data Type Key/Index Details CalleeCaptureDevDriver varchar(256) Driver for the the call receiver’s capture device. CalleeRenderDevDriver varchar(256) Driver for the the call receiver’s render device. CalleeNetworkConnectionType tinyint The call receiver's network connection type; 0 is Wired, 1 is wireless. CalleeVPN bit The call receiver’s link; 1 is virtual private network (VPN), 0 is non-VPN. CalleeLinkSpeed decimal(18,0) The network link speed in bps for the call receiver’s endpoint. ConversationalMOS decimal(3,2) Narrowband Conversational MOS of the audio sessions (based on both audio streams). ConversationalMOSAlg varchar(256) Not used. Caller Bit Indicate whether metrics from the caller were received; 1 is yes, 0 is no. Callee bit Indicate whether metrics from the call receiver were received; 1 is yes, 0 is no. AudioStream Table Each record represents one audio stream. One audio media line usually contains two audio streams. Column Data Type Key/Index Details ConferenceDateTime Datetime primary Referenced from the MediaLine Table. SessionSeq Int primary Referenced from the MediaLine Table. 208 Column Data Type Key/Index Details MediaLineLabel tinyint primary Referenced from the MediaLine Table. StreamID int primary Unique ID within a media line. JitterInterArrival Int Average Network jitter from Real Time Control Protocol (RTCP) statistics. JitterInterArrivalMax Int Maximum Network Jitter during the call. PacketLossRate decimal(5,4) Average packet loss rate during the call. PacketLossRateMax decimal(5,4) Maximum packet loss observed during the call. BurstDensity decimal(9,4) Average density of packet Loss during bursts of losses during the call. BurstDuration Int Average duration of packet loss during bursts of losses during the call. BurstGapDensity decimal(9,4) Average density of packet loss during gaps between bursts of packet loss. BurstGapDuration Int Average duration of gaps between bursts of packet loss. PacketUtilization Int Packet count for the audio stream. BandwidthEst Int Bandwidth estimates for the audio stream. DegradationAvg decimal(3,2) Network MOS Degradation for the 209 Column Data Type Key/Index Details whole call. Range is 0.0 to 5.0. This metric shows the amount the Network MOS was reduced because of jitter and packet loss. For acceptable quality it should less than 0.5. DegradationMax decimal(3,2) Maximum Network MOS degradation during the call. DegradationJitterAvg decimal(3,2) Network MOS degradation caused by Jitter. DegradationPacketLossAvg decimal(3,2) Network MOS degradation caused by packet loss. AudioPayloadDescription varchar(256) The audio codec used for the call. AudioPayloadType int Not used. AudioSampleRate int Sampling rate for the audio stream. InboundAudioSignalLevel * int Represents the PostAnalog Gain Control audio signal level. The unit for this metric is dBmo. For acceptable quality it should be at least 30 dBmo. This metric is not reported by the A/V Conferencing Server or IP phones. This is reported by the Mediation Server on approximately 2% of the calls on the Mediation Server to 210 Column Data Type Key/Index Details gateway leg. InboundAudioNoiseLevel * int Represents the PostAnalog Gain Control audio noise level. The unit for this metric is dBmo. For acceptable quality it should be less than 35 dBmo. This metric is not reported by the A/V Conferencing Server or IP phones. This is reported by the Mediation Server on approximately 2% of the calls on the Mediation Server to gateway leg. InboundAudioSignalEchoReturn* int Echo Return Loss Enhancement metric. The unit for this metric is dB. Lower values represent less echo. This metric is not reported by the A/V Conferencing Server or IP phones. This is reported by the Mediation Server on approximately 2% of the calls on the Mediation Server to gateway leg. OutboundAudioSignalLevel* int Represents the Post Analog Gain Control audio Signal level. The unit for this metric is dBmo. For acceptable quality it should be at least dBmo. This metric is not reported 211 Column Data Type Key/Index Details by the A/V Conferencing Server or IP phones. This is reported by the Mediation Server on approximately 2% of the calls on the Mediation Server to gateway leg. OutboundAudioNoiseLevel* int Represent the Post Analog Gain control audio noise level. The unit for this metric is dBmo. For acceptable quality it should be less than 35 dBmo. This metric is not reported by the A/V Conferencing Server or IP phones. This is reported by the Mediation Server on approximately 2% of the calls on the Mediation Server to gateway leg. OutboundAudioSignalEchoReturn* int Echo Return Loss Enhancement metric. The unit for this metric is dB. Lower values represent less echo. This metric is not reported by the A/V Conferencing Server or IP phones. This is reported by the Mediation Server on approximately 2% of the calls on the Mediation Server to gateway leg. 212 Column Data Type Key/Index Details AudioSpeakerFeedbackMicIn* int This is the microphone input level from the loudspeaker signal which comes from the far end. The unit is dBoV. For acceptable quality this value should be less than 20 dBoV. If this number is too high, it means that the near end microphone is getting too much feedback from the near end loudspeaker. Not reported by A/V Conferencing Servers, Mediation Servers, or IP phones. AudioSpeechLevelMicIn* int This is the speech level into the microphone at the near end. The unit is dBoV. For acceptable quality it should be between -18 dBoV and -35 dBoV, if greater than -18 dBoV, then signal clipping or echo is occurring when both parties talk. If it is less than -35 dBoV, then speech might be distorted. Not reported by A/V Conferencing Servers, Mediation Servers, or IP phones. AudioSpeechLevelPostProcess* int Overall average speech level sent to the far end (after signal processing) from the near end. The unit for 213 Column Data Type Key/Index Details this metric is dBoV. For acceptable quality it should be within [-30 to -18] dBoV. Not reported by A/V Conferencing Servers, Mediation Servers, or IP phones. AudioSignalLevelLoudSpeaker* int Speaker/Headphone input level (at the near end). The unit for this metric is dBoV. For acceptable quality it should range between [-35 to -15] dBoV. If too high there may be clipping. If too low then there might be low volume issues. Not reported by A/V Conferencing Servers, Mediation Servers, or IP phones. AudioBackGroundNoiseMicIn* int Background Noise Input to the microphone at the near end. The unit for this metric is dBoV. For acceptable quality the range should be less than -35 dBoV. If noise is too high, this indicates a bad device or bad device setup which is degrading audio quality. Not reported by A/V Conferencing Servers, Mediation Servers, or IP phones. 214 Column Data Type Key/Index Details AudioBackGroundNoiseSent* int Background noise left over after noise suppression. This is the noise sent to the far end. The unit for this is dBoV. For acceptable call quality this should be less than -45 dBoV. Not reported by A/V Conferencing Servers, Mediation Servers, or IP phones. AudioLocalSpeechToEcho* int This the ratio of speech to echo. The unit for this is dB. For acceptable quality it should be greater than 10 dB. If less than 10dB then speech level is too low compared to echo level, and distorted speech might occur. Not reported by A/V Conferencing Servers, Mediation Servers, or IP phones. AudioSpeakerGlitchRate int Average glitches per 5 minutes for the loudspeaker rendering. For good quality, this should be less than 1 per 5 minutes. Not reported by A/V Conferencing Servers, Mediation Servers, or IP phones. AudioMicGlitchRate int Average glitches per 5 minutes for the microphone capture. 215 Column Data Type Key/Index Details For good quality this should be less than 1 per 5 minutes. Not reported by A/V Conferencing Servers, Mediation Servers, or IP phones. AudioSpeakerClipRate int Clipping occurrences per 5 minutes for loudspeaker rendering. For good quality, this should be less than 1 per 5 minutes. Not reported by A/V Conferencing Servers, Mediation Servers, or IP phones. AudioMicClipRate int Clipping per 5 minutes for microphone capture. For good quality this should be less than 1 per 5 minutes. Not reported by A/V Conferencing Servers, Mediation Servers, or IP phones. AudioRxAGCSignalLevel* int Received signal level on the Mediation Server from the gateway; this applies only to the Mediation Server. The unit of this metric is dBoV. For good quality, the acceptable range should be [-30 to -18] dBoV. AudioRxAGCNoiseLevel* int Received Received signal level on the Mediation Server from 216 Column Data Type Key/Index Details the gateway; this applies only to the Mediation Server. The unit of this metric is dBoV. For good quality, the acceptable range should be less than -50 dBoV. RoundTrip int Round trip time from RTCP statistics. For acceptable quality this should be less than 100ms. RoundTripMax int Maximum round trip time for the audio stream. OverallAvgNetworkMOS decimal(3,2) Average wideband Network MOS for the call. This metric depends on the packet loss, jitter and codec used. Range is [1.0 to 5.0] OverallMinNetworkMOS decimal(3,2) The minimum wideband Network MOS for the call. SendListenMOS decimal(3,2) The average predicted wideband Listening MOS score for audio sent, including speech level, noise level and capture device characteristics. SendListenMOSMin decimal(3,2) The minimum SendListenMOS for the call. RecvListenMOS decimal(3,2) The average predicted wideband Listening MOS score for audio 217 Column Data Type Key/Index Details received from the network including speech level, noise level, codec, network conditions and capture device characteristics. RecvListenMOSMin decimal(3,2) The minimum RecvListenMOS for the call. Inbound bit Stream data on receiver side is received. Outbound bit Stream data on sender side is received. SenderIsCallerPAI bit 1 means the stream direction is from Caller to Callee. 0 means the stream direction is from Callee to Caller. Note: * means, the metric is scaled by *-100 when stored in QoE DB. Dividing the number by -100 will give the ranges listed in this table. VideoStream Table Each record represents one video stream. One video media line usually contains two video streams. Column Data Type Key/Index Details ConferenceDateTime Datetime primary Referenced from the MediaLine Table. SessionSeq Int primary R Referenced from the MediaLine Table. MediaLineLabel tinyint primary Referenced from the MediaLine Table. 218 Column Data Type Key/Index Details StreamID int primary Unique ID within a media line. JitterInterArrival Int Average network jitter from Real Time Control Protocol (RTCP) statistics. JitterInterArrivalMax Int Maximum network jitter during the video session. RoundTrip int Round trip time from RTCP statistics. RoundTripMax int Maximum round trip time for the video stream. PacketLossRate decimal(5,4) Average packet loss rate during the call. PacketLossRateMax decimal(5,4) Maximum packet loss observed during the call. BurstDensity decimal(9,4) Not available. BurstDuration Int Not available. BurstGapDensity decimal(9,4) Not available. BurstGapDuration Int Not available. PacketUtilization Int Packet count for the video stream (Real Time Transport Protocol, RTP). BandwidthEst Int Bandwidth estimates for the video stream. VideoPayloadDescription varchar(256) Video codec used. 219 Column Data Type Key/Index Details VideoPayloadType int Not used. VideoResolution char(9) Resolution of the video in pixels width multiplied by pixels height. Reported as a string. VideoBitRateAvg int Average bit rate of the video stream. InboundVideoFrameRateAvg decimal(9,4) The video frame rate received. OutboundVideoFrameRateAvg decimal(9,4) The video frame rate sent. VideoBitRateMax int The maximum video bit rate during the video session. VideoPacketLossRate decimal(5,4) The average fraction of video packets lost as specified in RFC 3550, computed over the duration of the session. VideoFrameLossRate decimal(9,4) The percentage of total video frames that are lost. VideoFrameEncodingTime decimal(9,2) Average encoding time for video frames during the video session. VideoFrameDecodingTime decimal(9,2) Average decoding time for video frames during the video session. VideoFEC bit Not available. 220 Column Data Type Key/Index Details FrozenVideoFreq decimal(9,4) Frequency of frozen video occurring (occurrences per second). FrozenPeriodPercentAvg decimal(7, 4) A measure of the percentage of the duration of the video call in which frozen video was experienced. For good quality, this should be less than 10%. ConsecutivePacketLossAvg decimal(20,2) Average number of consecutive video packets lost during the call. For good quality this should be less than 3.0 for a video call. RateMatchLevel decimal(4,2) Represents the average level of rate matching applied by the Audio/Video Conferencing Server on the send channel. 0 is no frame removal, 1 is B frame removal, 2 is B and P frame removal, and 3 is B,P,SP removal. For acceptable temporal video quality, this should be 1 or less. An average rate matching level of 1 221 Column Data Type Key/Index Details represents about 7.5 fps for CIF sized video and 12.5 fps for VGA/HD video. Inbound bit Stream data on receiver side is received. Outbound bit Stream data on sender side is received. SenderIsCallerPAI bit 1 means the stream direction is from Caller to Callee. 0 means the stream direction is from Callee to Caller. Sample Database Queries This section contains sample queries for the QoE database. To get jitter and packet loss average for all audio stream select avg(cast(JitterInterArrival as bigint)) as JitterAvg, avg(PacketLossRate) as PacketLossRateAvg from AudioStream To find the total numbers of conferences that used Meeting Console select avg(ConversationalMOS) from Session s inner join MediaLine m on s.ConferenceDateTime = m.ConferenceDateTime and s.SessionSeq = m.SessionSeq and m.MediaLineLabel = 0 -- audio media line inner join UserAgent uaCaller on s.CallerUserAgent = uaCaller.UserAgentKey and uaCaller.UAType = 4 – communicator 222 inner join UserAgent uaCallee on s.CalleeUserAgent = uaCallee.UserAgentKey and uaCallee.UAType = 4 -- communicator To get ConversstionalMOS, SendingMOS and ListendingMOS per capture device select t.DeviceName as Device, count(*) as SampleNum, avg(ConversationalMOS) as ConversationalMOS, avg(SendListenMOS) SendingMOS, avg(RecvListenMOS) as ListendingMOS from ( select d.DeviceName, m.ConferenceDateTime, m.SessionSeq, a.StreamID, m.ConversationalMOS,a.SendListenMOS, a.RecvListenMOS from MediaLine m inner join AudioStream a on m.ConferenceDateTime = a.ConferenceDateTime and m.SessionSeq = a.SessionSeq and m.MediaLineLabel = 0 inner join Device d on m.CallerCaptureDev = d.DeviceKey and d.DeviceType = 1 union select d.DeviceName, m.ConferenceDateTime, m.SessionSeq, a.StreamID, m.ConversationalMOS,a.SendListenMOS, a.RecvListenMOS from MediaLine m inner join AudioStream a on m.ConferenceDateTime = a.ConferenceDateTime and m.SessionSeq = a.SessionSeq and m.MediaLineLabel = 0 inner join Device d on m.CalleeCaptureDev = d.DeviceKey and d.DeviceType = 1 )as t group by t.DeviceName order by SampleNum desc 223 Message Queuing Architecture and Configuration for Archiving The archiving and CDR agent uses Message Queuing to receive notifications from the Archiving and CDR Server destination queue. (Message Queuing also serves as a local temporary transmission queue if the Archiving Server is unavailable.) Message Queuing must be installed on all computers that participate in archiving, such as the following:  An Office Communications Server with an archiving and CDR agent that connects to the Archiving Server.  The Office Communications Server that is running the Archiving Server.  You must install Message Queuing on each server that you want to associate with the Archiving Server. If you want to archive an Enterprise pool, you must install Message Queuing on each server in the pool.  Because Message Queuing relies on the Active Directory Domain Services for encryption to the destination queue, Message Queuing must be installed with the Active Directory integration component, which is the default configuration during Message Queuing installation. Note: In a two-tier topology where the Archiving service component and the message queue are on a separate computer from the archiving database, automatic setup of encryption is not supported for the messages that are sent by the Archiving service component to the archiving database. Instead, encryption of the link between the Archiving service component and the archiving database must be configured manually by using SQL Server SSL encryption. For details about configuring SQL Server SSL encryption, see the Microsoft Knowledge Base article 276553, How to enable SSL encryption for SQL Server 2000 if you have a valid Certificate Server, at http://go.microsoft.com/fwlink/?LinkId=144421. For information about configuring the registry to establish and help enforce SQL encryption, see the Microsoft Knowledge Base article 841695, How to establish and enforce encrypted multiprotocol connections in SQL Server 2000, at http://go.microsoft.com/fwlink/?LinkId=144422. Do not set the destination queue (that is, the private queue) privacy level to None on the server that is running the Archiving Server. The privacy level must be set to either Body or Optional. The default setting is Optional. Do not set the privacy level to Body when the Archiving Server and the Front End Server are installed on the same computer. When the Archiving Server and the Front End Server are installed on the same computer and the privacy level on the destination queue is set to Body, messages are not archived and the server stops running if archiving is running as a critical service. 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 224 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. Note that in Office Communications Server 2007 R2, the Archiving and CDR agent will not archive a message if it does not receive a SIP response from another client. For example, if client 1 sends a message to client 2, and if the SIP response from client 2 fails to reach client 1 due to a network glitch or a machine shut down, that message will not be archived. Message Stamping The Archiving and CDR agent contains message-stamping capabilities to provide administrators control over whether messages are archived multiple times if they pass through multiple pools or Front End servers in their path. In such a situation, administrators can effectively control the number of times a message is archived. To enable this control, the Archiving and CDR agent stamps every message that it archives. The value of the stamp is specified in the following WMI property:  WMI Class: MSFTSIPLogoptions  WMI Property: ArchivingBEToken  Value: backend_token In an example where two archiving agents are involved, the first archiving agent stamps the message with the value as backend_token and archives it. Subsequently, the second archiving agent looks at the stamp and compares it to the value of the WMI property ArchivingBEToken. If the administrator intends to have the second archiving agent archive the message, the administrator needs to change the value of the WMI property to a value distinct from backend_token (the value of that property for the first archiving agent). If the value is identical for the second archiving agent, it will not archive that message. Creating a Third-Party QoE Solution You can use the data that Monitoring Server collects to build your own custom solution, such as custom reports, integrating with other monitoring and management systems, or troubleshooting and diagnostic tools. The topics in this section present the information you will need to collect and process the audio and video metrics for your custom solution. For information on the QoE Database Schema, see QoE Database Schema. In This Section  Infrastructure Requirements and Prerequisites of Monitoring Server 225  Deploying a Custom QoE Solution  WMI Reference for QoE Solutions  Enabling or Disabling an HTTP Proxy for QoE Solutions Infrastructure Requirements and Prerequisites of Monitoring Server In Office Communications Server 2007 R2, QoE components reside in two primary areas, the QoE Agent and the QoE service and database. The QoE Agent is automatically installed on Front End Servers and Standard Edition servers. The QoE service and database are part of Monitoring Server, which must be installed separately. Before you begin developing your custom solution, ensure that you have deployed a Monitoring Server and that it is operational. For deployment details, see the Deploying Monitoring Server documentation. At the end of each call, the unified communications (UC) endpoints send an A/V (audio/video) metric report to the QoE Agent. If QoE is enabled on the pool and the QoE Agent is properly configured, it will, in turn, transmit the report to your custom solution (metric report consumer) by using HTTP POST. For each QoE Agent in your organization, you can configure only one metric report consumer. You need to do this QoE Agent configuration work on each Front End Server. For more details about requirements, see these sections:  Certificate Requirements for Your QoE Solution  Protocol Considerations for Your QoE Solution Certificate Requirements for Your QoE Solution When you deploy your custom solution, we recommend that the HTTPS protocol be used in order to improve the security of your data and privacy of your users. By default, HTTPS will allow only the client to authenticate the server; however, mutual certificate authentication will allow both the client to authenticate the server and the server to authenticate the client. If HTTPS is used, you will need to take the following certificate considerations into account:  The Front End Server or Standard Edition server running the QoE Agent must trust the root CA that issued the certificate that is used by the Web server.   The subject name of the server certificate must match the FQDN of the report consumer URL that is configured in the ConsumerURL property in WMI. For details, see WMI Reference for QoE Solutions. If you want to use mutual certificate authentication, a client certificate must be configured on the Front End Server or Standard Edition server running the QoE Agent. For the client certificate, you must ensure the following:  The certificate is stored in the local computer store so that the QoE Monitoring Server can locate the certificate.  The certificate has the enhanced key usage (EKU) extension for client authentication.  The metric report consumer server is configured to trust the root certification authority (CA) that issued the client certificate. The root CA needs to be stored in the "Trusted Root Certification Authorization" folder under the local computer store. 226  Appropriate permissions are granted to the RTCComponentUniversalServices domain group for the certificate to be read.  The certificate is configured in Microsoft Windows® Management Instrumentation (WMI) on the Front End Server or Standard Edition server running the QoE Agent. For details, see WMI Reference for QoE Solutions. Note: On a heterogeneous Windows environment that uses Windows Certificate Services, trust is usually implicit, but it may require some extra configuration if a non-Windows Web server is used for the metric report consumer. For details about Certificate Services, see "Certificate Services" at the Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=150367. For details about programming with Certificate Services, see "Programming Certificate Services" at http://go.microsoft.com/fwlink/?LinkId=150368. Protocol Considerations for Your QoE Solution There are a few protocol considerations that you should be aware of before you develop your custom solution. In order to support persistent connections, the metric report consumer must be a server that is compliant with HTTP 1.1. Note: To improve the security of your data and the privacy of your users, we recommend that HTTPS with mutual certificate authorization be configured. This sample call flow illustrates how the metric report consumer accepts an A/V metric report for a single session. You will be responsible for the protocol implementation between the Monitoring Agent and the metrics report consumer. Figure 1. Metric Report Consumer Acceptance of an A/V Metric Report 227 Protocol Requirements The following protocol requirements should be taken into consideration when you develop your custom solution:  The metric report consumer must be able to handle multiple incoming HTTP connections and to simultaneously process requests that come in on these different connections. This will enable a single metric report consumer to communicate with multiple Monitoring Agents.  Multiple A/V metrics reports may exist in a single POST body, up to the maximum configured value for the WMI setting MaxPostBatchSize.  The A/V metrics reports will be sent in XML, UTF-8 encoded.  The XML payload will have a root element of VQReportEventList. The ID attribute of VQReportEventList will be set to a unique value for the set of A/V metrics reports that it contains. If a transient network error or server error occurs or if the Monitoring Agent does not receive an HTTP response from your application, then the agent will repost the entire VQReportEventList document with the original ID. You can disable reposting when a transient network error or server error occurs by setting ErrorRetryEnabled to false in WMI.  The QoE Agent performs only a basic level of validation against the A/V metrics report before it posts the report to the metric report consumer. None of the QoE Monitoring Server report aggregation logic is applied to the reports prior to the post.  The QoE Agent will not throttle requests; the metric report consumer is expected to keep up with the normal volume of A/V metric reports.  In order to handle A/V metric report bursts, such as might occur at the end of a large conference, the QoE Monitoring Server buffers A/V metrics reports, as needed, on behalf of the consumer. The buffer size itself is a configurable number of kilobytes. After the report bursts exceed the buffer size, the QoE Monitoring Server will drop the oldest reports. If the QoE Monitoring Server service or the computer is restarted, the contents of the buffer will not be retained.  Upon receiving metrics reports, the report consumer should return the HTTP response immediately. Performing any additional synchronous processing on the reports before returning will cause a drop in the report throughput rate to the report consumer. HTTP Status Codes Table 1 defines the status codes that are used in the HTTP protocol between the QoE Monitoring Server and the metric report consumer. Note: Only HTTP 2xx and 400 status codes are expected from the metric report consumer. All other status codes will be treated as a transient network error or server error and will cause the QoE Monitoring Server to retry the POST request. Table 1. Supported HTTP status codes HTTP Status Code Metric Consumer Usage QoE Monitoring Server Action 2xx Metric consumer is expected to The post transaction will be 228 HTTP Status Code Metric Consumer Usage QoE Monitoring Server Action promptly return 202 Accepted to valid metric CDR post requests. marked as complete. 400 Bad Request Metric consumer should return 400 Bad Request whenever basic validation of the A/V metric report post request fails. The post transaction will be abandoned and not retried. All other status codes No other status codes are expected from the metric consumer. The QoE Monitoring Server will treat all other status codes as transient errors and will retry the post request. Deploying a Custom QoE Solution Deploying your custom solution requires only a few steps. To deploy your solution 1. Install an HTTP 1.1 compliant Web server, such as Internet Information Services. 2. Install your application. 3. If HTTPS will be used (recommended), install the appropriate certificate on the consumer and, as needed, on the Front End Servers that run the QoE Agent. 4. Configure external consumer settings on the QoE Monitoring Server by using WMI. For details about WMI settings, see WMI Reference for QoE Solutions. 5. By default, the QoE Monitoring Server will not use any HTTP proxy. For details about configuring the QoE Monitoring Server to use the configured HTTP proxy, see Enabling or Disabling an HTTP Proxy for QoE Solutions. WMI Reference for QoE Solutions The following table lists the various configuration settings that can be set through WMI for the \\cimv2\MSFT_SIPQMSExternalConsumer singleton class. This class already exists, so you will not need to create it. Table 2. WMI Settings for Class MSFT_ SIPQMSExternalConsumer Property Name Description Type Default Range Access Type InstanceID Class identifier GUID 530943174455-44ed- Up to 1024 Read Only 229 Property Name Description Type Default Range Access Type ConsumerURL The URL that A/V Metric String Reports will be posted too. B8D5A716972B334 4 character s NULL Valid HTTPS or HTTP URL Note: Read/Writ e The host name in the URL must be identical to Subject field of the server certificate. For instance, if the server certificate is configured as contoso.voipclient1.com, the consumer URL must be https://contoso.voi p-client1.com. ConsumerName A display name for the consumer. String NULL Up to 256 Read/Writ character e s ClientCertIssuer A binary array in raw data format that represents the certification authority that issued the certificate. This data is in ASN.1 byte array format. uint8 NULL N/A Read/Writ e uint8 NULL N/A Read/Writ e This setting is used only if ConsumerURL is an HTTPS URL. This setting should be NULL if the client will not use a certificate. ClientCertSN A binary array in raw data format that represents the serial number of the client 230 Property Name Description Type Default Range Access Type certificate. This setting is used only if ConsumerURL is an HTTPS URL. This setting should be NULL if the client will not use a certificate. Enabled If True, the QoE Monitoring Server will send A/V Metric Reports to the configured consumer. Boolea n ErrorRetryEnable d If True, the QoE Boolea Monitoring Server will retry n when transient errors occur. False N/A Read/Writ e True N/A Read/Writ e Read/Writ e MaxPostBatchSiz Maximum number of e reports to send in one transaction. uint32 50 5-100 MaxQueueSize uint32 50,000 0Read/Writ MAX_INT e The maximum amount of memory (in KB) that is used to cache metric reports on behalf of the consumer. If the queue limit is exceeded, the QoE Monitoring Server will discard the oldest reports first. If MaxQueueSize is set to 0, the buffer size has no upper limit. Because individual reports may range from 2 KB to 8 KB, we recommend against setting MaxQueueSize to less than 10. 231 Enabling or Disabling an HTTP Proxy for QoE Solutions Both the Monitoring Server and the metric report consumer server will usually be located within your organization’s internal network, so you will not need an HTTP proxy. By default, Monitoring Server will not use any HTTP proxy, and it will send the reports directly to the FQDN of the metric report consumer. You can, however, configure Monitoring Server to use the existing proxy settings that are configured for the Monitoring Server by either local machine or Group Policy settings. To enable or disable an HTTP proxy 1. Log on to the Monitoring Server as a member of the Administrators group. 2. Start the Registry Editor: Click Start, and then click Run. In the Open box, type regedit, and then click OK. 3. In the console tree, right-click HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RealTime Communications\{B956FCFA-77F2-4ECA-A3EE-F864B8209C0D}. Create this registry key it is doesn’t exist. 4. Point to New, and then click DWORD Value. 5. In the details pane, in the Name column, type EnableProxyForMetricsConsumer for the new value, and then press ENTER. 6. In the details pane, right-click EnableProxyForMetricsConsumer, and then click Modify. 7. In the Edit DWORD Value dialog box, in the Value data box, do one of the following:  To use the Internet Explorer HTTP proxy settings, type 1, and then click OK.  To no longer use the Internet Explorer HTTP proxy settings, type 0, and then click OK. 8. Restart the QoE Monitoring service for the changes to take effect. Edge Servers Drilldown For details about Edge Servers, see the Microsoft Office Communications Server 2007 R2 the Edge Server Deployment Guidelines in the Planning and Architecture documentation. Response Group Client Web Service Drilldown The Response Group Service has a Client Web Service, which can be used by 3rd party applications to retrieve information about the Agents, their Agent Group memberships, and signin status. The following operations are supported through the client web service:  GetAgent  GetGroups 232  IsAgent  SignIn  SignInMultiple  SignOut  SignOutMultiple Service Descriptions The following list the service descriptions of the operations within the Client Web Service  GetAgent: Returns information about the currently authenticated agent.  GetGroups: Returns information about the groups the currently authenticated agent is a member of. For each group, the following information is available:  IsAgent: Returns true if the currently authenticated user is an agent.  SignIn: Signs the current agent into the given group and returns true when the operation has successfully completed.  SignInMultiple: Signs the current agent in to the given groups and returns true when the operation has successfully completed.  SignOut: Signs the current agent out of the given group and returns true when the operation has successfully completed.  SignOutMultiple: Signs the current agent out of the given groups and returns true when the operation has successfully completed. Client DNS Queries Drilldown This topic gives a brief description of how DNS queries work in Office Communications Server 2007 R2. During DNS lookup, SRV records are queried in parallel and returned in the following order to the client: 1. _sipinternaltls._tcp.<domain>— for internal TLS connections. 2. _sipinternal._tcp.<domain>— for internal TCP connections (performed only if TCP is allowed). 3. _sip._tls.<domain>— for external TLS connections. Where <domain> is the SIP domain used by your internal clients. The last query is useful when clients are connecting from outside your internal network. For details about remote user access, see Planning for External User Access in the Planning and Architecture documentation. The client uses the SRV record that is returned and is successful. The client does not try any other SRV records. After the SRV record is returned, a query is performed for the DNS A record for the host name that is returned by the SRV record. If no records are found during the DNS SRV query, the client 233 performs an explicit lookup of sipinternal.<domain>. If the lookup does not produce results, the client performs a lookup for sip.<domain>. If the client does not find sip.<domain>, it performs a lookup for sipexternal.<domain>. If your DNS infrastructure prohibits configuration of these DNS records, you can manually edit the client registry to point to the appropriate home server. For details about editing the client registry and configuring policy settings for the client, see Deploying Communicator in the Client Planning and Deployment documentation. Application Server Drilldown Application Server 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 Edition pool servers. Applications developed using the Unified Communication Managed APIs (UCMA) 2.0 can use the Application Server platform as a common framework that leverages Office Communications Server capabilities such as deployment, trust, administration, load balancing and routing, and monitoring. Without Application Server, each application developer would have to create his own deployment, administration and integration story, leading to repeated effort, more time to market, and inconsistent behavior. Proliferation of these different solutions would also lead to complexity in deploying and maintaining the Office Communications Server deployment. Application Server is designed to host server applications that act as SIP endpoints. It is not intended to host Web applications and does not integrate with Internet Information Services (IIS), although applications running on it can expose Windows Communication Foundation (WCF) Web service endpoints. Like the Office Communications Server Conferencing Servers, Application Server is another server role, and when deployed on an Enterprise Edition consolidated pool topology each Application Server application runs on all servers in the pool and together they share the overall workload of the application. The Application Server implementation in Office Communications Server 2007 R2 is the first stage in the evolution of the platform, and in this release it hosts four new applications that come with Office Communications Server 2007 R2: Response Group Service, Outside Voice Control (also known as Call Control Service), Conferencing Attendant, and the Conferencing Announcement Service. However, in this release, Application Server is not supported as a platform for third-party applications. The topics in this section is intended to help Office Communications Server administrators and product specialists have a deeper understanding of the Application Server architecture and applications and prepare them to troubleshoot any issues encountered involving the four Application Server applications included with this release of the product. In This Section  Characteristics of the Office Communications Server 2007 R2 Application Server  Application Server Configuration  Application Server Application Configuration 234 Characteristics of the Office Communications Server 2007 R2 Application Server Architecture Application Server consists of a single Windows service—Application Host (OCSAppServerMaster.exe)—and one or more instances of another Windows service— OCSAppServerHost.exe. Each instance of OCSAppServerHost.exe on a server hosts an Application Server application unique to that server. There will never be multiple instances of any particular Application Server application on a server. In the Enterprise Edition consolidated pool topology, all Front End Servers run identical instances of each Application Server application selected at the time of Office Communications Server installation. The Application Server applications themselves are written as .NET Framework 3.5 managed assemblies. All OCSAppServerHost.exe process instances and the OCSAppServerMaster.exe process run under the RTCComponentService account security context. Each Application Server application leverages the following Office Communications Server 2007 R2 components:  WMI – Each application uses the lcwmi WMI provider to store/retrieve global and pool settings. For each Application Server application, all instances in a pool use a common set of settings stored in the backend RTCConfig database. Global settings are stored in Active Directory Domain Services.  Unified Communications Managed APIs (UCMA) 2.0 –Application Server applications interface these APIs to access the SIP and media stack on each front end server. Communications between the Application Server applications and other SIP endpoints all route through a SIP Proxy in the same pool as the application (but not necessarily on the same physical server).  Contact Objects/Trusted Services – Application Server applications are SIP Application Endpoints and as such require a SIP Address of Record (AOR) in the form of a SIP URI or Tel URI. This is accomplished by assigning an Active Directory Domain Services Contact object to each application and setting the application as a Trusted Service. These assignments enable the application to act as a SIP User Agent without having to authenticate or register, and enables them to subscribe to the presence of registered users and publish presence on behalf of registered users.  Management – The Office Communications Server 2007 R2 Management Console exposes service start-up and shut-down control of the Application Server services on a per-server basis in the same way it provides control of the other Office Communications Server 2007 R2 services, such as the Front End services or Conferencing Servers. If an Application Server application requires pool-level configuration, the Management Console can list the application under the new Applications option under the pool’s Properties menu in Office Communications Server 2007 R2. This will launch a new snap-in for managing that 235 application’s pool level settings. (In R2, only the Response Group feature requires pool-level configuration.) The Management Console also can expose property sheets on the Forest container as needed to configure global properties associated with the Application Server application. In Office Communications Server 2007 R2, Communicator 2007 R2 Attendant is the only Application Server application that requires configuration at this level. Because all Application Server application instances in a pool are identical, configuration of Application Server applications on a per-server basis is unnecessary.  Installation/Activation – the Application Server environment and each Application Server application are packaged as Windows installer (.MSI) files called from the main Office Communications Server installation program (if one or more Application Server applications were selected for installation). After you install it, they are activated or deactivated in AD DS using lcscmd.exe /server:<appserver> /action:Activate|Deactivate /Role:AppServer.  Logging –Application Server applications can expose new components to the Office Communications Server 2007 R2 Logging Tool (OCSLogger.exe) for tracing communications with the application. Other Key Application Server Characteristics Distributed Workload The Office Communications Server Application Host process does not listen on the network at all, but like the Office Communications Server Conferencing Servers, each Application Server application has a TCP port assigned to it. All servers in the pool listen on those assigned ports for each the specific Application Server application they host, and the hardware load balancer also listens on those ports and distributes inbound traffic to Application Server application instances on a server in the pool. All SIP communications with an Application Server application occurs over TLS between a SIP Proxy in its pool using the pool’s SSL certificate, even if the Application Server application instance happens to be on the same physical server as the SIP Proxy. As with other UC endpoints, media communications are direct between the client and the Application Server application instance that took the call. For example, once a call has been routed to a Conferencing Attendant instance, the audio media flows directly between it and the Mediation Server that handled the call. Stateless Application Server applications are stateless in that they do not persist data between sessions, and each instance operates autonomously of the other instances of that application in the pool or across pools. All Application Server instances of a particular application are equivalent across servers in pool and do not communicate with each other or another server process (unlike the Conferencing Servers, which communicate state information to the Conferencing Server Factory). Furthermore, Application Server applications do not register with the SIP Registrar and thereby do not support multiple points-of-presence. A call to an Application Server application is routed to only one Application Server instance and the other instance remain unaware of that call. 236 The Office Communications Server Application Host service (OCSAppServerMaster.exe) also does not monitor the state of the Application Server applications on its server, other than monitoring whether the instances are running and if it detects an unhandled exception in the application, it will restart it automatically. Application Server Configuration In Office Communications Server 2007 R2, the Application Server infrastructure has no configurable post-installation settings (during installation, the RTCComponentService service account is assigned and the service is set for automatic start with a dependency on Windows Management Instrumentation [WMI]). A WMI Class exists in the LCWMI provider for Application Server settings— MSFT_SIPApplicationServerSetting—but currently there is no data store for this class. Because Application Server is a separate Office Communications Server 2007 R2 role, at the time of activation an msRTCSIP-ApplicationServer Service Connection Point (SCP) for each Application Server-role server is published in Active Directory Domain Services separate from SCPs of the other roles, such as the Front-End services and the Conferencing Servers. Application Server Application Configuration In the Office Communications Server 2007 R2 implementation, the Application Server applications retrieve settings information via WMI. Global settings are stored in AD, while pool level application settings are stored in the RTCConfig database. As mentioned earlier, some of these settings are established at time of activation, while others are configurable from the Office Communications Server 2007 R2 Management Console. All are viewable and configurable using the WBEMTEST utility and the global settings can also be accessed using ADSIEDIT.MSC. Global Settings  MSFT_SIPPoolSetting – each pool is represented by an instance of this class. One if its properties—Applications Property— is a multi-valued array containing the names of the Application Server applications installed in the pool.  MSFT_SIPApplicationContactSetting – this class contains instances for each Contact object required by the Application Server applications. If all four R2 Application Server applications have been installed, activated, and configured, there will be instances for each pool’s Response Group Presence Watcher (RGSPresenceWatcher), Conferencing Announcement Service, Conferencing Attendant (CAAPrivateContactObject), plus one for each Dial-In Conferencing access number configured for the organization.  MSFT_SIPTrustedServiceSetting – this class will contain one instance for each Application Server application for each pool, which stores the Distinguished Name (DN), GRUU address, and port number for the Application Server application instances in that pool. 237 Pool Settings  MSFT_SIPApplicationConfigSetting – Each pool’s RTCConfig database contains one instance of this class for each Application Server application installed in the pool, and each instance tells the Front End Server the name, labels, and location of the application’s assembly file.  Other Pool-level Application settings – An Application Server application can also extend the Office Communications Server 2007 schema to add classes specific to itself. In Office Communications Server 2007 R2, the Response Group service added 11 new classes (and corresponding tables in the RTCConfig database) for storing settings. See Response Group Client Web Service Drilldown for details about these settings. SIP Trunking Drilldown Office Communications Server 2007 R2 enables basic call origination and termination using a Session Initiation Protocol (SIP) trunk to a service provider. In This Section This section contains the following topics:  SIP Trunking Drilldown: Supported Scenarios  SIP Trunking Drilldown: Supported Topologies  SIP Trunking Drilldown: Security Considerations  SIP Trunking Drilldown: Bandwidth Considerations  SIP Trunking Drilldown: Protocol Flow and Details  SIP Trunking Drilldown: High Availability SIP Trunking Drilldown: Supported Scenarios Supported scenarios include the following:  An enterprise Office Communications Server user is able to place a local or long distance outbound call to the public switched telephone network (PSTN) by using a service provider Session Initiation Protocol (SIP) trunk.  An enterprise Office Communications Server user is able to receive an inbound PSTN call to his/her Direct Inward Dialing (DID) number by using a service provider SIP trunk. If the service provider supports number portability, you can keep your pre-existing DID.  The Calling Party Number (that is, used to show caller ID) is supplied (if allowed) for inbound and outbound calls.  An active call can be placed on hold and off hold. Any other scenario is outside the scope for the Office Communications Server 2007 R2 release. Some examples include the following:  E.911 support for outbound calls.  Invoking any service provider call conferencing functionality over the SIP trunk. (This is separate from the conferencing functionality provided by Office Communications Server.) 238  Invoking any service provider call forwarding/redirect functionality over the SIP trunk. (This is separate from the call forwarding/redirect functionality provided by Office Communications Server.) SIP Trunking Drilldown: Supported Topologies The interface for connecting Office Communications Server environment to the Session Initiation Protocol (SIP) trunk of the service provider is made on the external side of a Mediation Server. The following list contains the supported topologies that you can use to enable this connection to your service provider’s SIP trunk:  Private connection. In this configuration, the mediation server connects to the SIP trunk using a private network connection to the service provider. For instance, this could be a dedicated MPLS T1 connection installed for the purpose of SIP trunking.  VPN connection. In this configuration, the mediation server connects to the SIP trunk using a virtual private network (VPN) connection to the service provider. This could run over a general Internet connection or an existing MPLS wide area network (WAN) connection. Unlike the private connection option, these multi-purpose connections are usually shared and used for multiple scenarios. The purpose for the VPN connection is to create an isolated, secure channel on which the SIP trunked calls are carried. 239  Public Connection. In this configuration, the Mediation Server connects to the SIP trunk by using a direct Internet connection. Unlike the private and VPN options, this topology does not leverage an isolated link to the SIP trunk. SIP Trunking Drilldown: Security Considerations Office Communications Server employs Transport Layer Security (TLS) to secure server/server and client/server SIP signaling and secure real-time protocol (SRTP) to secure media flow. The Mediation Server role has always supported TLS and SRTP on the Office Communications Server facing non-gateway side. With the release of Office Communicator Server 2007 R2, the Mediation Server role now supports TLS and SRTP on the gateway side. However, TLS/SRTP is 240 not supported by all service providers nor is it required in all SIP trunk topologies. This section describes when it is necessary to enable TLS and SRTP on the gateway side of the Mediation Server to ensure a secure deployment. There is only one key condition that requires TLS and SRTP to be enabled. Namely, there is some point in the network path between the Mediation Server and the service provider SIP trunk that is accessible to more than a limited set of non-IT personnel.  Private Connection. The connection to the service provider is dedicated and only used to carry SIP trunk packets. Because only authorized IT engineers at the company and the service provider are able to observe this traffic, TLS/SRTP is not required. However, if the service provider supports it, you may still implement TLS/SRTP for an added layer of protection. Be sure that the subnet linking the Mediation Server to the private connection is also private.  VPN Connection. Although the network between the Mediation Server and the service provider is likely shared by a number of applications, the virtual private network (VPN) connection effectively creates a dedicated pipe used only to carry SIP trunk packets. The key difference from the physical connection topology is that network isolation is being provided by the encryption capabilities of the VPN rather than physical separation. At minimum, the VPN should encrypt all traffic at a level comparable or better than 128-bit Advanced Encryption Standard (AES). Assuming this is the case, the only people who could observe this SIP trunking traffic would be authorized IT engineers of the company and the service provider, so TLS/SRTP is not required. However, if the service provider supports it, you may still implement TLS/SRTP for an added layer of protection. If you use a VPN appliance, ensure that the subnet linking the Mediation Server to the VPN appliance is also private. Note that if the tunneling mechanism carries User Datagram Protocol (UDP) packets over a TCP transport, this may impact the latency characteristics of the call, given that TCP is a reliable transport while UDP is not.  Public Connection. With a public connection, clearly no dedicated connection exists. Quite the contrary, it should be assumed that a large number of people will be able to inspect all SIP trunk-related packets. Enabling TLS and SRTP is strongly advised to ensure a secure deployment. SIP Trunking Drilldown: Bandwidth Considerations SIP trunking services are typically priced according to the maximum number of simultaneous calls. Bandwidth availability needs to be taken into account so that you can take full advantage of the peak capacity that you have paid for. The bandwidth needs are determined as follows: SIP Trunk Peak Bandwidth = Max Simultaneous Calls x 80kbps The 80kbps value reflects 64kbps for the G711 codec plus 16kbps of packet overhead. In reality, the bandwidth will be somewhat lower due to silence suppression. That means the Mediation Server and the service provider stops sending real-time transport protocol (RTP) media packets when the respective participant is not talking. For audio sent by the Mediation Server, silence suppression will reduce the bandwidth by roughly 35%. The challenge is that bandwidth planning is usually symmetric, and each service provider implements different degrees of silence 241 suppression (or perhaps no silence suppression at all). Therefore, it is best to plan for the full 80kbps bandwidth unless you have further information regarding the silence suppression characteristics of your particular service provider. In the private connection topology, it is easy to plan your bandwidth because it is a dedicated link. Simply compute your SIP trunk peak bandwidth, and then obtain at least that much bandwidth in your dedicated connection. In the virtual private network (VPN) connection topology, how you plan your bandwidth depends on the network that the VPN is running over. If the VPN is running over a controlled link between your company and the service provider (for example, a corporate MPLS link), compute your SIP trunk peak bandwidth and set aside that much bandwidth on the link for the VPN connection. If the VPN is running over an uncontrolled link (for example, a public internet connection), compute your SIP trunk peak bandwidth and reserve that much bandwidth on your link for the VPN connection. This prevents a saturated link from causing bandwidth issues for your SIP trunk. However, this does not guarantee that your SIP trunk traffic will not be affected by congestion on the Internet. Therefore, running a VPN over an Internet connection is not recommended for deployments that require a high service level agreement (SLA). From a bandwidth standpoint, the public connection topology is handled similarly to running a VPN connection over an Internet connection. Compute your SIP trunk peak bandwidth and reserve that much bandwidth on your public connection link. This prevents a saturated link from causing bandwidth issues for your SIP trunk. However, this does not guarantee that your SIP trunk traffic will not be affected by congestion on the Internet. Again, running a VPN over an Internet connection is not recommended for deployments requiring a high SLA. SIP Trunking Drilldown: Protocol Flow and Details This topic describes the various Session Initiation Protocol (SIP) trunking protocol flows. SIP Call Flow and State Machine The implementation of SIP trunking in Office Communications Server 2007 R2 supports a constrained set of call scenarios. The diagram below reflects a high-level state machine for a call leg between the Mediation Server and the SIP trunk. From the Idle state, either the service provider or the Mediation Server could send a SIP Invite, which indicates that a call is being offered. Several provisional responses may be sent, such as 180 Ringing indications. However, a final response will ultimately be sent, such as a 480 Temporarily Unavailable or a 200 OK. In the former case, the SIP dialog fails to be established and the call state reverts to Idle. In the latter case, the SIP dialog succeeds and the call state goes to the Active state. During the Active state, the only supported call mediation command is to place the call on and off Hold. This may be done by either endpoint of the SIP dialog by sending another SIP Invite that contains the appropriate SDP command to indicate the call is active or on hold. From either the Active or On Hold states, the call may be terminated by either endpoint by sending a Bye. 242 Call Hold The Mediation Server only supports one method for placing a call on and off hold. To place a call on hold, an additional SIP Invite will be sent on an active call’s SIP dialog. The Session Description Protocol (SDP) body of this dialog contains a full SDP body containing the line a= inactive. To place a call off hold, an additional SIP Invite is sent on a held call’s SIP dialog. The SDP body of this dialog contains a full SDP body containing the line a=sendrecv. Dual-tone multifrequency (DTMF) The Mediation Server supports sending and receiving DTMF according to RFC 4733. Effectively, this passes a DTMF tone by sending a stream of real-time transport protocol (RTP) packets on the media channel using a payload type specific to DTMF. This is the same mechanism used in the rest of the Office Communications Server system to pass DTMF digits. Early Media New in Office Communications Server 2007 R2, the Mediation Server now supports the negotiation of Early Media on the Mediation Server per RFC 3960. This enables the negotiation and establishment of a media channel prior to the final 200 OK response. This would enable a service provider to send carrier specific in-band ring tones and ensure that no audio is lost when a user answers the phone. It is optional whether the service provider implements it. Uniform Resource Identifier (URI) Formatting All URI formatting is performed according to RFC 3966, where an E.164 number is preceded by a +. The SIP URI must have a trailing user=phone parameter. For an example, see the following: 243 INVITE sip:+14255550101@s1.ms.com;user=phone From: <sip:+14255550101@g1.contoso.com;user=phone> To: sip:+142575550155@s1.ms.com;user=phone This coordinates nicely with the Office Communications Server design of passing numbers in E.164 format. Incoming calls are already in the correct format and can be handled by Office Communications Server inbound routing. Outgoing calls, once normalized, can be passed directly to the SIP trunk as an E.164 number without having to perform any number translation. Codec Support The Mediation Server only supports G.711a and G.711u at a 20ms packet interval. This would be shown in the SDP as follows: a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMU/8000 a=ptime:20 Per RFC 2198, you may have support for sending redundant media packet (also called forward error correction). If it is supported, it is shown in the SDP list as follows: a=rtpmap:97 RED/8000 Finally, you may see a final codec for DTMF as follows: a=rtpmap:101 telephone-event/8000 SIP Trunking Drilldown: High Availability Various degrees of high availability can be achieved with Session Initiation Protocol (SIP) trunking. As with any failover solution, a higher the level of resiliency will come at an increased cost. Following are some different scenarios along with their corresponding high availability mitigation:  Mediation Server failure. To protect against a Mediation Server failure, first install a second Mediation Server alongside the existing Mediation Server. Next, add this Mediation Server to any voice routes containing the existing Mediation Server. For outbound calls, Office Communications Server automatically load balances between the two Mediation Servers and route calls failover to just one of the Mediation Servers in case the other server goes down. Therefore, the service provider must be configured to accept SIP trunk calls originating from two source Internet Protocol (IP) addresses. Handling failover for incoming calls is done in an analogous fashion. The service provider should be configured with both gateway Internet Protocol (IP) addresses corresponding to the two Mediation Servers. The service provider should load balance between these servers by sending some calls to one server and some to the other. More importantly, if one server is no longer responding, the service provider must take that Mediation Server out of the pool and only send incoming calls to the active Mediation Servers. 244  Connection failure. To protect against a connection failure, use a second connection for the redundant Mediation Server instance. This second connection ensures that if one of the connections goes down, only one Mediation Server will be affected. The service provider must be able to detect this connection failure for incoming calls and send calls to the other connection. Address Book Server Drilldown The primary function of the Address Book Server and related services is to provide global address list (GAL) information that is retrieved from Active Directory Domain Services (AD DS) and make it available to clients through one of the following services:  Address Book File Download Service. Where clients such as Office Communicator and devices such as Office Communicator Phone Edition download address book files, enabling clients to perform local address book queries.  Address Book Web Query Service. Where clients such as Office Communicator Mobile send address book queries by using HTTPS to a Web service running on the Web Components Server. If individual clients accessed AD DS directly, it could impact Active Directory and network performance due to excessive Lightweight Directory Access Protocol (LDAP) queries. To make address book updates faster and more efficient, the Address Book Server generates daily address book file and address book database updates that are leveraged by the Address Book File Download Service and Address Book Web Query Service respectively. The secondary and optional function of the Address Book Server is to convert the format of phone numbers that may in a local format (for example, 555-0101) into the RFC 3966/ITU E.164 standardized format (for example, +1.425.555.0101). This conversion is referred to as phone number normalization. Phone numbers stored in Office Communications Server user and contact objects can be normalized by Address Book Server so they can be easily used by the Office Communications Server clients. Although it is preferable for normalized phone numbers to be entered into Active Directory, Active Directory does not perform any phone number normalization itself. The phone number normalization occurs when the Address Book Server reads the phone numbers from the RTC database, normalizes them if necessary, and then writes them into address book files and address book database (RTCAb). Among its daily tasks, the Address Book Server generates a set of compressed full files and delta files for use by the Address Book File Download Service. These files are stored in a standard NTFS folder. The advantage of the full file and delta file generation is that it minimizes the impact of the client download. When an Office Communicator 2007 R2 or Office Communicator Phone Edition (2007 R2 release) client logs on to its Enterprise pool or Standard Edition server, it uses one of two configured URLs (that is, one for internal access and the other for external access) to access the file from the NTFS folder by using HTTPS, HTTP, or by the file URL. When the client downloads the address book file for the first time, the full address book file is downloaded. On subsequent days in most situations, a delta file containing the changes since the last update is downloaded. 245 Relative to Office Communications Server 2007, a key architectural improvement for Address Book services in Office Communications Server 2007 R2 is the addition of an Address Book Web Query Service for mobile clients such as Communicator Mobile (2007 R2 release). Rather than download potentially large address book files, Communicator Mobile (2007 R2 release) clients make on-demand address book queries to the Address Book Web Query Service. Note: The Address Book logic described in the following sections apply to all Office Communications Server deployments except a few special environments with either a very large number of users or a relatively volatile directory. For these types of environments, Office Communications Server Address Book logic behaves differently in a small number of aspects, resulting in slight improvements in CPU and network efficiency. Exceptions for special environments are called out separately in the sections below. In This Section  Address Book Server Introduction  Address Book Server: File and Database Generation  Address Book Server: Address Book File Download Service  Address Book Server: Address Book Web Query Service  Address Book Server: Advanced Address Book Features Address Book Server Introduction Introduction The primary function of the Address Book Server and related services is to provide global address list information that is retrieved from Active Directory Domain Services and make it available to clients through one of the following services:  Address Book File Download Service, where clients such as Office Communicator and devices such as Office Communicator Phone Edition download address book files, which enable the clients to perform local address book queries, and  Address Book Web Query Service, where clients such as Office Communicator Mobile send address book queries via HTTPS to a web service running on the Web Components Server. If individual clients accessed the Active Directory Domain Services directly, it could impact Active Directory (AD) and network performance due to excessive LDAP queries. To make address book updates faster and more efficient, the Address Book Server generates daily address book file and address book database updates that are leveraged by the Address Book File Download Service and Address Book Web Query Service respectively. The secondary and optional function of the Address Book Server is to convert the format of phone numbers that may in a local format (e.g. 555-0101) into the RFC 3966/ITU E.164 standardized format (e.g. +1.425.555.0101). This conversion is referred to as phone number normalization. Phone numbers stored in Office Communications Server (OCS) user and contact objects can be normalized by Address Book Server so they can be easily used by the OCS 246 clients. Although it is preferable for normalized phone numbers to be entered into Active Directory, AD does not perform any phone number normalization itself. The Address Book Server normalizes phone numbers for numbers read from the OCS’ Rtc database and then writes the normalized numbers into the address book files and address book database. Among its daily tasks, the Address Book Server generates a set of compressed full files and delta files for use by the Address Book File Download Service. These files are stored in a standard NTFS folder. The advantage of the full file and delta file generation is that it minimizes the impact of the client download. When an Office Communicator 2007 R2 or Office Communicator Phone Edition 2007 R2 client logs on to its Enterprise pool or Standard Edition Server, it uses a configured URL to the Web Components Server Address Book location. IIS (Web Components Server) then retrieves the AB file via the virtual directory pointing to the NTFS folder. By using this URL, the client retrieves a full file the first day it connects to the server and, under most conditions, delta files on subsequent days. Relative to OCS 2007, a key architectural improvement for Address Book services in OCS 2007 R2 is the addition of an Address Book Web Query Service for mobile clients such as Communicator Mobile 2007 R2. Rather than download potentially large address book files, Communicator Mobile R2 clients make on-demand address book queries to the Address Book Web Query Service. NOTE: The Address Book logic described in the following sections applies to all OCS deployments except a few special environments with either a very large number of users or a relatively volatile Directory. For such environments, OCS Address Book logic behaves differently in a small number of aspects, resulting in slight improvements in CPU and/or network efficiency. Exceptions for special environments are called out separately in the sections below. Address Book Server: File and Database Generation This section covers the address book process and the functions of the ABServer.exe process. Address Book Server Data Flow The address book data is retrieved from Active Directory, stored in the RTC database, extracted from the RTC database, and then placed in files and the RTCAb database for use by various clients. The following steps are performed:  User Replicator (UR) reads the new or modified (that is, added, deleted, changed) user and contact object information from Active Directory and writes it into the RTC database. This process runs every 60 seconds.  ABServer.exe reads the address book information from the RTC database and generates two sets of full and delta (that is, contains only the changes) address book files for use by Office Communicator (that is, with the file extension *.lsabs) and Office Communicator Phone Edition (that is, with the file extension *.dabs). These files are placed in a NTFS directory. ABServer.exe also creates a full database (that is, RTCAb) that is used by the Address Book 247 Web Query Service. By default, ABServer runs on a daily basis at 01:30. Also all phone numbers that cannot be normalized are placed into a .txt file in the same NTFS folder.  Office Communicator, Office Communicator Phone Edition, and other related clients download either the full or delta file on a daily basis. They are access either through a file URL (also called a UNC path) to the NTFS folder or through a HTTPS URL (or HTTP if configured). The address book entries are then stored locally in the GalContacts.db and potentially in GalContactsDelta.db.  Office Communicator Mobile clients leverage the Address Book Web Query Service, which leverages the latest daily updates in the RTCAb database. Address Book Server Process The Address Book Server process (C:\Program Files\Microsoft Office Communications Server 2007 R2\Server\Core\ABServer.exe) is responsible for generating the address book files (that is, *.lsabs and *.dabs), address book database (that is, RTCAb), and normalizing phone numbers (optional). This process is automatically run daily on one of the Office Communications Server Front End Servers. By default, the first server added to the Office Communications Server pool is given this role. The following table lists the various command-line options. Table 1. ABServer.exe Command-Line Options Command line options Command line option Description arguments -? None Displays all command switches for ABServer.exe. -syncNow None Manually synchronizes the Address Book Server by pausing the service to perform synchronization, and then restarting the service. If you are in a failover scenario and failing over from one server to another and syncNow does not work, check the load-balancer settings. The health monitor for incoming port 135 should point to 5060 (or 5061) on the servers. By default, it will point to 135 on the servers and since 135 is always up when the computer is running the server remains marked as being up even though Office Communications Server Front 248 Command line options Command line option Description arguments End service is down. -regenUR None Forces user replication regeneration. -dumpFile input-file [output-file] Input-file [output-file] Dumps the input file given as the first argument, formatted as text, to the output file given as the second argument. If the second argument is not given, the output file name defaults to the same path and file name as the input file with a .txt extension appended. -testPhoneNorm Phone-number Loads the normalization rules text file and attempts to normalize the phone number arguments. The results are displayed in the command-line window. If the phone number argument contains spaces, the phone number must be enclosed in quotation marks (that is, “ “). -validateDB None Validates the schema and user data in the database. -dumpRules None Displays all rules currently in effect, including generic and custom rules. ABServer.exe also makes use of the following MSFT_SIPAddressBookSetting WMI properties that control its behavior. Table 2. ABServer.exe WMI Properties Property name Type Default value Description MaxDeltaFileSizePer centage Integer 1250 Delta file is not created if percent change is greater than this number. (1250 INVALID USE OF 249 Property name Type Default value Description SYMBOLS 12.5%) OutputLocation String None File location, a valid folder. RunTime Integer(0 to 2359) 130 Service start time based on local time.(130 INVALID USE OF SYMBOLS O1:30 or 1:30am) SynchronizedPollingIntervalSecs Integer 300 Number of seconds between checks for synchronization. UseNormalizationRules Boolean True Flag to perform normalization or not. PartitionOutputByOU Boolean False Flag to partition data by organizational unit (OU). IgnoreGenericRules Boolean False Flag that determines whether or not to use the built-in generic rules. Additionally, there are static Address Book Server settings that are compile-time constants in the code as follows:  Output file extension = .lsabs  NumberOfDaysToKeep = 30 By default, the SQL maintenance interval is set for 02:00 local time each day. If the Address Book Server runs during this time, its performance is likely to degrade. For this reason, the Address Book Server runs by default at 01:30 local time each day which gives it 30 minutes to complete before it overlaps with the SQL maintenance interval. The service can be configured to run and generate the files in the Address Book Server file store at another time by configuring the MSFT_SIPAddressBookSetting::RunTime WMI setting. You can also force the Address Book Server to do a synchronization pass immediately by using the command ABServer -syncNow. This command is useful in case the address book files are accidentally deleted. You can also use it for testing purposes. ABServer.exe generates various files for use by the Address Book File Download service and a database for use by the Address Book Web Query service. 250 For detailed information about the ABServer.exe process and the WMI attributes, see Administering Address Book Server in the Administering Office Communications Server 2007 R2 documentation. Address Book Server: Address Book File Download Service This topic describes how the address book file download service works. File Generation ABServer.exe generates two sets of files for use by 2 groups of clients. For clients that typically have sufficient local storage space, ABServer.exe generates a file containing the full address book that contains a large set of user and contact object attributes. To optimize download efficiency, it also generates up to 29 delta files that contain incremental updates containing the last one day, two days and up to 29 days worth of changes. These files have the *.lsabs file extension. For clients that have limited local storage such as Microsoft Communicator Phone Experience, ABServer.exe generates a full address book file and up to 29 delta files that contain a restricted set of user and contact object attributes. These files have the *.dabs file extension (that is, device Address Book Server). In Office Communications Server Standard Edition, the Address Book files are stored by default in <drive>:\%ProgramFiles%\Office Communications Server 2007 R2\Web Components\Address Book Files\Files. In Enterprise Edition, the Address Book file store is a shared NTFS folder that the administrator manually creates during setup. The data gathered by the Address Book Server is stored in a binary format in compressed files to minimize storage requirements. The number of days that the delta files are kept is set at the static value of 30 days, and this number cannot be changed. After 59 days (the first 29 days after a fresh start will contain fewer delta files), the Address Book Server reaches a steady state where a set of up to 1800 files, which contain up to 900 *.lsabs and 900* .dabs files, each of which includes 30 full files and up to 870 (that is, 30 days * 29 files/day) delta files. Each time the Address Book Server starts, it determines whether there are data files in the output directory. If no data files are found, it will generate one full file. A delta file is not generated if there are no initial full files from previous days to compare against. The output files are written to the Address Book file store, a folder that can be assigned an access control list (ACL) by using the standard NTFS share permissions. The following table shows how the full files and delta files are generated for both *.lsabs and *.dabs files. Table 1. File Generation Day Day 1 Generated and deleted *.lsabs Generated and deleted *.dabs files files Full (F1) Full (F1) 251 Day Generated and deleted *.lsabs Generated and deleted *.dabs files files Full (F2) Full (F2) Delta of F2 - F1 Delta of F2 - F1 Full (F3) Full (F3) Delta of F3 –F2 Delta of F3 –F2 Delta of F3 –F1 Delta of F3 –F1 Full (F4) Full (F4) Delta of F4 - F3 Delta of F4 - F3 Delta of F4 - F2 Delta of F4 - F2 Delta of F4 - F1 Delta of F4 - F1 Day 5-29 … … Day 30 Full (F30) Full (F30) (reaches a steady state) Delta of F30-F29 Delta of F30-F29 Delta of F30-F28 Delta of F30-F28 … … Delta of F30-F1 Delta of F30-F1 Day 31 Full (F31) Full (F31) (now needs to start deleting files older than 30 days) Delta of F31-F30 Delta of F31-F30 Delta of F31-F29 Delta of F31-F29 … … Delta of F31-F2 Delta of F31-F2 All files from D1 are deleted. All files from D1 are deleted. Full (F32) Full (F32) Delta of F32-F31 Delta of F32-F31 Delta of F32-F30 Delta of F32-F30 … … Delta of F32-F3 Delta of F32-F3 All files from D2 are deleted. All files from D2 are deleted. 30 Full files + 30 days of up to 29 delta files/day = 900 files 30 Full files + 30 days of up to 29 delta files/day = 900 files Day 2 Day 3 Day 4 Day 32 Maximum Total Files (Steady State) 1800 files By default (that is, without organizational unit (OU) partitioning), all data files are stored in one directory. File names for full files are of the form F-xxxx, where xxxx is the file creation date 252 expressed as the hexadecimal 0-based number of days since January 1, 2001. Delta file names are of the form D-xxxx-yyyy.lsabs, where xxxx is the full file creation date, and yyyy is the delta file creation date. Files are also assigned the appropriate *.lsabs or *.dabs file extension. Files are created in memory and are written using a file handle that is created with no sharing allowed so that client applications cannot access a file before it has been completely written. Note: Exception: If a delta file size gets to beyond a certain percentage of the Full file size, a new Full file is generated instead of the incremental delta file. This percentage is specified by the server variable MaxDeltaFileSizePercentage. The default value for this is 1250, or 12.5%. If this percentage is surpassed on the size of the server-side delta file, the server produces a full file instead of a delta file. In this case, the server generates fewer than 30 days of delta file information, which is an exception to its normal logic. If this number is set to a higher value, the chances of forcing a full download decreases. However, there is more client-side processing required to update its local database. Additionally, any change to any attribute of an address book entry causes the entire record to be updated. For example, if the Mobile phone number changes, the entire user address book entry is updated. Organizational Unit and Address Book File Generation It is possible to create different sets of address book files based on the Organizational Unit (OU) property in Active Directory. For example, Active Directory could leverage OUs to partition the Active Directory into two or more logical groups based on business unit (for example, Automotive, Marine) or business function (for example, Sales, Engineering, Manufacturing). By setting the MSFT_SIPAddressBookSetting:PartitionOutputByOU WMI property to True, ABServer.exe creates a number of sets of address book files in a tree of folder names that map to the OU. This setting is passed to clients, which in turn access the address files under the appropriate subdirectory as indicated by the user or contact object’s OU path setting. PartitionOutputByOU can be leveraged in cases in large organizations where it is desirable to restrict the number of contacts or the size of the address book files that are accessed by groups of clients. It is also leveraged in Office Communications Server hosting environments where you need to partition users based on the company. Client and Address Book Server Communication The Address Book URLs (that is, one internal and one external) are the paths that clients use to access the data files in the Address Book Server file store. These URLs are configured under the Address Book tab in the Web Components Properties for the given Standard Edition server or Enterprise pool, and are retrieved through in-band provisioning (absInternalServerUrl and absExternalServerUrl) by the client when it logs on to its Standard Edition server or Enterprise pool. The clients can also have these URLs configured through Group Policy Objects. 253 Office Communicator needs to be configured to access the Address Book file store by using an URL defined in one of the following formats:  HTTPS Format. A secure HTTP (HTTPS) URL is the recommended methodology for accessing address book files. HTTP can also be used but is not secure. This method uses the Internet Information Services (IIS) HTTP server(s) which is the core component of the Web Components Server. If you require the file store to be accessible by remote users who are connecting outside the intranet (outside the firewall), the IIS server is required and you must configure HTTPS on your virtual server.  File URL Format. The file URL (also called an UNC path) is the other method for accessing address book files. This approach is not recommended because you cannot use it for remote access. The file URL is a standard file URL in the format \\server\share. Standard share and NTFS permissions are applicable to this URL. The clients connect to the file store through the Server Message Block (SMB) protocol. There are two cases when a File URL cannot be used: when remote access is required and if the Office Communications Server pool is set to require encryption. In both of these cases, a HTTPS URL is required. Note: If your clients use an HTTPS URL to access the Address Book Server file store, verify that the client certificate is already trusted by Internet Explorer prior to an attempt by clients to access the Address Book URL. If the client certificate is not trusted, the download fails. The user is not prompted to check the certificate and to configure it as trusted. Consider using a certificate that is trusted by default on your client. The type of authentication required for an Address Book URL varies depending on whether the URL is used for internal or external clients. The following table shows the supported authentication for each type of URL. Table 2. Supported Authentication for Address Book URLs Address Book URL Type Authentication Internal Integrated Windows Authentication (NTLM or Kerberos) External NTLM or HTTPS (basic over Secure Sockets Layer (SSL)) Address Book and Office Communicator The Address Book Client Provider is a module within Office Communicator that is responsible for synchronizing global address list (GAL) contacts with the Office Communicator contact database. Since all GAL contacts are read-only, this synchronization is a one-way process as follows: 1. Office Communicator logs on to the Enterprise pool or Standard Edition server using its logon logic. 254 2. Office Communicator accesses the internal and external address book shares by using the URLs provided either by the Group Policy Object (GPO) ABSInsideURL and ABSOutsideURL policy settings, or by retrieving them from the server during the logon process. These URLs are in either HTTPS, HTTP, or File URL format. The GPO settings take precedence over the settings retrieved from the server. If these GPOs are not set and depending on the setting of the AbsUseFallback Group Policy setting, the URLs are retrieved from either the Enterprise pool of the Standard Edition server. For details about these GPOs, see Deploying Communicator in the Client Planning and Deployment documentation and the Microsoft Office Communications Server 2007 R2 Group Policy Settings documentation at http://go.microsoft.com/fwlink/?LinkID=140494. 3. Office Communicator determines whether it is connecting from inside the intranet or connecting from outside through an Access Edge Server and then selects the appropriate URL for the connection. The logon credentials of the Office Communicator client are used to connect to the selected Address Book Server URL. Office Communicator uses the standard Internet Explorer application programming interface (API) to perform the URL authorization. If access is denied, one of the following occurs:  If the user is inside the intranet, the client displays an icon indicating an Address Book download failure. The user is not asked for credentials again.  If the user is outside the intranet, the user is prompted to enter proper URL credentials. Note: Office Communicator supports the use of a fallback URL for high availability. For details about configuring additional URL entries, see Using WMI to Configure Address Book Server Settings in the Administering Office Communications Server 2007 R2 documentation. Client Download Process If a client is accessing the URL for the first time and successfully connects, the client attempts to download the current full data file. On subsequent days, the client attempts to download a delta file based on the last full synchronization date. During daily client usage, this delta file is based on the previous day’s changes. If the client is offline for a day or more, it determines which delta file it must download to get up to date. For example, if the client is offline from Friday afternoon to Monday morning, it will attempt to download a delta file containing 3 days of changes. If the client is offline for more than 30 days, it is forced to attempt to download the full data file. The client stores this information in the local GalContacts.db database. Storing this information in a local database reduces the time taken to synchronize information on the client computer with the latest information stored in Active Directory, thereby significantly improving the GAL search process. The client will also create an index to the database which is stored in the file GalContacts.db.idx. In the event of a download failure because of network connectivity or other issues, the client retries in time intervals that doubles on each previous failure (that is, 1 minute, 2 minutes, 4 255 minutes, and so on, up to a maximum of 64 minutes, and then retries every 64 minutes). Any data that was downloaded before the failure is discarded, and the retry begins again at the beginning. If the failure persists for more than 24 hours, a warning is displayed, and an application event is added to the Event Log. When the client logs on, it determines if it has been more than 24 hours since the last download. If so, then the current download occurs immediately. Otherwise, download is scheduled at 00:00 UTC (Universal Coordinated Time, also known as GMT). The following exceptions apply:  If the address book contains over 50K entries, the client maintains a separate delta database GalContactsDelta.db and index GalContactsDelta.db.idx for GAL contacts, and periodically merges updates into its main database GalContacts.db. This helps reduce the processing required on a daily basis on the client machine in very large environments.  There are conditions when the server will not generate some of all of the delta files on the server. This happens when the MaxDeltaFileSizePercentage is exceeded. In this case the client will be forced to download the full address book file. This effectively causes the GalCaontacts.db to be completely replaced. Whenever a full download occurs in the case where there are over 50K entries, the GalContactsDelta.db database will be emptied (as there are no deltas).  An additional client-side case is when the client cannot access the relevant delta file (that is, possibly locked, access denied, or not created due to time zones and file download time). In this case the client attempts to access relevant older delta files (that is, up to 2 additional days back). For example, after logging on at 09:00, the client cannot access a delta file containing 4 days of changes on Wednesday (after the files have been generated at 01:30). The client tries to access the delta file generated on Tuesday containing 3 days of changes, and if that cannot be accessed, it tries to access the delta file generated on Monday with 2 days of changes. After successfully accessing one of these older delta files, the client does not try to access additional files until the next day. Although the client does not obtain the latest changes, it will likely get some previous changes, which in turn minimizes the amount of deltas it needs to process the following day. Internet Explorer Dependencies Because Office Communicator uses the standard Internet Explorer API to perform the URL authorization, it depends on the following Internet Explorer settings:  Security Settings, including the intranet URL settings. For example, if you are using an Internet (that is, external) type of URL, such as http://server.com/share, for intranet (that is, internal) users instead of an intranet URL, such as http://server/share, unless this URL is configured explicitly as an intranet URL in Internet Explorer, Office Communicator ignores this entry. We recommend that you use an intranet URL for internal users. If you have a specific need to use an Internet URL, you must manually configure this URL as an intranet URL in Internet Explorer, or you must use an Active Directory group policy to configure the URL. 256  Proxy Settings. If you use an HTTP proxy to manage your Web traffic and the Address Book data flows through this proxy, the client cannot access these URLs if the proxy becomes unavailable or if authorization problems occur with the proxy. File Store Recommendations and File Size Guidelines As a best practice, store Address Book data files on separate storage. The storage can be any of the many types, for example a direct access storage device (DASD) or a storage area network (SAN). The storage needs specific to the Address Book Server are very minimal and are expected to be in the range of 20 MB to 5 GB, depending on the number of users in the forest. The size of the full data files depends on the number of users and contacts stored in your Active Directory. The size of the delta files increases with the number of daily changes that occur to users and contacts in Active Directory. A large number of changes increases the delta file size and the time it takes to generate the delta files. On average the *.dabs files are about 25% of the size of the *.lsabs files. This depends on the number of fields that are typically populated. Office Communicator Local Address Book Database Files Office Communicator 2007 R2 stores the local address book database and in the directory: <drive>:\%LOCALAPPDATA%\Microsoft\Communicator\<user>\ The following table shows sample address book files for an organization with approximately 250,000 address book entries (that is, users, contact objects). The file sizes vary depending on various factors such as the number of address book fields that are populated. Table 3. Sample Address Book Files Name Date modified Type Size GalContacts 6/5/2009 9:32 AM Data Base File 99,156 KB GalContacts.db.idx 6/5/2009 9:32 AM IDX File 52,394 KB GalContactsDelta 6/12/2009 8:30 AM Data Base File 3,696 KB GalContactsDelta.db.idx 6/12/2009 8:30 AM IDX File 2,122 KB Address Book and Office Communicator Phone Edition The file download process on the Office Communicator Phone Edition (IP Phones) and related devices is similar to on the process for Office Communicator, with the main difference being that it downloads the smaller *.dabs files. These files contain a limited set of attributes, specifically displayName, msRTCSIP_PrimaryUserAddress, telephoneNumber (that is, office), and mobile (that is, telephone number). Although this search experience is not as robust as that of Office Communicator, it is fairly effective. Additionally many users do not use the text search capability on IP Phones because it is not as easy to use as using a keyboard with Office Communicator. 257 Additionally predictive text searches may seem to return unexpected results, match phone numbers and names, and have a limited screen for showing result sets. The IP Phones locally implement a method of doing predictive search, enabling a user to query address book text names by using dial pad digits. For example, the digit 2 could map to an “A”, “B” or “C” and 6 could map to “M”, “N” or “O”. Thus, the digit sequence “226” would match address book entries with the name “Cam”, “Bam”, “Can”, and so on. Address Book Web Query Service In enterprise environments, Address Book files can get too large to be reasonably downloadable by mobile clients, such as Communicator Mobile (2007 R2 release). To better target the needs of mobile clients, Office Communications Server 2007 R2 introduces a parallel path for Mobile Address Book data: The Address Book Web Query Service, which leverages the RTCAb database to provide on-demand address book queries for mobile clients. Address Book Server: Address Book Web Query Service The Address Book Web Query Server queries are passed by the client to the Address Book Web Query server by HTTPs (or HTTP if configured). The internal and external URLs are configured on the server under which are leveraged for both Address Book Web Query Server and Distribution List Expansion. These URLs are then passed to the clients through the dlxInternalUrl and dlxExternalUrl in-band provisioning settings. Queries are sent to the Address Book Web Query Server by using HTTPS (or HTTP if configured through the URL). The ASP.net first pre-processes the query and forms an SQL query, which is executed by the SQL Server (or SQL Server Express for SE) using the RTCAb database. Next, post-processing of the results occurs (that is, constructing the information to be sent to the client). The query results are then returned to the client. Following are sample URLs for internal and external Address Book Web Server queries. The specific search attributes are not included. The following table lists the RTCAb database fields that are extracted from the RTC database by ABServer.exe. Table 1. RTCAb Database Fields Name Active Directory name Attribute ID Example Display Name displayName 4 “Sara Davis”, “Dan G Fennell” Office Number telephoneNumber 10 1.425.555.0101 Mobile Mobile 13 1.425.555.0198 258 Name Active Directory name Attribute ID Example SIP Address msRTCSIP_PrimaryUserAddress 9 sarad@contoso.com Primary email address proxyAddress 18 sarad@contoso.com , sara.davis@contoso.com Number The RTCAb database is designed so that additional search fields can be easily added to the database (adding additional fields is currently not supported). The example in the following table shows sample data in the AbAttributeValue table, which is the primary table in the RTCAb database that is used for queries. The UserID column maps to an address book entry (for example, a user or contact object). The AttrID column identifies the attribute (see the previous table), the Value column is the alpha-numeric value of the attribute (for example, “Bill Malone”), and the DTMF column encodes the string value in a numeric format for predictive text dial pad. Table 2. Sample AbAttributeValue Table Ptrn UserId AttrId Value DTMF (dial pad index) 1 365649 10 +1 (425) 5550198 X50198 1*425*5550198*50198 1 365649 10 14255550198 14255550198 1 365649 10 4255550198 4255550198 1 365649 10 5550198 5550198 1 365649 10 0198 0198 1 365649 4 Bill Malone 2455*42837 1 365649 9 Billm 24556 1 365649 9 billm@contoso.com 24556126686761266 1 365649 17 billm@contoso.com 24556126686761266 1 365649 18 billm@contoso.com 24556126686761266 1 365649 18 billm@msg.Contoso.com 245561674126686761266 1 365649 18 billm@titanium.contoso.com 24556184826486126686761266 1 365649 18 billmcontoso.com 2455626686761266 1 365649 18 2455626686761266 24556674126686761266 1 365649 18 billmtitanium.contoso.com 2455684826486126686761266 259 Note: The digit 1 in the dual-tone multifrequency (DTMF) interface is used for various characters (for example, !, @, ., -) and the digits 0 and 1. The symbol * is used to represent a space or other separators. Office Communicator Address Book Queries Currently, Office Communicator is the only client that leverages the Address Book Web Query Service. The Address Book Web Query Service supports a wide set of query options. The following table contains the parameters and default values that can be processed by the Address Book Web Query Service. Although it is not possible for users or administrators to modify this query, this table helps demonstrate how Address Book Query works and how queries may differ for future clients that may leverage this service. Table 3. Parameters and Default Values Parameter Type Default Notes QueryString String Dial Boolean True Determines whether a predictive search query is performed (for example, dial pad queries that leverage the DTMF index) PrefixQueryAttributes String displayName, msRTCSIPPrimaryUserAddress, proxyAddress, telephoneNumber, mobile Attributes where a SQL LIKE comparison operator is used (for example, “Cam” matches “Cameron) ExactQueryAttributes String displayName, msRTCSIPPrimaryUserAddress, proxyAddress, telephoneNumber, mobile Attributes where a SQL = comparison operator is used (for example, “Cam” does NOT match Expression for the query 260 Parameter Type Default Notes “Cameron”) RequestTimeout Query timeout MaxResult Int 50 Maximum results to return ReturnAttributes String givenName, sn, displayName, mailNickName, physicalDeliveryOfficeName, msRTCSIPPrimaryUserAddress, proxyAddress, telephoneNumber, homePhone, otherHomePhone, mobile, otherMobile, otherTelephone, ipPhone, mail, manager Default set of attributes to be returned to the user. Many of these attributes cannot be used in the query string expression The following table lists parameters that Communicator Mobile uses. These are hardwired into Communicator Mobile and cannot be changed. Table 4. Communicator Mobile Parameters Parameter Type Default Notes QueryString String Dial Boolean False Does not support dial pad queries PrefixQueryAttributes String displayName, msRTCSIPPrimaryUserAddress, proxyAddress, telephoneNumber, mobile Uses prefix match (SQL LIKE) ExactQueryAttributes String Expression for the query RequestTimeout Query timeout MaxResult Int 20 Saves network bandwidth ReturnAttributes String givenName, sn, displayName, mailNickName, physicalDeliveryOfficeName, msRTCSIPPrimaryUserAddress, Default set of attributes to be returned to the user. Many of these attributes 261 Parameter Type Default Notes proxyAddress, telephoneNumber, homePhone, otherHomePhone, mobile, otherMobile, otherTelephone, ipPhone, mail, manager cannot be used in the query string expression Queries on Display Name Currently the Address Book Server only supports name-based queries based on display name. It does not support queries based on the Active Directory entries for last name (that is, SN), first name (that is, givenName), and so on. It may also match the user part of the Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) or e-mail address. To support names typed in different orders (for example, “Sara Davis”, “Davis, Sara”, and “Davis Sara”) and users with multiple first or last names (for example, “Pablo Rovira Diez”), multiple entries are placed into the AbAttributeValue table for the display name. For example, the following entries are placed in the table for Pablo Rovira Diez: Pablo Rovira Diez Diez Pablo Rovira Diez, Pablo Rovira Rovira Diez Pablo Rovira Diez, Pablo Since the Address Book Web Query Service leverages the SQL LIKE string matching expression, all of the following strings will match at least one of the table entries, and will return “Diez Pablo Rovira” as a match (in addition to other possible matches). Pa Pablo Pablo Rovira Diez Pablo Diez, P Rovira Rovira Diez P Rovira Diez, P However the following strings will not create a match: Rovira Pablo Pablo Diez The general case for display name index generation is as follows:  Simple Case 262   DisplayName = "A B" will support  AB  B a (Inversed)  B,A (Inversed with Comma)  Generates 3 indices Complex Case  Display Name = “A B C D E” will support  ABCDE  D E A B C (Last 2 words)  D,E A B C (Last 2 words with Comma)  E A B C D (Last word)  E, A B C D (Last word with Comma)  Generates 5 indices (no more, no less) In the case where there are more than two words in the last name, the index based on the display name will most likely need to be leveraged to obtain the desired match. Queries on Phone Numbers To support practical queries based on phone numbers, a number of indices are created. By leveraging the SQL LIKE expression (that is, partial match), you can use a number of useful options for searching phone numbers. The RFC 3966/E.164 phone number “+1.425.555.0101” will get entries with the following indexes:  +1.425.555.0101  4255550101  5550101  0101  14255550101  Tel:+14255550101  14255550101 The RFC 3966/E.164 phone number “+01 (23) 456789 x01” will get entries with the following indexes:  +01.23.456789.01  012345678901  2345678901  45678901  01  0123456789  Tel:+0123456789;ext=01 263 Address Book Web Query also pre-processes queries to remove any extraneous symbols. For example, the string +1(425) 555-0101 would be translated to 14255550101 before running the query. Sorting Query Results Currently, Communicator Mobile only retrieves for the first 20 matches for a given query. The Address Book Query Server searches for the first 100 matches for any query, of which only the first 20 entries in the result set are passed back to the client (that is, based on the actual query sent by the client). For performance reasons the Address Book Query Server does not attempt to process more than 100 matches. For example, if a user tries to query “Bo”, only the first 100 matches that SQL Server finds are returned. In cases where there are more than 100 potential matches, the query does not fetch every attribute that begins with a “Bo” (for example, every user with a first name or last name that begins with a “Bo”, a SIP URI that begins with a “Bo”, and so on) and sort them, as this would take up significant database cycles. Although this is not optimal, it achieves a decent tradeoff between functionality and performance. In general, most users refine their query and re-submit it rather than scrolling through pages of query results. There are a few issues when a user attempts to search for a common name. For example, if a user searched for “Daniel” and there were more than 100 “Daniels” in the address book, 100 random matches would be returned and subsequently sorted. The user may see “Daniel Park” and “Daniel Taylor” sequentially and assume that “Daniel Roman” (that is, alphabetically between Park and Taylor) is not in the address book. However, this is not necessarily the case because “Daniel Roman” may not have been in the set of 100 entries returned and would not be presented in the list. In this case the user would be expected to enter a more refined query. Predictive Text Queries The AbAttributeValue database table also has a column for DTMF queries. This is a special index created to support predictive text queries where telephone dial pads are used to enter queries. For example, the digit 2 could represent an “A”, “B” or “C”. Thus if a user keyed in “226”, it would match any existing entries that start with “226” in the DTMF column (for example, “Cam”, “Cameron”, “Candice”, “Bam”, etc.). Although this query is supported by the Address Book Web Query Server, there are no clients that currently leverage this interface. Note: Communicator Mobile performs numeric matches on office and mobile phone numbers and any SIP or e-mail address that leverages digits. However these queries do not leverage the predictive text query algorithms. Address Book Web Query Database The Address Book Web Query RTCAb database is collocated as a separate SQL Server instance on the same SQL Server as the RTC database for the given pool. The database leverages the same high availability features as the RTC database. The database should also be included in 264 any backup plan, although historical copies are not relevant and the database can be regenerated by using the ABServer –syncnow command. The database is implemented by using two database partitions, where each partition contains a complete copy of the address book. At any given point in time, one partition is active, which means it is being used by Address Book Web Query Server for handling queries from clients. The other partition is then available to the ABServer.exe process for the next nightly update. After the update process is finished (that is, committed to the database), this new partition becomes active. This technique helps enable optimal performance as there are no locking contention issues in the database (that is, all queries are read-only). The size of the RTCAb is modest and is dependent on the number of contacts in the address book and the number of fields populated. SQL Server also reserves significant space for the creation and maintenance of the database and various indices. Address Book Web Query Database Language Support The Address Book Web Query RTCAb database currently uses the Latin1_General_CI_AI (that is, Case Insensitive, Accent Insensitive) database collation. In SQL Server, collations control various language-specific rules for how comparisons (that is, SQL = and LIKE) and sorts (that is, SQL ORDER BY) behave. The Latin1_General collation supports various Latin-based languages that have the same superset of order and sorting rules, including Dutch, English, German, Italian, and Portuguese/ Brazilian. There are languages where the general rules of Latin largely apply to (for example, Modern Spanish and French) but may have some subtle issues around comparison and sorting (for example, certain ligatures may not be correctly sorted). For other languages, such as Japanese and Simplified Chinese, where the rules of Latin have no influence, sorting and comparison are dictated by the underlying characteristics of Unicode. In languages with a large number of characters, users often rely on exact match and not necessarily matches based on a partial letter match. Not having correct alphabetical ordering may not be as much of an issue as it is with languages like English. Address Book Web Query Server Performance The Address Book Web Query Server and RTCAb database generally only have a minimal impact on performance the Web Components Server (typically running on the Front-End servers) and the back-end server. Currently, only the Communicator Mobile clients use Address Book Web Query Server and queries on this device are explicitly controlled by the user when they use the Search function, as opposed to being performed automatically as a user types in a name or phone number. The Address Book Web Query ASP.net process is relatively lightweight and the back-end database processing is all read-only queries on a database that is updated once per day. The Address Book Query service does not pose any significant performance bottleneck, and whatever impact it has can be resolved by general performance tuning on the front-end and back-end servers. 265 Address Book Server: Advanced Address Book Features This topic discusses advanced Address Book Server features, like phone number normalization, User Replicator, and filtering. Address Book Server Phone Number Normalization Office Communicator requires standardized RFC 3966/E.164 phone numbers. To use phone numbers that are unstructured or inconsistently formatted, Office Communications Server relies on the Address Book Server to perform phone number translation in conjunction with mapping rules. If the UseNormalizationRules WMI property is set to TRUE, ABServer.exe reads the phone numbers from the RTC database, normalizes them (if necessary), and then writes the normalized values into the address book (that is, download) files and the Address Book Web Query database RTCAb. Clients, such as Office Communicator and Communicator Mobile, can use these normalized numbers. You can apply two types of rules to phone numbers. One type is the set of generic rules that are automatically performed by the server. The other type is a set of sample company rules that can be edited and is included in the installation folder alongside ABServer.exe. The sample company rules include a comment at the start of the file informing the administrator that if they want specific rules for their company, they should copy the sample file to the output location for the pool and change the name to Company_Phone_Number_Normalization_Rules.txt, so that it will be used for future synchronization passes. If the UseNormalizationRules WMI flag is set to TRUE, the rules are applied to those Active Directory attributes with 0x2000 bit set in the Flags column value. If the 0x1000 bit is set in the Flags column value, the associated Active Directory attribute value is always normalized. Sample_Company_Phone_Number_Normalization_Rules.txt is the sample file in which you configure rules specific to your company requirements. To use this file, copy it to Company_Phone_Number_Normalization_Rules.txt. Otherwise, Address Book Server will use only the generic rules configured by default on the server. Note: When you remove the Address Book Server, Company_Phone_Number_Normalization_Rules.txt is not deleted. If you want to remove this file, you must delete it manually. User Replicator and Address Book Server The Address Book Server uses data provided by User Replicator to update the information that it initially obtains from the global address list (GAL). User Replicator writes the Active Directory attributes for each user, contact, and group into the AbUserEntry table in the database and the Address Book Server syncs the user data from the database into files in the Address Book Server file store and into the Address Book Web Query database RTCab. The schema for the AbUserEntry table uses two columns, UserGuid and UserData. UserGuid is the index column and contains the 16-byte GUID of the Active Directory object. UserData is an image column which contains all of the previously mentioned Active Directory attributes for that contact. 266 User Replicator determines which Active Directory attributes to write by reading a configuration table located in the same SQL instance as the AbUserEntry table. The AbAttribute table contains three columns, ID, Name and Flags. The table is created during database setup. If the AbAttribute table is empty, User Replicator skips its AbUserEntry table processing logic. Address Book Server attributes are dynamic and are retrieved from the AbAttribute table, which is initially written by the Address Book Server when the Address Book Server is activated. Address Book Server activation populates the AbAttribute table with the values needed to support Office Communicator 2007 R2. The following table shows those current values. Table 1. AbAttribute Table Values ID Name Flags 1 msExchHideFromAddressLists 0xFF000003 2 givenName 0x01000000 3 Sn 0x02000000 4 displayName 0x03020000 5 Title 0x04000000 6 mailNickname 0x05000400 7 Company 0x06000000 8 physicalDeliveryOfficeName 0x07000000 9 msRTCSIP-PrimaryUserAddress 0x08020800 10 telephoneNumber 0x09022800 11 homeNumber 0x0A002800 12 otherHomeNumber 0x0A002000 13 Mobile 0x0B022800 14 otherMobile 0x0B002000 15 otherTelephone 0x0C002000 16 ipPhone 0x0D002000 17 Mail 0x0E000000 18 proxyAddresses 0x00000105 19 groupType 0x0F010800 20 ManagerouPathId 0x10000000 21 0x11000800 267 The numbers in the ID column must be unique and should never be reused. Also, keeping the ID values below 256 saves space in the output files written by the Address Book Server. However, the maximum ID value is 65535. The Name column corresponds to the Active Directory attribute name that User Replicator should put in the AbUserEntry table for each contact. The value in the Flags column is used to define the type of attribute. The following types of Address Book Server attributes are recognized by User Replicator, indicated by the low byte of the value in the Flags column. Table 2. Address Book Server Attributes Recognized by User Replicator Attribute Description 0x0 A string attribute. User Replicator converts this type to UTF-8 before storing it in the AbUserEntry table. 0x1 A binary attribute. User Replicator stores this in the blob without any conversion. 0x2 A string attribute, but is included only if the attribute value begins with "tel:". This is primarily for multi-valued string attributes, specifically proxyAddresses. In this case, Address Book Server is interested only in proxyAddresses entries that begin with "tel:". Therefore, in the interest of saving space, User Replicator stores only the entries that begin with "tel:". 0x3 A Boolean string attribute, which if TRUE causes User Replicator to not include this contact in the AbUserEntry table. If FALSE, it causes User Replicator to include the attributes for this contact in the AbUserEntry table, but not the particular attribute with this flag. This is another special case type that is primarily for the msExchHideFromAddressLists attribute. 0x4 A string attribute, but is included only if the attribute value begins with "smtp:" and includes the "@" symbol. 0x5 A string attribute, but is included only if the attribute value begins with either "tel:" or "smtp:" and includes the "@" symbol. 0x100 If set, this is a multi-valued attribute that can appear more than once for each contact. 268 Attribute Description 0x400 If set, this identifies the e-mail alias attribute for a contact. Address Book Server uses this flag to identify which attribute value to show in the phone normalization event log entry. 0x800 If set, this identifies a required attribute for a contact. Address Book Server includes a user in the AbUserEntry table only if there is a value for this attribute in Active Directory. If there is more than one required attribute, only one of them is required to have a value to include the user in the AbUserEntry table. 0x1000 If set, Address Book Server always normalizes the value of this attribute. 0x2000 If set, Address Book Server uses the normalized number from proxyAddresses, if the UseNormalizationRules WMI setting is FALSE; otherwise it behaves the same as when the flag bit is 0x1000. 0x4000 If set, Address Book Server does not include objects in the AbUserEntry table that have this value for the specified attribute. For example, if the msRTCSIP-PrimaryUserAddress attribute has this flag bit set, then contacts that have this attribute are not written to the database. 0x8000 If set, Address Book Server does not include objects in the AbUserEntry table that do not have this value for the specified attribute. If both the 0x4000 and 0x8000 flag bits are set on an object, the attribute with the flag bit value set to 0x4000 takes precedence, and the object is excluded from the AbUserEntry table. 0x10000 If set, this represents a group object. User Replicator uses this flag bit to include contacts with the groupType attribute whose presence indicates a group (for example, a distribution list or security group). 0x20000 If set, User Replicator uses this flag bit to include this attribute in device-specific Address 269 Attribute Description Book Server files (that is, files with a .dabs extension). Filtering the Address Book The users populated in the Address Book Server files can be controlled based on certain Active Directory Attributes listed in the AbAttribute table. One such attribute used for filtering is the msExchangeHideFromAddressBook attribute. This is a user attribute added by the Exchange schema. If the value of this attribute is TRUE, Exchange Server uses this attribute to hide the contact from the Outlook GAL. Similarly, if the value of this attribute is TRUE, User Replicator does not include that user in the AbUserEntry table and this user will not be in the Address Book Server files. You can use some flag bits to define a filter to use on Address Book Server attributes. For example, the presence of certain flag bits can identify an attribute as an include attribute or an exclude attribute. User Replicator filters out contacts that contain an exclude attribute and filters out contains that do not contain an include attribute. Currently, there are three different filters. The following table lists these filers. Table 3. Filters Attribute Description 0x800 If set, this identifies a required attribute for a contact. User Replicator uses this flag bit to filter out contacts that do not contain at least one required attribute. The OuPathId is a required attribute, which is always set. So at least one of other required attributes should be set. Otherwise, contact (that is, with value of required attribute OuPathId) will still not be written to database. For example, if telephoneNumber and homePhone are defined as required attributes, only the contacts that have at least one of these attributes are written to the database. 0x4000 If set, this identifies an exclude attribute. User Replicator uses this flag bit to filter out contacts that contain this attribute. For example, if msRTCSIP-PrimaryUserAddress is defined as an exclude attribute, contacts that have this attribute are not written to the database. 0x8000 If set, this identifies an include attribute. User 270 Attribute Description Replicator uses this flag bit to filter out contacts that do not contain this attribute. For example, if msRTCSIP-PrimaryUserAddress is defined as an include attribute, only the contacts that have this attribute are written to the database. Note: If both the 0x4000 (exclude attribute) and 0x8000 (include attribute) flag bits are set, the 0x4000 bit overrides the 0x8000 bit and the contact is excluded. Although you can filter the Address Book to include only certain users, limiting entries does not limit other users' ability to contact the filtered users or to see their presence status. Users can always find, manually send instant messages, or manually initiate calls to users not in the Address Book by entering a user's complete sign-in name. Also, Office Communicator 2007 R2 can use contact information for a user in Outlook or the Windows Address Book. While having full contact records in the Address Book files enables you to use Office Communicator 2007 R2 to initiate e-mail, telephone, or Enterprise Voice calls (that is, if Enterprise Voice is enabled on the server) with users that are not configured for Session Initiation Protocol (SIP), some organizations prefer to include only SIP-enabled users in their Address Book Server entries. You can filter the Address Book to include only SIP-enabled users by clearing the 0x800 bit in the Flags column of the following required attributes: mailNickname, telephoneNumber, homePhone, and mobile. You can also filter the Address Book to include only SIP-enabled users by setting the 0x8000 (include attribute) in the Flags column of the msRTCSIP-PrimaryUserAddress attribute. This also helps to exclude service accounts from the Address Book files. After you modify the AbAttribute table, you can refresh the data in the AbUserEntry table by running the abserver.exe –regenUR command. After UR replication completes, you can update the file in the Address Book Server file store by manually running the abserver.exe –syncNow command. Management of Office Communications Server 2007 R2 Office Communications Server 2007 R2 provides several administrative tools to facilitate the management of servers and users in an Office Communications Server 2007 R2 deployment. This section provides a description of the tools and information about key management and operations tasks for Office Communications Server 2007 R2. In This Section 271  Administrative Tools Overview  Installation and Use of Administrative Tools  Troubleshooting for Office Communications Server 2007 R2  Load Balancers for Office Communications Server 2007 R2  Media Ports  Voice Quality of Service (QoS)  WMI Settings for Office Communications Server 2007 R2  Client Registry Keys/GPO for Office Communications Server 2007 R2  In-Band Provisioning over SIP Administrative Tools Overview Office Communications Server 2007 R2 provides dedicated administrative tools. To manage Office Communications Server 2007 R2, you can do either of the following:  Install the administrative tools on any server on which Office Communications Server 2007 R2 and its components are installed.  Install the administrative tools on a separate computer, such as a centralized administration console on which Office Communications Server 2007 R2 is not installed. Note: The Office Communications Server administrative tools are no longer installed automatically on servers running Office Communications Server, but you can install the tools by using the same Deployment Wizard that you use to install Office Communications Server 2007 R2. The exception is the Office Communications Server 2007 R2 Group Chat Server Configuration Tool, which is installed by default on each computer running Group Chat Server or the Group Chat Compliance service. Administrative Tools The following table describes the tools available for administering Office Communications Server 2007 R2 and its components. Table 1. Administrative Tools Tool Description Availability and use Office Communications Server 2007 R2 snap-in A Microsoft Management Console (MMC) snap-in that is the primary administrative tool for Office Communications Server 2007 R2 servers in an Active Directory domain. Available on any other computer in the domain on which the Office Communications Server 2007 R2 administrative tools are installed. It cannot be used to manage Edge Servers, 272 Tool Description Availability and use Proxy Servers, or other computers not in the domain. Use it to view and configure Office Communications Server 2007 R2 pools, servers, and users, including the settings for the servers and users on Standard Edition servers and in Enterprise pools that are in the Active Directory forest. Office Communications Server 2007 R2 management components for Active Directory Users and Computers Additional functionality for management of Office Communications Server 2007 R2 servers in Active Directory Domain Services (AD DS). It is required for initially enabling each user for Office Communications Server. You can also use it for managing user settings for Office Communications Server 2007 R2 users in the domain, based on the organizational unit (OU) or folder in which they reside, by using the Active Directory Users and Computers snap-in. Available in Active Directory Users and Computers on computers on which the Office Communications Server 2007 R2 administrative tools are installed, but can be used only if the server is in a domain. Office Communications Server 2007 R2 snap-in extension for the Computer Management console An MMC snap-in that is the primary tool for management of Office Communications Server 2007 R2 servers that are not in an Active Directory domain, such as Edge Servers in the perimeter network, as well as Proxy Servers. Available on any computer on which the Office Communications Server 2007 R2 administrative tools are installed. On the local computer, only server-level settings can be managed with this snap-in extension. If the local computer is not running Office Communications Server 2007 R2, you can use Computer Management to connect to an Office 273 Tool Description Availability and use Communications Server 2007 R2 server and then use the Office Communications Server 2007 R2 snap-in extension to manage the server-level settings of that computer. The 2007 R2 version of Communicator Web Access snap-in An MMC snap-in that is the primary administrative tool for Communicator Web Access. Available on any server in the domain on which the Office Communications Server 2007 R2 administrative tools are installed. Response Group Service snap-in An MMC snap-in that is the primary administrative tool for Office Communications Server 2007 R2 servers. Available in the Office Communications Server 2007 R2 snap-in. Response Group Configuration A Web-based tool that is used Tool to create and manage Response Groups. Installed with the Web Components Server or Standard Edition server. Any computer that is in the same forest as the server that is running the Response Group Service can use the Internet Explorer Internet browser to access the Response Group Configuration Tool. Office Communications Server 2007 R2 Group Chat Administration Tool A Group Chat tool to create categories and chat rooms, define their scope and membership, create federated users and groups, manage how users can use the chat rooms, and specify which users are administrators and managers. Can be installed on any computer in the domain available for installation of the Group Chat Administration Tool. Group Chat Server Configuration Tool A Group Chat tool to start, Available on any server stop, and configure Group running Group Chat Server or Chat Servers, configure the the Compliance service. Group Chat database, manage 274 Tool Description Availability and use compliance, and set logging levels. LCSCmd.exe RGSCOT.exe A command-line tool used to prepare Active Directory Domain Services, create Enterprise pools, perform XML-based logging, manage permissions, and install, activate, check the status of, or deactivate servers, as well as to perform backup and restoration operations for Office Communications Server 2007 R2 servers and Enterprise pools. Available on any computer in the domain on which the Office Communications Server 2007 R2 administrative tools are installed. A command-line tool used to create and manage Response Group Service Contact objects. Available on any server in the domain on which the Office Communications Server 2007 R2 administrative tools are installed. This tool is used initially for Active Directory preparation, and then for ongoing backup and restoration operations, so it is not covered in this documentation. For details about how to use this tool for Active Directory preparation and other command-line management tasks, see Preparing Active Directory Domain Services for Office Communications Server 2007 R2 in the Deployment documentation and the Command Line Reference in the Reference documentation. In addition to the administrative tools described in the table, you can use Windows Management Instrumentation Tester (WBEMTest), which ships with the Windows Server 2008 and Windows Server 2003 operating systems, to modify Windows Management Instrumentation (WMI) settings. Run the WBEMTest tool on any computer on which Office Communications Server 2007 R2 is installed. This guide includes specific procedures for using WBEMTest to change WMI settings. For details about WBEMTest, see "Using WBEMTest user interface" at http://go.microsoft.com/fwlink/?LinkId=139797. Note: The Group Chat and Communicator Web Access tools listed in the table are described in separate administration documentation. For details about administering Group Chat and 275 Communicator Web Access, see the Administering Group Chat documentation and the Communicator Web Access (2007 R2 Release) Administration Guide documentation. Permissions Installation of Office Communications Server 2007 R2 administrative tools on a computer that is not running Office Communications Server 2007 R2 requires using an account that is a member of the Administrators group (or an account with equivalent privileges). Using administrative tools requires the following:  To administer user account settings, an account that is a member of the RTCUniversalUserAdmins group, or an account with equivalent privileges.  For all other Office Communications Server 2007 R2 administration tasks, an account that is a member of the RTCUniversalServerAdmins group, or an account with equivalent privileges. Installation and Use of Administrative Tools You can install and use the Office Communications Server 2007 R2 administrative tools on any computer in the domain that meets the administrative tools prerequisites, such as on a computer that you use as a central administrative console. For details about installation prerequisites, see Internal Office Communications Server Component Requirements in the Supported Topologies and Infrastructure Requirements documentation. Note: Installation and use of Office Communications Server requires that users be members of specific groups. For details about providing appropriate permissions and delegation, see Accounts and Permissions Requirements in the Planning and Architecture documentation. This section covers primarily the use of the Office Communications Server 2007 R2 administrative tools to manage Office Communications Server. For details about installing and using the administrative tools, including the Office Communications Server user management functionality in Active Directory Users and Computers, see the Administering Office Communications Server 2007 R2 documentation. For details about using the LCSCmd.exe command-line tool to manage Office Communications Server, see the Office Communications Server 2007 R2 Command Line Reference Guide in the Reference documentation. For details about other tools for administering other Office Communications Server 2007 R2 components, see the Administering Communicator Web Access documentation and the Administering Group Chat documentation. In This Section This section includes the following topics:  Version Restrictions  Remote Administration Requirements  Installing Administrative Tools 276 Version Restrictions Installing Office Communications Server 2007 R2 administrative tools on the same computer as Office Communications Server 2007 administrative tools or Live Communications Server 2005 with Service Pack 1 (SP1) administrative tools is not supported. Additionally, you cannot administer servers and users from previous versions of Office Communications Server or Microsoft Live Communications Server with the Office Communications Server 2007 R2 administrative tools, nor can you administer Office Communications Server 2007 R2 servers and users with previous versions of the Office Communications Server or Live Communications Server administrative tools. You can use the Move Users Wizard in Office Communications Server 2007 R2 to move users from Office Communications Server 2007. For details about migrating from Office Communications Server 2007 to Office Communications Server 2007 R2, see Supported Migration Paths and Coexistence Scenarios in the Supported Topologies and Infrastructure Requirements documentation and the migration documentation in the Office Communications Server 2007 R2 TechNet Library at http://go.microsoft.com/fwlink/?LinkID=132106. Remote Administration Requirements If you want to use remote administration to deploy or administer Office Communications Server 2007 R2 while Windows Firewall is running, you must configure Windows Firewall to enable the remote administration exception. For details, see "Help: Enable or disable the remote administration exception" in the Windows Server product documentation at http://go.microsoft.com/fwlink/?LinkId=137361. To remotely administer or deploy the Web Components Server, you must also add Inetinfo.exe to the Windows Firewall exceptions list. For details, see "Help: Add a program to the Windows Firewall exceptions list" in the Windows Server product documentation at http://go.microsoft.com/fwlink/?LinkId=137362. Installing Administrative Tools In Office Communications Server 2007 R2, the Office Communications Server administrative tools are not installed by default. To install the administrative tools on a computer running Office Communications Server 2007 R2 or on another computer, such as a management console from which you want to centrally manage Office Communications Server 2007 R2 servers and users, you can use the Deployment Wizard to install the administrative tools, including Response Group Service and Communicator Web Access. For a description of each of these tools, see Administrative Consoles in the Planning and Architecture documentation. Important: Before installing the administrative tools, verify that all prerequisites have been met, including operating system requirements and installation of required updates. For details, see Administrative Tools Software Requirements in the Supported Topologies and Infrastructure Requirements documentation. 277 Use one of the following two procedures to install the Office Communications Server 2007 R2 administrative tools on a computer running a 64-bit version of the operating system or a 32-bit version of the operating system. Note: This topic covers the installation of the Office Communications Server 2007 R2 administrative tools, which are the primary tools for managing Office Communications Server. For information about other tools for managing other optional Office Communications Server 2007 R2 components, see the Communicator Web Access (2007 R2 Release) Administration Guide documentation and the Administering Group Chat documentation. To install the Office Communications Server 2007 R2 administrative tools on a computer running a 64-bit version of the operating system 1. On the computer on which you want to install the Office Communications Server 2007 R2 administrative tools, log on using an account that is a member of the Administrators group (or an account with equivalent privileges) and the Domain Admins group. 2. Do one of the following:  Insert the Microsoft Office Communications Server CD, and then click Enterprise Edition.  Insert the Microsoft Office Communications Server CD, and then click Standard Edition.  If you are installing from a network share to a 64-bit computer, browse to the \setup\amd64 folder on the network share, and then double-click setupEE.exe or setupSE.exe. 3. On the Office Communications Server 2007 R2 Deployment Wizard page, click Administrative Tools. 4. Review the license agreement, click I accept the terms in the license agreement to proceed, and then click OK. 5. Take the appropriate action on each page of the wizard to complete the installation. Note: Installing or removing the administrative tools on a computer running the Windows Vista operating system on which the Security Center service is running with the startup mode set to Automatic may result in the following error message: "Error stopping service since one or more dependent services failed to stop. Please try again." If you close the error message, the process should complete successfully. To install the Office Communications Server 2007 R2 administrative tools on a computer running a 32-bit version of the operating system 1. On the computer on which you want to install the Office Communications Server 2007 R2 administrative tools, log on using an account that is a member of the Administrators 278 group (or an account with equivalent privileges) and the Domain Admins group. 2. On the Microsoft Office Communications Server CD or a network share containing the installation files, browse to the \support\i86 folder. 3. Run vcredist_x86.exe to start the Microsoft Visual C++ 2008 Redistributable Setup wizard. Take the appropriate action on each page of the wizard to complete the installation. 4. Run SQLServer2005_BC.msi to start the Microsoft SQL Server 2005 Backward Compatibility Setup Wizard. Take the appropriate action on each page of the wizard, including using the default for Feature Selection, to complete the installation. 5. Run sqlncli.msi to start the wizard for Microsoft SQL Server Native Client. Take the appropriate action on each page of the wizard, including using the default for Feature Selection, to complete the installation. 6. Run OCSCore.msi to start the Office Communications Server 2007 R2 Core Components Setup Wizard. Take the appropriate action on each page of the wizard to complete the installation. 7. Run AdminTools.msi to start the Office Communications Server 2007 R2 Administrative Tools Setup Wizard. Take the appropriate action on each page of the wizard to complete the installation. Note: Installing or removing the administrative tools on a computer running Windows Vista on which the Security Center service is running with the startup mode set to Automatic may result in the following error message: "Error stopping service since one or more dependent services failed to stop. Please try again." If you close the error message, the process should complete successfully. Troubleshooting for Office Communications Server 2007 R2 Office Communications Server 2007 R2 includes several logging and diagnostics tools that can help troubleshoot an Office Communications Server deployment. The tools include:  OCSLogger. Generates logs for different server components while the server is running.  Snooper. Protocol analysis tool designed to view logs generated by the OCSLogger tool; loads the supplied log file and shows the messages in its display. Snooper is part of Microsoft Office Communications Server 2007 R2 Resource Kit Tools. The Resource Kit includes documentation for using the tool. Office Communications Server also includes ms-diagnostics headers that are error code extensions that solve the need for more granular SIP error codes to communicate diagnostic information through a new ms-diagnostics header. There are two purposes of these error code extensions: 279  Convey diagnostic information to help troubleshoot infrastructure (server) problems, misconfigurations, syntactical problems and other reasons for a non-successful SIP response.  Convey actionable error codes to the client, which can then be used by the client applications, such as the Live Meeting client and Office Communicator, to display appropriate errors to the user. The error IDs and reason values for ms-diagnostic headers are documented in the “Appendix A: Diagnostics Header Error ID and Reason Values” section of the [MS-OCER]: Client Error Reporting Protocol Specification at http://go.microsoft.com/fwlink/?LinkId=144413. Load Balancers for Office Communications Server 2007 R2 A hardware load balancer is required in an Enterprise pool with more than one Enterprise Edition server. A load balancer is not required for a Standard Edition server or a single Enterprise Edition Front End Server. A load balancer is required, for arrays of Office Communications Server 2007 R2 Edge Servers. The load balancer performs the critical role of delivering scalability and high availability across multiple servers connected to a centralized database on the Office Communications Server 2007 R2, Back-End Database. Prerequisites for a Load Balancer Connecting to a Pool Before configuring a load balancer to connect to the Office Communications Server 2007 R2 Enterprise pool, you must configure the following:  A static IP address for servers within your pool.  For each server within the pool, a certificate issued for server authentication by a certification authority in the pools local domain.  A virtual IP (VIP) address and a DNS record for the load balancer.  Test users created and SIP-enabled in the pool.  Install root certificate from the certification authority (CA) in the domain (or trusted CA) on client computers.  Log on to all servers in the pool using TLS to ensure certificates are working. Load Balancer Requirements A load balancer for the Office Communications Server 2007 R2 Enterprise pool must meet the following requirements:  Must expose a VIP Address through ARP (Address Resolution Protocol).  The VIP must have a single DNS entry, called Pool FQDN.  The VIP must be a static IP address. 280  Must allow multiple ports to be opened on the same VIP. Specifically, it must expose the ports described in the following table. Ports Required Port Use 5060 SIP communication over TCP. 5061 SIP communication over TLS. 135 To move users from a pool and other remote DCOM-based operations. 443 HTTPS traffic to the pool URLs. 444 Communication between the focus (Office Communications Server 2007 R2 component that manages conference state) and the conferencing servers. 5065 SIP listening requests for Application Sharing. 5069 Monitoring Server. 5071 SIP listening requests for Response Group Service. 5072 SIP listening requests for Conferencing Attendant. 5073 SIP listening requests for Conferencing Announcement Server. 5074 SIP listening requests for Outside Voice Control. 8404 TLS (remoting over MTLS) listening for interserver communications for Response Group Service.  The load balancer must provide TCP-level affinity. This means that the load balancer must ensure that TCP connections can be established with one Office Communications Server 2007 R2 in the pool and all traffic on that connection destined for that same Office Communications Server 2007 R2.  The load balancer must provide a configurable TCP idle-timeout interval with a maximum value greater than or equal to the minimum of the REGISTER refresh or SIP Keep-Alive interval of 30 minutes.  The load balancer should support a rich set of metrics (round robin, least connections, weighted, and so forth). A weighted least connections-based load balancing mechanism is recommended for the load balancer. This means that the load balancer will rank all Office 281 Communications Servers 2007 R2 based on the weight assigned to them and the number of outstanding connections. This rank will then be used to pick the Office Communications Server 2007 R2 to be used for the next connection request.  The load balancer must be able to detect Office Communications Server 2007 R2 availability by establishing TCP connections to either port 5060 (SIP over TCP), 5061 (SIP over TLS), and 444 (conferencing over HTTPS), depending on which is active (often called a heartbeat or monitor). The polling interval must be a configurable value with a minimum value of at least five seconds. The load balancer must not select an Office Communications Server 2007 R2 that shuts down until a successful TCP connection (heartbeat) can be established again.  Every Office Communications Server 2007 R2 must have exactly one network adapter. Multihoming an Office Communications Server 2007 R2 is not supported.  The network adapter must have exactly one static IP address. This IP address will be used for the incoming load-balanced traffic.  The computer must have a registered FQDN. The IP address registered for this FQDN must be publicly accessible from within the enterprise.  The load balancer must allow for adding and removing servers to the pool without shutting down.  The load balancer must be NAT (network address translation) capable. When you configure the load balancer, you need to request the relevant network and DNS administrator for a VIP (virtual IP) address for the load balancer, as well as a static IP address for every server that you plan to deploy in the Enterprise pool. Supported Load Balancer Configurations Most load balancers can be configured to operate in either Secure Network Address Translation (SNAT) mode or Destination Network Address Translation (DNAT) mode. With SNAT, both the source and IP destinations are changed as a TCP request passes through the Load Balancer. With DNAT, only the destination IP address is changed and the source IP address is passed through intact. Destination network address translation (DNAT) is not supported for load balancing of an Enterprise pool or Communicator Web Access, but both DNAT and source network address translation (SNAT) are supported for load balancing of Edge Servers and HTTP The issues with DNAT are related to inter-server communication within a pool (specifically, members of a pool trying to connect to their own VIP), which will fail in a DNAT configuration. In any location with multiple Edge Servers deployed behind a load balancer, the external firewall cannot function as a network address translation (NAT). However, in a site with only a single Edge Server deployed, the external firewall can be configured as a NAT. If you do so, configure the NAT as a destination network address translation (DNAT) for inbound traffic—in other words, configure any firewall filter used for traffic from the Internet to the Edge Server with DNAT, and configure any firewall filter for traffic going from the Edge Server to the Internet (outbound traffic) as a source network address translation (SNAT). The inbound and outbound filters must map to the same public IP address and the same private IP address. For details about load balancing pools, see Enterprise 282 Edition in the Planning and Architecture documentation. For details about load balancing Edge Servers, see External User Access Components in the Planning and Architecture documentation. For details about load balancing Communicator Web Access, see Communicator Web Access Support in the Planning and Architecture documentation. For details about Directors, see Director Component in the Supported Topologies and Infrastructure Requirements documentation. For details about load balancing support in Office Communications Server 2007 R2, see Environmental Requirements in the Supported Topologies and Infrastructure Requirements documentation. Also, Direct Server Return is a third variant of NAT. Direct Server Return is not supported. Media Ports This section describes port range requirements for media traffic. For information on configuring non-media ports (for example, an overall system-wide ports table), see the Planning and Architecture documentation. For a complete list of all edge server, firewall, and external load balancer port settings, see the Deploying Edge Servers for External User Access documentation. For details about load balancer configuration, see Load Balancers for Office Communications Server 2007 R2. In This Section  Mediation Server for Office Communications Server 2007 R2  Media Port Range for Office Communications Server 2007 R2 Mediation Server for Office Communications Server 2007 R2 The internal edge of a Mediation Server should be configured to correspond to a unique static route that is described by an IP address and a port number. This IP address must be the one corresponding to the IP address from the DNS resolution of the FQDN of the Mediation Server. The default port is 5061. The external edge of a Mediation Server should be configured as the internal next-hop proxy for the media gateway. It should be identified by a unique combination of IP address and port number. The IP address should not be the same as that of the internal edge, and the default port is 5060. When configuring Mediation Server, you are advised to accept the default media port gateway range of 60,000 to 64,000. The default range media port range enables the server to handle up to 1,000 simultaneous voice calls. Reducing the port range greatly reduces server capacity and should be undertaken only for specific reasons by an administrator who is knowledgeable about media port requirements and scenarios. For this reasons, altering the default port range is not recommended. Note: Organizations that use IPSec for packet security are advised to disable it for media ports because the security handshake required by IPSec delays call setup. IPSec is 283 unnecessary for media ports because SRTP encryption secures all media traffic between the Mediation Server and the internal Communications Server network. Media Gateway Depending on the gateway vendor, there are potentially many attributes that must be set, but to use the gateway for Enterprise Voice, port 5060 must be configured as the listening port that is used for TCP connections to the Mediation Server. Media Port Range for Office Communications Server 2007 R2 This section describes the minimum media port allocation requirements for the client and server. The default UDP/TCP port range used by the Office Communicator 2007 R2 client is 1024-65535. The Real Time Media Communications stack in Office Communicator 2007 R2 allocates the media port dynamically in this range. To maintain an adequate level of performance, you can specify a smaller port range for Office Communicator 2007 R2 to use. To control the specific range of ports that need to be open on a firewall, a registry key setting is provided to force the media stack to reduce the range of port values that can be used for realtime media communications. On the Office Communicator client, the port range registry settings are as follows:  HKLM\Software\Policies\Microsoft\Communicator\PortRange\Enabled  HKLM\Software\Policies\Microsoft\Communicator\PortRange\MaxMediaPort  HKLM\Software\Policies\Microsoft\Communicator\PortRange\MinMediaPort By default none of these registry keys is set. Minimum Number of Ports If you use the port range registry key settings to reduce the ports that can be used for media, it is recommended that you do so according to the minimums described in this section. For client endpoints, the port range should not be reduced to the point where it can compromise the ability of the media stack to negotiate audio, video, and desktop sharing communication ports during session setup or during a call. More specifically, for an Office Communicator 2007 R2 client, the minimum port range is 40. A smaller range of ports can result in errors during call transfer and conference escalation scenarios. By configuring a minimum of 40 ports, you enable the client to evaluate the candidate transport addresses that it can use to stream audio, video, and desktop sharing to another client, as described in the Internet Engineering Task Force (IETF) Interactive Connectivity Establishment (ICE) protocol. Candidate addresses include a local address and an address on the A/V Access Edge server. A minimum of 40 ports in the port range will also accommodate any escalations from a peer-to-peer call to a conference. Note: An escalation of a peer-to-peer call to a conference triggers a temporary doubling of the ports in use. 284 Different call scenarios can dictate whether to deliver by using User Datagram Protocol (UDP) or Transmission Control Protocol (TCP). However, whenever UDP can be used to deliver media, it will be used instead of TCP. Note: Secure Real-Time Transport Protocol (SRTP) and Secure Real-Time Transport Control Protocol (SRTCP) streams are multiplexed over TCP but are delivered separately in the case of UDP. UDP connections are more resilient to packet loss than TCP. When a UDP packet is lost, there is no transport impact to subsequent packets. When packet loss occurs over TCP, all subsequent packets are held at the transport level to ensure a reliable stream of data. As a result, overall latency in the media delivery chain may increase over TCP. The following set of tables show the detailed port requirements for call setup: Table 1.0 Port Requirements for Call Setup Voice ICE v6 Voice ICE v6 Voice ICE v6 Voice ICE v19 Voice ICE v19 UDP RTP UDP RTCP TCP RTP+ UDP RDP UDP RTCP RTCP ICE Local Candidate 1 1 1 1 1 ICE A/V Edge Server Candidate 1 1 1 1 1 Voice Maximum Number of Ports 4 4 4 4 4 Consultative Call Transfer, Number of Additional Ports 4 4 4 4 4 Total Audio Maximum Number of Ports 8 8 8 8 8 Audio Video Maximum Number of Ports 16 16 16 16 16 Consultative Call Transfer Maximum Number of Ports 16 16 16 16 16 Total Audio Video Maximum Number of Ports 32 32 32 32 32 285 Voice ICE v6 Voice ICE v6 Voice ICE v6 Voice ICE v19 Voice ICE v19 UDP RTP UDP RTCP TCP RTP+ UDP RDP UDP RTCP RTCP Audio Video Desktop Sharing Maximum Number of Ports 16 16 16 16 16 Consultative Call Transfer Maximum Number of Ports 16 16 16 16 16 Total Audio Video Desktop Sharing Maximum Number of Ports 32 32 32 32 32 Table 1.1 Port Requirements for Call Setup Voice ICE v19 CIF/VGA/HD Video CIF/VGA/HD Video CIF/VGA/HD Video TCP RTP+ ICE v6 UDP RTP ICE v6 UDP RTCP ICE v6 TCP RTP+ RTCP RTCP ICE Local Candidate 1 1 1 1 ICE A/V Edge Server Candidate 1 1 1 1 Voice Maximum Number of Ports 4 N/A N/A N/A Consultative Call Transfer, Number of Additional Ports 4 N/A N/A N/A Total Audio Maximum Number of Ports 8 N/A N/A N/A Audio Video Maximum Number of Ports 16 16 16 16 Consultative Call Transfer Maximum Number of Ports 16 16 16 16 286 Voice ICE v19 CIF/VGA/HD Video CIF/VGA/HD Video CIF/VGA/HD Video TCP RTP+ ICE v6 UDP RTP ICE v6 UDP RTCP ICE v6 TCP RTP+ RTCP RTCP Total Audio Video Maximum Number of Ports 32 32 32 32 Audio Video Desktop Sharing Maximum Number of Ports 16 16 16 16 Consultative Call Transfer Maximum Number of Ports 16 16 16 16 Total Audio Video Desktop Sharing Maximum Number of Ports 32 32 32 32 Table 1.2 Port Requirements for Call Setup CIF/VGA/HD Video CIF/VGA/HD Video CIF/VGA/HD Video Desktop ICE v19 UDP RTP ICE v19 UDP RTCP ICE v19 TCP RTP+ Sharing TCP RTCP RTP+ RTCP ICE Local Candidate 1 1 1 2 ICE A/V Edge Server Candidate 1 1 1 1 Voice Maximum Number of Ports N/A N/A N/A N/A Consultative Call Transfer, Number of Additional Ports N/A N/A N/A N/A Total Audio Maximum Number of Ports N/A N/A N/A N/A Audio Video Maximum Number of Ports 16 16 16 N/A 287 CIF/VGA/HD Video CIF/VGA/HD Video CIF/VGA/HD Video Desktop ICE v19 UDP RTP ICE v19 UDP RTCP ICE v19 TCP RTP+ Sharing TCP RTCP RTP+ RTCP Consultative Call 16 Transfer Maximum Number of Ports 16 16 N/A Total Audio Video Maximum Number of Ports 32 32 32 N/A Audio Video Desktop Sharing Maximum Number of Ports 16 16 16 16 Consultative Call 16 Transfer Maximum Number of Ports 16 16 16 Total Audio Video Desktop Sharing Maximum Number of Ports 32 32 32 32 The following set of tables show the detailed port requirements for escalation during a call: Table 2.0 Port Requirements for Escalation During a Call Voice ICE v6 Voice ICE v6 Voice ICE v6 Voice ICE v19 Voice ICE v19 UDP RTP UDP RTCP TCP RTP+ UDP RDP UDP RTCP RTCP Established P2P or Conference 1 1 1 1 1 Escalation From P2P to Conference 1 1 1 1 1 Total Audio Maximum Number of Ports 4 4 4 4 4 Total Audio Video Maximum Number 16 16 16 16 16 288 Voice ICE v6 Voice ICE v6 Voice ICE v6 Voice ICE v19 Voice ICE v19 UDP RTP UDP RTCP TCP RTP+ UDP RDP UDP RTCP 16 16 RTCP of Ports Total Audio Video Desktop Sharing Maximum Number of Ports 16 16 16 Table 2.1 Port Requirements for Escalation During a Call Voice ICE v19 CIF/VGA/HD Video CIF/VGA/HD Video CIF/VGA/HD Video TCP RTP+ ICE v6 UDP RTP ICE v6 UDP RTCP ICE v6 TCP RTP+ RTCP RTCP Established P2P or Conference 1 1 1 1 Escalation From P2P to Conference 1 1 1 1 Total Audio Maximum Number of Ports 4 N/A N/A N/A Total Audio Video Maximum Number of Ports 16 16 16 16 Total Audio Video Desktop Sharing Maximum Number of Ports 16 16 16 16 Table 2.2 Port Requirements for Escalation During a Call CIF/VGA/HD Video CIF/VGA/HD Video CIF/VGA/HD Video Desktop ICE v19 UDP RTP ICE v19 UDP RTCP ICE v19 TCP RTP+ Sharing TCP RTCP RTP+ RTCP Established P2P or Conference 1 1 1 2 Escalation From P2P to 1 1 1 1 289 CIF/VGA/HD Video CIF/VGA/HD Video CIF/VGA/HD Video Desktop ICE v19 UDP RTP ICE v19 UDP RTCP ICE v19 TCP RTP+ Sharing TCP RTCP RTP+ RTCP Conference Total Audio N/A Maximum Number of Ports N/A N/A N/A Total Audio Video 16 Maximum Number of Ports 16 16 N/A Total Audio Video 16 Desktop Sharing Maximum Number of Ports 16 16 16 The following set of tables show the detailed overall requirements for ports: Table 3.0 Overall Requirements for Ports Voice ICE v6 Voice ICE v6 Voice ICE v6 Voice ICE v19 Voice ICE v19 UDP RTP UDP RTCP TCP RTP+ UDP RDP UDP RTCP RTCP Minimum Ports Required for Audio 16 16 16 16 16 Minimum Ports Required for Audio Video 32 32 32 32 32 Minimum Ports Required for Audio Video Desktop Sharing 32 32 32 32 32 ALL * 32 32 32 32 32 290 Table 3.1 Overall Requirements for Ports Voice ICE v19 CIF/VGA/HD Video CIF/VGA/HD Video CIF/VGA/HD Video TCP RTP+ ICE v6 UDP RTP ICE v6 UDP RTCP ICE v6 TCP RTP+ RTCP RTCP Minimum Ports Required for Audio 16 N/A N/A N/A Minimum Ports Required for Audio Video 32 32 32 32 Minimum Ports Required for Audio Video Desktop Sharing 32 32 32 32 ALL * 32 32 32 32 Table 3.2 Overall Requirements for Ports CIF/VGA/HD Video CIF/VGA/HD Video CIF/VGA/HD Video Desktop ICE v19 UDP RTP ICE v19 UDP RTCP ICE v19 TCP RTP+ Sharing TCP RTCP RTP+ RTCP Minimum Ports Required for Audio N/A N/A N/A N/A Minimum Ports Required for Audio Video 32 32 32 N/A Minimum Ports 32 Required for Audio Video Desktop Sharing 32 32 32 ALL * 32 32 32 32 Note: * 8 additional ports required to accommodate any third party applications. At least 40 ports needed for allocating ports in the same range at the same time. 291 As described in the tables, the minimum number of ports that must be allocated on a client platform is 40. During a normal call, the number of ports used will not exceed 2, 4, or 5 depending on whether audio, audio/video, or audio/video/Desktop sharing are streamed. Server Port Allocation Changing the default port range on the server is not recommended. However, if your organization has a need to establish port ranges on the server, you can use the following WMI settings to configure the port range:  MSFT_SIPPoolConfigSetting  MSFT_SIPDataMCUSetting  MSFT_SIPMediationServerConfigSetting For an A/V Conferencing Server as well as all other server components terminating Audio/Video media (for example, Front-Ends hosting Conferencing Attendant, Response Group Service), the port range must be at least six times the maximum number of concurrent call legs that can be supported on the server (that is, two ports for the RTP and RTCP traffic for each modality – audio, video, and panoramic video). For an A/V Access Edge server, the port range must be at least twelve times the maximum number of outside user calls that can be supported on the server (two ports for the RTP and RTCP traffic for each modality – audio, video and panoramic video, or audio, video, and desktop sharing for ICE v6 and ICE v19. For a Mediation Server, the port range must be at least eight times the maximum number of concurrent calls that can be supported on the server (that is, two ports for the RTP and RTCP traffic for audio multiplied by two because the Mediation Server is a back-to-back User Agent for ICE v6 and also for ICE v19). Voice Quality of Service (QoS) The quality of the service associated with synchronous traffic like audio or video can be impacted by delay, jitter, and packet loss in the IP network. Although Office Communications Server 2007 R2 has been designed to work without any Quality of Service (QoS) framework, it can be deployed in IP networks with QoS implemented using Differentiated Services (DiffServ). To support the QoS environment, endpoints are configured to mark the IP traffic conveying the realtime audio and video IP traffic according to well-established classes of services designed to protect the real-time communication traffic from other asynchronous traffic in the IP network, including instant messaging (IM), application sharing data, and file downloads. These markings can be changed to map to different classes of services as desired by an enterprise. QoS with Office Communications Server 2007 R2 A network enabled for Differentiated Services (DiffServ) provides class-level prioritization based on Differentiated Services Code Point (DSCP) marking of the IP packets. Each DSCP value corresponds to a class of service for forwarding packets from the sender or intermediary router to 292 the next router or receiver in the network. The forwarding behaviors can be implemented by using a variety of techniques, including priority queuing, weighted fair queuing, or conventional leaky bucket-based techniques. Relevant classes for the delivery of audio and video media streams are the Expedited Forwarding (EF) and Assured Forwarding (AF) classes, respectively. For a description of the 6-bit DSCP field values in the Type of Service byte of any IP packet, see IETF RFC 2474. In Office Communications Server 2007 R2, DSCP marking can be enabled to configure the media stack to mark the IP traffic conveying the real-time audio and video IP traffic according to wellestablished classes of services. By default, DSCP marking is not enabled. If enabled, the marking of the IP packets is done by the QoS Packet Scheduler service. The resulting marked packets can subsequently be recognized by network entities (end systems and routers) to manage the media traffic according to the QoS priorities. The QoS marking is applied to all media ports and regardless of whether the audio/video traffic is delivered over Real-Time Protocol (RTP; see IETF RFC 3350) or Secure Real-Time Protocol (SRTP; see IETF RFC 3711). Because QoS policies are often tied to UDP or TCP ports, Office Communications Server 2007 R2 also includes a Group Policy registry setting (on client platforms) or a WMI setting (on server platforms) to specify the port range for the UDP and TCP ports used in delivering media streams. Before enabling QoS for Office Communications Server 2007 R2, you must provision the network correctly. Relevant classes for the delivery of audio and video media streams in Office Communications Server 2007 R2 are the following:  For audio, the Expedited Forwarding (EF) class. Audio streams affected by this marking include DTMF, Comfort Noise, and Audio with Forward Error Correction (FEC) streams.  For video, the Assured Forwarding (AF) class. Video streams affected by this marking include Video streams with FEC packets. After ensuring that the network is correctly configured, Office Communications Server 2007 R2 can be configured to support a QoS environment by enabling DSCP marking, which includes doing the following:  Enabling QoS on the appropriate servers and clients  Running QoS on computers  Ensuring that Group Policy settings are correct on servers and client computers The procedures in Enabling DSCP Marking describe how to configure Office Communications Server components to support a QoS environment. Note: Generally, a QoS environment is set up before Office Communications Server is deployed, and the procedures in this documentation are implemented after the Communications Server components are deployed. If you add Differentiated Services capability to the Enterprise network after you deploy Office Communications Server 2007 R2, use the information in Implementing Support for a QoS Environment in the Administering Office Communications Server 2007 R2 documentation to enable and configure Office Communications Server media traffic to take advantage of this new capability. 293 Enabling DSCP Marking The procedures in this section describe how to configure components to enable Differentiated Services Code Point (DSCP) marking for Office Communications Server 2007 R2. This includes:  Enabling QoS.  Installing the QoS Packet Scheduler on computers.  Verifying Group Policy settings on computers. Note: DSCP marking is generally enabled at the time of deployment in a QoS environment. If you add Differentiated Services capability to the Enterprise network after deploying Office Communications Server 2007 R2, you can configure Office Communications Server media traffic to take advantage of this new capability at that time. Enabling QoS To enable DSCP marking for Office Communications Server 2007 R2, you must enable QoS on the following components:  Media servers, which are configured via in-band provisioning. These servers include the following:  A/V Conferencing Server.  Front End Servers or Standard Edition servers running Conferencing Attendant or Response Group Service.  Unified Communications Managed API server.  Mediation Servers, which are configured using WMI settings.  Office Communicator 2007 R2 clients, including Communicator 2007 R2 Attendant, which are configured by creating a registry key.  Office Communicator 2007 R2 Phone Edition clients, which are configured using Office Communicator property settings via in-band provisioning. Note: After completing these procedures for enabling QoS, you must verify that the QoS Packet Scheduler is running and the Group Policy settings are correct on each client and server, using the procedures provided later in this topic. To enable QoS on media servers 1. Log on to the Office Communications Server 2007 R2 server as a member of the RTCUniversalServerAdmins group or an account with equivalent user rights. 2. Click Start, and then click Run. 3. In the Open box, type wbemtest, and then click OK. 4. In the Windows Management Instrumentation Tester dialog box, click Connect. 5. In the Connect dialog box, in Namespace, specify root\cimv2, and then click Connect. 294 6. In the Windows Management Instrumentation Tester dialog box, click Query. 7. In the Query dialog box, in Enter Query, do one of the following:  For Standard Edition Server, specify select * from MSFT_SIPPoolConfigSetting where backend="(local)\\rtc", and then click Apply.  For an Enterprise pool, specify select * from MSFT_SIPPoolConfigSetting where backend=”<SQL Server>\\<database instance>", and then click Apply. (RTC is the default database instance name.) 8. In the Query Result dialog box, double-click the MSFT_SIPPoolConfigSetting instance (which should be the only instance available on this media server). 9. In the Object editor dialog box, in Properties, click ServerQoSEnabled, and then click Edit Property. 10. In the Property Editor dialog box, in Value, specify True, and then click Save Property. 11. Repeat the preceding steps for each Office Communications Server 2007 R2 server that is in a different pool in your environment, including each A/V Conferencing Server, server running the Response Group Service, and Unified Communications Managed API server. Media servers within the same pool will share the settings after they have been set on the Office Communications Server 2007 R2 server for that pool. Mediation Server does not join a pool, so the settings need to be run separately as a WMI setting on that platform. Important  After completing this procedure, ensure that the QoS Packet Scheduler is installed and that Windows Group Policy settings are appropriately configured on each computer.  Policies are propagated via in-band provisioning, so for the policies to become effective, you must do one of the following: To enable QoS on Mediation Servers 1. Log on to the Mediation Server as a member of the RTCUniversalServerAdmins group or an account with equivalent user rights. 2. Click Start, and then click Run. 3. In the Open box, type wbemtest, and then click OK. 4. In the Windows Management Instrumentation Tester dialog box, click Connect. 5. In the Connect dialog box, in Namespace, type root\cimv2, and then click Connect. and then click Enum Classes. 6. In the Windows Management Instrumentation Tester dialog box, click Enum Classes. 7. In the Superclass info dialog box, leave the name blank, and then click OK. 8. In the Query Result dialog box, double-click the class name MSFT_SIPMediationServerConfigSetting. 9. In the Object editor for MSFT_SIPMediationServerConfigSetting dialog box, click 295 Instances. 10. In the Query Result dialog box, double-click the MSFT_SIPMediationServerConfigSettingInstanceID instance (which should be the only instance available on this Mediation Server). 11. In the Object editor dialog box, in Properties, click QoSEnabled, and then click Edit Property. 12. In the Property Editor dialog box, in Value, specify True, and then click Save Property. 13. In the ObjectEditor dialog box, click Save Object. 14. Restart the Mediation Server service. 15. Repeat the preceding steps on each Office Communications Server 2007 R2 Mediation Server. Note: This procedure only enables DSCP in the WMI settings of the Mediation Server. After completing this procedure, ensure that the QoS Packet Scheduler is installed and that Group Policy settings are appropriately configured on each computer, and then restart the services. To enable QoS on Communicator clients 1. Log on to the desktop, laptop, or Attendant client as a member of the Administrator group or an account with equivalent user rights. 2. Open the Registry Editor. 3. Create the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RTC\Transport 4. Restart the Office Communicator 2007 R2 service. 5. Repeat the preceding steps on each desktop, laptop, and attendant client. Note: This procedure only enables DSCP on the client. After completing this procedure, ensure that the QoS Packet Scheduler is installed and that Group Policy settings are appropriately configured on each computer, and then restart the services. To enable QoS on Office Communications Server 2007 R2 Phone Edition 1. Log on to a server running Office Communications Server 2007 R2 or a computer on which Office Communications Server 2007 R2 administrative tools are installed, as a member of the RTCUniversalServerAdmins group or an account with equivalent user rights. 2. Open the Office Communications Server 2007 R2 snap-in. 3. In the console tree, expand the forest node, and then do one of the following:  For an Enterprise pool, expand Enterprise pools, expand the pool, right-click Front 296 Ends, and then click Properties.  For a Standard Edition server, expand Standard Edition servers, right-click the pool, click Properties, and then click Front End Properties. 4. In the Front End Properties dialog box, on the Voice tab, next to Advanced options, click Configure. 5. Verify the IP QoS value (default is 40) and the 802.1p Voice value (default is 0) For optimum quality of service, we recommend that you use the default values. To turn off DSCP marking, set both values to 0. 6. For the new settings to take effect, restart the device or log off and log on to the device. 7. Click OK, twice. Installing the QoS Packet Scheduler on Computers The QoS Packet Scheduler needs to be active and configured properly in order for Office Communications Server 2007 R2 servers and clients in order to make the marking active. For details about the QoS Packet Scheduler service, see Voice Quality of Service (QoS) in the Technical Reference for Office Communications Server 2007 R2 in the Reference documentation. By default, the QoS Packet Scheduler is installed on computers running Windows XP, Windows Vista, and Windows 2008. By default, the QoS Packet Scheduler is not installed on Windows Server 2003. Use the following procedures to determine whether the QoS Packet Scheduler is installed and, if not, install it. To install the QoS Packet Scheduler on Windows XP or Windows Server 2003 1. Log on to the computer as a member of the Administrators group or an account with equivalent user rights. 2. Click Start, and then click Control Panel. 3. Click Network Connections. 4. Right-click the network interface on which you want to enable the QoS Packet Scheduler, and then click Properties. 5. Click Install. 6. In Select Network Component Type, click Service. 7. Click Add. 8. In Select Network Service, click QoS Packet Scheduler, and then click OK. To install the QoS Packet Scheduler on Windows Vista or Windows Server 2008 1. Log on to the computer as a member of the Administrator group or an account with equivalent user rights. 2. Click Start, and then click Control Panel. 3. Click Network and Sharing Center. 297 4. Right-click the network interface on which you want to enable the QoS Packet Scheduler, and then click Properties. 5. Click Install. 6. In Select Network Feature, click Service. 7. Click Add. 8. In Select Network Service, click QoS Packet Scheduler, and then click OK. Verifying Group Policy Settings on Computers In order to support DSCP marking on the servers and client computers in your organization, the Group Policy settings for conforming packets for the two service types used by QoS Packet Scheduler must be enabled and cannot be set to zero. This includes the following:  SERVICETYPE_GUARANTEED. This setting guarantees that IP datagrams will arrive within the guaranteed delivery time and will not be discarded due to queue overflows, provided the flow's traffic stays within its specified traffic parameters. This service is intended for applications that need a firm guarantee that a datagram will arrive no later than a certain time after it was transmitted by its source. The Real Time Media Communications stack marks the RTP/SRTP audio packets (default payload type value equal to 0, 3, 4, 8, 13, 97, 101, 111, 112, 114, 115, 116, or 118) as SERVICETYPE_GUARANTEED. This marking is off by default. To enable QoS on highdefinition video, also update the following registry key to set the value to 250000 bytes per sec (2 Mbps): HKEY_LOCAL_MACHINE\Software\Microsoft\RTC\Transport\VideoBandwidthDiscardThresh oldBytesPerSec  The SERVICETYPE_CONTROLLEDLOAD setting provides an end-to-end QoS that closely approximates transmission quality provided by best-effort service, as expected under unloaded conditions from the associated network components along the data path. Applications that use SERVICETYPE_CONTROLLEDLOAD may therefore assume the following:  The network will deliver a very high percentage of transmitted packets to its intended receivers. In other words, packet loss will closely approximate the basic packet error rate of the transmission medium.  Transmission delay for a very high percentage of the delivered packets will not greatly exceed the minimum transit delay experienced by any successfully delivered packet.  The Real Time Media Communications stack marks the RTP/SRTP video packets (default payload type value equal to 34 or 121) as SERVICETYPE_CONTROLLEDLOAD. This marking is off by default. Use the following procedure on each client and server to ensure that the Group Policy settings for the two service types are set correctly. 298 To verify service type settings on a computer 1. Log on to the computer as a member of the Administrators group or an account with equivalent user rights. 2. Click Start, and then click Run. 3. In the Open box, type gpedit.msc. 4. In the Group Policy Object Editor dialog box, expand Computer Configuration, expand Administrative Template, expand Network, expand QoS Packet Scheduler, and then click DSCP value of conforming packets. 5. In DSCP value of conforming packets, verify that Guaranteed service type and Controlled load service each have one of the following settings:  Not configured.  Enabled with a nonzero value. To see the value, right-click the setting, and then click Properties.  Disabled. Note: To ensure that the policies are applied, you may need to run the gpupdate /target:computer /force command. This command may need to be run each time the computer is restarted. For details, see Knowledge Base article 973779, “Some QoS Group Policy settings are not retained after you restart a client computer that is running Windows Vista or Windows Server 2008” at http://support.microsoft.com/kb/973779 and Knowledge Base article 972878, “The "Guaranteed service type" Group Policy setting returns to the default value after you restart a client computer that is running Windows XP or Windows Server 2003” at http://support.microsoft.com/kb/972878. WMI Settings for Office Communications Server 2007 R2 For details about Office Communications Server WMI settings, see the Office Communications Server SDK at the Microsoft Web site http://go.microsoft.com/fwlink/?LinkId=144486. Client Registry Keys/GPO for Office Communications Server 2007 R2 For details about Office Communicator registry settings, see the Office Communicator 2007 policy documentation available at the Microsoft Web site http://go.microsoft.com/fwlink/?LinkID=140494. 299 In-Band Provisioning over SIP After the client is signed in, the client receives settings from the server pool through in-band provisioning. Specific settings that have been configured in the Office Communications Server properties are propagated to the client during this process. Unlike Group Policy, which is delivered by using a separate mechanism that is based on Windows and Active Directory, inband provisioning carries settings within the Session Initiation Protocol (SIP) and does not require a separate communications channel. For example, Office Communicator clients receive server locations, security information, and settings related to specific client features during in-band provisioning. Office Communicator Phone Edition devices receive the list of supported location profiles and pool-level defaults through in-band provisioning. The following table outlines the settings that are sent to Office Communicator clients during inband provisioning and the location where these settings are configured on the server. Table 1. In-Band Provisioning Settings Settings sent through in-band provisioning Location in server properties Internal and external URLs for the Address Book Server and Web Service for Distribution Group expansion. In the pool properties, Web Component Properties, Address Book tab, Internal URL and External URL Location of the Media Relay Access server (MRAS, part of A/V Edge Server) In the forest properties, Global Properties, Edge Servers tab, under A/V Edge Servers. SIP high security mode In the pool properties, Front End Properties, Voice tab, in the Advanced Voice Options page (after Advanced Options, click Configure), under SIP security mode. Telephony Mode, which determines whether enterprise and voice telephony features, remote call control, computer-to-computer calling, are enabled Voice license: In the user’s Active Directory properties, Communications tab, Telephony options.Enterprise license: In the forest properties, Global Settings, Meetings, Global Policies Enterprise with Voice license: Both of the above settings Audio/video conferencing and data conferencing, In the forest properties, Global Properties, Meetings, Global Policies Simultaneous ringing In the forest properties, Voice Properties, Policy tab, edit the policy and select or clear the Allow simultaneous ringing of phones check box Whether encryption is supported or required when making and receiving audio and video Pool Properties, Media tab, under Security Settings, Encryption Level 300 Settings sent through in-band provisioning Location in server properties calls Default location context for phone calls In the forest properties, Voice Properties, Location tab Line information for the UC phone line In the user’s Active Directory properties, Communications tab, Telephony options, Line URI. Maximum video rate allowed In the pool properties, Front End Properties, Video tab, select the appropriate setting for Maximum video quality Enforce pin lock In the pool properties, Front End Properties, Voice tab, select or clear the Enforce phone lock check box Why Use In-Band Provisioning? To ensure a consistent user experience across all endpoints, Office Communications Server uses in-band provisioning. This enables policies and settings (for example, the MRAS setting) to be sent to non-domain joined clients as well as devices such as Office Communicator Phone Edition, Office Communicator Mobile (2007 R2 release). For endpoints like Office Communicator 2007 R2, an advantage of using in-band provisioning is that information critical to client functionality is stored on the server and not on the computer or the specific endpoint. In-band provisioning simplifies the application of policies and server settings across the organization because the settings apply to all clients that sign in to the server pool. However, some organizations may need to apply distinct settings and policies to different groups within the organization. Administrators can achieve this greater level of granularity by using Group Policy to apply separate client settings to different Active Directory groups. Note: Office Communicator Phone Edition clients receive all settings from the server through inband provisioning and are not configurable through registry-based Group Policy. Some application layer settings are common between Office Communicator 2007 R2 and Office Communicator Phone Edition. Because Office Communicator Phone Edition has no group policy mechanism, certain application layer settings that were previously controlled solely through Group Policy have moved in-band in the Office Communications Server 2007 R2 release. This change was made so that Office Communicator Phone Edition clients could receive these settings through in-band provisioning. However, before you remove any group policies because the settings have moved in-band, you should consider the effect on Office Communicator 2007 R2 clients. Following are the affected settings: 301  Portrange (Specify dynamic port ranges) and the Enabled, MaxMediaPort, and MinMediaPort subkeys  EnableTracing (Turn on tracing for Office Communicator)  EnableSIPHighSecurityMode (Configure SIP security mode) Of these settings, the SIP Security Mode setting is used during the bootstrapping process to specify whether Transport Layer Security (TLS) is required. If your organization requires a TLS connection between clients and servers in previous versions of Office Communications Server, you have probably already set the Group Policy for SIP Security Mode. Even though the setting has moved in-band for Office Communications Server 2007 R2, you should retain the SIP Security Mode group policy because it is still used during bootstrapping, before the client is able to receive settings through in-band provisioning. Maintaining the SIP Security Mode policy retains security during the bootstrapping process. Office Communicator 2007 R2 Group Policy Precedence Some Office Communicator 2007 R2 features and behaviors can be configured by the administrator by using Office Communications Server 2007 R2 in-band provisioning, or by the user through the Communicator 2007 R2 Options dialog box. However, Group Policies take precedence over both of these methods. The following table summarizes the order in which settings take precedence when a conflict occurs. Table 2. Group Policy Precedence Precedence Location or Method of Setting 1 HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator 2 HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator 3 Office Communications Server 2007 R2 In-Band provisioning 4 Office Communications Server 2007 R2 In-Band provisioning Policy transport In-band settings are requested when a client signs in. The client sends a sequence of messages and the server responds. The following shows the sequence of interactions between the client and the server. The client first sends a SERVICE request for the location profile settings. The following is an example of the start-line. SERVICE sip:amst@litwareinc.com;gruu;opaque=app:locationprofile:get;default SIP/2.0 302 The server responds with a 200 OK message that contains the location profile settings. The content type of the response is application/ms-location-profile-definition+xml. The message body contains the dialing rule patterns and corresponding translations. An example of a message body is as follows: <LocationProfileDescription xmlns="http://schemas.microsoft.com/2007/03/locationProfileDescription" > <Name>Local.LitwareInc.com</Name> <Rule> <Pattern>^(112)$</Pattern> <Translation>$1</Translation> <InternalEnterpriseExtension>false</InternalEnterpriseExtension> <ApplicableForDeviceDialing>true</ApplicableForDeviceDialing> </Rule> </LocationProfileDescription> The client then sends a SUBSCRIBE request for the contact list. The Event header in the SUBSCRIBE message has a value of vnd-microsoft-roaming-contacts. The server responds with a 200 OK message that contains the contact list, the various groups that the users has created and contacts who belong to each group. The Content type header of the response is application/vnd-microsoft-roaming-contacts+xml. The following snippet shows an example of the response that contains the contact list. <contactList deltaNum="248" > <group id="1" name="~" externalURI="" /> <group id="2" name="Sales Team" externalURI="" /> <group id="3" name="Accounts Team" externalURI="" /> <contact uri="amst@contoso.com" name="" groups="2 3" subscribed="true" externalURI="" /> <contact uri="hc@contoso.com" name="" groups="1" subscribed="true" externalURI="" /> <contact uri="gy@contoso.com" name="" groups="1" subscribed="true" externalURI="" /> <contact uri="va@contoso.com" name="" groups="1 2" subscribed="true" externalURI="" /> </contactList> 303 A client endpoint also sends a SUBSCRIBE message for various provisioning settings. This SUBSCRIBE message contains an Event header with a value of vnd-microsoft-provisioning-v2. The Content type of the message is application/vnd-microsoft-roaming-provisioning-v2+xml. An example of a SUBSCRIBE message for the roaming provisioning settings is as follows: <provisioningGroupList xmlns="http://schemas.microsoft.com/2006/09/sip/provisioninggrouplist"> <provisioningGroup name="ServerConfiguration"/> <provisioningGroup name="meetingPolicy"/> <provisioningGroup name="ucPolicy"/> <provisioningGroup name="publicationGrammar"/> <provisioningGroup name="userSetting"/> </provisioningGroupList> The server responds with a 200 OK message that contains the settings for the requested provisioning groups. The Content type of the response is application/vnd-microsoft-roamingprovisioning-v2+xml. The response contains server configuration such as update server URLs, Address book server URLs, Console download URLs. The following settings are new in Office Communications Server 2007 R2: Call Control Server Uri, Pool Uri, and Maximum video rate allowed. An example of the response containing the roaming provisioning settings is as follows: <provisionGroupList xmlns="http://schemas.microsoft.com/2006/09/sip/provisiongrouplistnotification"> <provisionGroup name="ServerConfiguration" > <ucMaxVideoRateAllowed>VGA-600K</ucMaxVideoRateAllowed> <absInternalServerUrl>https://absint.contoso.com/Abs/Int/Handler</absIn ternalServerUrl> <absExternalServerUrl>https://absext.contoso.com/Abs/Ext/Handler</absEx ternalServerUrl> <absWebServiceEnabled>true</absWebServiceEnabled> <ucPC2PCAVEncryption>RequireEncryption</ucPC2PCAVEncryption> <organization>Contoso, Inc.</organization> <consoleDownloadInternalUrl>http://r.office.microsoft.com/r/rlidOCSR2?c lid=1033&p1=livemeeting</consoleDownloadInternalUrl> 304 <consoleDownloadExternalUrl>http://r.office.microsoft.com/r/rlidOCSR2?c lid=1033&p1=livemeeting</consoleDownloadExternalUrl> <dlxInternalUrl>https://ocs.contoso.com/GroupExpansion/Int/service.asmx </dlxInternalUrl> <dlxExternalUrl>https://ocs.contoso.com/GroupExpansion/Ext/service.asmx </dlxExternalUrl> <dlxEnabled>true</dlxEnabled> <ucDiffServVoice>40</ucDiffServVoice> <ucVoice802_1p>0</ucVoice802_1p> <ucEnforcePinLock>true</ucEnforcePinLock> <ucMinPinLength>6</ucMinPinLength> <ucPhoneTimeOut>10</ucPhoneTimeOut> <ucExchangeMWIPoll>3</ucExchangeMWIPoll> <ucEnableSIPSecurityMode>High</ucEnableSIPSecurityMode> <ucEnableUserLogging>false</ucEnableUserLogging> … </provisionGroup> <provisionGroup name="meetingPolicy" instanceId="{6B151D61-D98B-4A169D6C-8BBB3111228A}" > <instance> <property name="Name"><![CDATA[Default Policy]]></property> <property name="ColorDepth"><![CDATA[High colors]]></property> <property name="AllowPresenterToDelegateRecording"><![CDATA[false]]></property> <property name="EnableAppDesktopSharing"><![CDATA[true]]></property> <property name="AllowAppSharingForExternalMeeting"><![CDATA[Desktop]]></property> <property name="MeetingSize"><![CDATA[50]]></property … </instance> </provisionGroup> <provisionGroup name="ucPolicy" instanceId="{6B41BE99-5C45-41E5-B34CF6B8D0079E7B}" > 305 <instance> <property name="Name"><![CDATA[Default Policy]]></property> <property name="AllowUsersToChangeTeamSettings"><![CDATA[true]]></property> <property name="AllowSimultaneousRinging"><![CDATA[true]]></property> </instance> </provisionGroup> </provisionGroup> <provisionGroup name="userSetting" > <ucUserLocationProfile >Main.Contoso.com</ucUserLocationProfile> </provisionGroup> </provisionGroupList> Provisioning Groups There are different provisioning groups, each group deals with a specific area of category of settings. The various provisioning groups and the settings they contain are as follows:  Server Configuration. Contains update server URLs, Address Book server URLs, console download URLs, distribution list URLs, media relay server URL, Quality of Service (QoS) server URL, Communicator Web Access URLs, call control server URLs.  Meeting Policy. Settings that control whether the presenter is allowed to record a meeting, whether application sharing is allowed, IP audio and IP video.  User setting. User specific location profile.  ucPolicy. Contains settings for simultaneous ringing, phone usages, and so on.  Publication Grammar. A fixed manifest sent out by the server. It allows the client endpoint to control the aggregation logic and the manifest is server agnostic. 306

Office Communications Server 2007 R2

Related documents

Products

Support

Office Communications Server 2007 R2

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib