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 Microsoft Office Communications Server 2007 R2.........................................................................1 Technical Reference.................................................................................................................... 1 Contents.......................................................................................................................................... 3 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).............................9 RTCHost............................................................................................................................. 12 Back-End Database............................................................................................................ 12 Presence Components....................................................................................................... 13 Web Components Services for Office Communications Server 2007 R2............................13 Archiving and Monitoring for Office Communications Server 2007 R2................................14 Unified Communications Application Services (UCAS) Infrastructure.................................15 Conferencing Components..................................................................................................... 15 Conferencing Infrastructure Components...........................................................................15 Conferencing Servers for Office Communications Server 2007 R2....................................18 Voice Components................................................................................................................. 20 RTCHost Voice Components..............................................................................................20 Unified Communications Application Services (UCAS) Voice Applications.........................22 Communication Protocols for Office Communication Server 2007 R2.......................................24 Protocols Overview................................................................................................................ 24 Conferencing Protocols.......................................................................................................... 25 Centralized Conferencing Control Protocol (C3P)...............................................................27 PSOM................................................................................................................................. 28 RTP/RTCP.......................................................................................................................... 28 SIP/SDP.............................................................................................................................. 28 Signaling and Control Protocol............................................................................................29 Media Protocols.................................................................................................................. 29 Scenarios for Office Communications Server 2007 R2.................................................................29 Conferencing Scenario for Office Communications Server 2007 R2.........................................30 Core (Focus, Focus Factory, and Conferencing Server Factory)...........................................30 3
Conferencing Lifecycle........................................................................................................ 30 Conferencing Data Flow..................................................................................................... 31 Conference Creation and Activation....................................................................................32 Joining a Conference.......................................................................................................... 37 Adding Participants to the Conference................................................................................41 Notification Document......................................................................................................... 44 Conference Deactivation..................................................................................................... 46 Conference Expiration........................................................................................................ 46 Web Conferencing Server for Office Communications Server 2007 R2.................................46 Web Conferencing Architecture.......................................................................................... 47 File Structure....................................................................................................................... 48 Metadata Folder.................................................................................................................. 49 Organizer Folder................................................................................................................. 50 Conference Folder.............................................................................................................. 50 Types of Slides.................................................................................................................... 52 Content Upload and Download over PSOM........................................................................53 Content Upload over PSOM and Download over HTTPS...................................................54 Slide Set Files..................................................................................................................... 56 Handouts (File Transfers).................................................................................................... 63 PersistData Folder (Shared Notes).....................................................................................64 Content Folder.................................................................................................................... 65 Conference Content Folder................................................................................................. 66 File Size Restrictions.......................................................................................................... 68 Compliance......................................................................................................................... 68 Conferencing Scenario Call Flows in Office Communications Server 2007 R2......................71 Lock or Unlock a Conference.............................................................................................. 71 Dial In to a PSTN Conference Using SIP C3P (Telephony Conferencing Server)...............71 Dial Out to Device Using addUser (Audio Conferencing Provider).....................................72 Remove a Participant.......................................................................................................... 72 Mute or Unmute.................................................................................................................. 73 Make Presenter................................................................................................................... 74 Dial-In Conferencing Scenario................................................................................................... 75 Server-Based Dial-In Conferencing Components...................................................................77 Active Directory–Based Configuration Data........................................................................77 Office Communications Server Front End Server Components..........................................80 Client-Based Dial-in Conferencing Components....................................................................85 Conferencing Add-in for Microsoft Office Outlook...............................................................85 Live Meeting Client............................................................................................................. 86 Office Communicator.......................................................................................................... 86 Call Flows............................................................................................................................... 87 Meeting Set-up.................................................................................................................... 87 To create an Anonymous-Allowed Live Meeting with Dial-In Conferencing support............87 Connecting to the Meeting.................................................................................................. 88 Desktop Sharing Scenario......................................................................................................... 92 Office Communications Server 2007 R2 Desktop Sharing Architecture.................................93 Architectural Overview........................................................................................................ 93 4
Protocols Used By Desktop Sharing...................................................................................94 Desktop Sharing Components............................................................................................ 96 Desktop Sharing Call Flows................................................................................................. 101 Creating a Desktop Sharing Conference..........................................................................101 Adding a User to a Desktop Sharing Conference.............................................................102 Desktop Sharing Session Control.....................................................................................105 Communicator Web Access Scenario......................................................................................107 Functionality Overview......................................................................................................... 107 New Communicator Web Access Features.......................................................................108 Office Communicator and Web Access Feature Comparison...........................................109 Communicator Web Access Core Architecture.....................................................................111 UCMA Layer Functions..................................................................................................... 113 Application Logic Layer Functions.....................................................................................113 Client Functions................................................................................................................ 114 Communicator Web Access Audio........................................................................................ 116 Communicator Web Access Audio Scenarios...................................................................117 Call Deflection Session Initiation Protocol (SIP) Tracing...................................................120 Add Audio Session Initiation Protocol (SIP) Tracing..........................................................125 Outside Voice Control Scenario............................................................................................... 141 Outside Voice Control Architecture.......................................................................................143 Architectural Overview......................................................................................................... 144 Protocols Used By Outside Voice Control.........................................................................145 Call Flows............................................................................................................................. 145 Outbound Call................................................................................................................... 145 Inbound Call...................................................................................................................... 148 Group Chat Feature Scenario.................................................................................................. 150 Group Chat Services............................................................................................................ 150 Channel Service................................................................................................................ 150 Lookup Service................................................................................................................. 151 Web Service...................................................................................................................... 152 Compliance Service.......................................................................................................... 152 Key Protocols and Windows Services Used by Group Chat................................................153 Session Initiation Protocol (SIP)........................................................................................ 153 Windows Communication Foundation (WCF)...................................................................153 HTTPS.............................................................................................................................. 153 Message Queuing............................................................................................................. 154 Group Chat Call Flows......................................................................................................... 154 Group Chat Client Sign In................................................................................................. 154 Subscribing to a Chat Room and Posting a Message.......................................................157 Technical Drilldowns................................................................................................................... 159 SIP Processing Drilldown........................................................................................................ 159 SIP Processing and GRUU.................................................................................................. 159 GRUU Creation.................................................................................................................... 160 How GRUU Is Used by Office Communications Server.......................................................160 User Replicator Drilldown........................................................................................................ 161 5
Archiving and Monitoring Drilldown..........................................................................................162 Archiving and Monitoring Servers............................................................................................ 163 Archiving Server................................................................................................................ 163 Monitoring Server.............................................................................................................. 163 Archiving Database Schema................................................................................................164 List of Tables..................................................................................................................... 164 Supporting Tables............................................................................................................. 164 Tables for Messages in IM Conferences...........................................................................164 Tables for Peer-to-Peer IM Archiving................................................................................165 Tables for Internal Use by Office Communications Server................................................165 Table Details..................................................................................................................... 165 ClientVersions Table.......................................................................................................... 165 Computers Table............................................................................................................... 166 ContentTypes Table.......................................................................................................... 166 Dialogs Table.................................................................................................................... 166 Pools Table....................................................................................................................... 167 Users Table....................................................................................................................... 167 Conferences Table............................................................................................................ 167 ConferenceMessageRecipientList Table...........................................................................168 ConferenceMessages Table..............................................................................................169 SessionDetails Table......................................................................................................... 170 Messages Table................................................................................................................ 172 CDR Database Schema....................................................................................................... 173 List of Tables..................................................................................................................... 173 Static Tables...................................................................................................................... 173 Supporting Tables............................................................................................................. 173 Tables Specific to Conference CDR Records....................................................................174 Tables for Messages in IM Conferences...........................................................................174 Tables for Peer-to-Peer Sessions.....................................................................................175 Table for VoIP Call Details................................................................................................. 175 Tables for Troubleshooting................................................................................................175 Tables for Internal Use by Office Communications Server................................................176 Table Details..................................................................................................................... 176 MediaList Table................................................................................................................. 176 Roles Table....................................................................................................................... 177 UserAuthTypes Table........................................................................................................ 177 ClientVersions Table.......................................................................................................... 178 Computers Table............................................................................................................... 178 Pools Table....................................................................................................................... 178 Dialogs Table.................................................................................................................... 178 Gateways Table................................................................................................................ 179 Mcus Table........................................................................................................................ 179 Users Table....................................................................................................................... 180 Phones Table.................................................................................................................... 180 Conferences Table............................................................................................................ 180 FocusJoinsAndLeaves Table............................................................................................182 6
McuJoinsAndLeaves Table...............................................................................................183 ConferenceMessageCount Table......................................................................................184 SessionDetails Table......................................................................................................... 185 FileTransfers Table............................................................................................................ 187 Media Table....................................................................................................................... 188 VoipDetails Table.............................................................................................................. 188 Application Table............................................................................................................... 190 ErrorDef Table................................................................................................................... 190 ErrorReport Table.............................................................................................................. 191 ProgressReport Table....................................................................................................... 191 Sample Database Queries................................................................................................192 QoE Database Schema........................................................................................................ 193 List of Tables..................................................................................................................... 193 Table Details..................................................................................................................... 194 Sample Database Queries................................................................................................217 Message Queuing Architecture and Configuration for Archiving...........................................218 Message Stamping............................................................................................................... 220 Creating a Third-Party QoE Solution....................................................................................220 Infrastructure Requirements and Prerequisites of Monitoring Server................................220 Deploying a Custom QoE Solution....................................................................................224 WMI Reference for QoE Solutions....................................................................................224 Enabling or Disabling an HTTP Proxy for QoE Solutions..................................................226 Edge Servers Drilldown........................................................................................................... 227 Response Group Client Web Service Drilldown.......................................................................227 Service Descriptions............................................................................................................. 227 Client DNS Queries Drilldown.................................................................................................. 228 Application Server Drilldown.................................................................................................... 228 Characteristics of the Office Communications Server 2007 R2 Application Server..............229 Architecture....................................................................................................................... 229 Other Key Application Server Characteristics...................................................................231 Application Server Configuration..........................................................................................231 Application Server Application Configuration........................................................................232 Global Settings.................................................................................................................. 232 Pool Settings..................................................................................................................... 232 SIP Trunking Drilldown............................................................................................................ 232 SIP Trunking Drilldown: Supported Scenarios......................................................................233 SIP Trunking Drilldown: Supported Topologies.....................................................................233 SIP Trunking Drilldown: Security Considerations.................................................................235 SIP Trunking Drilldown: Bandwidth Considerations..............................................................236 SIP Trunking Drilldown: Protocol Flow and Details...............................................................237 SIP Call Flow and State Machine......................................................................................237 Call Hold........................................................................................................................... 237 Dual-tone multifrequency (DTMF).....................................................................................238 Early Media....................................................................................................................... 238 Uniform Resource Identifier (URI) Formatting...................................................................238 Codec Support.................................................................................................................. 238 7
SIP Trunking Drilldown: High Availability..............................................................................239 Address Book Server Drilldown............................................................................................... 239 Address Book Server Introduction........................................................................................241 Introduction....................................................................................................................... 241 Address Book Server: File and Database Generation..........................................................242 Address Book Server Data Flow.......................................................................................242 Address Book Server Process..........................................................................................242 Address Book Server: Address Book File Download Service...............................................245 File Generation................................................................................................................. 245 Organizational Unit and Address Book File Generation....................................................248 Client and Address Book Server Communication.............................................................248 Address Book and Office Communicator..........................................................................249 Client Download Process.................................................................................................. 250 Internet Explorer Dependencies........................................................................................ 251 File Store Recommendations and File Size Guidelines....................................................251 Office Communicator Local Address Book Database Files...............................................251 Address Book and Office Communicator Phone Edition...................................................252 Address Book Web Query Service....................................................................................252 Address Book Server: Address Book Web Query Service....................................................252 Office Communicator Address Book Queries ...................................................................254 Queries on Display Name ................................................................................................ 256 Queries on Phone Numbers ............................................................................................. 257 Sorting Query Results....................................................................................................... 258 Predictive Text Queries..................................................................................................... 258 Address Book Web Query Database................................................................................259 Address Book Web Query Database Language Support..................................................259 Address Book Web Query Server Performance................................................................260 Address Book Server: Advanced Address Book Features....................................................260 Management of Office Communications Server 2007 R2...........................................................266 Administrative Tools Overview................................................................................................. 266 Administrative Tools............................................................................................................. 267 Permissions.......................................................................................................................... 270 Installation and Use of Administrative Tools.............................................................................270 Version Restrictions.............................................................................................................. 271 Remote Administration Requirements..................................................................................271 Installing Administrative Tools............................................................................................... 272 Troubleshooting for Office Communications Server 2007 R2..................................................274 Load Balancers for Office Communications Server 2007 R2...................................................274 Prerequisites for a Load Balancer Connecting to a Pool......................................................274 Load Balancer Requirements............................................................................................... 275 Supported Load Balancer Configurations.............................................................................277 Media Ports............................................................................................................................. 278 Mediation Server for Office Communications Server 2007 R2.............................................278 Media Gateway................................................................................................................. 279 Media Port Range for Office Communications Server 2007 R2...........................................279 8
Minimum Number of Ports................................................................................................279 Server Port Allocation....................................................................................................... 286 Voice Quality of Service (QoS)................................................................................................287 QoS with Office Communications Server 2007 R2...............................................................287 Enabling DSCP Marking....................................................................................................... 288 Enabling QoS.................................................................................................................... 289 Installing the QoS Packet Scheduler on Computers.........................................................292 Verifying Group Policy Settings on Computers.................................................................293 WMI Settings for Office Communications Server 2007 R2......................................................294 Client Registry Keys/GPO for Office Communications Server 2007 R2..................................294 In-Band Provisioning over SIP................................................................................................. 294 Why Use In-Band Provisioning?.......................................................................................296 Office Communicator 2007 R2 Group Policy Precedence................................................297 Policy transport................................................................................................................. 297 Provisioning Groups.......................................................................................................... 301
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
[email protected]. We are always glad to hear from you. Note: You can download the Office Communications Server 2007 R2 Technical Reference Guide as a Word file from the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkID=159649. In This Document •
Office Communications Server 2007 R2 Architecture
•
Scenarios for Office Communications Server 2007 R2
•
Technical Drilldowns
•
Management of Office Communications Server 2007 R2
Office Communications Server 2007 R2 Architecture After providing a brief overview of the Office Communications Server 2007 R2 topology and component architecture, this section describes the architecture of the pool components in detail and the protocols that the components use to interact with each other. In This Section 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 Back-End Database Server also runs on the single physical server. Thus, all elements share the same server resources. 2
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 functions, performs directory replication functions and interfaces with the database, hosts 5
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: •
RTCSrv 6
•
Office Communications Server Application Programming Interface (API)
•
RTCHost
•
Back-End Database
•
Presence Components
•
Web Components Services for Office Communications Server 2007 R2
•
Archiving and Monitoring for Office Communications Server 2007 R2
•
Unified Communications Application Services (UCAS) Infrastructure
RTCSrv The RTCSrv.exe process is the core Office Communications Server 2007 R2 process. RTCSrv runs on every Standard Edition server and Front End instance of Office Communications Server 2007 R2. RTCSrv.exe hosts the User Services module, the server application programming interface (API), archiving and call detail recording (CDR), Quality of Experience (QoE), and the Session Initiation Protocol (SIP) Proxy. The User Services module, the server API, archiving and CDR, and QoE sit on top of the SIP Proxy. A message dispatcher mediates by sending messages between these components and the SIP Proxy. The following figure shows the RTCSrv.exe process. Figure 1. The RTCSrv.exe process
7
SIP Proxy The SIP Proxy is the core protocol platform on which all other Office Communications Server 2007 R2 services are built. The SIP Proxy provides the basic structure for networking and security, and performs connection management, message header parsing, routing, authentication, and state management. The SIP Proxy, also known as the SIP stack, forms the basis for all other Office Communications Server 2007 R2 services. Signaling connections, authentication, message routing, and state management all rely on the SIP Proxy. User Services User Services enables the instant messaging (IM), presence, and conferencing features of Office Communications Server 2007 R2. For details about the presence components of User Services, see Presence Components. User Services includes the Focus and Focus Factory, which are explained in more detail in Conferencing Components. The following table describes the functionality provided for User Services. Table 1. User Services Component
Function
User Replicator
User Replicator is the component of Office Communications Server 2007 R2 that is responsible for keeping the presence store in the SQL database synchronized with user and contact objects in Active Directory Domain Services (AD DS). User Replicator monitors the data in AD DS and then sends the data through RTCSrv.exe to the SQL database on the 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 8
Component
Function
Server back-end database.
Archiving, CDR, and QoE The archiving and CDR components, are installed on every Front End Server when you deploy Office Communications Server 2007 R2 Standard Edition server or Enterprise Edition server. Similarly, QoE is installed on every Front End Server. Archiving and CDR, and QoE connect to the Archiving Server and the Monitoring Server (that is, running in one of several possible physical topologies) using Message Queuing (previously known as MSMQ) technology. The Archiving Server receives instant messages from the archiving and CDR agent and stores the information in a SQL database. The Monitoring Server receives call data from the archiving and CDR agent, and QoE data from the QoE agent. For details about archiving and monitoring, see Archiving and Monitoring Drilldown.
Office Communications Server Application Programming Interface (API) The Office Communications Server 2007 R2 application programming interface (API) is built on the Session Initiation Protocol (SIP) proxy platform and implemented using the following: • Server API module (Apiem.dll). An extension that provides the basic scripting capability for creating custom message filters and routing applications. The scripts can either run in process with Office Communications Server 2007 R2 (Rtcsrv.exe) or can be incorporated in a managed server application that is running in a separate process. • Managed server API platform (ServerAgent.dll). A platform that you use to implement both Microsoft and non-Microsoft managed server applications. Managed server applications that are written by using the managed server API run as separate processes. • Local shared-memory IPC (Queue.dll). The interface between the server API module and managed applications. •
Internal COM API. An API used to communicate with the SIP proxy platform.
The following figure shows how the API architecture is implemented for Front End Servers.
9
Figure 1. API architecture for Front End Servers
SIP-aware managed server applications that are developed by using the managed server API platform extend the core services available in Office Communications Server2007 R2. Managed server applications include both of the following: • Office Communications Server 2007 R2 applications implemented by using RTCHost.exe. This includes the following filtering applications: Voice over Internet Protocol (VoIP) applications, conferencing server Factory, Real-time Communications (RTC) Aggregate application, and other applications (that is, non-Microsoft applications). For details about the managed server applications implemented with RTCHost.exe, see RTCHost. •
Non-Microsoft applications developed in-house, by vendors, or by using other resources.
The managed server API for implementing these applications functions as follows: •
Exposed through the Microsoft.Rtc.Sip namespace.
•
Uses the server API to perform specific SIP message processing tasks.
• Implemented by using the managed server application platform (that is, ServerAgent.dll assembly). Each managed application loads the ServerAgent.dll and executes in its own process space. Managed applications are isolated from each other in a way that prevents a faulty application from affecting other applications. Following are the two major components of the server API module (Apiem.dll) that support implementation of managed server applications: • Application manifest. A script that is written by using Microsoft SIP Processing Language (MSPL) and describes an application to the server. When a managed server 10
application registers with the server using the ServerAgent class, it provides this script to the server. The application manifest serves the following purposes: • Provides details about the application type and the state that the server needs to maintain for the application to run, so the server can optimize processing for the application. • Contains a message filter script to communicate detailed information about which messages (that is, requests and responses) the application needs to see. To filter messages, the application manifest has a set of built-in actions that it can invoke. For any other actions required by a specific message (that is, those actions that cannot be handled by the built-in actions), the application manifest can invoke managed code in a separate application process by passing all or parts of the message to the code in the application process. Using the built-in actions helps you avoid cross-process calls for simple processing (for example, basic if, then, and else functions). • Enables the application developer to specify moderate amount of logic to be executed by an interpreter inside the server API module. If the functionality of the interpreter is not sufficient, a cross-process call is made as a single call containing only the portions of the message that are appropriate to the message filtering used. • Uses an application Uniform Resource Identifier (URI) to uniquely identify the application to the server. The application URI is expected to be an HTTP URL, but no validation is performed. •
Microsoft.Rtc.Sip class library. Contains the following classes: •
SIP message and transaction processing classes.
• ServerAgent class. This class implements most of the logic needed to manage sessions with the server. It is the entry point for the managed server API. Each application initiates an instance of ServerAgent.dll and supplies an application manifest instance to it. The ServerAgent.dll assembly manages the session with the server, including compiling the application manifest and registering with the server. If the registration succeeds, the ServerAgent class sets up the environment necessary to receive and process SIP messages from the server. The ServerAgent.dll assembly invokes application-specific event handlers for specific events (for example, message events and transaction events). For each instance of the application, a single ServerAgent.dll object manages the applications session with the server. To exit, the application releases the ServerAgent.dll object, which causes the session with the server to end. You can use the Office Communications Server 2007 R2 Software Development Kit (SDK) to develop applications by using the Microsoft.Rtc.Sip class library. You can download the SDK at http://go.microsoft.com/fwlink/?LinkId=144480. For details about using the SDK, see “Communications Server 2007 R2 Server SDK Documentation” at http://go.microsoft.com/fwlink/?LinkId=144482.
11
RTCHost RTCHost.exe runs on each Front End server and can be accessed through the Managed Server application programming interface (API) library. The following applications run inside the RTCHost.exe process: • The Client Version Filter enables the server to deny client connections based on a client’s version number. The Client Version Filter compares a client’s version number with the version settings specified by the administrator by reading the clients Session Initiation Protocol (SIP) User-Agent header. You can configure the Client Version Filter by using the Office Communications Server Management Microsoft Management Console (MMC).snap-in. • The RTC Aggregate application manages the multiple points of presence (MPOP) feature for Office Communications Server 2007 R2 by aggregating the presence information published by multiple client endpoints into one presence status that best represents the user's current availability. For details about the RTC Aggregate application, see Presence Components. • The Intelligent IM Filter helps prevent unsolicited marketing that targets instant messaging (IM) programs. The Intelligent IM Filter uses settings configured by the administrator to filter incoming instant messages received by the server from outside the organization’s firewall. You can configure the Intelligent IM Filter by using the Office Communications Server Management snap-in. • The Conferencing Server Factory is required for conferencing. For details, see Conferencing Components. • The User Pin Service authorizes dial-in conferencing participants that enter in a conference personal identification number (PIN) when joining a conference by using the public switched telephone network (PSTN). • The VoIP applications that run inside RTCHost.exe are the Inbound Routing application, Translation Service, and Outbound Routing application. Together, these applications enable the server to route VoIP calls. For details, see Voice Components. • The Exchange UM Routing component handles redirection of missed calls to Exchange Unified Messaging. For details, see Voice Components.
Back-End Database In Office Communications Server 2007 R2, the back-end database stores configuration information, contact lists and presence information for users, and any state information required to resume a conference. Presence data and conferencing data are stored in different tables of the same physical database. In a Standard Edition configuration, all server components are installed on the same computer, including the back-end database. The back-end database on a Standard Edition server uses Microsoft SQL Server 2005 Express Edition with Service Pack 2 (SP2) or later. In an Enterprise Edition configuration, the back-end database must be configured as a separate dedicated computer. In an Enterprise pool, all servers in the pool share a central Microsoft SQL Server database. This database runs on Microsoft SQL Server 2008 (32-bit or 64-bit) or SQL 12
Server 2005 with Service Pack 2 (SP2) or later (32-bit or 64-bit), and you can cluster it in an active-passive configuration for higher availability.
Presence Components This section describes the presence components and the relationship between these components. It also shows the process boundaries for the various components. The primary presence components of Office Communications Server 2007 R2 are the User Services module that runs inside the RTCSrv.exe process and the RTC Aggregate application that runs inside the RTCHost.exe process. The User Services module processes registration requests received by a Front End Server and sends presence, registration, and conferencing data to the Back-End Database Server to keep the presence store in the SQL database synchronized with user and contact objects in Active Directory. The RTC Aggregate application aggregates presence information from multiple client endpoints into one presence document. The following figure shows the presence components. Figure 1. Presence components
Web Components Services for Office Communications Server 2007 R2 The Web Components Services run on Microsoft Internet Information Server (IIS), and enable Office Communications Server clients to perform the following functions: • Download Address Book Server files to provide Office Communicator with global address list (GAL) information. • Expand membership in distribution groups and other data that is used by the Web Conferencing Server. 13
•
Access meeting presentations and other content from Web conferences.
•
Host software packages for device updates.
•
Host administration for Response Group Service.
Archiving and Monitoring for Office Communications Server 2007 R2 Office Communications Server 2007 R2 includes Archiving and Monitoring functionality as follows: • Archiving. Designed for enterprise compliance needs, enables the capture and storage of instant messaging (IM) content. •
Monitoring. Designed for enterprise operational needs and enables the following: • The capture of call detail recordings (CDRs) that include IM, conferencing, and voice and video calls. CDRs include usage information related to voice calls, audio/video (A/V) conversations, application sharing, remote assistance, and Web conferences. • The capture and viewing of detailed Quality of Experience (QoE) metrics to monitor voice and video quality. QoE data includes statistics about voice and video quality, both for individual calls and aggregate reports.
The following figure shows the archiving and monitoring architecture in Office Communications Server 2007 R2. Figure 1. Archiving and monitoring architecture in Office Communications Server 2007 R2
The Front-End server hosts an archiving and CDR agent, which is part of the RTCSrv process, to capture archiving and CDR data which is transferred over Message Queuing (also known as MSMQ) to the Archiving Server and Monitoring Server respectively. The Archiving Server and Monitoring Server are separate Office Communications Server roles. Similarly, the Front End contains a QoE agent, which is part of the RTCQMS process, to capture QoE data. The QoE data is transferred over Message Queuing to the Monitoring Server. In Office Communications Server 2007 R2, the CDR function moves to the Monitoring Server from the Archiving Server with which it was a co-located in Office Communications Server 2007. CDR data accumulation and reporting requirements have characteristics more in common with QoE data than Archiving data, which drove the evolution in architecture.
14
Unified Communications Application Services (UCAS) Infrastructure Unified Communications Application Server (UCAS) is a platform introduced in Office Communications Server 2007 R2 that makes it easier to build server-side applications that run on Standard Edition servers or Enterprise pool servers. Each Front-End Server in a pool runs an instance of an Application Server host. Applications developed by using the Unified Communication Managed APIs (UCMA) 2.0 can use the UCAS platform as a common framework that leverages Office Communications Server capabilities such as deployment, trust, administration, load balancing and routing, monitoring, and so on. UCAS is designed to host server applications that act as Session Initiation Protocol (SIP) endpoints. Similar to Office Communications Server conferencing servers, UCAS is another server role. When you deploy UCAS on an Enterprise Edition server consolidated pool topology, each UCAS application runs on all servers in the pool and together they share the overall workload of the application. UCAS consists of a single Windows service, called Application Host (OCSAppServerMaster.exe), and one or more instances of another Windows service called OCSAppServerHost.exe. Each instance of OCSAppServerHost.exe on a server hosts a UCAS application unique to that server. Several new features in Office Communications Server 2007 R2 are implemented as UCAS applications, including dial-in conferencing, Response Group Service, and Outside Voice Control. For details, see Voice Components. For details about Application Server architecture, see Application Server Drilldown.
Conferencing Components Conferencing functionality in Office Communications Server 2007 R2, which includes instant messaging (IM) conferencing, Web conferencing, audio/video conferencing, desktop sharing, and control of third-party audio conferencing services, is supported by the following: • Conferencing infrastructure components. Includes conference control entities such as the Focus, Focus Factory, and so on. •
Conferencing servers. Handle media, including mixing functions for media.
Together, these two components support conferences over across a broad range of modalities. In This Section 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.
15
Figure 1. Conferencing component interrelationships
The Focus Factory and Focus components run in the main conferencing process, which is also the Session Initiation Protocol (SIP) Proxy process (RTCSrv). The Conferencing Server Factory is a fairly lightweight component (hosted by the RTCHost process) that is accessed by the Focus once for each media type when that media needs to be activated for the conference. The Conferencing Server Factory is an application running on each Front End Server and uses an HTTP interface. Communication between the Focus and conferencing servers, and between the Conferencing Server Factory and conferencing servers is HTTP-based. Focus The Focus is the central policy and state manager for a conference and acts as the coordinator for all aspects of the conference. The Focus is responsible for enforcing the conference control policy, managing the overall security for a conference, managing conference participant roles and privileges, sending conference state notifications to clients and providing a conduit for control commands to flow between clients and conferencing servers. 16
When a new media type must be activated for a conference, the Focus also instantiates the conference on the appropriate conferencing server, communicates with the conferencing server about adding a new user, obtains the authorization credentials so the client can connect to that conference, and then sends the media information to the client. The same sequence is repeated for all clients who want to add this media. When a new media type is added to the conference, the sequence is repeated with the new conferencing server for that media type. By centralizing the security enforcement and roster management, the Focus relieves each of the conferencing servers of this duty. Focus Factory The Focus Factory is a SIP entity that creates, deletes, and modifies meetings in the conferencing database. The Focus Factory manipulates meetings in the conferencing database according to Centralized Conferencing Control Protocol (C3P) commands that are issued by clients. Conferencing Server Factory The Conferencing Server Factory is responsible for provisioning a conference for a particular media type on a conferencing server. The Conferencing Server Factory can also take into account the current load on the conferencing servers before assigning a conferencing server to a conference. There is one Conferencing Server Factory instance on each Front End Server, which handles all media types. Conferencing Database A Focus holds important information for the entire conference, including all conference participants. If a Focus instance fails, it must be possible to restart the conference. To support this, any state information that is needed to resume the conference persists in a conferencing database, which runs on the SQL Server back-end database. In Office Communications Server 2007 R2, presence and registrar information, and conferencing information are stored in different tables of the same physical database. The important metadata associated with a conference in the conferencing database includes the following: •
Conference ID.
•
PSTN Meeting ID.
•
Expiration date and time of the conference.
•
List of meeting participant roles and the privileges associated with those roles.
•
Conference key for participants without an identity in Active Directory.
•
Supported media types.
•
Authorization types (for example, closed, open, and anonymous).
The conferencing database contains the metadata for a conference but does not contain calendar information. Conference calendar information (for example, meeting start and end times), the recurrence schedule, and exceptions to recurrence are all important for a prescheduled conference, but that information is maintained outside of the conferencing database. Instead, 17
conference calendar information is maintained by scheduling clients, as appropriate, typically as an Exchange Server calendar item. The Focus stores all conference state information on the Back-End Database Server to ensure that state information is accessible to all Front End Servers. With this model, if a client loses connectivity to the conferencing server, the client can reconnect, and its request can be handled by any Front End Server. This provides a natural failover model for front-end failures, as well as temporary loss of network connectivity from client to server. Similarly, information about conferencing server load persists on the Back-End Database Server, so that it is available to a Conferencing Server Factory instance running on any Front End Server. This data is written by a Conferencing Server Factory to the database, but any conferencing server for a particular media type under the control of the Conferencing Server Factory can read the database.
Conferencing Servers for Office Communications Server 2007 R2 A conferencing server is responsible for mixing and managing one or more media types. The following types of conferencing servers are included in Office Communications Server 2007 R2: •
Web Conferencing Server for data collaboration.
•
A/V Conferencing Server for audio and video.
•
Instant messaging (IM) Conferencing Server for multiparty IM.
•
Telephony Conferencing Server for interfacing with audio conferencing providers.
• Application Sharing Server for multiparty or Communicator Web Access-based application sharing. The architecture allows the addition of other conferencing servers as needed in the future. The IM Conferencing Server, Application Sharing Server, and Telephony Conferencing Server can only be installed as part of a Front End Server, but you can install A/V Conferencing Servers and Web Conferencing Servers independently of other components. Web Conferencing Servers, A/V Conferencing Servers, and IM Conferencing Servers each have two logical components: a media controller and a media processor. MC (Media Controller) The media controller on a conferencing server is responsible for managing the control commands between a Focus and a conferencing server. MP (Media Processor) The media processor is responsible for media management (for example, mixing, relaying, and transcoding). In a Web Conferencing Server, the media processor is a software component that is responsible for managing data collaboration for Office Communications Server. In an A/V Conferencing Server, the media processor mixes audio streams, switches video streams, and converts the media for clients who are on slow links. Of all the conferencing components, the media processor can be the most CPU and network intensive component. In our architecture, a media controller and media processor are collocated on the same computer to simplify deployment.
18
A/V Conferencing Server The A/V Conferencing Server enables multiparty audio and video mixing and relaying capabilities. It is built on industry standard real-time transport protocol (RTP) and real-time transport control protocol (RTCP). The A/V Conferencing Server also incorporates elements of the Internet Engineering Task Force (IETF) drafts for Interactive Connectivity Establishment (ICE) as a means to enable the exchange of media between two or more clients that are using Network Address Translators (NATs). ICE is an extension to Session Description Protocol (SDP) that enables media streams to traverse NATs by including in the SDP multiple IP address and port combinations for a particular transport protocol, known as candidate transport addresses, that the client can use to communicate with other clients. In an Office Communications Server environment, a client uses Session Traversal Utilities for NAT (STUN) and Traversal Using Relay NAT (TURN) protocols to obtain its candidate transport addresses from the Office Communications Server A/V Conferencing Edge Server. During negotiation, clients on either end exchange SDPs and then test candidate addresses for peer-to-peer connectivity. After the connectivity checks, clients renegotiate by including only the candidate transport address that succeeded in the SDP for a SIP re-INVITE request and response. For details about IETF drafts for ICE, see “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols” at http://go.microsoft.com/fwlink/?LinkId=144408. Web Conferencing Server The Web Conferencing Server adds data collaboration functionality to Office Communications Server. The Web Conferencing Server is built on the same Persistent Shared Object Model (PSOM) technology that is used by the Live Meeting service. Both signaling and media are sent to and from a Web Conferencing Server using the PSOM protocol. The Web Conferencing Server supports Live Meeting features, such as Microsoft Office PowerPoint presentations, document presentations, chat, voting, white boarding, and application sharing. The Web Conferencing Server uses shared folders on a file system to store conference state and conference contents. Universal Naming Convention (UNC) paths are configured on the Web Conferencing Server to refer to the shared folders, which are created by an administrator during Office Communications Server deployment. These folders for conference metadata and conference content can be located on the same computer as the Web Conferencing Server or, preferably, on a dedicated computer. For information about the way that a Web Conferencing Server works, see Web Conferencing Server for Office Communications Server 2007 R2. IM Conferencing Server The IM Conferencing Server is installed automatically on the Front End Server. The IM Conferencing Server enables multiparty instant messaging (IM). The IM Conferencing Server uses SIP for signaling and media.
19
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 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 20
(PSTN) gateway. The Outbound Routing application uses call authorization rules to route each call to the appropriate media gateway. The following figure shows the architecture of the core components: Translation Service, Inbound Routing, and Outbound Routing. Figure 1. Core component architecture
Inbound Routing The Inbound Routing application determines how incoming calls to the server should be routed. If an Enterprise Voice client specifies settings for handling missed calls, the Inbound Routing application acts accordingly. For example, if a client is configured for call forwarding, the Inbound Routing application can forward incoming calls either to a specified number or to an Exchange Server 2007 Unified Messaging server that can answer the call. Translation Service The Translation Service applies administrator-specified phone number normalization rules to translate a dialed number into an E.164 format that can be more easily consumed by a PBX or PSTN gateway. Enterprise Voice in Office Communications Server 2007 R2 employs the Translation Service to normalize phone numbers into a single format. Normalized phone numbers assist the server with reverse number lookup, outbound call routing, and call authorization rules. 21
Reverse number lookup is a process whereby a user's phone number is mapped to the appropriate SIP Uniform Resource Identifier (URI). By performing reverse number lookup, the server can route calls to all endpoints associated with a particular user’s SIP URI. Reverse number lookup also enables advanced call handling features, such as call forwarding. After a dialed number is normalized by the Translation Service, the Outbound Routing application can apply call authorization rules to route the call. Outbound Routing The Outbound Routing application uses call authorization rules configured by the administrator to route each call to the appropriate media gateway. Call authorization rules in Office Communications Server 2007 R2 are similar to traditional telephony "class of service" options. If the Outbound Routing application determines that a caller is not authorized to dial a particular number (for example, numbers outside the organization or international numbers), the Outbound Routing application can inform the caller that the call cannot be completed.
Unified Communications Application Services (UCAS) Voice Applications Unified Communications Application Services (UCAS) Enterprise Voice applications were added in the Office Communications Server 2007 R2 release to provide key Enterprise Voice features, such as dial-in conferencing (Conferencing Attendant and Conferencing Announcement Service), basic Automatic Call Distribution (that is, Response Group Service), and Office Communications Server server-side functions to extend Enterprise Voice to cellular telephones (that is, Outside Voice Control). Dial-in conferencing allows callers to use standard public switched telephone network (PSTN) telephones to dial in to audio conferences hosted on Office Communications Server. (In Office Communications Server 2007, only Office Communications Server enterprise-enabled users who connect over Internet Protocol (IP) audio could join audio conferences hosted on Office Communications Server.) Dial-in conferencing is enabled by the Conferencing Attendant and Conferencing Announcement Service UCAS applications. For details, see Dial-In Conferencing Scenario. Conferencing Attendant The Conferencing Attendant is an auto-attendant service (that is, a bot) that authenticates and joins dial-in participants to audio conferences. Office Communications Server 2007 R2 Conferencing Attendant supports 14 different languages. The Conferencing Attendant prompts the caller for conference IDs and passcode (that is, if the caller is calling in as an anonymous participant) or extension number and personal identification number (PIN) (that is, if the caller is joining as a Enterprise User), plays on-hold music when enterprise users have not yet joined the meeting, requests authentication from a front-end service, and joins authenticated callers to the Focus and A/V Conferencing Server for the requested conference ID. The Conferencing Attendant Service on each Front End Server listens on Transmission Control Protocol (TCP) port 5072 for incoming calls. These requests normally come from a Mediation Server and are proxied by the Mediation Server’s next hop pool.
22
Conferencing Announcement Service The Conference Announcement Service is another trusted bot that participates in all dial-in enabled audio conferences. It monitors the conference roster and plays entry and exit tones to all dial-in attendees when other dial-in attendees join or leave, and also tells attendees when their microphone has been muted or unmuted in the language that they chose when they connected to the Conferencing Attendant. No configuration is required for this service. The Conference Announcement Service on each Front End Server listens on TCP port 5073 for requests from a Focus that is running on one of the Front End Servers in the pool. Response Group Service The Office Communications Server 2007 R2 Response Group Service enables administrators to create and configure one or more response groups for the purpose of routing and queuing incoming phone calls to one or more designated agents. These response groups can be deployed in departmental or workgroup environments and in entirely new telephony installations. Typical usage scenarios include an internal helpdesk, a customer service desk, or a general external call handler. Response Group Service can increase response group usage and reduce the associated overhead by pushing the tasks of response group maintenance down to the users who directly benefit from them. The Response Group Service functionality is enabled by the Response Group Service application, which is a UCAS application that implements standard response group call-routing algorithms (that is, including serial, longest-idle, parallel, and round robin), interactive voice response (IVR), call queuing, on-hold music, presence-based routing, and so on. Outside Voice Control The Office Communications Server 2007 R2 Outside Voice Control feature enables users to use their enterprise telephone number for inbound and outbound calls on their personal mobile phone. To use this feature, the user must have Office Communicator Mobile (2007 R2 release) installed on a Windows Mobile phone and must be able to use data packet communication between the mobile phone and the mobile phone provider (for example, General Packet Radio Source (GPRS)) that allows SIP messages to be transmitted. The user must also be enabled for Enterprise Voice. For inbound calls, Office Communications Server 2007 R2 sends a SIP Invite to all registered SIP endpoints of the user including the user’s Communicator Mobile (2007 R2 release) client running on the phone, over the data channel. Office Communications Server 2007 R2 subsequently initiates an outbound PSTN/mobile network call through Office Communications Server 2007 R2 Mediation Server to the user’s mobile phone number. For an outbound call from a mobile phone, the user has the option to enter the phone number to be dialed into Communicator Mobile (2007 R2 release) or to initiate a call to a SIP contact using Communicator Mobile (2007 R2 release). The user receives an incoming mobile phone call from Office Communications Server using the mobile phone provider’s cellular network. After the user accepts the call from Office Communications Server, Office Communications Server sets up a second call leg to the designated called party and then join the two connections. The called party 23
receives a call from the user’s company using the user’s office phone number despite the fact that the user is actually on a mobile phone. The Outside Voice Control application on each Front End Server listens on TCP port 5074.
Communication Protocols for Office Communication Server 2007 R2 In This Section This section includes the following topics: •
Protocols Overview
•
Conferencing Protocols
Protocols Overview While Session Initiation Protocol (SIP) is still the primary control protocol used by Office Communications Server 2007 R2, Web Conferencing Server, A/V Conferencing Server, and their subcomponents, they also employ other protocols to set up and modify conferences and to set up and break down media streams between different elements in the Office Communications Server2007 R2 network. The following protocols are employed by Office Communications Server 2007 R2: • Session Initiation Protocol (SIP). The industry standard protocol described in IETF RFC 3261 that defines a standard for session setup, termination, and media negotiation between two parties. It is widely used for Voice over IP (VoIP) call signaling. • Asynchronous JavaScript And XML (AJAX). Used in Communicator Web Access to ensure efficient client-server interaction, while keeping the Web user interface (UI) responsive. • Centralized Conferencing Control Protocol (C3P). Used to encode Conferencing Control commands in Office Communications Server. • HTTPS. The set of rules for exchanging files (that is, text, graphic images, sound, video, and other multimedia files) on the World Wide Web. Relative to the Transmission Control Protocol (TCP)/Internet Protocol (IP) suite of protocols, the basis for information exchange on the Internet, HTTP is an application-layer protocol. HTTPS is the HTTP protocol over Secure Sockets Layer (SSL)/Transport Layer Security (TLS). • Interactive Connectivity Establishment (ICE). Used to provide media connectivity across firewalls and Network Address Translation (NAT) devices, thereby enabling audio/video anywhere. • Persistent Shared Object Model (PSOM). A proprietary protocol for the transport of real-time data, including audio and video. PSOM uses TCP or TLS as the underlying transport. • Remote Desktop Protocol (RDP). The Microsoft protocol that is used in Office Communications Server 2007 R2 for desktop sharing. This is the protocol that is used for Microsoft Remote Desktop Services. 24
• Real-time transport protocol/real-time control protocol (RTP/RTCP). The industry standard protocol for the transport of real-time data, including audio and video. • Session Description Protocol (SDP). Used to negotiate capabilities between SIP endpoints during call initiation. • Secure real-time transport protocol/secure real-time control protocol (SRTP/SRTCP). Encrypted versions of RTP/RTCP. • Scale secure real-time transport protocol (SSRTP). Scale secure RTP/RTCP, used for efficient media sessions for multi-point audio/video conferences. • Simple Traversal of UDP through NAT (STUN). Used by endpoints to determine the public IP addresses allocated to them by the NAT (if applicable). • Transport Layer Security (TLS). Used to encrypt SIP or HTTP trafficin addition to server authentication. •
Third Party Control Protocol (TPCP). Used for Outside Voice Control.
• Traversal Using Relay NAT (TURN). A protocol for allocating a public IP address and port on a globally reachable server for the purpose of relaying media from one endpoint to another. For detailed specifications for Office Communications Server protocols, including several of those listed in this topic, see “Microsoft Office Protocol Documents” at http://go.microsoft.com/fwlink/? LinkId=158438.
Conferencing Protocols The following table shows the protocols that are used between conferencing components. Table 1. Conferencing Protocols Client
Focus
Focus
Conferencing
Conferencing
Factory
Server Factory
server
Client
X
Session Initiation Protocol (SIP), Centralized Conferencing Control Protocol (C3P)
SIP, C3P
X
SIP, real-time transport protocol (RTP), Persistent Shared Object Model (PSOM) and so on
Focus
SIP, C3P
X
X
HTTPS, C3P
HTTPS, C3P
Focus Factory
SIP, C3P
X
X
X
X
Conferencing Server Factory
X
HTTPS, C3P
X
X
HTTPS, C3P
Conferencing
SIP, RTP,
HTTPS, C3P
X
HTTPS, C3P
X 25
Client
Server
Focus
Focus
Conferencing
Conferencing
Factory
Server Factory
server
PSOM and so on
The following figure provides an overview of the protocols and the components that use them to communicate. Figure 1. Office Communication Server 2007 R2 conferencing protocols and component relationships
26
Interfaces in the diagram identify a specific link, based on the transport and purpose, between two logical elements. The same protocol can be used in different ways over the various interfaces. For example, SIP/3CP is used to communicate C3P commands over SIP INFO messages and conference event package notifications over SIP SUBSCRIBE and NOTIFY messages.
Centralized Conferencing Control Protocol (C3P) C3P is a conference manipulation protocol used by the Office Communications Server 2007 conferencing servers. C3P is used to modify the conference state. The channels over which C3P can be used in an Office Communications Server 2007 deployment are shown in Figure 1. C3P has request/pending response/final response semantics similar to SIP. The following table lists C3P commands. Table 2. C3P Commands Conference Level
addConference deleteConference modifyConference getConference getMCU modifyConferenceLock modifyUsersMediaFilters
User Level
addUser deleteUser modifyUser modifyUserRoles setUserAccess
Scheduling
getAvailableMcuTypes getConferencingCapabilities getEncryptionKey 27
Scheduling
getConferences
Endpoint Level
modifyEndpointRole
Endpoint Media Level
addEndpointMedia deleteEndpointMedia modifyEndpointMedia
High Availability (HA)/Load Balancing
ping getConference
PSOM PSOM is the media protocol for data collaboration. PSOM uses Transport Layer Security (TLS) as the underlying transport. Conferencing clients can use PSOM to establish media channels with the Web Conferencing Server to negotiate or transfer media.
RTP/RTCP RTP/RTCP is the standard protocol for the transport of real-time data, including audio and video.
SIP/SDP Session Initiation Protocol (SIP) is the industry standard protocol described in IETF RFC 3261 that defines a standard way for session setup, termination, and media negotiation between two parties. It is widely used for Voice over IP (VoIP) call signaling. Session Description Protocol (SDP) is the industry standard protocol described in IETF RFC 4566 that defines a standard way to convey media details, transport addresses, and other session description metadata to the participants when initiating multimedia teleconferences, Voice over IP calls, streaming video, or other sessions.
28
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. 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
29
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 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. 30
Conferencing Data Flow This figure shows the data flow between participating components when an intranet client creates and joins a conference.
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 31
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.
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:@;gruu;opaque=app:conf:focus:id: . For instance: sip:
[email protected];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.
32
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 and important policy information a client should know before scheduling a conference. For example: SERVICE sip:
[email protected];gruu;opaque=app:conf:focusfactory To: sip:
[email protected];gruu;opaque=app:conf:focusfactory From: sip:
[email protected];tag=f7588dc66124429ab736 Call-ID: 3412asdsss CSeq: 1 SERVICE Content-Type: application/cccp+xml SIP headers... 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: 33
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: INVITE sip:
[email protected];gruu;opaque=app:conf:focus:id:1234 To: sip:
[email protected];gruu;opaque=app:conf:focus:id:1234 From: sip:
[email protected];tag=f7588dc66124429ab736 Call-ID: adfsfasdfasdfds CSeq: 1 INVITE Content-Type: application/cccp+xml SIP headers... 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:
[email protected];gruu;opaque=app:conf:focus:id:1234 To: sip:
[email protected];gruu;opaque=app:conf:focus:id:1234 From: sip:
[email protected];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:
[email protected];gruu;opaque=app:conf:focus:id:1234 From: sip:
[email protected];tag=f7588dc66124429ab736 Call-ID: adfsfasdfasdfds CSeq: 1 SUBSCRIBE Event: conference Accept: application/conference-info+xml Content-Type: application/conference-info+xml 34
SIP headers... sip:
[email protected];gruu;opaque=app:conf:audiovideo:id:1234 audio-video audio-video sip:
[email protected];gruu;opaque=app:conf:meeting:id:1234 meeting meeting sip:
[email protected];gruu;opaque=app:conf:chat:id:1234 chat chat sip:
[email protected];gruu;opaque=app:conf:phoneconf:id:1234 phone-conf phone-conf The following figure shows the message flow between conferencing components when the Focus bootstraps the Web Conferencing Server.
35
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 msnotification purpose parameter. The second URL is a SIP URL that specifies the outboundproxy 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).
36
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.
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.
37
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. 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 38
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. 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.
39
Client joining media with a Web Conferencing Server using addUser dial-in 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.
40
Step 6. The Focus sends a participant joined conferencing server state change notification to all clients subscribed to the conference state. BENOTIFY sip:
[email protected] SIP/2.0 SIP headers... Bob Kelly connected data collab dataCollab
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.
41
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 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.
42
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. 43
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: on-hold 44
on-hold presenter connected connected participant connected brownbag sip:
[email protected];ms-app=conf/meeting;ms-conf-id=cd Data MCU meeting sip:
[email protected];ms-app=conf/audio-video;ms-confid=cd/uri> AV MCU audio-video 45
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.
46
• 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 47
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 organization needs to retain data exchanged in Web conferences to satisfy regulatory compliance 48
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 folder. If a folder for a conference does not exist, the Web Conferencing Server creates a new conference
49
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
50
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.
51
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
52
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. 53
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.
54
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.
55
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-.exml and set-s-.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.
56
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. 57
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 58
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. What day is today? MON TUE WED THU FRI SAT SUN Metadata file for Text Slide The following is an example of the XML content for a Text slide. 59
This is the content of a text slide I've just typed Metadata File for Web Slide The following is an example of the XML content for a Web slide. Metadata File for Whiteboard Slide The following is an example of the XML content for a Whiteboard slide. 01000000000a0075007a00af007100cc009c00c000ba009d00b0009b009d00f40084011 400980116009901160099 17000000009700fa01090144 Metadata File for Snapshot Slide The following is an example of the XML content for a Snapshot slide. 01000000000a0075007a00af007100cc009c00c000ba009d00b0009b009d00f40084011 400980116009901160099 17000000009700fa01090144 Metadata File for Word Document Slide The following is an example of the XML content for a Word document slide. Metadata File for Application Sharing Slide The following is an example of the XML content for an Application Sharing 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-.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).
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. This is the content of the shared notes pane I've just edited 64
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.
65
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.
EMDI
An encrypted MDI document – the console converts the Word document into a MDI before 66
Extension
Description
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
67
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. The following figure shows the structure of the compliance folder. 68
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.
69
70
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.
71
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 72
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.
73
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.
74
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.
75
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 76
•
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; 77
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:
[email protected]), 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-@.) 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, thereby setting the dial-in numbers that are used by the conference. Users who are enabled for 78
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 = ), plus instances for each server in those pools (msRTCSIP-TrustedServerFQDN = ). 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.
79
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 80
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
81
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 meeting is created. The pool portion of the Conference ID routes the dial-in caller to the specific pool where the meeting is hosted. 82
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. 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.
83
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. 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 84
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.
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.
85
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 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 86
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. 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. 87
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. 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 nexthop 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 88
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.
89
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. 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.
90
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.
91
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:
92
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.
93
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.
94
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.
95
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, Registrar, Focus Factory, and Focus instances. In an Enterprise pool, the hardware load balancer 96
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. 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. 97
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. and download.. 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 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, 98
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).
99
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).
100
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: 101
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 a=candidate:1 a=candidate:2 a=candidate:2
1 2 1 2
TCP-PASS 2120613887 192.168.100.20 18608 typ host TCP-PASS 2120613374 192.168.100.20 18608 typ host TCP-ACT 2121006591 192.168.100.20 4636 typ host 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. 102
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.
103
Note: In the following diagrams, the SIP ACKs and some other traffic have been skipped for readability.
104
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.
105
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.
106
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. 107
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.
108
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 109
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
110
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.
111
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.
112
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
113
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.
114
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. 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 115
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 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 116
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 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.
117
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 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. 118
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. 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 119
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. 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 120
Direction: incoming Peer: 192.0.2.143:1331 Message-Type: request Start-Line: INVITE sip:
[email protected];user=phone SIP/2.0 From: ;tag=ea1b3cab6b;epid=213be0ea4a To: CSeq: 1 INVITE Call-ID: a9c2eb61a37944979e6ba90adbf869ce Via: SIP/2.0/TLS 192.0.2.143:1331 Max-Forwards: 70 Contact: 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: , Supported: ms-conf-invite Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="24C84179", targetname="sip/ocs.litwareinc.com", crand="2137c1d9", cnum="73", response="602306092a864886f71201020201011100ffffffff1e132d0f694dca10627 59f1ba2b2538c" Content-Type: multipart/alternative;boundary="---=_NextPart_000_0A41_01C9F328.696A8600" Content-Length: 4786 Message-Body: ------=_NextPart_000_0A41_01C9F328.696A8600 121
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";tag=ea1b3cab6b;epid=213be0ea4a To: ;epid=454BF77D78 CSeq: 1 INVITE Call-ID: a9c2eb61a37944979e6ba90adbf869ce ms-user-data: ms-publiccloud=true;ms-federation=true Record-Route: ;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 Content-Length: 4786 Via: SIP/2.0/TLS 192.0.2.143:1331;ms-received-port=1331;ms-receivedcid=58200 P-Asserted-Identity: "User2",
122
Contact: 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: ;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 Message-Type: response Start-Line: SIP/2.0 101 Progress Report From: "User2";tag=ea1b3cab6b;epid=213be0ea4a To: CSeq: 1 INVITE 123
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";tag=ea1b3cab6b;epid=213be0ea4a To: "User1";tag=ba51cb6d68;epid=454BF77D78 CSeq: 1 INVITE 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: 124
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";tag=ea1b3cab6b;epid=213be0ea4a To: "User1";tag=ba51cb6d68;epid=454BF77D78 CSeq: 1 ACK Call-ID: a9c2eb61a37944979e6ba90adbf869ce Via: SIP/2.0/TLS 192.168.5.28:2507;branch=z9hG4bK41780D13.6D1B53BD01D5FDC8;branched=FALSE Max-Forwards: 70 Content-Length: 0 Message-Body: – $$end_record
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. 125
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:
[email protected];gruu;opaque=app:conf:focusfactory SIP/2.0 From: ;epid=B90980A18B;tag=7fc74f8252 To: 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: $$end_record 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" 126
Peer: cwa.litwareinc.com:3380 Message-Type: response Start-Line: SIP/2.0 200 OK From: "User1;epid=B90980A18B;tag=7fc74f8252 To: ;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:
[email protected];gruu;opaque=app:conf:focusfactory SIP/2.0 From: ;epid=B90980A18B;tag=44f970267e To: 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 127
CONTENT-TYPE: application/cccp+xml Message-Body: $$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;epid=B90980A18B;tag=44f970267e To: ;tag=04E32C 63BB6B7CF14891AD3423F629A0 CSeq: 1501 SERVICE Call-ID: a44fe317039844478b3879e2dfeb66f2 Content-Length: 1893 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 128
Direction: incoming Peer: cwa.litwareinc.com:3380 Message-Type: request Start-Line: SERVICE sip:
[email protected];gruu;opaque=app:conf:focusfactory SIP/2.0 From: ;epid=B90980A18B;tag=435df06b43 To: 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 From: "User1;epid=B90980A18B;tag=435df06b43 To: ;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:
