Docstoc

OCS 2007 R2 Technical Reference

Document Sample
OCS 2007 R2 Technical Reference Powered By Docstoc
					Microsoft Office Communications
Server 2007 R2

Technical Reference


Published: July 2009
Updated: October 2009




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
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the companies, organizations, products, domain
names, e-mail addresses, logos, people, places, and events depicted in examples herein are
fictitious. No association with any real company, organization, product, domain name, e-mail
address, logo, person, place, or event is intended or should be inferred. Complying with all
applicable copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in or introduced into a retrieval
system, or transmitted in any form or by any means (electronic, mechanical, photocopying,
recording, or otherwise), or for any purpose, without the express written permission of Microsoft
Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.
© 2009 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, ActiveX, Excel, Hyper-V, Internet Explorer, MSN, MSDN, OneNote,
Outlook, PowerPoint, RoundTable, SharePoint, SQL Server, Visio, Visual Basic, Visual C++,
Visual J#, Visual Studio, Windows, Windows Live, Windows Media, Windows Mobile, Windows
NT, 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
Technical Reference for Office Communications Server 2007 R2 .............................................. 11

Office Communications Server 2007 R2 Architecture................................................................. 11
  Topology and Component Architecture................................................................................... 12
     Standard Edition (Single Server Installation) ....................................................................... 12
     Enterprise Edition ............................................................................................................... 13
     Consolidated Configuration ................................................................................................. 13
     Expanded Configuration...................................................................................................... 13
  Pool Components for Office Communications Server 2007 R2 ............................................... 13
     Overview of Pool Components ............................................................................................ 14
     Common Infrastructure Components................................................................................... 16
       RTCSrv ........................................................................................................................... 17
       Office Communications Server Application Programming Interface (API) ......................... 20
       RTCHost ......................................................................................................................... 22
       Back-End Database......................................................................................................... 23
       Presence Components .................................................................................................... 23
       Web Components Services for Office Communications Server 2007 R2 .......................... 24
       Archiving and Monitoring for Office Communications Server 2007 R2 .............................. 24
       Unified Communications Application Services (UCAS) Infrastructure ............................... 25
     Conferencing Components.................................................................................................. 26
       Conferencing Infrastructure Components ......................................................................... 26
       Conferencing Servers for Office Communications Server 2007 R2 ................................... 29
     Voice Components ............................................................................................................. 31
       RTCHost Voice Components ........................................................................................... 31
       Unified Communications Application Services (UCAS) Voice Applications ....................... 33
  Communication Protocols for Office Communication Server 2007 R2 ..................................... 35
     Protocols Overview ............................................................................................................. 35
     Conferencing Protocols ....................................................................................................... 36
       Centralized Conferencing Control Protocol (C3P)............................................................. 39
       PSOM ............................................................................................................................. 40
       RTP/RTCP ...................................................................................................................... 40
       SIP/SDP .......................................................................................................................... 40
       Signaling and Control Protocol ......................................................................................... 40
       Media Protocols ............................................................................................................... 41

Scenarios for Office Communications Server 2007 R2 ............................................................... 41
  Conferencing Scenario for Office Communications Server 2007 R2........................................ 41
   Core (Focus, Focus Factory, and Conferencing Server Factory)......................................... 42
     Conferencing Lifecycle .................................................................................................... 42
     Conferencing Data Flow .................................................................................................. 42
     Conference Creation and Activation ................................................................................. 44
     Joining a Conference ....................................................................................................... 49


                                                                                                                                          3
     Adding Participants to the Conference ............................................................................. 53
     Notification Document...................................................................................................... 56
     Conference Deactivation.................................................................................................. 58
     Conference Expiration ..................................................................................................... 58
  Web Conferencing Server for Office Communications Server 2007 R2 ................................ 58
     Web Conferencing Architecture ....................................................................................... 59
     File Structure ................................................................................................................... 60
     Metadata Folder .............................................................................................................. 61
     Organizer Folder.............................................................................................................. 62
     Conference Folder ........................................................................................................... 62
     Types of Slides ................................................................................................................ 64
     Content Upload and Download over PSOM ..................................................................... 65
     Content Upload over PSOM and Download over HTTPS ................................................. 66
     Slide Set Files ................................................................................................................. 68
     Handouts (File Transfers) ................................................................................................ 75
     PersistData Folder (Shared Notes) .................................................................................. 76
     Content Folder................................................................................................................. 77
     Conference Content Folder .............................................................................................. 78
     File Size Restrictions ....................................................................................................... 80
     Compliance ..................................................................................................................... 80
  Conferencing Scenario Call Flows in Office Communications Server 2007 R2 ..................... 83
Dial-In Conferencing Scenario ................................................................................................ 87
  Server-Based Dial-In Conferencing Components ................................................................ 89
     Active Directory–Based Configuration Data...................................................................... 89
     Office Communications Server Front End Server Components ........................................ 92
  Client-Based Dial-in Conferencing Components .................................................................. 97
     Conferencing Add-in for Microsoft Office Outlook ............................................................. 98
     Live Meeting Client .......................................................................................................... 98
     Office Communicator ....................................................................................................... 99
  Call Flows ........................................................................................................................... 99
     Meeting Set-up ................................................................................................................ 99
     To create an Anonymous-Allowed Live Meeting with Dial-In Conferencing support........... 99
     Connecting to the Meeting ............................................................................................. 100
Desktop Sharing Scenario .................................................................................................... 105
  Office Communications Server 2007 R2 Desktop Sharing Architecture.............................. 106
     Architectural Overview ................................................................................................... 106
     Protocols Used By Desktop Sharing .............................................................................. 107
     Desktop Sharing Components ....................................................................................... 109
  Desktop Sharing Call Flows .............................................................................................. 114
     Creating a Desktop Sharing Conference ........................................................................ 114
     Adding a User to a Desktop Sharing Conference ........................................................... 115
     Desktop Sharing Session Control .................................................................................. 118
Communicator Web Access Scenario................................................................................... 120
  Functionality Overview ...................................................................................................... 120
     New Communicator Web Access Features .................................................................... 121
     Office Communicator and Web Access Feature Comparison ......................................... 122

                                                                                                                                         4
   Communicator Web Access Core Architecture .................................................................. 124
     UCMA Layer Functions.................................................................................................. 126
     Application Logic Layer Functions.................................................................................. 126
     Client Functions............................................................................................................. 127
   Communicator Web Access Audio .................................................................................... 129
     Communicator Web Access Audio Scenarios ................................................................ 130
     Call Deflection Session Initiation Protocol (SIP) Tracing ................................................. 133
     Add Audio Session Initiation Protocol (SIP) Tracing ....................................................... 139
  Outside Voice Control Scenario ............................................................................................ 154
   Outside Voice Control Architecture.................................................................................... 156
   Architectural Overview ...................................................................................................... 158
     Protocols Used By Outside Voice Control ...................................................................... 159
   Call Flows ......................................................................................................................... 159
     Outbound Call ............................................................................................................... 159
     Inbound Call .................................................................................................................. 162
  Group Chat Feature Scenario............................................................................................... 164
   Group Chat Services......................................................................................................... 164
     Channel Service ............................................................................................................ 164
     Lookup Service .............................................................................................................. 165
     Web Service .................................................................................................................. 166
     Compliance Service ....................................................................................................... 166
   Key Protocols and Windows Services Used by Group Chat ............................................... 167
     Session Initiation Protocol (SIP) ..................................................................................... 167
     Windows Communication Foundation (WCF) ................................................................. 167
     HTTPS .......................................................................................................................... 167
     Message Queuing ......................................................................................................... 168
   Group Chat Call Flows ...................................................................................................... 168
     Group Chat Client Sign In .............................................................................................. 168
     Subscribing to a Chat Room and Posting a Message ..................................................... 171

Technical Drilldowns ............................................................................................................... 174
  SIP Processing Drilldown ..................................................................................................... 174
    SIP Processing and GRUU ............................................................................................... 174
    GRUU Creation................................................................................................................. 175
    How GRUU Is Used by Office Communications Server ..................................................... 175
  User Replicator Drilldown ..................................................................................................... 176
  Archiving and Monitoring Drilldown....................................................................................... 178
    Archiving and Monitoring Servers ...................................................................................... 178
      Archiving Server ............................................................................................................ 178
      Monitoring Server .......................................................................................................... 178
    Archiving Database Schema ............................................................................................. 179
      List of Tables ................................................................................................................. 179
      Supporting Tables ......................................................................................................... 179
      Tables for Messages in IM Conferences ........................................................................ 179
      Tables for Peer-to-Peer IM Archiving ............................................................................. 180
      Tables for Internal Use by Office Communications Server .............................................. 180


                                                                                                                                         5
 Table Details ................................................................................................................. 180
 ClientVersions Table...................................................................................................... 180
 Computers Table ........................................................................................................... 181
 ContentTypes Table ...................................................................................................... 181
 Dialogs Table ................................................................................................................ 181
 Pools Table ................................................................................................................... 182
 Users Table ................................................................................................................... 182
 Conferences Table ........................................................................................................ 183
 ConferenceMessageRecipientList Table ........................................................................ 184
 ConferenceMessages Table .......................................................................................... 184
 SessionDetails Table ..................................................................................................... 185
 Messages Table ............................................................................................................ 187
CDR Database Schema.................................................................................................... 188
 List of Tables ................................................................................................................. 188
 Static Tables ................................................................................................................. 188
 Supporting Tables ......................................................................................................... 189
 Tables Specific to Conference CDR Records ................................................................. 189
 Tables for Messages in IM Conferences ........................................................................ 190
 Tables for Peer-to-Peer Sessions .................................................................................. 190
 Table for VoIP Call Details ............................................................................................. 190
 Tables for Troubleshooting ............................................................................................ 191
 Tables for Internal Use by Office Communications Server .............................................. 191
 Table Details ................................................................................................................. 191
 MediaList Table ............................................................................................................. 192
 Roles Table ................................................................................................................... 192
 UserAuthTypes Table .................................................................................................... 192
 ClientVersions Table...................................................................................................... 193
 Computers Table ........................................................................................................... 193
 Pools Table ................................................................................................................... 194
 Dialogs Table ................................................................................................................ 194
 Gateways Table ............................................................................................................ 194
 Mcus Table.................................................................................................................... 195
 Users Table ................................................................................................................... 195
 Phones Table ................................................................................................................ 196
 Conferences Table ........................................................................................................ 196
 FocusJoinsAndLeaves Table ......................................................................................... 197
 McuJoinsAndLeaves Table ............................................................................................ 198
 ConferenceMessageCount Table................................................................................... 199
 SessionDetails Table ..................................................................................................... 200
 FileTransfers Table ........................................................................................................ 202
 Media Table .................................................................................................................. 204
 VoipDetails Table .......................................................................................................... 204
 Application Table ........................................................................................................... 205
 ErrorDef Table ............................................................................................................... 206
 ErrorReport Table .......................................................................................................... 206
 ProgressReport Table.................................................................................................... 207

                                                                                                                                   6
    Sample Database Queries ............................................................................................. 208
  QoE Database Schema .................................................................................................... 209
    List of Tables ................................................................................................................. 209
    Table Details ................................................................................................................. 210
    Sample Database Queries ............................................................................................. 233
  Message Queuing Architecture and Configuration for Archiving......................................... 235
  Message Stamping ........................................................................................................... 236
  Creating a Third-Party QoE Solution ................................................................................. 236
    Infrastructure Requirements and Prerequisites of Monitoring Server .............................. 237
    Deploying a Custom QoE Solution ................................................................................. 240
    WMI Reference for QoE Solutions ................................................................................. 240
    Enabling or Disabling an HTTP Proxy for QoE Solutions ................................................ 243
Edge Servers Drilldown ........................................................................................................ 243
Response Group Client Web Service Drilldown .................................................................... 243
  Service Descriptions ......................................................................................................... 244
Client DNS Queries Drilldown............................................................................................... 244
Application Server Drilldown ................................................................................................. 245
  Characteristics of the Office Communications Server 2007 R2 Application Server ............. 246
    Architecture ................................................................................................................... 246
    Other Key Application Server Characteristics ................................................................. 247
  Application Server Configuration ....................................................................................... 248
  Application Server Application Configuration ..................................................................... 248
    Global Settings .............................................................................................................. 248
    Pool Settings ................................................................................................................. 249
SIP Trunking Drilldown ......................................................................................................... 249
  SIP Trunking Drilldown: Supported Scenarios ................................................................... 249
  SIP Trunking Drilldown: Supported Topologies.................................................................. 250
  SIP Trunking Drilldown: Security Considerations ............................................................... 251
  SIP Trunking Drilldown: Bandwidth Considerations ........................................................... 252
  SIP Trunking Drilldown: Protocol Flow and Details ............................................................ 253
    SIP Call Flow and State Machine ................................................................................... 253
    Call Hold ....................................................................................................................... 254
    Dual-tone multifrequency (DTMF) .................................................................................. 254
    Early Media ................................................................................................................... 254
    Uniform Resource Identifier (URI) Formatting ................................................................ 254
    Codec Support .............................................................................................................. 255
  SIP Trunking Drilldown: High Availability ........................................................................... 255
Address Book Server Drilldown ............................................................................................ 256
  Address Book Server Introduction ..................................................................................... 257
    Introduction ................................................................................................................... 257
  Address Book Server: File and Database Generation ........................................................ 258
    Address Book Server Data Flow .................................................................................... 258
    Address Book Server Process ....................................................................................... 259
  Address Book Server: Address Book File Download Service ............................................. 262
    File Generation .............................................................................................................. 262
    Organizational Unit and Address Book File Generation .................................................. 264

                                                                                                                                       7
      Client and Address Book Server Communication ........................................................... 264
      Address Book and Office Communicator........................................................................ 265
      Client Download Process ............................................................................................... 266
      Internet Explorer Dependencies ..................................................................................... 267
      File Store Recommendations and File Size Guidelines .................................................. 268
      Office Communicator Local Address Book Database Files ............................................. 268
      Address Book and Office Communicator Phone Edition ................................................. 268
      Address Book Web Query Service ................................................................................. 269
     Address Book Server: Address Book Web Query Service ................................................. 269
      Office Communicator Address Book Queries ................................................................. 271
      Queries on Display Name .............................................................................................. 273
      Queries on Phone Numbers........................................................................................... 274
      Sorting Query Results.................................................................................................... 275
      Predictive Text Queries ................................................................................................. 275
      Address Book Web Query Database.............................................................................. 275
      Address Book Web Query Database Language Support ................................................ 276
      Address Book Web Query Server Performance ............................................................. 276
     Address Book Server: Advanced Address Book Features ................................................. 277

Management of Office Communications Server 2007 R2 ......................................................... 282
 Administrative Tools Overview ............................................................................................. 283
   Administrative Tools.......................................................................................................... 283
   Permissions ...................................................................................................................... 287
 Installation and Use of Administrative Tools ......................................................................... 287
   Version Restrictions .......................................................................................................... 288
   Remote Administration Requirements ............................................................................... 288
   Installing Administrative Tools ........................................................................................... 288
 Troubleshooting for Office Communications Server 2007 R2 ................................................ 290
 Load Balancers for Office Communications Server 2007 R2 ................................................. 291
   Prerequisites for a Load Balancer Connecting to a Pool .................................................... 291
   Load Balancer Requirements ............................................................................................ 291
   Supported Load Balancer Configurations .......................................................................... 293
 Media Ports.......................................................................................................................... 294
   Mediation Server for Office Communications Server 2007 R2 ........................................... 294
     Media Gateway ............................................................................................................. 294
   Media Port Range for Office Communications Server 2007 R2.......................................... 295
     Minimum Number of Ports ............................................................................................. 295
     Server Port Allocation .................................................................................................... 302
 Voice Quality of Service (QoS) ............................................................................................. 303
   QoS with Office Communications Server 2007 R2............................................................. 303
   Enabling DSCP Marking ................................................... Error! Bookmark not defined.304
     Enabling QoS ................................................................ Error! Bookmark not defined.305
     Installing the QoS Packet Scheduler on Computers ....... Error! Bookmark not defined.308
     Verifying Group Policy Settings on Computers ............... Error! Bookmark not defined.308
 WMI Settings for Office Communications Server 2007 R2 .................................................... 304
 Client Registry Keys/GPO for Office Communications Server 2007 R2 ................................. 310


                                                                                                                                        8
In-Band Provisioning over SIP .............................................................................................. 310
    Why Use In-Band Provisioning?..................................................................................... 312
    Office Communicator 2007 R2 Group Policy Precedence............................................... 312
    Policy transport .............................................................................................................. 313
    Provisioning Groups ...................................................................................................... 317




                                                                                                                                     9
Technical Reference for Office
Communications Server 2007 R2
This document provides detailed technical reference information for administrators who are
deploying, have deployed, or are administering Microsoft Office Communications Server 2007
R2. This information is not necessary for day-to-day management of your Office Communications
Server deployment, but it can be useful if you are troubleshooting an issue, or if you are
implementing a solution or developing an application that requires more technical detail than the
basic documentation provides.
The information in this document supplements and should be used in conjunction with the rest of
the Office Communications Server 2007 R2 documentation set. Additional resources for technical
questions that are not covered here are as follows:
   The Technical Overview in the Getting Started documentation.
   The Microsoft TechNet portal for Office Communications Server at
     http://go.microsoft.com/fwlink/?LinkID=144770, which includes technical forums where you
     can ask specific questions.
If you have specific questions, comments, or suggestions for this Technical Reference, please
contact us at ocsdoc@microsoft.com. We are always glad to hear from you.
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:
   Topology and Component Architecture
   Pool Components for Office Communications Server 2007 R2
   Communication Protocols for Office Communication Server 2007 R2



                                                                                                   11
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.
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.


                                                                                                  12
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.


Pool Components for Office Communications
Server 2007 R2
In This Section
This section includes the following topics:
   Overview of Pool Components

                                                                                                  13
   Common Infrastructure Components
   Conferencing Components
   Voice Components


Overview of Pool Components
Office Communications Server supports the following three scenarios or workloads: instant
messaging (IM) and presence, conferencing (including Web conferencing, desktop sharing,
audio/video conferencing), and Enterprise Voice, which encompasses telephony. This section
describes all of the architectural components of an Office Communications Server 2007 R2
Standard Edition server or Enterprise pool. Collectively, these components support all three
workloads.
This section focuses on the services that run on the core Office Communications Server roles,
the components within those services, and relationships between them. This section does not
cover network architecture or deployment architecture, which complement component
architecture. For details about those aspects of architecture, see the Planning And Architecture
documentation.
While this section describes components in the context of an Enterprise pool, it also applies to
most aspects of a Standard Edition server. All server components (that is, services, database,
and so on) described in this section run together on a single instance of a Standard Edition
server. This is a typical configuration for simple or relatively small deployments (that is, up to a
few thousand users) where high availability is not a requirement.
Conceptually, a pool consists of one or more Front End Servers and one or more databases on
the Back-End Database Server with a single SQL Server. In a pool, all persistent states are
stored in the database on the Back-End Database Server, so that when a Front End Server
component fails, failover can be quick. Figure 1 shows a sample Enterprise pool.




                                                                                                       14
Figure 1. Sample Enterprise pool




Figure 1 illustrates the components of Front End Servers and the Back-End Database Server.
There is a hardware load balancer for the Front End Servers, which are required for an Enterprise
pool that has more than one Enterprise Edition server. (If your pool consists of only one Front
End Server, which is connected to a separate Back-End Database Server running SQL Server, a
load balancer is not required.) All Front End Servers in a consolidated configuration pool are
homogeneous and identical to each other. Therefore, all relevant Office Communications Server
services and applications are installed on all Front End Servers in this type of a pool.
On each Office Communications Server 2007 R2 Front End Server, the main components can be
classified as follows:
   Common infrastructure components. These components are required for the operation of
     any Office Communications Server workload, and provide a foundation for conferencing and
     voice components. The common infrastructure components include:
        RTCSrv. This is the main Office Communications Server service that runs the Office
          Communications Server Session Initiation Protocol (SIP) stack, performs presence


                                                                                               15
          functions, performs directory replication functions and interfaces with the database, hosts
          application interfaces, and has modules to capture archiving and call detail recording
          (CDR) data.
        Back-end database. This is a SQL persistent store with information on user identities
          and capabilities that are replicated from Active Directory, user contact lists, and dynamic
          presence and conferencing data.
        RTCHost. This process hosts several Office Communications Server applications for
          presence, conferencing, and Enterprise Voice that are required for core functioning of
          these scenarios.
        OCS Application interfaces. These interfaces enable the applications on RTCHost (as
          well as third-party applications built on the same API) to interface with the main server
          process RTCSrv (for example, to inspect the SIP stream).
        Web Components infrastructure. This infrastructure, which is built on Microsoft
          Internet Information Server (IIS), hosts various HTTP components required for presence,
          conferencing, and Enterprise Voice functions.
        UCAS infrastructure. The Unified Communications Application Services (UCAS)
          infrastructure enables Office Communications Server to host robust, scalable, middle-tier
          server endpoint applications. Several UCAS applications for Enterprise Voice are hosted
          by this infrastructure.
   Conferencing components. These components include various conferencing-specific
     components hosted by the common infrastructure discussed previously (for example, an
     RTCHost application, several web components), as well as a set of conferencing servers
     which perform mixing functions for IM conferencing, Web conferencing, desktop sharing
     conferencing, and audio/video conferencing.
   Voice components. These are the additional Office Communications Server components
     required for enterprise telephony functions. These components include RTCHost
     applications for inbound telephony routing, outbound telephony routing, and phone number
     normalization, as well as UCAS applications for dial-in conferencing, response groups (that
     is, similar to Automatic Call Distribution for Voice), and Outside Voice Control (which extends
     enterprise telephony functionality to cellular phones).
Each of these classes of components is described in the topics that follow.


Common Infrastructure Components
The common infrastructure components are required for the operation of any Office
Communications Server workload, and provide a foundation for conferencing and voice
components. The common infrastructure components include RTCSrv, Office Communications
Server application interfaces, RTCHost, the back-end database, presence components, Web
components, archiving and monitoring components, and Unified Communications Application
Services (UCAS) infrastructure.
In This Section
This section contains the following topics:

                                                                                                    16
   RTCSrv
   Office Communications Server Application Programming Interface (API)
   RTCHost
   Back-End Database
   Presence Components
   Web Components Services for Office Communications Server 2007 R2
   Archiving and Monitoring for Office Communications Server 2007 R2
   Unified Communications Application Services (UCAS) Infrastructure


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




                                                                                               17
Figure 1. The RTCSrv.exe process




SIP Proxy
The SIP Proxy is the core protocol platform on which all other Office Communications Server
2007 R2 services are built. The SIP Proxy provides the basic structure for networking and
security, and performs connection management, message header parsing, routing,
authentication, and state management.
The SIP Proxy, also known as the SIP stack, forms the basis for all other Office Communications
Server 2007 R2 services. Signaling connections, authentication, message routing, and state
management all rely on the SIP Proxy.

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




                                                                                              18
Table 1. User Services

Component                                       Function

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

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

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




                                                                                             19
Office Communications Server Application Programming Interface (API)
The Office Communications Server 2007 R2 application programming interface (API) is built on
the Session Initiation Protocol (SIP) proxy platform and implemented using the following:
   Server API module (Apiem.dll). An extension that provides the basic scripting capability for
     creating custom message filters and routing applications. The scripts can either run in
     process with Office Communications Server 2007 R2 (Rtcsrv.exe) or can be incorporated in a
     managed server application that is running in a separate process.
   Managed server API platform (ServerAgent.dll). A platform that you use to implement both
     Microsoft and non-Microsoft managed server applications. Managed server applications that
     are written by using the managed server API run as separate processes.
   Local shared-memory IPC (Queue.dll). The interface between the server API module and
     managed applications.
   Internal COM API. An API used to communicate with the SIP proxy platform.
The following figure shows how the API architecture is implemented for Front End Servers.

Figure 1. API architecture for Front End Servers




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



                                                                                               20
   Office Communications Server 2007 R2 applications implemented by using RTCHost.exe.
     This includes the following filtering applications: Voice over Internet Protocol (VoIP)
     applications, conferencing server Factory, Real-time Communications (RTC) Aggregate
     application, and other applications (that is, non-Microsoft applications). For details about the
     managed server applications implemented with RTCHost.exe, see RTCHost.
   Non-Microsoft applications developed in-house, by vendors, or by using other resources.
The managed server API for implementing these applications functions as follows:
   Exposed through the Microsoft.Rtc.Sip namespace.
   Uses the server API to perform specific SIP message processing tasks.
   Implemented by using the managed server application platform (that is, ServerAgent.dll
     assembly). Each managed application loads the ServerAgent.dll and executes in its own
     process space. Managed applications are isolated from each other in a way that prevents a
     faulty application from affecting other applications.
Following are the two major components of the server API module (Apiem.dll) that support
implementation of managed server applications:
   Application manifest. A script that is written by using Microsoft SIP Processing Language
     (MSPL) and describes an application to the server. When a managed server application
     registers with the server using the ServerAgent class, it provides this script to the server.
     The application manifest serves the following purposes:
        Provides details about the application type and the state that the server needs to
          maintain for the application to run, so the server can optimize processing for the
          application.
        Contains a message filter script to communicate detailed information about which
          messages (that is, requests and responses) the application needs to see. To filter
          messages, the application manifest has a set of built-in actions that it can invoke. For any
          other actions required by a specific message (that is, those actions that cannot be
          handled by the built-in actions), the application manifest can invoke managed code in a
          separate application process by passing all or parts of the message to the code in the
          application process. Using the built-in actions helps you avoid cross-process calls for
          simple processing (for example, basic if, then, and else functions).
        Enables the application developer to specify moderate amount of logic to be executed by
          an interpreter inside the server API module. If the functionality of the interpreter is not
          sufficient, a cross-process call is made as a single call containing only the portions of the
          message that are appropriate to the message filtering used.
        Uses an application Uniform Resource Identifier (URI) to uniquely identify the application
          to the server. The application URI is expected to be an HTTP URL, but no validation is
          performed.
   Microsoft.Rtc.Sip class library. Contains the following classes:
        SIP message and transaction processing classes.
        ServerAgent class. This class implements most of the logic needed to manage sessions
          with the server. It is the entry point for the managed server API. Each application initiates

                                                                                                     21
         an instance of ServerAgent.dll and supplies an application manifest instance to it. The
         ServerAgent.dll assembly manages the session with the server, including compiling the
         application manifest and registering with the server. If the registration succeeds, the
         ServerAgent class sets up the environment necessary to receive and process SIP
         messages from the server. The ServerAgent.dll assembly invokes application-specific
         event handlers for specific events (for example, message events and transaction events).
         For each instance of the application, a single ServerAgent.dll object manages the
         applications session with the server. To exit, the application releases the ServerAgent.dll
         object, which causes the session with the server to end.
         You can use the Office Communications Server 2007 R2 Software Development Kit
         (SDK) to develop applications by using the Microsoft.Rtc.Sip class library. You can
         download the SDK at http://go.microsoft.com/fwlink/?LinkId=144480. For details about
         using the SDK, see ―Communications Server 2007 R2 Server SDK Documentation‖ at
         http://go.microsoft.com/fwlink/?LinkId=144482.


RTCHost
RTCHost.exe runs on each Front End server and can be accessed through the Managed Server
application programming interface (API) library. The following applications run inside the
RTCHost.exe process:
   The Client Version Filter enables the server to deny client connections based on a client’s
     version number. The Client Version Filter compares a client’s version number with the
     version settings specified by the administrator by reading the clients Session Initiation
     Protocol (SIP) User-Agent header. You can configure the Client Version Filter by using the
     Office Communications Server Management Microsoft Management Console (MMC).snap-in.
   The RTC Aggregate application manages the multiple points of presence (MPOP) feature
     for Office Communications Server 2007 R2 by aggregating the presence information
     published by multiple client endpoints into one presence status that best represents the
     user's current availability. For details about the RTC Aggregate application, see Presence
     Components.
   The Intelligent IM Filter helps prevent unsolicited marketing that targets instant messaging
     (IM) programs. The Intelligent IM Filter uses settings configured by the administrator to filter
     incoming instant messages received by the server from outside the organization’s firewall.
     You can configure the Intelligent IM Filter by using the Office Communications Server
     Management snap-in.
   The Conferencing Server Factory is required for conferencing. For details, see
     Conferencing Components.
   The User Pin Service authorizes dial-in conferencing participants that enter in a conference
     personal identification number (PIN) when joining a conference by using the public switched
     telephone network (PSTN).
   The VoIP applications that run inside RTCHost.exe are the Inbound Routing application,
     Translation Service, and Outbound Routing application. Together, these applications enable
     the server to route VoIP calls. For details, see Voice Components.

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


Back-End Database
In Office Communications Server 2007 R2, the back-end database stores configuration
information, contact lists and presence information for users, and any state information required
to resume a conference. Presence data and conferencing data are stored in different tables of the
same physical database.
In a Standard Edition configuration, all server components are installed on the same computer,
including the back-end database. The back-end database on a Standard Edition server uses
Microsoft SQL Server 2005 Express Edition with Service Pack 2 (SP2) or later.
In an Enterprise Edition configuration, the back-end database must be configured as a separate
dedicated computer. In an Enterprise pool, all servers in the pool share a central Microsoft SQL
Server database. This database runs on Microsoft SQL Server 2008 (32-bit or 64-bit) or SQL
Server 2005 with Service Pack 2 (SP2) or later (32-bit or 64-bit), and you can cluster it in an
active-passive configuration for higher availability.


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




                                                                                                 23
Figure 1. Presence components




Web Components Services for Office Communications Server 2007 R2
The Web Components Services run on Microsoft Internet Information Server (IIS), and enable
Office Communications Server clients to perform the following functions:
   Download Address Book Server files to provide Office Communicator with global address list
     (GAL) information.
   Expand membership in distribution groups and other data that is used by the Web
     Conferencing Server.
   Access meeting presentations and other content from Web conferences.
   Host software packages for device updates.
   Host administration for Response Group Service.


Archiving and Monitoring for Office Communications Server 2007 R2
Office Communications Server 2007 R2 includes Archiving and Monitoring functionality as
follows:
   Archiving. Designed for enterprise compliance needs, enables the capture and storage of
     instant messaging (IM) content.
   Monitoring. Designed for enterprise operational needs and enables the following:
        The capture of call detail recordings (CDRs) that include IM, conferencing, and voice and
          video calls. CDRs include usage information related to voice calls, audio/video (A/V)
          conversations, application sharing, remote assistance, and Web conferences.

                                                                                                 24
       The capture and viewing of detailed Quality of Experience (QoE) metrics to monitor voice
         and video quality. QoE data includes statistics about voice and video quality, both for
         individual calls and aggregate reports.
The following figure shows the archiving and monitoring architecture in Office Communications
Server 2007 R2.

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




The Front-End server hosts an archiving and CDR agent, which is part of the RTCSrv process, to
capture archiving and CDR data which is transferred over Message Queuing (also known as
MSMQ) to the Archiving Server and Monitoring Server respectively. The Archiving Server and
Monitoring Server are separate Office Communications Server roles.
Similarly, the Front End contains a QoE agent, which is part of the RTCQMS process, to capture
QoE data. The QoE data is transferred over Message Queuing to the Monitoring Server.
In Office Communications Server 2007 R2, the CDR function moves to the Monitoring Server
from the Archiving Server with which it was a co-located in Office Communications Server 2007.
CDR data accumulation and reporting requirements have characteristics more in common with
QoE data than Archiving data, which drove the evolution in architecture.


Unified Communications Application Services (UCAS) Infrastructure
Unified Communications Application Server (UCAS) is a platform introduced in Office
Communications Server 2007 R2 that makes it easier to build server-side applications that run on
Standard Edition servers or Enterprise pool servers. Each Front-End Server in a pool runs an
instance of an Application Server host. Applications developed by using the Unified
Communication Managed APIs (UCMA) 2.0 can use the UCAS platform as a common framework
that leverages Office Communications Server capabilities such as deployment, trust,
administration, load balancing and routing, monitoring, and so on. UCAS is designed to host
server applications that act as Session Initiation Protocol (SIP) endpoints.
Similar to Office Communications Server conferencing servers, UCAS is another server role.
When you deploy UCAS on an Enterprise Edition server consolidated pool topology, each UCAS
application runs on all servers in the pool and together they share the overall workload of the
application. UCAS consists of a single Windows service, called Application Host


                                                                                                25
(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.




                                                                                              26
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



                                                                                               27
privileges, sending conference state notifications to clients and providing a conduit for control
commands to flow between clients and conferencing servers.
When a new media type must be activated for a conference, the Focus also instantiates the
conference on the appropriate conferencing server, communicates with the conferencing server
about adding a new user, obtains the authorization credentials so the client can connect to that
conference, and then sends the media information to the client. The same sequence is repeated
for all clients who want to add this media. When a new media type is added to the conference,
the sequence is repeated with the new conferencing server for that media type. By centralizing
the security enforcement and roster management, the Focus relieves each of the conferencing
servers of this duty.

Focus Factory
The Focus Factory is a SIP entity that creates, deletes, and modifies meetings in the
conferencing database. The Focus Factory manipulates meetings in the conferencing database
according to Centralized Conferencing Control Protocol (C3P) commands that are issued by
clients.

Conferencing Server Factory
The Conferencing Server Factory is responsible for provisioning a conference for a particular
media type on a conferencing server. The Conferencing Server Factory can also take into
account the current load on the conferencing servers before assigning a conferencing server to a
conference. There is one Conferencing Server Factory instance on each Front End Server, which
handles all media types.

Conferencing Database
A Focus holds important information for the entire conference, including all conference
participants. If a Focus instance fails, it must be possible to restart the conference. To support
this, any state information that is needed to resume the conference persists in a conferencing
database, which runs on the SQL Server back-end database. In Office Communications Server
2007 R2, presence and registrar information, and conferencing information are stored in different
tables of the same physical database.
The important metadata associated with a conference in the conferencing database includes the
following:
   Conference ID.
   PSTN Meeting ID.
   Expiration date and time of the conference.
   List of meeting participant roles and the privileges associated with those roles.
   Conference key for participants without an identity in Active Directory.
   Supported media types.
   Authorization types (for example, closed, open, and anonymous).
The conferencing database contains the metadata for a conference but does not contain calendar
information. Conference calendar information (for example, meeting start and end times), the

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


Conferencing Servers for Office Communications Server 2007 R2
A conferencing server is responsible for mixing and managing one or more media types. The
following types of conferencing servers are included in Office Communications Server 2007 R2:
   Web Conferencing Server for data collaboration.
   A/V Conferencing Server for audio and video.
   Instant messaging (IM) Conferencing Server for multiparty IM.
   Telephony Conferencing Server for interfacing with audio conferencing providers.
   Application Sharing Server for multiparty or Communicator Web Access-based application
     sharing.
The architecture allows the addition of other conferencing servers as needed in the future. The IM
Conferencing Server, Application Sharing Server, and Telephony Conferencing Server can only
be installed as part of a Front End Server, but you can install A/V Conferencing Servers and Web
Conferencing Servers independently of other components.
Web Conferencing Servers, A/V Conferencing Servers, and IM Conferencing Servers each have
two logical components: a media controller and a media processor.

MC (Media Controller)
The media controller on a conferencing server is responsible for managing the control commands
between a Focus and a conferencing server.

MP (Media Processor)
The media processor is responsible for media management (for example, mixing, relaying, and
transcoding). In a Web Conferencing Server, the media processor is a software component that is
responsible for managing data collaboration for Office Communications Server. In an A/V
Conferencing Server, the media processor mixes audio streams, switches video streams, and
converts the media for clients who are on slow links. Of all the conferencing components, the
media processor can be the most CPU and network intensive component. In our architecture, a


                                                                                                 29
media controller and media processor are collocated on the same computer to simplify
deployment.

A/V Conferencing Server
The A/V Conferencing Server enables multiparty audio and video mixing and relaying capabilities.
It is built on industry standard real-time transport protocol (RTP) and real-time transport control
protocol (RTCP).
The A/V Conferencing Server also incorporates elements of the Internet Engineering Task Force
(IETF) drafts for Interactive Connectivity Establishment (ICE) as a means to enable the exchange
of media between two or more clients that are using Network Address Translators (NATs). ICE is
an extension to Session Description Protocol (SDP) that enables media streams to traverse NATs
by including in the SDP multiple IP address and port combinations for a particular transport
protocol, known as candidate transport addresses, that the client can use to communicate with
other clients. In an Office Communications Server environment, a client uses Session Traversal
Utilities for NAT (STUN) and Traversal Using Relay NAT (TURN) protocols to obtain its candidate
transport addresses from the Office Communications Server A/V Conferencing Edge Server.
During negotiation, clients on either end exchange SDPs and then test candidate addresses for
peer-to-peer connectivity. After the connectivity checks, clients renegotiate by including only the
candidate transport address that succeeded in the SDP for a SIP re-INVITE request and
response.
For details about IETF drafts for ICE, see ―Interactive Connectivity Establishment (ICE): A
Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols‖ at
http://go.microsoft.com/fwlink/?LinkId=144408.

Web Conferencing Server
The Web Conferencing Server adds data collaboration functionality to Office Communications
Server. The Web Conferencing Server is built on the same Persistent Shared Object Model
(PSOM) technology that is used by the Live Meeting service. Both signaling and media are sent
to and from a Web Conferencing Server using the PSOM protocol. The Web Conferencing Server
supports Live Meeting features, such as Microsoft Office PowerPoint presentations, document
presentations, chat, voting, white boarding, and application sharing.
The Web Conferencing Server uses shared folders on a file system to store conference state and
conference contents. Universal Naming Convention (UNC) paths are configured on the Web
Conferencing Server to refer to the shared folders, which are created by an administrator during
Office Communications Server deployment. These folders for conference metadata and
conference content can be located on the same computer as the Web Conferencing Server or,
preferably, on a dedicated computer.
For information about the way that a Web Conferencing Server works, see Web Conferencing
Server for Office Communications Server 2007 R2.




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

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

Application Sharing Server
The Application Sharing Server is a new conferencing server role introduced in Office
Communications Server 2007 R2, and is used specifically for multiparty desktop sharing from the
Office Communicator client and desktop sharing from the Communicator Web Access client. The
Application Sharing Server uses the Remote Desktop Protocol (RDP), with RTP as the transport
for remote access scenarios.
Although the Web Conferencing Server also supports Application Sharing (that is, by using the
PSOM protocol and the Live Meeting client), the Application Sharing Server provides desktop
sharing functionality that users can access directly in Office Communicator and Communicator
Web Access, instead of requiring users to start the Live Meeting client separately.


Voice Components
Office Communications Server 2007 R2 provides a rich set of Enterprise Voice features suitable
for global voice (that is, telephony) deployments. This section describes the voice components
and the relationship between these components. It also describes the process boundaries for the
various components.
Other topics in the Technical Reference describe common infrastructure and conferencing
infrastructure that enable certain key functions for Enterprise Voice. For example, Session
Initiation Protocol (SIP) registration, performed by RTCSrv.exe and the User Services module,
enables the fundamental call switching aspect of Enterprise Voice. The key additional
components specific to enabling Enterprise Voice are either hosted on RTCHost.exe (that is,
Inbound Routing, Translation Service, Outbound Routing, Exchange UM) or hosted as Unified
Communications Application Services (UCAS) applications (that is, Conferencing Attendant,
Conferencing Announcement Service, Response Group Service, and Outside Voice Control).
In This Section
This section contains the following topics:
   RTCHost Voice Components
   Unified Communications Application Services (UCAS) Voice Applications


RTCHost Voice Components
The core voice components of Office Communications Server 2007 R2 are the Inbound Routing
application, the Translation Service, and the Outbound Routing application that run inside the
                                                                                                31
RTCHost.exe process on each Front End Server. The Inbound Routing application determines
how incoming calls to the server should be routed, based on settings configured on the client.
The Translation Service uses administrator-specified phone number normalization rules to
translate a dialed number into an E.164 format that can be consumed by other components in the
system, such as the private branch exchange (PBX) or public switched telephone network
(PSTN) gateway. The Outbound Routing application uses call authorization rules to route each
call to the appropriate media gateway.
The following figure shows the architecture of the core components: Translation Service, Inbound
Routing, and Outbound Routing.

Figure 1. Core component architecture




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



                                                                                                   32
Translation Service
The Translation Service applies administrator-specified phone number normalization rules to
translate a dialed number into an E.164 format that can be more easily consumed by a PBX or
PSTN gateway. Enterprise Voice in Office Communications Server 2007 R2 employs the
Translation Service to normalize phone numbers into a single format. Normalized phone numbers
assist the server with reverse number lookup, outbound call routing, and call authorization rules.
Reverse number lookup is a process whereby a user's phone number is mapped to the
appropriate SIP Uniform Resource Identifier (URI). By performing reverse number lookup, the
server can route calls to all endpoints associated with a particular user’s SIP URI. Reverse
number lookup also enables advanced call handling features, such as call forwarding.
After a dialed number is normalized by the Translation Service, the Outbound Routing application
can apply call authorization rules to route the call.

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


Unified Communications Application Services (UCAS) Voice Applications
Unified Communications Application Services (UCAS) Enterprise Voice applications were added
in the Office Communications Server 2007 R2 release to provide key Enterprise Voice features,
such as dial-in conferencing (Conferencing Attendant and Conferencing Announcement Service),
basic Automatic Call Distribution (that is, Response Group Service), and Office Communications
Server server-side functions to extend Enterprise Voice to cellular telephones (that is, Outside
Voice Control).
Dial-in conferencing allows callers to use standard public switched telephone network (PSTN)
telephones to dial in to audio conferences hosted on Office Communications Server. (In Office
Communications Server 2007, only Office Communications Server enterprise-enabled users who
connect over Internet Protocol (IP) audio could join audio conferences hosted on Office
Communications Server.) Dial-in conferencing is enabled by the Conferencing Attendant and
Conferencing Announcement Service UCAS applications. For details, see Dial-In Conferencing
Scenario.

Conferencing Attendant
The Conferencing Attendant is an auto-attendant service (that is, a bot) that authenticates and
joins dial-in participants to audio conferences. Office Communications Server 2007 R2
Conferencing Attendant supports 14 different languages. The Conferencing Attendant prompts
the caller for conference IDs and passcode (that is, if the caller is calling in as an anonymous
participant) or extension number and personal identification number (PIN) (that is, if the caller is
joining as a Enterprise User), plays on-hold music when enterprise users have not yet joined the

                                                                                                   33
meeting, requests authentication from a front-end service, and joins authenticated callers to the
Focus and A/V Conferencing Server for the requested conference ID.
The Conferencing Attendant Service on each Front End Server listens on Transmission Control
Protocol (TCP) port 5072 for incoming calls. These requests normally come from a Mediation
Server and are proxied by the Mediation Server’s next hop pool.

Conferencing Announcement Service
The Conference Announcement Service is another trusted bot that participates in all dial-in
enabled audio conferences. It monitors the conference roster and plays entry and exit tones to all
dial-in attendees when other dial-in attendees join or leave, and also tells attendees when their
microphone has been muted or unmuted in the language that they chose when they connected to
the Conferencing Attendant. No configuration is required for this service.
The Conference Announcement Service on each Front End Server listens on TCP port 5073 for
requests from a Focus that is running on one of the Front End Servers in the pool.

Response Group Service
The Office Communications Server 2007 R2 Response Group Service enables administrators to
create and configure one or more response groups for the purpose of routing and queuing
incoming phone calls to one or more designated agents. These response groups can be
deployed in departmental or workgroup environments and in entirely new telephony installations.
Typical usage scenarios include an internal helpdesk, a customer service desk, or a general
external call handler. Response Group Service can increase response group usage and reduce
the associated overhead by pushing the tasks of response group maintenance down to the users
who directly benefit from them.
The Response Group Service functionality is enabled by the Response Group Service
application, which is a UCAS application that implements standard response group call-routing
algorithms (that is, including serial, longest-idle, parallel, and round robin), interactive voice
response (IVR), call queuing, on-hold music, presence-based routing, and so on.

Outside Voice Control
The Office Communications Server 2007 R2 Outside Voice Control feature enables users to use
their enterprise telephone number for inbound and outbound calls on their personal mobile
phone.
To use this feature, the user must have Office Communicator Mobile (2007 R2 release) installed
on a Windows Mobile phone and must be able to use data packet communication between the
mobile phone and the mobile phone provider (for example, General Packet Radio Source
(GPRS)) that allows SIP messages to be transmitted. The user must also be enabled for
Enterprise Voice.
For inbound calls, Office Communications Server 2007 R2 sends a SIP Invite to all registered SIP
endpoints of the user including the user’s Communicator Mobile (2007 R2 release) client running
on the phone, over the data channel. Office Communications Server 2007 R2 subsequently
initiates an outbound PSTN/mobile network call through Office Communications Server 2007 R2
Mediation Server to the user’s mobile phone number.

                                                                                                     34
For an outbound call from a mobile phone, the user has the option to enter the phone number to
be dialed into Communicator Mobile (2007 R2 release) or to initiate a call to a SIP contact using
Communicator Mobile (2007 R2 release). The user receives an incoming mobile phone call from
Office Communications Server using the mobile phone provider’s cellular network. After the user
accepts the call from Office Communications Server, Office Communications Server sets up a
second call leg to the designated called party and then join the two connections. The called party
receives a call from the user’s company using the user’s office phone number despite the fact
that the user is actually on a mobile phone.
The Outside Voice Control application on each Front End Server listens on TCP port 5074.


Communication Protocols for Office
Communication Server 2007 R2
In This Section
This section includes the following topics:
   Protocols Overview
   Conferencing Protocols


Protocols Overview
While Session Initiation Protocol (SIP) is still the primary control protocol used by Office
Communications Server 2007 R2, Web Conferencing Server, A/V Conferencing Server, and their
subcomponents, they also employ other protocols to set up and modify conferences and to set up
and break down media streams between different elements in the Office Communications
Server2007 R2 network. The following protocols are employed by Office Communications Server
2007 R2:
   Session Initiation Protocol (SIP). The industry standard protocol described in IETF RFC
     3261 that defines a standard for session setup, termination, and media negotiation between
     two parties. It is widely used for Voice over IP (VoIP) call signaling.
   Asynchronous JavaScript And XML (AJAX). Used in Communicator Web Access to
     ensure efficient client-server interaction, while keeping the Web user interface (UI)
     responsive.
   Centralized Conferencing Control Protocol (C3P). Used to encode Conferencing Control
     commands in Office Communications Server.
   HTTPS. The set of rules for exchanging files (that is, text, graphic images, sound, video, and
     other multimedia files) on the World Wide Web. Relative to the Transmission Control Protocol
     (TCP)/Internet Protocol (IP) suite of protocols, the basis for information exchange on the
     Internet, HTTP is an application-layer protocol. HTTPS is the HTTP protocol over Secure
     Sockets Layer (SSL)/Transport Layer Security (TLS).
   Interactive Connectivity Establishment (ICE). Used to provide media connectivity across
     firewalls and Network Address Translation (NAT) devices, thereby enabling audio/video
     anywhere.
                                                                                                  35
   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.
   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            SIP, C3P      X                SIP, real-time
                               Initiation                                        transport
                               Protocol (SIP),                                   protocol (RTP),
                               Centralized                                       Persistent
                               Conferencing                                      Shared Object
                               Control Protocol                                  Model (PSOM)
                               (C3P)                                             and so on

Focus              SIP, C3P    X                  X            HTTPS, C3P        HTTPS, C3P


                                                                                                36
                  Client      Focus              Focus       Conferencing      Conferencing
                                                 Factory     Server Factory    server

Focus Factory     SIP, C3P    X                  X           X                 X

Conferencing      X           HTTPS, C3P         X           X                 HTTPS, C3P
Server Factory

Conferencing      SIP, RTP,   HTTPS, C3P         X           HTTPS, C3P        X
Server            PSOM
                  and so on



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




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




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




                                                                                                  38
Centralized Conferencing Control Protocol (C3P)
C3P is a conference manipulation protocol used by the Office Communications Server 2007
conferencing servers. C3P is used to modify the conference state. The channels over which C3P
can be used in an Office Communications Server 2007 deployment are shown in Figure 1.
C3P has request/pending response/final response semantics similar to SIP. The following table
lists C3P commands.

Table 2. C3P Commands

Conference Level

addConference

deleteConference

modifyConference

getConference

getMCU

modifyConferenceLock

modifyUsersMediaFilters



User Level

addUser

deleteUser

modifyUser

modifyUserRoles

setUserAccess



Scheduling

getAvailableMcuTypes

getConferencingCapabilities

getEncryptionKey

getConferences




                                                                                                39
Endpoint Level

modifyEndpointRole



Endpoint Media Level

addEndpointMedia

deleteEndpointMedia

modifyEndpointMedia



High Availability (HA)/Load Balancing

ping

getConference



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


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


SIP/SDP
Session Initiation Protocol (SIP) is the industry standard protocol described in IETF RFC 3261
that defines a standard way for session setup, termination, and media negotiation between two
parties. It is widely used for Voice over IP (VoIP) call signaling.
Session Description Protocol (SDP) is the industry standard protocol described in IETF RFC 4566
that defines a standard way to convey media details, transport addresses, and other session
description metadata to the participants when initiating multimedia teleconferences, Voice over IP
calls, streaming video, or other sessions.


Signaling and Control Protocol
This section describes the protocols supported by the various server components and the
functionality supported by each of those protocols. Clients and servers use signaling and control
protocols for session setup and conference management. For each media in a conference or an
audio/video call, different media protocols are used.


                                                                                                 40
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 real-
time transport control protocol (SRTCP) to secure and encrypt both media types. RTP/RTCP can
use either TCP or User Datagram Protocol (UDP) as the underlying transport for audio/video, but
will use only TCP for desktop sharing.



Scenarios for Office Communications Server
2007 R2
This part of the Technical Reference provides details about architecture and call flows that enable
specific end-user scenarios.
In This Section
This section includes the following topics:
   Conferencing Scenario for Office Communications Server 2007 R2
   Dial-In Conferencing Scenario
   Desktop Sharing Scenario
   Communicator Web Access Scenario
   Outside Voice Control Scenario
   Group Chat Feature Scenario


Conferencing Scenario for Office
Communications Server 2007 R2
This section describes how conferencing works. It contains a detailed discussion about how
conferencing components interact and includes call flows for various conferencing scenarios.
Together with the Focus and the Focus Factory, the Web Conferencing Server, A/V Conferencing
Server, and Application Sharing Service (ASMCU) provide conferencing functionality.

                                                                                                41
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 real-
time media stops streaming in the meeting. Then, the meeting state and meeting content are
purged at the time the conference expires, as defined when the meeting was scheduled. If a
meeting is a recurring meeting, the meeting can be reactivated after the previous instance has
been deactivated, if it has not already expired. Any content that was uploaded previously is
available when the recurrent meeting starts again.


Conferencing Data Flow
This figure shows the data flow between participating components when an intranet client creates
and joins a conference.




                                                                                                  42
This is a description of the data flow between conferencing components when an intranet client
creates and joins a conference:
   Step 1. The scheduling client communicates with the Focus Factory using Domain Name
     System (DNS) lookup or the manually configured server address. The scheduling client
     sends information required for creating a meeting, such as the conference ID, participant list,
     user role information, and expiration date in a SERVICE request.
   Step 2. The Focus Factory creates a conference record in the conferencing database on the
     Back-End Database Server. The Focus Factory also creates and returns a SIP URI that
     represents the conference to the client.
   Step 3. The conferencing client connects to the Focus and establishes two dialogs with it, an
     INVITE dialog to join a conference and carry additional command traffic from the client to the
     Focus and a SUBSCRIBE/NOTIFY dialog to get conference state change notifications.
   Step 4. The Focus connects to the Back-End Database Server to retrieve the conference
     record and to query the conferencing database to verify that the client joining the meeting is
     valid. Policy checks are also performed at this time.
   Step 5. The Focus requests information from the Conferencing Server Factory about how to
     contact a conferencing server.
   Step 6. The Conferencing Server Factory finds the conferencing server of the type requested
     by the Focus and then tries to provision a conference on that conferencing server, in order to
     allocate resources for the conference. If provisioning succeeds, the Conferencing Server
     Factory returns to the Focus an HTTP URL that allows the Focus to establish a control link
     with the conferencing server.
   Step 7. The Focus communicates with the conferencing server to issue commands that begin
     or end the conference, change the participant list, or otherwise change the conference state.
   Step 8. The conferencing client communicates with the conferencing server. If the server is
     an A/V Conferencing Server, the signaling protocol is SIP and the media is transported over
     RTP/RTCP. If the server is a Web Conferencing Server, both signaling and media are sent
     using the PSOM protocol. If the server is an Application Sharing Server, the signaling
     protocol is SIP and the media is transported over RDP encapsulated within RTP.


                                                                                                      43
Conference Creation and Activation
The scheduling client communicates with the Focus Factory to create a new conference. To
create a conference, the Focus Factory on the server creates and configures a conference
record. The Focus Factory then sends the URI for the Focus instance to the client. The
conference URI includes the organizer of the conference and a unique conference identifier. The
syntax is as follows:
sip:<organizer>@<domain.com>;gruu;opaque=app:conf:focus:id: <unique ID>.
For instance:
sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:3ICYEOLHDKOE3ZP5K9QO56XN70D8X
CDW.
There is however a unique conference identifier that is especially reserved for reservationless
meetings. The unique id is 3814A82809A34ED0958CFDB60957BDF. This meeting never
expires. When a client creates a conference using the SIP SERVICE mechanism, the client first
makes a SERVICE request, which requests a summary of conferencing capabilities supported in
the server, and then passes all the information that it needs regarding the conference, media
types, privileges, and participants as part of a second SERVICE request to the Focus Factory.
The Focus Factory creates the conference record and then sends the connection information to
the client in the 200 OK response to the SERVICE request.
This figure shows the message flow between conferencing components when a client creates a
conference using the SIP SERVICE mechanism.




The following is a description of the message flow between conferencing components when a
client creates a conference using the SIP SERVICE mechanism:
Step 1. The client sends a SERVICE request to the Focus Factory with information requesting
conferencing capabilities. These capabilities include a list of media capabilities, PSTN support

                                                                                                   44
and important policy information a client should know before scheduling a conference. For
example:
SERVICE sip:Ted@contoso.com;gruu;opaque=app:conf:focusfactory
To: sip:Ted@contoso.com;gruu;opaque=app:conf:focusfactory
From: sip:client1@contoso.com;tag=f7588dc66124429ab736
Call-ID: 3412asdsss
CSeq: 1 SERVICE
Content-Type: application/cccp+xml
SIP headers...
<XML body>
Step 2. After the getConferencingCapabilities SERVICE request has been sent and the response
parsed by the client so that it can be aware of the capabilities available, the client sends a
SERVICE request to the Focus Factory to have the conference created.
Step 3. The Focus Factory parses the create conference information in the SERVICE request
and writes it to the conferencing database in the Database.
Step 2.2. After the Focus Factory writes to the conferencing database on the Back-End Database
Server, the Focus Factory sends a 200 OK response to the client with the conference information.
The following figure shows the message flow between conferencing components when a client
joins a conference.




The following is a description of the message flow between conferencing components when a
client joins a conference:
Step 1. The client sends an INVITE request to the Conference URI to join the conference. The
purpose of the INVITE dialog is two-fold. The INVITE dialog indicates that the client wishes to join
the conference. The INVITE dialog is also used by the client to send an INFO request in the
context of the dialog, in order to set up control of the conference, as follows:

                                                                                                  45
INVITE sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234
To: sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234
From: sip:joe@contoso.com;tag=f7588dc66124429ab736
Call-ID: adfsfasdfasdfds
CSeq: 1 INVITE
Content-Type: application/cccp+xml
SIP headers...
<addUser C3P request>
The C3P addUser request in the body of the INVITE can be used to specify specific client
attributes, such as its Display Name.
Step 2. The client will use the SUBSCRIBE/NOTIFY dialog for watching the conference state, as
follows:
SUBSCRIBE sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234
To: sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234
From: sip:joe@contoso.com;tag=f7588dc66124429ab736
Call-ID: adfsfasdfasdfds
CSeq: 1 SUBSCRIBE
Event: conference
Accept: application/conference-info+xml
Content-Length: 0SIP headers...
The Focus processes and accepts the subscription and notifies subscribers of any conference
state changes. The conference state includes the state maintained by the Focus itself, the
conference policy, and the media policy/information.
Step 2.1. The initial conference state document can be included in the 200 OK of the
SUBSCRIBE, if the client expresses support for this extension, as follows:
SIP/2.0 200 OK
To: sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234
From: sip:joe@contoso.com;tag=f7588dc66124429ab736
Call-ID: adfsfasdfasdfds
CSeq: 1 SUBSCRIBE
Event: conference
Accept: application/conference-info+xml
Content-Type: application/conference-info+xml
SIP headers...
<conference-state version="0" state="full"


                                                                                              46
entity="sip:confuri">
    <conference-info>
     <conf-uris>
        <entry>
          <uri>sip:Ted@contoso.com;gruu;opaque=app:conf:audio-
video:id:1234</uri>
          <display-text>audio-video</display-text>
          <purpose>audio-video</purpose>
        </entry>
        <entry>
          <uri>sip:Ted@contoso.com;gruu;opaque=app:conf:meeting:id:1234</
uri>
          <display-text>meeting</display-text>
          <purpose>meeting</purpose>
        </entry>
        <entry>
          <uri>sip:Ted@contoso.com;gruu;opaque=app:conf:chat:id:1234</uri
>
          <display-text>chat</display-text>
          <purpose>chat</purpose>
        </entry>
        <entry>
          <uri>sip:Ted@contoso.com;gruu;opaque=app:conf:phone-
conf:id:1234</uri>
          <display-text>phone-conf</display-text>
          <purpose> phone-conf</purpose>
        </entry>
     </conf-uris>
    </conference-info>
<....Other conf Info...>
</conference-state>
The following figure shows the message flow between conferencing components when the Focus
bootstraps the Web Conferencing Server.




                                                                                        47
The following is a description of the message flow between conferencing components when the
Focus bootstraps the conferencing server:
Step 1. The client joins the conference, as described previously.
Step 2. The MCU Factory is selected based on the MCU Type and Vendor configured at
scheduling time. The Focus then makes a getMcu call to the MCU Factory.
Step 2.1. If the MCU Factory finds a suitable MCU, then it responds to the Focus with a success
getMcu response.
Step 3. When the MCU Server URL has been obtained by the Focus, it then makes an
addConference call to the MCU. The MCU can choose to accept or reject the request. However,
when failing the call the MCU must place a reason element inside the addConference response
element that contains an indicator of why the request was failed. This reason is an enumeration
defined in the C3P schema. If the conference exists already, the MCU must respond with
conferenceExistsAlready.
   The Conf-Uris section lists the MCU Conference URI for this conference. The MCU needs to
     use this information to correlate incoming media-INVITE requests to the conference.
   The Service-Uris section contains two URIs – one is an HTTPS URL that gives the Focus
     Pool URL for use in sending C3P notifications. This URL is indicated by the ms-notification
     purpose parameter. The second URL is a SIP URL that specifies the outbound-proxy for use
     by the MCU when it sends a SIP request. This outbound-proxy is usually the Focus itself but
     it may be different. We use the purpose value of ms-sip-outbound-proxy to indicate this.
   Conference attributes (for example, organizer, user count, admission policy, and
     expiration time) are communicated in the addConference call.
   Entity-Policy information applicable to the MCU is also conveyed in the addConference call
     (this is discussed in a previous section).
Step 3.1. If the MCU accepts the addConference request, it then responds to the
addConference call with a success parameter. It can optionally request Focus to send
conference notifications by setting the notification parameter appropriately.

                                                                                               48
Joining a Conference
After a client joins the conference and the conference is created, the client must establish a
media session with a conferencing server responsible for that media type. For each conferencing
server that is involved in a conference, the Focus assigns a virtual SIP URI that is routable to the
Focus itself. The initial notification from the Focus to the client contains the URIs for all
conferencing servers in the conference.
A client can join itself to the conference in one of the following two ways:
   To join to an IM Conferencing Server or an A/V Conferencing Server (Conferencing Servers
     that communicate using SIP), a client issues a direct media INVITE to the conferencing
     server URI.
   To join to a Web Conferencing Server (which does not use SIP), a client issues an addUser
     C3P dial-in command targeted at the conferencing server URI. (All C3P commands are
     carried inside a SIP INFO.)
A presenter client will typically invite another participant into a conference by first sending an
appINVITE directly to the other participant. (An appINVITE is an INVITE between client
endpoints in which the body of the request contains the Focus URI for the conference.)
If that participant client supports C3P, it will join itself to the conference using one of the
preceding methods.
If the participant is a client with aversion of Office Communications Server prior to 2007, the
presenter client will receive a 415 error that will cause the presenters client to issue an addUser
C3P dial-out command to the conferencing server URI, to have the conferencing server directly
connect to the legacy client.
In This Section
This section includes the following topics:
   Direct Media INVITE Conference Join Method for Office Communications Server 2007 R2
   C3P addUser dial-in Conference Join Method

Direct Media INVITE Conference Join Method for Office Communications Server 2007 R2
Clients can join a conference by sending a direct media INVITE. This method can only be used
with conferencing servers that use SIP to establish sessions, such as the A/V Conferencing
Server and the IM Conferencing Server. A media INVITE is an INVITE where the To: line
contains the conferencing server URI.
Clients can join a conference by sending a direct media INVITE. This method can only be used
with conferencing servers that use SIP to establish sessions, such as the A/V Conferencing
Server and the IM Conferencing Server. A media INVITE is an INVITE where the To: line
contains the conferencing server URI.
A client can send the media session INVITE to the conferencing server URI directly, without any
prior addUser call. The INVITE is routed to the Focus. The Focus checks if the connection
information is a routable SIP address and forwards the INVITE directly to the conferencing server.
The Focus also sends the addUser command to the conferencing server on the client's behalf.
The conferencing server authorizes the request and responds with the connection information.

                                                                                                     49
The following figure shows the message flow between conferencing components when a client
joins a conference by sending a direct media INVITE.




Client sending the media session INVITE to the conferencing server directly
* The BENOTIFY is sent to all clients subscribed to the conference state.
The following is a description of the message flow between conferencing components when a
client joins a conference by sending the media session INVITE to the conferencing server URI
directly:
Step 1. The client sends an INVITE to the focus/conference URI it received in the notification
document. This INVITE is routed to the focus. The client might have included a session
description for media negotiation. Since the focus recognizes that the INVITE was addressed to a
particular conferencing server, it safely ignores any session description in the body of the INVITE.
Step 2. The Focus then sends an HTTP request to the conferencing server assigned by the
Conferencing Server Factory to this conference asking it to expect a new participant (addUser).
Any bootstrapping requests that the Focus sends to initialize the conference on the conferencing
server are not included in the call flow diagram.
Step 2.1. The conferencing server sends a successful response for the addUser call. The
response includes the actual URL that it wants the participant to use to communicate with the
conferencing server. If the server sending the response is an A/V Conferencing Server, the URL
indicates that the participant can communicate with the conferencing server using SIP.
Step 1.1. After the Focus receives the successful response for the addUser request, the Focus
forwards the INVITE to the A/V Conferencing Server.


                                                                                                  50
Step 1.2. The conferencing server sends a successful response to the client.
Step 1.3. The client sends an ACK to the conferencing server to complete the INVITE dialog. The
same INVITE dialog is also used for media negotiation with the conferencing server.
Note:
Although the client establishes the INVITE dialog directly with the conferencing server, the SIP
requests traverse the Focus.
Step 3. After the client successfully joins the conferencing server, it sends a participant joined
event to the Focus.
Step 4. The Focus sends a participant joined conferencing server state change notification to all
clients subscribed to the conference state.
Step 5. Direct media negotiation occurs between the client and the conferencing server. With an
A/V Conferencing Server, the media are RTP/RTCP streams.

C3P addUser dial-in Conference Join Method
A client can connect to a non-SIP based conferencing server, such as a Web Conferencing
Server, by issuing an addUser C3P dial-in command. When a client issues an addUser dial-in
C3P command, the Focus forwards the command to the Web Conferencing Server. The Web
Conferencing Server authorizes the command and returns the appropriate connection
information. The client then establishes a direct media session with the conferencing server.
The Following figure shows the message flow between conferencing components when a client
joins a conference by issuing an addUser C3P dial-in command.




Client joining media with a Web Conferencing Server using addUser dial-in
                                                                                                     51
The following is a description of the message flow between conferencing components when a
client joins a conference by sending an addUser C3P command to the Web Conferencing
Server:
Step 1. The client sends an INFO request with an addUser dial-in command to the Focus. The
client uses the focus/conference URI it received in the notification document.
Step 2. The Focus determines if a conferencing server has been assigned to support this
particular media type for this conference. If a conferencing server has not been assigned, the
Focus sends an HTTP request to the Conferencing Server Factory asking it to allocate a
conferencing server for this conference. In the diagram, it is assumed that the conferencing
server has been assigned to the conference. The Focus then sends an HTTP request to the
designated conferencing server asking it to expect a new participant (addUser). Any
bootstrapping requests that the Focus sends to initialize the conference on the conferencing
server are not included in the call flow diagram.
Step 2.1. The conferencing server sends a successful response for the addUser request. The
response contains the actual URL it wants the conference participant to use to talk to the
conferencing server. If the client is joining a Web Conferencing Server, the URL is a PSOM URL.
Authorization information, if any, is also included in the response.
Step 3. The Focus sends the PSOM connection information to the client.
Step 4. The client directly establishes a PSOM channel with the Web Conferencing Server.
Step 5. After the client successfully joins the Web Conferencing Server, it sends a participant
joined event to the Focus.
Step 6. The Focus sends a participant joined conferencing server state change notification to all
clients subscribed to the conference state.
BENOTIFY sip:client1@contoso.com SIP/2.0
    SIP headers...
<conference-state version="1" state="partial"
           entity="sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234"
>
     <user entity="bob@contoso.com" state="full">
     <display-text>Bob Kelly</display-text>
        <endpoint entity="addf">
           <state>connected</state>
             <!--
             MEDIA
             -->
             <media entity="2" state="full">
                <display-text>data collab</display-text>
                <proto>dataCollab</proto>

                                                                                                  52
              </media>
        </endpoint>
      </user>
<....Other conf Info...>
</conference-state>


Adding Participants to the Conference
This section describes the different ways that participants can be added to a conference.
In This Section
This section includes the following topics:
   Adding Participants Using an AppINVITE
   C3P addUser dial-out Conference Join Method

Adding Participants Using an AppINVITE
This method of adding participants to a conference is used by clients that support C3P and can
therefore join both the Media and the media conferencing server.
After a client has joined a conference successfully, the client can send an app INVITE to another
participant. The app INVITE displays as a message prompt in the user's client and contains a
conferencing URL and meeting key. After the participant accepts (clicks) the message prompt, it
will launch the conferencing client, which then dials the participant in to the conference.
The following figure shows the message flow between conferencing components when a client
adds a participant to a conference using an appINVITE.




Ad hoc invitation to another participant


                                                                                                 53
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.




                                                                                                       54
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.

                                                                                                     55
Step 6. The Focus sends a participant joined conferencing server state change notification to all
clients subscribed to the conference state.


Notification Document
For each media type used in the conference, the Focus assigns a virtual SIP URI that routes to
the Focus. The initial notification from the Focus to the client contains the list of SIP URIs for all
the conferencing servers in the conference. The client uses the conference URI to identify the
conferencing server it into which it wants to dial or to which it wants to issue a control command.
The conference state package data model has the following elements:
   Conference description. Conference title and description.
   Conference View. Conference-specific information for each entity involved in the conference
     (for example, the Focus, A/V Conferencing Server, and IM Conferencing Server). This
     information includes capabilities, current state, settings, and policy information.
   Users. Roster of the conferences, the users, corresponding endpoints, and the media
     sessions to which they are connected.
The following is an example of a conference state notification document with two conferencing
servers:
<conference-info >
<conference-description>
     <msci:conference-view ci:state="full">
         <msci:entity-view entity="avMcuConfUri" ci:state="full">
             <!—MCU specific data, media-specific states go here -->
         </msci:entity-view>
         <msci:entity-view entity="dataMcuConfUri" ci:state="full">
                 <!—MCU specific data, media-specific states go here -->
         </msci:entity-view>
         <msci:entity-view entity="acpMcuConfUri" ci:state="full">
             <!—MCU specific data, media-specific states go here -->
         </msci:entity-view>
     </msci:conference-view>
<users>
<user entity="sip:user1@contoso.com" state="full" >
<endpoint entity="sip:user1@contoso.com" >
<status>on-hold</status>
</endpoint>
</user>
<user entity="sip:user2@contoso.com" state="full" >
                                                                                                     56
<endpoint entity="sip:user2@contoso.com" >
<status>on-hold</status>
</endpoint>
</user>
<user entity="sip:user3@conf.fabrikam.com" state="full" >
<roles><entry>presenter</entry>
</roles>
<endpoint entity="sip:user1@conf.fabrikam.com" >
<status>connected</status>
</endpoint>
<endpoint entity="{guid}" session-type="audio-video" >
<status >connected</status>
</endpoint>
</user>
<user entity="sip:user4@conf.fabrikam.com" state="full" >
<roles><entry>participant</entry>
</roles>
<endpoint entity="sip:user2@conf.fabrikam.com" >
<status>connected</status>
</endpoint>
</user>
</users>
<display-text>brownbag </display-text>
<conf-uris>
<entry>
<uri>sip:organizer@contoso.com;ms-app=conf/meeting;ms-conf-id=cd</uri>
<display-text>Data MCU</display-text>
<purpose>meeting</purpose>
</entry>
<entry>
<uri>sip:organizer@contoso.com;ms-app=conf/audio-video;ms-conf-
id=cd/uri>
<display-text>AV MCU</display-text>
<purpose>audio-video</purpose>


                                                                         57
</entry>
</conf-uris>
</conference-description>
<conference-info>


Conference Deactivation
A presenter can terminate a conference that is in progress at any point. When a presenter
terminates a conference, the client sends a SIP INFO request with a C3P deleteConference
command to the Focus, which includes the conference URI. The Focus performs authorization to
verify that the user is a presenter with privileges to end the conference. The Focus then
generates an update to the participant list by sending a SIP NOTIFY message to all users with an
active INVITE dialog associated with the conference. The conferencing server sends a SIP BYE
to each client that has an active media dialog. At this point, the conference has effectively ended.
A conference is deactivated in the following scenarios:
   When no new participant has joined a conference (meaning the conference is idle) in 24
     hours.
   10 minutes after all authenticated participants have left the conference.


Conference Expiration
When a conference is created, an expiration date is typically passed to the server for the
conference. When the expiration date arrives, the Focus is responsible for deleting all information
about the conference from the conferencing database and the Web Conferencing Server is
responsible for deleting the conference content.


Web Conferencing Server for Office Communications Server
2007 R2
A discussion of the Web Conferencing Server must necessarily include a discussion of the
interactions between the components: conferencing client, Focus, Focus Factory, Conferencing
Server, and Conferencing Server Factory. Definitions of the conferencing components are as
follows:
   Conferencing Client. A SIP endpoint capable of joining and participating in a conference.
   Scheduling Client. A SIP endpoint that is responsible for scheduling the conference. For
     example, the Conferencing Add-in for Microsoft Office Outlook messaging and collaboration
     client is a scheduling client for scheduled conferences and Office Communicator can be a
     scheduling client for ad-hoc conferences.
   Focus. A Focus is a SIP endpoint that represents a conference. It is responsible for
     managing the state of the conference, enforcing security, managing roles and privileges and
     providing conference state updates to the clients. A Focus instance runs on a Front End
     Server.


                                                                                                  58
   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

                                                                                                  59
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

                                                                                                 60
organization needs to retain data exchanged in Web conferences to satisfy regulatory compliance
requirements, you can configure a UNC path to the compliance folder using either the MMC or
the WMI MSFT_SIPDataComplianceSettingClass class.
These UNC paths can point to a file system running on the same computer or, preferably, on a
dedicated file server. The administrator manually creates these folders when deploying Office
Communications Server.


Metadata Folder
The metadata folder stores the conference metadata (for example, the number of slides, the slide
names, and the slide types) that is shared by the Web Conferencing Server with clients over
Persistent Shared Object Model (PSOM). Under the metadata folder root, the Web Conferencing
Server creates the following structure of subfolders:
   For each conference organizer, the Web Conferencing Server creates a separate folder
     below the metadata folder root. The organizer folder name is a hash value computed using
     the organizer URI.
   For each conference, the Web Conferencing Server creates a separate folder below the
     organizer subfolder. The conference folder name is the same as the conference ID.
   Metadata files for a conference are stored in the conference folder.
The following figure shows the structure of metadata folders for m organizers and n conferences
for the first organizer.




The Web Conferencing Server creates these folders and subfolders when it receives a C3P
addConference request from the Focus. If a folder for an organizer does not exist, the Web
Conferencing Server creates a new organizer folder. If a folder for an organizer already exists,
the Web Conferencing Server creates the conference subfolder below the existing organizer

                                                                                                   61
folder. If a folder for a conference does not exist, the Web Conferencing Server creates a new
conference folder. If a conference folder already exists, the Web Conferencing Server saves the
metadata files in the existing conference folder.
Sensitive information about conferences, including each conferences encryption key, is stored in
the metadata folder. As a result, it is recommended that, during deployment, the administrator
grants Read/Write permissions for the metadata folder only to the user group that will administer
the Web Conferencing Server.

Contentmgr.xml File
In the metadata folder root, the Web Conferencing Server creates an XML file (Contentmgr.xml)
that is used to coordinate the mechanism that cleans up the expired content. For example, if your
organization deployed multiple instances of the Web Conferencing Server and all instances share
the same metadata and content folders, the Contentmgr.xml file is used to monitor and determine
which Web Conferencing Server is responsible for running the clean-up mechanism.
In the Contentmgr.xml file, you can find the fully qualified domain name (FQDN) of the Web
Conferencing Server responsible for removing expired content from the folders. The Web
Conferencing Server responsible for removing expired content periodically updates the
Contentmgr.xml file with its own FQDN and a time stamp indicating the last time it updated the
file. Meanwhile, other Web Conferencing Servers in the topology periodically read the file and
verify the time stamp. If more than 10 minutes have passed since the last update, another Web
Conferencing Server attempts to lock the file and write its own FQDN in the file to become the
new owner of the clean-up process.


Organizer Folder
When a Web Conferencing Server needs to create a metadata folder for a conference, it extracts
the organizer URI from the addConference XML. The URI is passed as input for a hash function.
The result of this call is used to search through the subfolders of the metadata root folder to
determine whether there is already an existing organizer subfolder. If no organizer subfolder
exists, the Web Conferencing Server creates a new one.
Having a separate folder for each organizer allows the administrator to easily move the
conferences owned by a particular user. The resource kit has a tool, DMHash.exe, which allows
an administrator to input an URI and obtain the hash. For example, if you need to change the URI
for a user and continue to have the content available, you need to:
   Run DMHash.exe with the old URI and get the name for the organizer folder.
   Run DMHash.exe with the new URI and get the name for the new organizer folder.
   Rename the old folder using the new hash value.


Conference Folder
When a Web Conferencing Server needs to create a metadata folder for a conference, after the
server has created or identified the appropriate organizer folder, the server extracts the
conference ID from the XML in the C3P addConference request, and then searches the
subfolders below the organizer folder for a folder with the same name as the conference ID. If a
                                                                                                   62
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.




                                                                                                  63
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                        -

                                                                                                   64
Slide Type                 Upload over PSOM         Download over PSOM        Download over HTTPS

PowerPoint                 Yes                      -                         Yes

Microsoft Office Word      Yes                      -                         Yes
documents

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.

                                                                                                      65
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.




                                                                                               66
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.




                                                                                                   67
Slide Set Files
For each slide set created, the Web Conferencing Server saves two encrypted XML files. The
encryption algorithm is AES and the encryption key is the master key stored in the
conference.xml file. Because the files are encrypted, their file names use an .exml file name
extension.
Each slide set has a unique identifier. The slide set file names are created using the following
patterns:
   set-<unique_identifier>.exml and set-s-<unique_identifier>.exml
For example, for a slide set with the unique identifier abc, the file names are set-abc.exml and
set-s-abc.exml.
The content of the two files is the same. The second file is provided for backup purposes. When
the Web Conferencing Server needs to save new changes in the slide set with the unique
identifier aaa, the server opens the first file—set-aaa.exml—and attempts to save the changes to
that file. If the original write operation succeeds, the Web Conferencing Server creates a copy of
set-aaa.exml and renames the copy slide-s-aaa.exml. If the write operation fails, the Web
Conferencing Server deletes set-aaa.exml, creates a copy of set-s-aaa.exml, and renames the
copy set-aaa.exml.
The following figure shows the logical flow of the update operation.




                                                                                                   68
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.

                                                                                                    69
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

                                                                                                        70
metadata file for the slide set stores only the link to the conference content file and the encryption
key.
For example, if you have a slide generated from a PowerPoint slide, under the XML node for that
slide you find the:
   Randomly generated name for the original uploaded PPT file.
   Encryption key for the PPT file.
   Randomly generated name for the large image of the slide in PNG format.
   Encryption key for the PNG file.
   Randomly generated name for the thumbnail image of the slide in PNG format.
   Encryption key for the PNG file.
You can use the names of these PPT and PNG files to search for the slide content in the
conference content folders.

Metadata File for Poll Slide
The following is an example of the XML content for a Poll slide.
<poll-slide
     name="[ Poll 1 ]"
     recording-id=""
     createdby="sip:vw01@rtcdev.nttest.contoso.com [vw01]">
     <question>What day is today?</question>
     <choice>MON</choice>
     <choice>TUE</choice>
     <choice>WED</choice>
     <choice>THU</choice>
     <choice>FRI</choice>
     <choice>SAT</choice>
     <choice>SUN</choice>
</poll-slide>

Metadata file for Text Slide
The following is an example of the XML content for a Text slide.
<text-slide
     name="[ Text Slide 1 ]"
     recording-id=""
     createdby="sip:vw01@rtcdev.nttest.contoso.com [vw01]"
>
     <current-text>

                                                                                                    71
    This is the content of a text slide I've just typed
    </current-text>
</text-slide>

Metadata File for Web Slide
The following is an example of the XML content for a Web slide.
<web-slide
    name="[ Web Slide 1 ]"
    recording-id=""
    createdby="sip:vw01@rtcdev.nttest.contoso.com [vw01]"
    url="http://microsoft.com">
</web-slide>

Metadata File for Whiteboard Slide
The following is an example of the XML content for a Whiteboard slide.
<image-slide
    name="[ White Board 1 ]"
    recording-id=""
    createdby="sip:vw01@rtcdev.nttest.contoso.com [vw01]"
    image-width-attr="704"
    image-height-attr="528"
    page-number="-1"
    rich-slide-type="Whiteboard"
    thumbnail-aspect="1.33333337">
    <ann
        COLOR="0"
        AUTHOR="vw01"
        TYPE="1"
        recording-id="">


01000000000a0075007a00af007100cc009c00c000ba009d00b0009b009d00f40084011
400980116009901160099
    </ann>
    <ann
        COLOR="0"
        AUTHOR="vw01"

                                                                         72
        TYPE="23"
        recording-id="">
        17000000009700fa01090144
    </ann>
</image-slide>

Metadata File for Snapshot Slide
The following is an example of the XML content for a Snapshot slide.
<image-slide
    name="[ Snapshot 1 ]"
    recording-id=""
    createdby="sip:vw01@rtcdev.nttest.contoso.com [vw01]"
    image="x8d51284585d1.epng"
    key="a51fe0f3e26813761e12435a9c2c5d89"
    image-filesize-attr="52865"
    image-width-attr="388"
    image-height-attr="369"
    page-number="-1"
    rich-slide-type="Image"
    thumbnail-image="xe31d11b0506d.epng"
    thumbnail-key="a51fe0f3e26813761e12435a9c2c5d89"
    thumbnail-aspect="1.0"
    compliance-image="xcb4de1d7b784-aae.png">
    <ann
        COLOR="0"
        AUTHOR="vw01"
        TYPE="1"
        recording-id="">


01000000000a0075007a00af007100cc009c00c000ba009d00b0009b009d00f40084011
400980116009901160099
    </ann>
    <ann
        COLOR="0"
        AUTHOR="vw01"

                                                                       73
        TYPE="23"
        recording-id="">
        17000000009700fa01090144
    </ann>
</image-slide>

Metadata File for Word Document Slide
The following is an example of the XML content for a Word document slide.
<image-slide
    name="Page 1"
    slideset-name="test.txt"
    recording-id=""
    createdby="sip:vw01@rtcdev.nttest.contoso.com [vw01]"
    image="xebc7f400248d.epng"
    key="ce3de85a37a8a6fc6b3b702b70a1a925"
    image-filesize-attr="6778"
    image-width-attr="816"
    image-height-attr="1056"
    document="x9838edc7b0d2.emdi"
    document-key="8ca685d4bcfb9afe94cc27ea4bd0a2e1"
    document-filesize-attr="1537"
    rich-slide-type="Modi"
    thumbnail-image="x908006115ceb.epng"
    thumbnail-key="40d224ca035ee8f77ba9c7342da17b1b"
    thumbnail-aspect="0.772727251"
    thumbnail-filesize-attr="748"
    compliance-image="xf3ae96bf86cd-aag-pngimage0.png"
    compliance-document="xbe356497761b-aag-x.mdi">
</image-slide>

Metadata File for Application Sharing Slide
The following is an example of the XML content for an Application Sharing slide.
<demo-slide
    name="Command Prompt - vw01"
    recording-id=""
    createdby=sip:vw01@rtcdev.nttest.microsoft.com [vw01]
                                                                                   74
    shareProcInfo=sip:vw01@rtcdev.nttest.contoso.com - 01C7E74B9137AC70
    shareHwnd="262300"
    shareSpeed="1"
    sharePid="4592"
    slideHotKey="19"
    slideColor="24"
    shareTitle="Command Prompt"
    slideCtrl="1"
    shareType="1">
</demo-slide>


Handouts (File Transfers)
You can think of file transfers, also known as handouts, as another type of slide set. Handouts
can be considered slide sets that contain only one slide of a single type: a transferred file.
The Web Conferencing Server follows the same process to save and update handout slides that
it uses for other slide sets. First, the server saves two encrypted XML files for each handout. The
content of the two files is the same. The second file is provided for backup purposes.
The update procedure for a handout is called every five minutes. If an update operation fails, the
changes made to a handout in the past five minutes are not saved. If the Web Conferencing
Server stops running during this period, changes to the handout can be lost. However, the Web
Conferencing Server continually tries to update the XML files every five minutes. As a result, if
one attempt fails, the Web Conferencing Server can attempt to save the content later.
The only differences in the save and update process for handouts are the location where the files
are saved and updated, the naming convention used to name the files, and the file that keeps
track of the IDs for the slide set for handouts.
The files are saved under a separate subfolder (named ft) in the conference folder for the
organizer. The FTMaxID files contain the last used ID. The names of the files in which the slide
set information is saved take the following form: fileset-<id>.exml. The files are encrypted using
the master encryption key.
The file content represents the XML serialization of handout information. Because handout slides
are shared over HTTPS in the XML, there is an encryption key and the randomly generated name
for the file that is saved in the content folder.

Metadata File for a Handout (File Transfer)
The following is an example of the XML content for a handout (file transfer).
<fileset
    name="a8f5689f4866.blb"
    size="37"
    key="48d9dd6ebe2ca367478da698493edc21"
                                                                                                     75
    UploadedOnDate="8/25/2007 12:20 PM"
    UploadedOn="1188069617459"
    UploadedBy="sip:vw01@rtcdev.contoso.microsoft.com"
    file_deleted="false"
    original_filename="test.txt"
    creation_date="128325431784134388"
    CreatedOnDate="1/18/8441 5:22 PM"
    modification_date="128325431917125620"
    ModifiedOnDate="1/20/8441 6:18 AM">
</fileset>


PersistData Folder (Shared Notes)
In the PersistData folder, the Web Conferencing Server stores only one file. The file contains the
XML serialization of the shared notes information. The file is encrypted using the conference
master encryption key. The file contains the XML serialization for rich text.

Metadata File for Shared Notes
The following is an example of the XML content for shared notes.
<PersistentData>
  <ScopeManager />
     <SharedNotes>
        <RichString>
           <PlainText>This is the content of the shared notes pane I've
just edited
           </PlainText>
        <StyleData>
           <Character>
             <FormatTable>
            <Format fontface="Arial" fontsize="9.0" bold="false"
italic="false" underline="false" /><Format fontface="" fontsize="9.0"
bold="false" italic="false" underline="false" />
             </FormatTable>
             <FormatRunTable>
                <FormatRun format="0" length="62" />
             </FormatRunTable>
           </Character>

                                                                                                 76
           <Paragraph>
              <FormatTable>
                 <Format bullets="0" numbering="0" /><Format bullets="1"
numbering="0" />
                 <Format bullets="0" numbering="1" />
              </FormatTable>
              <ParaFormats>
                 <Paragraph format="0" />
              </ParaFormats>
           </Paragraph>
         </StyleData>
      </RichString>
     </SharedNotes>
</PersistentData>


Content Folder
The content folder stores the content that is shared between the Web Conferencing Server and
clients using the Web Components Server. The content folders structure is similar to other
subfolders. The content folder contains the following:
   A separate subfolder for each organizer; the folder name is a hash based on the organizer
     URI.
   Under the organizer subfolder, there is a separate folder for each conference; the folder
     name is the same as the conference ID.
The following figure shows the structure of the content folder.




                                                                                                 77
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.


                                                                                                    78
Extension                                            Description

EMDI                                                 An encrypted MDI document – the console
                                                     converts the Word document into a MDI before
                                                     it is sent to the Web Conferencing Server.

WAV                                                  An encrypted WAV document.


The following table lists the types of slides that the Slidefiles folder contains and the content each
slide type contains.


Slide                                                Content

Snapshot                                             EPNG for the larger image.
                                                     EPNG for the thumbnail.

PowerPoint slide                                     EPNG for the larger image.
                                                     EPNG for the thumbnail.
                                                     EPPT for the original PPT. (There is one copy
                                                     of this file. For example, if you have a PPT with
                                                     two slides, you only see a single EPPT file.)

Word Document Slide                                  EPNG for the larger image.
                                                     EPNG for the thumbnail.
                                                     EMID for the original MDI file.

WAV                                                  WAV for the original WAV file.
                                                     Chunks generated by the presenter client from
                                                     original WAV file.


Files Transferred Folder (ft)
The ft folder stores all the handouts (transferred files) that are shared over HTTPS. All files are
encrypted using AES and a randomly generated key. A new encryption key is used for each
content file. The key is stored in the metadata file (fileset-xxx.exml) created for the transferred file
that will be shared over HTTPS. The names of the files are randomly generated and stored in the
same metadata file as the encryption key.
The following table describes the file name extension for the handout slides contained in the ft
folder.


Extension                                            Description

BLB                                                  The encrypted transferred file




                                                                                                      79
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       50 MB                     25 MB
                        not exceed this value.

Total size              The total size of all files   100 MB                    100 MB
                        in a conference must
                        not exceed this value.

Number of files         The total number of           8052                      30000
                        files in a conference
                        must not exceed this
                        value.


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.


                                                                                                    80
The following figure shows the structure of the compliance folder.




Ensure that only authorized users have read or write permissions and that the Web Conferencing
Server has write permissions to the compliance folder.

Compliance Folder
The compliance folder stores unencrypted metadata and content files. The following table lists the
compliance subfolders and the types of files stored in those subfolders.


Subfolder                                         Description

Content                                           Stores the copies of metadata files.

Content-upload                                    Stores the copies of content files.

Chat                                              Stores the logs for Chat sessions.

Poll                                              Stores the logs with the votes for Poll slides.

Qna                                               Stores the logs for Question and Answer
                                                  sessions.


Unlike the metadata and content folders, the compliance folder also stores all deleted slides. The
metadata and content folders only store the most recent conference content.
The following figure shows the structure of compliance subfolders.




                                                                                                    81
82
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.
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

                                                                                                    83
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
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

                                                                                                 84
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 un-
mute 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.
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


                                                                                                  85
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.




                                                                                              86
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.




                                                                                                 87
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

                                                                              88
   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;
                                                                                                  89
contact. Unlike the Exchange Contact objects, dial-in conferencing Contact objects are stored in
the Configuration container rather than in a Domain container, and dial-in conferencing Contact
objects do not appear in the Active Directory Users and Computers snap-in.
Unlike users, Contact objects do not have their own authentication credentials. Services running
under the identity of a Contact object must either be flagged in AD DS as trusted or else
impersonate the identity of the user who called the service.
There will be multiple Contact objects in this container that are related to dial-in conferencing: one
for each dial-in number, plus one for the Conferencing Attendant service
(CAAPrivateContactObject) and one for the Conference Announcement service of each pool.
Each contact is a SIP User Agent that acts as a robotic endpoint for processing and routing dial-in
conference callers and for playing conference announcements.
Administrators manage dial-in contact objects using the Conferencing Attendant Properties tab
of the Forest Properties dialog box in the Office Communications Server management snap-in.
For each Conferencing Attendant phone number added, an Application Contact object is created
that contains the phone number, the pool name affiliated with the number, a SIP URI (for
example, sip:Microsoft.RTC.Applications.CAA-<GUID>@contoso.com), the primary spoken
language that is played to the caller by the Conferencing Attendant service, and a list of up to four
secondary languages that will be presented as alternates to users who dial into the
Communicator 2007 R2 Attendant.
However, the Conference Announcement Service and CAAPrivateContactObject objects are
configured during product activation, and neither is exposed through the snap-in. If you change
the name of your organization’s main SIP domain after you install Office Communications Server
2007 R2, you need to change the msRTCSIP-PrimaryUserAddress attribute for both objects to
reflect your new primary SIP domain. (Both use the form sip:RtcApplication-<GUID>@<SIP
Domain>.) You can edit this attribute by using ADSIEdit, or you can use the WBEMTest utility to
edit the PrimaryURI attribute of the corresponding Windows Management Instrumentation (WMI)
Conference Announcement Service and CAAPrivateContactObject instances, which are
located in the MSFT_SIPApplicationContactSetting top-level class.
Dial-in Contact objects cannot be shared across pools; each must be bound to an Enterprise pool
or one Standard Edition server.

Location Profile to Access Number Mappings
Another new AD DS schema change in Office Communications Server 2007 R2 is the Location
Contact Mappings container. This container contains instances of the msRTCSIP-
LocationContactMapping 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,

                                                                                                     90
thereby setting the dial-in numbers that are used by the conference. Users who are enabled for
Enterprise Voice are assigned a default region. They can, however, manually override this
default, for example, if dial-in attendees would be better served by access numbers in another
geographic region.

Global Meeting Policy
Authorizing users to create dial-in conferences is managed through the global Meeting Policy
tab. This tab is not new, but in Office Communications Server 2007 R2 the schema is extended
with two more settings, Enable PSTN conference dial-in and PSTN conference dial-in
requires passcode. Either a single meeting policy can be assigned to all users in the
organization, or different policies can be assigned to individual user accounts.
These meeting policies are stored in Active Directory Domain Services as instances in the
Configuration Container under Services, RTC Service, and then Policies. Each instance has an
msRTSIP-PolicyContent attribute that contains flags for EnablePSTNConferencing and
TrustedConferencingPinRequired.

Trusted Services
In addition to the Contact objects described previously, both the Conference Announcement
Service and Conferencing Attendant Service are represented by multiple objects (class type =
msRTCSIP-TrustedService) in the Configuration Container under Services, RTC Service, and
then Trusted Services container of Active Directory Domain Services (AD DS). For each pool
supporting Dial-in Conferencing services, there must be one instance of each type for each pool
name (msRTCSIP-TrustedServerFQDN = <pool name FQDN>), plus instances for each server
in those pools (msRTCSIP-TrustedServerFQDN = <server FQDN>). For Standard Edition
servers, there are only two objects, since the pool name and server name are the same.
These trusted service instances will have an RTCSIP-TrustedServiceType attribute of either
Microsoft.RTC.Applications.CAA or Microsoft.RTC.Applications.CAS.

Communicator Web Access URLs
Communicator Web Access serves an auxiliary role for Dial-in Conferencing unrelated to its
primary role as a Web server for hosting browser-based Communicator clients—to serve Web
pages that are linked to by Office Communicator 2007 R2 client, the Communicator 2007 R2
Attendant, the Conferencing Add-In for Office Outlook, and the Live Meeting client. These Web
pages allow users to view dial-in numbers for various locations and to provide them with an
interface to reset their dial-in corporate PIN numbers and personal conference IDs.
One Communicator Web Access server or server farm normally serves the Dial-in Conferencing
Settings Web pages for all users across all pools, as shown in the following figure.




                                                                                                 91
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 msRTCSIP-
DefaultCWAInternalURL, msRTCSIP-DefaultCWAExternalURL, and msRTCSIP-
GlobalSettingsData.)
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

                                                                                                92
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


                                                                                                     93
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



                                                                                                    94
meeting is created. The pool portion of the Conference ID routes the dial-in caller to the specific
pool where the meeting is hosted.
Although Meeting IDs (16 to 32 character hexadecimal identifiers used in the Conference URI to
uniquely identify meetings), the short Conference IDs of expired conferences can be reused and
are unique only within the scope of a single Office Communications Server organization. The
mappings between the Conference IDs and Meeting IDs are stored in the RTC database. Users
do not normally need to enter Meeting IDs manually, but dial-in users manually enter Conference
IDs using their keypads to tell the Conferencing Attendant Service which meeting they want to
join.
The overall length of Conference IDs not fixed and will expand as needed to support the number
of pools in the organization and the number of unexpired meetings in the pool, and the pool
portion (that is, the pool ID) will be at least two digits. As a minimum security consideration to
minimize effortless guessing of consecutive Conference IDs, after the complete conference ID is
generated, it is obfuscated by Office Communications Server (that is, the number the user sees
cannot be parsed into a pool portion and a meeting portion).
The Conference ID is generated at the home pool of the user who schedules it, and it designates
the pool that will host the meeting. However, since the conference creator’s pool always hosts the
conference, this means that conference IDs must be released and reissued whenever a
conference’s creator has been moved to another pool. This action is automatically taken by Office
Communications Server. Unlike Meeting IDs, Conference IDs may be reused after the conference
mapped to has been deleted or moved.
The Front End Server passes the Conference ID back to the conference client, where it is
conveyed to dial-in participants through some other means, such as in an e-mail message.

Focus
An instance of the Focus for each active meeting exists on one of the servers in the pool that is
hosting the meeting, and it maintains the conference state and can be monitored by other
components. For example, the Conference Announcement Service monitors the Focus to
determine when users arrive or leave the meeting and when users have been muted or unmuted.
The Focus publishes the meeting roster, which has been updated in Office Communications
Server 2007 R2 to include dial-in callers. If the caller has an Active Directory Domain Services
account and has provided his or her extension number and corporate PIN, he or she will be listed
in the roster lists of Live Meeting clients under the display name assigned to their user account.
However, if the caller has provided only the Conference ID (and passcode if required), he or she
will be listed in the roster by Caller ID (if the number is passed to the Mediation Server by the
PBX or gateway). If not, such callers will be listed as Unidentified Participant 1, Unidentified
Participant 2, and so forth.
From the roster list in the Live Meeting client, presenters can forcibly mute, unmute, and eject
dial-in participants just as if they were Live Meeting client users.




                                                                                                      95
Conferencing Server Factory
Although the Conferencing Server Factory is essential to support dial-in conferencing by
provisioning the A/V Conferencing Server that is needed for the meeting, it does not exhibit any
special behavior when dial-in conferencing attendees are involved.

Audio/Video Conferencing Server
An A/V Conferencing Server acts as a relay hub for audio and video used by the meetings
assigned to it. Dial-in callers appear to the A/V Conferencing Server as just another audio
endpoint. After a dial-in caller has been authenticated, the Conferencing Attendant signals the
A/V Conferencing Server in the pool hosting the meeting to establish an audio leg with the
Mediation server handling the dial-in participant.
When a dial-in user is connected to the A/V Conferencing Server, it in turn invites a Conference
Announcement Service in its pool to the meeting (unless one is already running), which in turn
joins the Focus as a trusted participant. The Conference Announcement Service monitors the
Focus, and announces certain state change events to all dial-in participants, such as when a
participant enters or leaves the meeting, or to individual dial-in participants, such as when his or
her microphone has been muted.

Mediation Servers
In order for the Dial-in Conferencing feature to service PSTN callers, the organization must have
either one or more Mediation Servers connected to the PSTN using a Media Gateway connected
to the PSTN or to a PBX, or Direct SIP Integration with a PBX or external SIP Trunking service
provider. As with Enterprise Voice user Direct Inward Dialing (DID) numbers and Exchange Auto
Attendant and Subscriber Access numbers, calls from the PSTN to the published dial-in access
numbers must also be routed to a Mediation Server. Inbound routing normalizes the called-party
number according to the default location profile rules on the Mediation Server and routes calls to
the address of the next-hop pool.
No special Mediation Server configuration is required to support dial-in conferencing, but the
normalization rules for the Mediation Server’s default location profile must normalize the dialed
number to a form (typically E.164) matching the Line URI of a Conferencing Attendant contact
object.
Routing of Conferencing Attendant contact numbers to a Mediation Server may also require
additional routing rules on the PBX and/or Media Gateway if the phone number patterns differ
from those of Enterprise Voice users (or if Enterprise Voice has not been deployed).
When planning for dial-in conferencing, keep in mind that each dial-in user will consume a
channel on a trunk connecting the PBX and/or Media Gateway to the PSTN. For organizations
who size their number of PSTN trunks and Mediation servers to accommodate normal levels of
inbound and outbound call volumes, this means they may not be able to support large numbers of
dial-in users; however, for such meetings they could still use an audio conferencing provider
(ACP) or the Web-hosted Live Meeting Service.
In Office Communications Server 2007 R2, it is not possible to link an ACP conferencing bridge to
an Office Communications Server A/V Conferencing Server.


                                                                                                    96
Communicator Web Access Server
As noted earlier, the 2007 R2 release of Communicator Web Access serves a role in dial-in
conferencing that is unrelated to its primary role of hosting a browser-based client for Office
Communications Server. Using the InternalURL and ExternalURL attributes of the
MSFT_SIPGlobalCWAServerConfigSetting object, which are provisioned to the client during
sign-in, the Office Communicator, Outlook Conferencing Add-In, and Live Meeting clients expose
links to new Communicator Web Access Web pages that display dial-in access numbers for
various locations and languages and that give users an interface to reset their personal dial-in
conference codes and PIN numbers.
Piggy-backing this functionality on Communicator Web Access spares Office Communications
Server customers from dedicating a separate server to this role and—because the function is
used very lightly—it does not significantly degrade overall Communicator Web Access
performance. This approach also makes it easier for organizations to provide Internet-based
access to these Web pages, because most organizations that deploy Communicator Web Access
also publish the service to the Internet.
The Dial-in Conferencing Settings Web site is accessed by appending /dialin to the internal or
external Communicator Web Access URLs. The site consists of two separate pages:
   Publish Dial-in Conference Numbers. The home page of the Dial-in Conferencing Settings
     Web site. This page does not require authentication and is read-only. It publishes the
     Conferencing Attendant access numbers for various languages and regions, and the page
     itself is available in 14 languages. (Support for non-English versions of the page requires
     installation of the Communicator Web Access Multilanguage Pack.)
   Change per-user dial-in settings. From the Dial-in Conferencing Settings home page, a
     user can click a sign-in link that brings up a site that enables him or her to reset dial-in
     conference PIN numbers and personal conference IDs. This page is available in the same
     languages as the home page.
Communicator Web Access does not store data locally. All dial-in conferencing data is extracted
from the pool that is assigned to the logged-on user, which retrieves data from the pool’s
database and from Active Directory Domain Services (AD DS).

Note:
     Communicator Web Access support for dial-in conferencing is also unrelated to the new
     PSTN dial-out feature, which allows Communicator Web Access users to participate in
     voice calls by calling them back on a PSTN phone or PBX extension.


Client-Based Dial-in Conferencing Components
To create a dial-in–enabled meeting, the user must be authorized and be using the 2007 R2
release of the Microsoft Conferencing Add-in for Microsoft Office Outlook, or the Live Meeting
client.




                                                                                                    97
Conferencing Add-in for Microsoft Office Outlook
The 2007 R2 release of the Conferencing Add-in for Microsoft Office Outlook has some new
functionality for scheduling dial-in conferences.
   Users can connect directly from Outlook to the Dial-In Conferencing Settings Web page on
     the Communicator Web Access server.
   Meeting creators can enable dial-in conferencing as an audio option.
When Outlook starts, the internal and external URLs of the Communicator Web Access server
are provisioned to Outlook from the pool by using the connection information that is configured in
the Live Meeting client.
When the Outlook user selects Dial-In Conferencing Settings from the Conferencing menu,
Outlook first tries to open the \dialin site on the external URL of the Communicator Web Access
server. If this fails, then it retries on the internal URL.
To enable dial-in conferencing for users, the meeting creator must enable dial-in conferencing for
the meeting using the Conferencing Add-in Audio options menu.
When an Outlook user clicks Schedule a Live Meeting, the client makes a SIP request to the
user’s pool stipulating that it wants to schedule a dial-in enabled meeting and generates a 32-
character 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

                                                                                                  98
uses the By E-mail menu option in the client (under the Attendees menu, under Invite) to create
an e-mail invitation, the organizer must manually insert the meeting’s dial-in information into the
body of the message.


Office Communicator
Although Office Communicator 2007 R2 does not provide a means for users to create scheduled
meetings, it does enable users to create unscheduled audio/video meetings. However, Office
Communicator does not contain provisions for inviting dial-in attendees to these meetings. (Office
Communicator-based participants can use the client’s dial-out feature to add phone users to
these meetings.)
Nevertheless, Office Communicator users can click a menu option that links them to the
Communicator Web Access server to view and modify their dial-in conferencing settings. Office
Communicator obtains the internal and external Communicator Web Access URLs using in-band
provisioning upon sign-in and uses these to open the Dial-In Conferencing Settings Web page in
a separate browser window.


Call Flows
There are two separate flows to dial-in conferencing: creating a dial-in conferencing–enabled
meeting and joining the meeting as a dial-in participant.


Meeting Set-up
Office Communications Server 2007 R2 introduces a new Centralized Conference Control
Protocol (C3P) command: getConferencingCapabilities. The client sends a SIP SERVICE
request containing a getConferencingCapabilities request to the Focus Factory to discover
capabilities of the hosting pool. The Focus Factory returns information that the client uses to form
AddConference and ModifyConference requests. For dial-in conferencing to be offered to the
person scheduling the meeting, the Pstn-bridging Enabled value must be set to True.
The client will use this information when it issues subsequent AddConference and
ModifyConference SERVICE requests.


To create an Anonymous-Allowed Live Meeting with Dial-In Conferencing
support
1. The client (that is, either the Conferencing Add-In for Outlook for scheduled meetings or the
   LiveMeeting client for unscheduled meetings) sends a SIP SERVICE request containing a
   GetConferencingCapabilities request that gets proxied to a Focus Factory globally-routable
   User Agent URI (GRUU) in the pool where the user is homed.
2. The Focus Factory extracts meeting capability information from its database and returns the
   information to the client. This information includes all of the dial-in conferencing dial-in access
   numbers categorized by region. The user’s location profile region determines the access
   numbers for the conference.


                                                                                                   99
3. The client sends a SIP SERVICE request containing an AddConference request to the
   Focus Factory with an msci:pstn-access attribute tag. If the user’s Meeting Policy requires
   that anonymous meetings have passcodes, the client generates a passcode, encrypts it, and
   sends it as part of the request.
4. The Focus Factory creates a meeting instance in the pool database, assigns it a Conference
   ID, and then returns this information to the client. A SIP SERVICE GetConference request to
   the Focus Factory is required to complete the meeting creation process.
5. If the meeting is scheduled from the Conferencing Add-in for Outlook, the user sends a
   meeting invitation that contains the dial-in information to the other attendees. If the meeting is
   created by using the Meet Now button in the Live Meeting client, the meeting creator has to
   copy the dial-in information and send it to other attendees by using an instant message or an
   e-mail message.
The following figure shows the sequence of data exchanges between the components involved.




Connecting to the Meeting
Authenticated Office Communicator and Live Meeting users (including federated users) who have
a computer with audio capability can connect to the conference as they did in Office
Communications Server 2007.
Assuming dial-in attendees call in from the PSTN on an ISDN-PRI trunk that is connected to the
hosting organization’s PBX and a media gateway is employed in the solution, the call flow for
joining the meeting is as follows:
1. The first Office Communicator or Live Meeting–based attendee joins the meeting, which
   activates the meeting and causes RTCSrv.exe to instantiate a meeting Focus on a Front End
   Server in the pool that is hosting the meeting. The Focus, in turn, requests the Conferencing
   Server Factory on that server to assign an A/V Conferencing Server to the meeting (and
   other Conferencing Servers).
2. A dial-in attendee dials the conference access number listed in his or her e-mail invitation,
   and the PSTN routes the call to the organization’s PBX.


                                                                                                   100
3. The PBX uses the called-party number to route the call to the media gateway. The media
   gateway then transforms the call from ISDN-PRI to SIP/RTP and routes the call to an Office
   Communications Server Mediation Server. (The media gateway may not be required if the
   organization has an IP-PBX that can transform the call from ISDN-PRI to SIP/RTP and route
   the call directly to the Mediation Server.)
4. If the number passed to the Mediation Server is not in E.164 format, the configured next-hop
   Office Communications Server Front End (that is, SIP proxy) server performs inbound
   normalization by using the Mediation Server’s default location profile. It performs a reverse
   number lookup against the user database on the normalized called number and finds a match
   with the Conferencing Attendant contact object’s msRTCSIP Line URI.
5. The Front End Server routes the call to the Conferencing Attendant Service on the pool
   bound to the Conferencing Attendant Contact object.
6. The Conferencing Attendant Service on that pool automatically answers the call, and a
   Secure Real-time Transport Protocol (SRTP) media connection is established between the
   Mediation Server and the Conferencing Attendant Service.
7. The Conferencing Attendant Service prompts anonymous users for their conference IDs and
   passcodes (if assigned), or if the user is an enterprise user (that is, has an identity in the
   Active Directory Domain Services) the user’s extension number and PIN. The following flow
   chart illustrates the prompt sequence that the Conferencing Attendant service follows. Callers
   enter responses from their phone keypad.




                                                                                              101
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.


                                                                                                 102
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.




                                                                                                   103
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.



                                                                                              104
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:


                                                                                                105
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.




                                                                                              106
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.




                                                                                               107
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.


                                                                                                 108
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,

                                                                                                   109
Registrar, Focus Factory, and Focus instances. In an Enterprise pool, the hardware load balancer
distributes requests for an Application Sharing Conferencing Server, which listens on TCP port
5065, among the pool servers.
An Application Sharing Conferencing Server is used only when the application sharing session
contains three or more participants or whenever one of the participants is using Communicator
Web Access.
An Application Sharing Conferencing Server communicates with clients, whether Office
Communicator or Communicator Web Access, using SIP/SDP and SIP/C3P for signaling and
RDP-over-SRTP for the display and remote control data. The SIP communications are secured
by MTLS, and they use the same SSL server certificate that is assigned to the Front End Server.
As with A/V traffic, the RDP/SRTP traffic does not use a certificate and instead uses Advanced
Encryption Standard (AES) and a shared key, which is negotiated and exchanged securely over
the signaling channel, to encrypt and decrypt the RDP traffic that it transports.
The Application Sharing Conferencing Server also communicates with the Focus and
Conferencing Server Factory over HTTPS/C3P using the same SSL certificate that is assigned to
the other Office Communications Server services on the Front End Server.
The Application Sharing Conferencing Server retrieves its configuration data by using Windows
Management Instrumentation (WMI), but the only configurable settings for the service are the
listening port and IP address, the range of media ports that RTP/SRTP can use, the maximum
number of users across all meetings, the maximum number of meetings, and the maximum
meeting size.

Focus and Conferencing Server Factory
The Office Communications Server 2007 R2 Focus and Conferencing Server Factory have been
updated to be aware of the Application Sharing Conferencing Server and to communicate with it
in the same manner as the other conferencing servers, primarily over HTTPS/C3P.

Office Communicator
Office Communicator 2007 R2 has been extended to support desktop sharing so that users can
participate in desktop sharing sessions without installing the Live Meeting client or any special
plug-ins, and if the user has been assigned a global meeting policy that includes the Enable
Program and Desktop Sharing option, there is nothing more for the user or the administrator to
do.
Because Office Communicator 2007 R2 is an ICE-enabled client, it can find the most efficient way
to establish peer-to-peer desktop sharing sessions with other Office Communicator 2007 R2
clients. The new version of Office Communicator also adds RDP support needed for desktop
sharing. (This RDP support is completely independent of the RDP support in Windows.)
The user interface for invoking and responding to desktop sharing is described in the Office
Communicator Help and in the Office Communicator 2007 R2 Technical Reference.




                                                                                               110
Communicator Web Access
Microsoft has extensively enhanced the 2007 R2 release of Communicator Web Access in order
to provide support for participants who do not have access to a computer with either the Office
Communicator or Live Meeting client.
The addition of dial-in and dial-out conferencing allows users with access to a phone to
participate in the audio portion of Office Communicator-based meetings, and new anonymous
sign-in support in Communicator Web Access desktop sharing allows even an anonymous user
with access to a browser to participate in online meetings that involve desktop sharing (if
permitted by Office Communications Server global Meeting policy).
In order to support Macintosh and Linux users, Communicator Web Access displays the sharer’s
desktop in the user’s browser window using AJAX Dynamic HTML (DHTML) over HTTPS. The
Communicator Web Access server gets the sharer’s RDP stream from the Application Sharing
Conferencing Server, which knows it is communicating with a Communicator Web Access Server
and converts the bitmaps normally used for Office Communicator viewing into JPEG format
before streaming them to the Communicator Web Access server over RDP/SRTP (there is only
one stream no matter how many users viewing the particular desktop sharing session are
connected to that Communicator Web Access server). The Communicator Web Access server
translates this stream into AJAX DHTML and sends it over HTTPS to each participating browser,
thereby enabling many non-Windows systems to display it properly. (The JPEG conversion that
occurs on the Application Sharing Conferencing Server is the reason why two-party calls
involving a Communicator Web Access client do not route desktop viewing and control data
directly to the other client.)
In addition to viewing shared desktops, users connecting from any supported browser can also
take control of the sharer’s desktop (that is, if permission has been granted by the sharer) without
requiring any special browser add-ins or controls.
In order to view desktop sharing sessions from Internet Explorer or Firefox, the client computer
needs to resolve two DNS CNAMES, as.<CWAserverFQDN> and
download.<CWAserverFQDN>. This requirement exists because these browsers will open no
more than two connections per URL (for example, https://cwa.contoso.com); however, for
optimum performance, desktop viewing requires additional open connections. The two CNAME
records allow the browsers to open four more connections.
If Communicator Web Access is published to the Internet, the external DNS must be able to
resolve these CNAME records to the IP address of the reverse proxy relaying external traffic to
the Communicator Web Access server. Furthermore, because the connections to the
Communicator Web Access server or its associated reverse proxy are over HTTPS, the
certificates on both servers must include the two CNAMES in its Subject Alternate Name (SAN)
field.
To allow users without Active Directory credentials to join the meeting, Communicator Web
Access was also enhanced in Office Communications Server 2007 R2 to support anonymous
sign-in upon receipt of a meeting invitation, and these participants get the same access to the
roster, IM, and desktop sharing capabilities as do authenticated users. If the organization has



                                                                                                  111
published Communicator Web Access to the Internet, then users with any of the supported Web
browsers can view desktop sharing sessions over the Internet.

Add-On for Internet Explorer and Firefox for Windows
If a meeting participant who is using Communicator Web Access wants to share his or her
desktop, he or she must be using Windows XP SP2 or Vista and either Internet Explorer 6 SP2,
Internet Explorer 7, or Firefox 3.0.x with the CWAPlugin.exe add-on installed on it. This add-on
provides the required support for ICE, SRTP/SRTCP, and RDP.
If the user’s computer does not already have this add-on, upon the user’s first attempt to share
their desktop the browser will prompt him or her to download it from the Communicator Web
Access server as shown in the following:




The user interface of the add-on setup program is available in 15 different languages. By default,
the browser’s current language setting will determine the language that the user sees. Users do
not need to have administrative privileges to install the add-in, but on Vista systems, the user
must have User Account Control enabled.
After CWAPlugin.exe is downloaded, it installs and registers a set of files into the user’s Windows
profile. CWAPlugin.exe registers the AppSharingHostClass and AsVersionQueryClass
ActiveX controls in Internet Explorer or the npCwaAppSh.dll plug-in in Firefox.

Note:
    The add-on is not supported on 64-bit versions of Internet Explorer; users of 64-bit
    Windows must launch the 32-bit version of Internet Explorer in order to install and use the
    add-in. The add-on does not install on Windows Server 2008.
Following are the browser management dialog boxes that indicate (in highlight) successful
installation (the one on the left is for Internet Explorer and the right for Firefox).




                                                                                                   112
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).




                                                                                                    113
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 peer-
to-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:

                                                                                              114
v=0
o=- 0 0 IN IP4 192.168.100.20
s=session
c=IN IP4 192.168.100.20
b=CT:99980
t=0 0
m=applicationsharing 4636 TCP/RTP/AVP 127
a=ice-ufrag:Ze3C
a=ice-pwd:s0a6z9xeF6+wQvu6lCDen9oG
a=candidate:1 1 TCP-PASS 2120613887 192.168.100.20 18608 typ host
a=candidate:1 2 TCP-PASS 2120613374 192.168.100.20 18608 typ host
a=candidate:2 1 TCP-ACT 2121006591 192.168.100.20 4636 typ host
a=candidate:2 2 TCP-ACT 2121006078 192.168.100.20 4636 typ host
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80
inline:7Qze/34RrnOBYwHVlcXWGdmlBYX7yvehzzoV4k3p|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:3t/fXZ5Fjho3/lkMea1c2xNhTfJxYGAM2KU/VGdu|2^31|1:1
a=setup:active
a=connection:new
a=rtcp:4636
a=mid:1
a=rtpmap:127 x-data/90000
a=x-applicationsharing-session-id:1
a=x-applicationsharing-role:sharer
a=x-applicationsharing-media-type:rdp
If User2 accepts the invite, his or her Office Communicator client sends back an OK with a list of
ICE candidates. Both clients evaluate the ICE candidate pairs. User1 then sends a new SIP
INVITE message containing the winning IP address for his or her computer, and User2 returns a
200 OK message with the winning IP address for his or her computer. By using this information,
the two Office Communicator clients establish an SRTP session over TCP between the two
negotiated endpoints, and User1 sends an RDP stream that mirrors his or her desktop to User2
over the SRTP channel.


Adding a User to a Desktop Sharing Conference
Continuing on with this same example, User1 needs to add a third participant, User3, to the
existing desktop sharing meeting with User2. (In this example, User3 is also in the same pool as
User1 and User2.) User1 clicks the Invite button, clicks Invite a Contact, and then clicks User3.

                                                                                                115
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.


                                                                                                116
Note:
   In the following diagrams, the SIP ACKs and some other traffic have been skipped for
   readability.




                                                                                          117
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.


                                                                                                  118
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.




                                                                                              119
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.

                                                                                                120
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.


                                                                                                121
Table 1. Supported Browsers

Operating system                                 Browser

Microsoft Windows 2000 with Service Pack 4          Internet Explorer 6.0 with SP1
(SP4)

Windows XP with SP2                                 Internet Explorer 6.0 with SP2
                                                    Internet Explorer 7.0
                                                    Firefox 3.0.X

Windows Vista                                       Internet Explorer 7.0
                                                    Firefox 3.0.X


Macintosh OS 10.3.9                                 Safari 1.3.X
                                                    Firefox 3.0.X

Macintosh OS 10.5.4                                 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




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

                                                                                                122
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         No                            Yes
menus

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)   Yes                           Yes
connectivity

Federation                      Yes                           Yes

Suggestive search               Yes                           No

Outlook contact search          Yes                           No

Global address list (GAL)       Yes, using Address Book       Yes, using Active Directory
contact search                  Server

Desktop sharing                 Yes                           Yes



                                                                                            123
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 non-
domain 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.




                                                                                                124
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.




                                                                                                125
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


                                                                                                   126
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.




                                                                                               127
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.



                                                                                                    128
The data and logic layer consists of the user session, the presence manager, the contact list
manager, the options manager, the conversation manager, the system alert manager, the search
manager, and the component store. In the UI layer, there is a one-to-one relationship between
the UI component and the manager in the data and logic layer. For Example, the system alert
manager controls the UI system alerts and included functions, and the conversation manager
affects the UI conversation window.
A use case example of an IM conversation would use the server communicator (proxy layer), the
user session, the presence manager (that is, to report to the pool that the user state has
changed), and then the component store invokes the conversation manager, which opens a
conversation window. During the course of the conversation, if the user receives a data packet
that needs open a system alert to notify the user of an audio call, the component store will invoke
the system alert manager which then opens a system alert.
In each case where you use the component store to control the UI experience, the headers in the
data packet contain information from Office Communications Server 2007 R2 that determine
which function is being called, while the data and logic layer determines how to respond to the
XML packet header. The previous conversation example is duplicated for each component
manager. The XML packet is received, the XML header indicates the action(s) to be taken, and
the component store either triggers a new conversation instance or adds components to the
existing conversation windows.


Communicator Web Access Audio
There are two basic audio scenarios for Communicator Web Access (2007 R2 release). Both of
the following scenarios enable Communicator Web Access (2007 R2 release) to control audio
calls, although Communicator Web Access (2007 R2 release) clients do not have audio
capability:
   Scenario 1: Enterprise Voice-enabled Communicator Web Access (2007 R2 release)
     user has an incoming voice call. Office Communications Server 2007 R2 forks the call to
     all registered endpoints. The Communicator Web Access (2007 R2 release) endpoint that is
     maintained in the Communicator Web Access (2007 R2 release) data logic layer is a valid
     registered endpoint, but the Communicator Web Access (2007 R2 release) client cannot
     perform audio function. Therefore, when the data logic layer in Communicator Web Access
     (2007 R2 release) receives the call notification, the data logic layer shows the user a system
     alert with call deflection options that are obtained from self-data and the data logic layer
     enables the user to input a custom number. The path through the client is proxy layer, user
     session, component store, system alert manager, and finally the system alert. The data logic
     layer receives the response from the client and passes this data back to Office
     Communications Server 2007 R2, which takes the action dictated by the user. The calling
     party is placed on hold for the amount of time that it takes to respond to the system alert.
     After the data packet from the client is returned to the data logic layer, the data logic layer
     passes the data back to the Office Communications Server 2007 R2 pool for action.
   Scenario 2: Communicator Web Access (2007 R2 release) user with an open instant
     messaging (IM) conference wants to add audio. From an existing IM conference, the

                                                                                                 129
     Communicator Web Access (2007 R2 release) user adds audio. The user selects a number
     from the displayed self-data or the user enters a custom number. The client sends this
     information along with the request to add audio to the Communicator Web Access (2007 R2
     release) data logic layer. The data logic layer signals to the other conference users that
     audio is being added and it takes one of the following actions:
        If the called party is Enterprise Voice, the connection is made to a valid registered
          endpoint or to an Office Communicator instance.
        If the called party is a Communicator Web Access (2007 R2 release) user, the
          Communicator Web Access (2007 R2 release) server invokes the call deflection
          scenario.
Office Communications Server 2007 R2 can call any global or local number that is allowed by the
Communicator Web Access (2007 R2 release) user’s location profile. For example, if the
Communicator Web Access (2007 R2 release) user inputs a telephone number that is not
reachable by Office Communications Server 2007 R2 because of routing restrictions or phone
usages, the call fails.
In This Section
This section contains the following topics:
   Communicator Web Access Audio Scenarios
   Call Deflection Session Initiation Protocol (SIP) Tracing
   Add Audio Session Initiation Protocol (SIP) Tracing


Communicator Web Access Audio Scenarios
Communicator Web Access (2007 R2 release) does not support the initiation of a direct audio call
from the contact list or any direct audio device. Communicator Web Access (2007 R2 release)
supports the following two-party and multiparty audio scenarios. Each scenario is accomplished
with either call deflection or adding audio to an existing conversation. Several scenarios are
outlined to show that Communicator Web Access (2007 R2 release) participates in the scenarios
even though there is no action taken by the Communicator Web Access (2007 R2 release) user.
Communicator Web Access (2007 R2 release) can also add instant messaging (IM) or desktop
sharing to existing audio. However, this action results in two completely different sessions: one
for the original audio and one for the new IM or desktop sharing session. Each scenario is
illustrated as a conversation between an Office Communicator 2007 R2 client (or clients) and a
Communicator Web Access (2007 R2 release) session.

Two-Party Audio Scenario
Receive new two-party audio only call (call deflection): If Office Communicator 2007 R2 calls
a Communicator Web Access (2007 R2 release) user, the Communicator Web Access (2007 R2
release) user sees the audio system alert and can select to redirect the call to a phone device.
The redirected call is sent to the phone device and has no association with Communicator Web
Access (2007 R2 release) after the redirection. The redirection selection list comes from the
Office Communications Server 2007 R2 user self-information data. The user may also enter a


                                                                                                  130
custom number. In either case, Office Communications Server 2007 R2 must be able to place
calls to the redirection number. If the user enters a phone number that is not allowed due to
location profile, phone usages, or route settings, the call fails.
Receive request to add audio conversation to an existing IM-only conversation (call
deflection): Communicator Web Access (2007 R2 release) is in an existing IM conversation with
Office Communicator 2007 R2. Office Communicator 2007 R2 adds audio. Communicator Web
Access (2007 R2 release) receives an audio system alert. Communicator Web Access (2007 R2
release) user can choose to redirect the audio call to a phone device. The redirected call is not
associated with Communicator Web Access 2007 R2 after deflection. The Communicator Web
Access (2007 R2 release) presence does not change to In a Call.
In existing two-party audio conversation and the other user adds IM: Communicator Web
Access (2007 R2 release) is in an existing audio conversation where the Communicator Web
Access (2007 R2 release) user is on cell phone (that is, with no associated conversation window)
with an Office Communicator 2007 R2 user. The Office Communicator 2007 R2 user sees the
Communicator Web Access (2007 R2 release) user in his roster and chooses to add IM.
Communicator Web Access (2007 R2 release) user sees a system alert and a conversation
window opens with the instant message. The audio conversation window and the Communicator
Web Access (2007 R2 release) IM conversation are not associated. There is no connection in
Communicator Web Access between the original audio conversation and the new IM window.
Communicator Web Access (2007 R2 release) user is in an existing two-party audio
conversation and sends IM to the other user: A Communicator Web Access (2007 R2
release) user is in an existing two-party audio conversation with Office Communicator 2007 R2.
The Communicator Web Access (2007 R2 release) user now wants to communicate with the
same Office Communicator 2007 R2 user by using IM. The Communicator Web Access (2007
R2 release) finds the Office Communicator 2007 R2 user in the contact list and clicks to start IM.
The Office Communicator 2007 R2 user sees a new window open for the new IM invitation. The
Office Communicator 2007 R2 user has two windows open with the Communicator Web Access
(2007 R2 release) user. There is no connection in Communicator Web Access between the
original audio conversation and the new IM window.

Conference (Multiparty) Audio Scenario
Initiate three or more party audio-only conference from the contact list (add audio): A
Communicator Web Access (2007 R2 release) user can initiate an audio conference from the
contact list by multi-selecting two or more contacts in the contact list. After choosing the
conference members, the Communicator Web Access (2007 R2 release) user can select the
phone icon, and direct Office Communications Server 2007 R2 to call the selected phone number
to initiate the audio portion of the conference. After the audio call is placed to the Communicator
Web Access (2007 R2 release) user, the other participants are invited to join the audio
conference.
Add audio to existing IM-only conference (add audio): A Communicator Web Access (2007
R2 release) user is in a conference with other users where IM is the only modality. The
Communicator Web Access (2007 R2 release) user wants to add audio to the conference. The
Communicator Web Access (2007 R2 release) user clicks the phone icon to add audio. An audio

                                                                                                131
setup pane appears where the Communicator Web Access (2007 R2 release) user selects the
self-information phone number he wants to use. The Office Communicator Server 2007 R2 A/V
conferencing server initiates the audio call to the Communicator Web Access user and sends
audio invitations to the other participants.
Receive new audio-only conference invitation (call deflection): Communicator Web Access
(2007 R2 release) user can receive and join an audio-only conference. The Communicator Web
Access (2007 R2 release) user can select which phone number she wants to use for the
conference by selecting the number from the conference system alert. A conversation window
appears with all of the conference participants in the roster. The Communicator Web Access
(2007 R2 release) user’s phone rings and the user can communicate by using audio with all of
the conference participants.
Receive request to add audio to existing IM-only conference (call deflection): A
Communicator Web Access (2007 R2 release) user is in an existing IM-only conference and a
participant in the conference adds audio. The Communicator Web Access (2007 R2 release)
user receives an audio system alert. The Communicator Web Access (2007 R2 release) user
accepts the call by specifying a self-information phone number to receive the call. There is no
connection between the original IM conversation and the new audio call.
Receive new audio and IM conference invitation (call deflection): The Communicator Web
Access (2007 R2 release) user receives an invitation to join a conference with IM and audio. The
system alert is a conference system alert that enables the Communicator Web Access (2007 R2
release) user to join the conference. In the conference window, under join audio conference,
the Communicator Web Access (2007 R2 release) user selects one of the self-information phone
numbers from which he wants to redirect the audio call. IM is also enabled.
Receive new audio, IM, and application sharing conference invitation (call deflection):
Other than the addition of the desktop sharing feature, this scenario is identical in function to the
previous scenario.

Escalation
In an existing two-party audio conversation and the Office Communicator 2007 R2 user
adds another participant: A Communicator Web Access (2007 R2 release) user is in an
existing two-party audio conversation with an Office Communicator 2007 R2 user. The Office
Communicator 2007 R2 user is using the rich client Voice over Internet Protocol (VoIP) functions
and the Communicator Web Access (2007 R2 release) user is on a phone device (that is, there is
no Communicator Web Access (2007 R2 release) UI associated with the call). The Office
Communicator 2007 R2 user sees the Communicator Web Access (2007 R2 release) user in her
roster as joined to the audio conversation. The Office Communicator 2007 R2 user chooses to
add another participant to the audio conversation. The other participant is successfully added
and joined to the audio conversation. All three participants appear in the Office Communicator
2007 R2 user’s roster and they can all hear each other. In this scenario, the Communicator Web
Access (2007 R2 release) user takes no action and the Office Communications Server 2007 R2
A/V conferencing server is controlling the audio bridge that allows the audio conference to reach
all participants.


                                                                                                   132
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 two-
party audio conversation with an Office Communicator 2007 R2 user. The Communicator Web
Access (2007 R2 release) user is on a phone device and the Office Communicator 2007 R2 user
is terminating audio through Office Communicator 2007 R2. The Office Communicator 2007 R2
user sees the Communicator Web Access (2007 R2 release) user in the roster. The Office
Communicator 2007 R2 user chooses to add desktop sharing to the conversation. The
Communicator Web Access (2007 R2 release) user sees a system alert for desktop sharing and
clicks the system alert to accept the invitation. The Communicator Web Access (2007 R2
release) user sees a browser open with the Office Communicator 2007 R2 user and himself listed
in the roster. The audio call is still active and there is no connection between the audio call and
the desktop sharing session.
The Office Communicator 2007 R2 user now adds another participant: The Communicator
Web Access (2007 R2 release) user is using a phone device for an audio conversation with the
Office Communicator 2007 R2 user and has a browser window open for desktop sharing with the
same Office Communicator 2007 R2 user. Now a third person is invited to the application sharing
session. The third person is joined to the audio conversation and desktop sharing session. All
three users can speak with each other. As noted previously, the Communicator Web Access
(2007 R2 release) user takes no action and the audio conversation and the desktop sharing
session have no connection.
The Communicator Web Access (2007 R2 release) user adds another participant: The
Communicator Web Access (2007 R2 release) user adds another participant to the audio
conversation and desktop sharing session. The Focus Factory knows that audio and desktop
sharing are enabled, so the Focus Factory sends the appropriate invitations to the new
participant. The new participant is joined to the audio conversation and desktop sharing session.
Communicator Web Access (2007 R2 release) still does not connect the audio conversation and
the desktop sharing session.


Call Deflection Session Initiation Protocol (SIP) Tracing
The following Session Initiation Protocol (SIP) packets illustrate the pertinent data between an
Office Communications Server 2007 R2 pool Front End Server and a Communicator Web Access
(2007 R2 release) server for the call deflection scenario. The Communicator Web Access (2007
R2 release) user deflects the incoming call to voice mail.
All incoming calls to Communicator Web Access (2007 R2 release) sessions meet this scenario.
An audio call is forked to all valid endpoints. Regardless of the source of the call, if the incoming
call is directed at the Communicator Web Access (2007 R2 release) session, the deflection
scenario is valid.

Call Deflection SIP Tracing Scenario
In this scenario, a Communicator Web Access (2007 R2 release) session exists. User1 is on
Communicator Web Access (2007 R2 release) and User2 is on Office Communicator 2007 R2.
User2 on Office Communicator 2007 R2 initiates an audio call to a phone number. An invitation
from Office Communicator 2007 R2 is sent to the pool Front End Server.

                                                                                                  133
TL_INFO(TF_PROTOffice Communicator 2007 R2 OL)
[1]0A2C.0A9C::06/22/2009-17:58:48.922.0009935d
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018A2F9
Direction: incoming
Peer: 192.0.2.143:1331
Message-Type: request
Start-Line: INVITE sip:+12065550101@litwareinc.com;user=phone SIP/2.0
From: <sip:User2@litwareinc.com>;tag=ea1b3cab6b;epid=213be0ea4a
To: <sip:+12065550101@litwareinc.com;user=phone>
CSeq: 1 INVITE
Call-ID: a9c2eb61a37944979e6ba90adbf869ce
Via: SIP/2.0/TLS 192.0.2.143:1331
Max-Forwards: 70
Contact: <sip:User2@litwareinc.com;opaque=user:epid:Ub31lldjtFyGH5-
ijiRSAgAA;gruu>
User-Agent: UCCAPI/3.5.6907.9 Office Communicator 2007 R2 /3.5.6907.34
(Microsoft Office Communicator 2007 R2)
Ms-Conversation-ID: AcnzYxWcvyhU/nzkQQK09Es13ht5ug==
Supported: timer
Supported: histinfo
Supported: ms-safe-transfer
Supported: ms-sender
Supported: ms-early-media
Supported: Replaces
Supported: 100rel
ms-keep-alive: UAC;hop-hop=yes
Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REfront end R, NOTIFY,
BENOTIFY, OPTIONS
P-Preferred-Identity: <sip:User2@litwareinc.com>, <tel:+14255550190>
Supported: ms-conf-invite
Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications
Service", opaque="24C84179", targetname="sip/ocs.litwareinc.com",
crand="2137c1d9", cnum="73",


                                                                        134
response="602306092a864886f71201020201011100ffffffff1e132d0f694dca10627
59f1ba2b2538c"
Content-Type: multipart/alternative;boundary="----
=_NextPart_000_0A41_01C9F328.696A8600"
Content-Length: 4786
Message-Body: ------=_NextPart_000_0A41_01C9F328.696A8600
Content-Type: application/sdp
$$end_record
The pool server determines that the phone number is a contact, and that the only registered
endpoint is Communicator Web Access (2007 R2 release). The pool Front End Server sends the
invitation to Communicator Web Access (2007 R2 release). In a situation where there is more
than one registered endpoint, the Front End Server forks the call to all valid endpoints. In this
case, Communicator Web Access (2007 R2 release) is the only endpoint.
TL_INFO(TF_PROTOffice Communicator 2007 R2 OL)
[1]0A2C.0A9C::06/22/2009-17:58:48.953.0009939f
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018A302
Direction: outgoing
Peer: cwa.litwareinc.com:5061
Message-Type: request
Start-Line: INVITE sip:cwa.litwareinc.com:5061;transport=Tls;ms-
opaque=303a446bf296e5e2 SIP/2.0
From: "User2"<sip:User2@litwareinc.com>;tag=ea1b3cab6b;epid=213be0ea4a
To: <sip:+12065550101@litwareinc.com;user=phone>;epid=454BF77D78
CSeq: 1 INVITE
Call-ID: a9c2eb61a37944979e6ba90adbf869ce
ms-user-data: ms-publiccloud=true;ms-federation=true
Record-Route:
<sip:ocs.litwareinc.com:5061;transport=tls;opaque=state:T:F;lr>;tag=04E
32C63BB6B7CF14891AD3423F629A0
Via: SIP/2.0/TLS
192.168.5.28:2507;branch=z9hG4bK41780D13.6D1B53BD01D5FDC8;branched=TRUE
Max-Forwards: 69
ms-application-via: backend_token;ms-server=ocs.litwareinc.com;ms-
pool=ocs.litwareinc.com;ms-application=AB072FF0-C918-424c-AC12-
7C100E91front end 3E

                                                                                              135
Content-Length: 4786
Via: SIP/2.0/TLS 192.0.2.143:1331;ms-received-port=1331;ms-received-
cid=58200
P-Asserted-Identity:
"User2"<sip:User2@litwareinc.com>,<tel:+14255550190>
Contact: <sip:User2@litwareinc.com;opaque=user:epid:Ub31lldjtFyGH5-
ijiRSAgAA;gruu>
User-Agent: UCCAPI/3.5.6907.9 Office Communicator 2007 R2 /3.5.6907.34
(Microsoft Office Communicator 2007 R2)
Ms-Conversation-ID: AcnzYxWcvyhU/nzkQQK09Es13ht5ug==
Supported: timer
Supported: histinfo
Supported: ms-safe-transfer
Supported: ms-sender
Supported: ms-early-media
Supported: Replaces
Supported: 100rel
ms-keep-alive: UAC;hop-hop=yes
Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REfront end R, NOTIFY,
BENOTIFY, OPTIONS
Supported: ms-conf-invite
Content-Type: multipart/alternative;boundary="----
=_NextPart_000_0A41_01C9F328.696A8600"
History-Info: <sip:User1@litwareinc.com>;index=1
Message-Body: ------=_NextPart_000_0A41_01C9F328.696A8600
Content-Type: application/sdp
$$end_record
The Front End Server sends 101 Progress Report to the caller (that is, on Office Communicator
2007 R2).
TL_INFO(TF_PROTOffice Communicator 2007 R2 OL)
[0]0A2C.0E7C::06/22/2009-17:58:48.953.000993fb
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018A306
Direction: outgoing;source="local"
Peer: 192.0.2.143:1331

                                                                                            136
Message-Type: response
Start-Line: SIP/2.0 101 Progress Report
From: "User2"<sip:User2@litwareinc.com>;tag=ea1b3cab6b;epid=213be0ea4a
To: <sip:+12065550101@litwareinc.com;user=phone>
CSeq: 1 INVITE
Call-ID: a9c2eb61a37944979e6ba90adbf869ce
Proxy-Authentication-Info: Kerberos
rspauth="602306092A864886F71201020201011100FFFFFFFF356BB0D9D7DF7A14FB5F
5B03B945C688", srand="ED8D8237", snum="118", opaque="24C84179",
qop="auth", targetname="sip/ocs.litwareinc.com", realm="SIP
Communications Service"
Content-Length: 0
Via: SIP/2.0/TLS 192.0.2.143:1331;ms-received-port=1331;ms-received-
cid=58200
ms-diagnostics: 13004;reason="Request was proxied to one or more
registered
endpoints";source="ocs.litwareinc.com";appName="InboundRouting"
Server: InboundRouting/3.5.0.0
Message-Body: –
$$end_record
The Front End Server receives 303 Proxy Should Redirect message from the Communicator Web
Access (2007 R2 release) server. This is the result of the Communicator Web Access (2007 R2
release) user selecting the redirect to voice mail option in the system alert.
TL_INFO(TF_PROTOffice Communicator 2007 R2 OL)
[1]0A2C.059C::06/22/2009-17:59:01.766.0009a336
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018A485
Direction: incoming
Peer: cwa.litwareinc.com:5061
Message-Type: response
Start-Line: SIP/2.0 303 Proxy Should Redirect
From: "User2"<sip:User2@litwareinc.com>;tag=ea1b3cab6b;epid=213be0ea4a
To:
"User1"<sip:+12065550101@litwareinc.com;user=phone>;tag=ba51cb6d68;epid
=454BF77D78
CSeq: 1 INVITE
                                                                                       137
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-received-
cid=58200
CONTACT: <sip:User1@litwareinc.com;opaque=app:voicemail>
CONTENT-LENGTH: 0
SERVER: RTCC/3.5.0.0 CWA/3.5.0.0
Message-Body: –
$$end_record
The Front End Server sends ACK for the 303 message to Communicator Web Access (2007 R2
release) to notify the Communicator Web Access (2007 R2 release) user that the call was
actually redirected to voice mail by the Front End Server.
TL_INFO(TF_PROTOffice Communicator 2007 R2 OL)
[1]0A2C.059C::06/22/2009-17:59:01.766.0009a34d
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018A486
Direction: outgoing;source="local"
Peer: cwa.litwareinc.com:5061
Message-Type: request
Start-Line: ACK sip:cwa.litwareinc.com:5061;transport=Tls;ms-
opaque=303a446bf296e5e2 SIP/2.0
From: "User2"<sip:User2@litwareinc.com>;tag=ea1b3cab6b;epid=213be0ea4a
To:
"User1"<sip:+12065550101@litwareinc.com;user=phone>;tag=ba51cb6d68;epid
=454BF77D78
CSeq: 1 ACK
Call-ID: a9c2eb61a37944979e6ba90adbf869ce
Via: SIP/2.0/TLS
192.168.5.28:2507;branch=z9hG4bK41780D13.6D1B53BD01D5FDC8;branched=FALS
E
Max-Forwards: 70
Content-Length: 0
Message-Body: –
$$end_record


                                                                                     138
Add Audio Session Initiation Protocol (SIP) Tracing
The following Session Initiation Protocol (SIP) trace packets illustrate the call flows to accomplish
the Communicator Web Access (2007 R2 release) Add Audio scenario.
The initial state is that User1 and User2 are in an instant messaging (IM) session and User1 asks
to add audio to the session. User1 is using Communicator Web Access (2007 R2 release) and
User2 is using Office Communicator 2007 R2.

Note:
    Example packets have been redacted to increase clarity.
Communicator Web Access (2007 R2 release) User1 sends a SERVICE packet to ask for the
conferencing capabilities of the Office Communications Server 2007 R2.


TL_INFO(TF_PROTOCOL) [1]0A2C.059C::06/22/2009-18:18:42.695.0009ef1d
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record Peer: cwa.litwareinc.com:3380
Instance-Id: 0018CF11
Direction: incoming
Message-Type: request
Start-Line: SERVICE
sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory SIP/2.0
From: <sip:User1@litwareinc.com>;epid=B90980A18B;tag=7fc74f8252
To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory>
CSeq: 1500 SERVICE
Call-ID: 5e652d08e0da4327b873797f1e15ab7d
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bKd8b3b93f
CONTENT-LENGTH: 395
USER-AGENT: RTCC/3.5.0.0 CWA/3.5.0.0
CONTENT-TYPE: application/cccp+xml
Message-Body: <?xml version="1.0" encoding="utf-8"?><request
requestId="1" from="sip:User1@litwareinc.com"
to="sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory"
C3PVersion="1"
xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions
" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions"
xmlns="urn:ietf:params:xml:ns:cccp"><getConferencingCapabilities
/></request>
$$end_record

                                                                                                  139
The pool server responds with the capability set.


TL_INFO(TF_PROTOCOL) [1]0A2C.0F78::06/22/2009-18:18:42.695.0009ef2c
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018CF12
Direction: outgoing;source="local"
Peer: cwa.litwareinc.com:3380
Message-Type: response
Start-Line: SIP/2.0 200 OK
From: "User1<sip:User1@litwareinc.com>;epid=B90980A18B;tag=7fc74f8252
To:
<sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory>;tag=04E32C
63BB6B7CF14891AD3423F629A0
CSeq: 1500 SERVICE
Call-ID: 5e652d08e0da4327b873797f1e15ab7d
Content-Length: 2089
Via: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bKd8b3b93f;ms-received-
port=3380;ms-received-cid=136F00
Content-Type: application/cccp+xml
$$end_record




Communicator Web Access (2007 R2 release) sends a SERVICE request to get the conference
key.


TL_INFO(TF_PROTOCOL) [1]0A2C.059C::06/22/2009-18:18:43.335.0009f028
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018CF6B
Direction: incoming
Peer: cwa.litwareinc.com:3380
Message-Type: request
Start-Line: SERVICE
sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory SIP/2.0

                                                                                     140
From: <sip:User1@litwareinc.com>;epid=B90980A18B;tag=44f970267e
To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory>
CSeq: 1501 SERVICE
Call-ID: a44fe317039844478b3879e2dfeb66f2
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bK5fb7f10
CONTENT-LENGTH: 384
USER-AGENT: RTCC/3.5.0.0 CWA/3.5.0.0
CONTENT-TYPE: application/cccp+xml
Message-Body: <?xml version="1.0" encoding="utf-8"?><request
requestId="2" from="sip:User1@litwareinc.com"
to="sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory"
C3PVersion="1"
xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions
" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions"
xmlns="urn:ietf:params:xml:ns:cccp"><getEncryptionKey /></request>
$$end_record


The pool server (that is, the conf:focusfactory) responds with the key.


TL_INFO(TF_PROTOCOL) [1]0A2C.059C::06/22/2009-18:18:43.335.0009f037
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018CF6C
Direction: outgoing;source="local"
Peer: cwa.litwareinc.com:3380
Message-Type: response
Start-Line: SIP/2.0 200 OK
From: "User1<sip:User1@litwareinc.com>;epid=B90980A18B;tag=44f970267e
To:
<sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory>;tag=04E32C
63BB6B7CF14891AD3423F629A0
CSeq: 1501 SERVICE
Call-ID: a44fe317039844478b3879e2dfeb66f2
Content-Length: 1893



                                                                          141
Via: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bK5fb7f10;ms-received-
port=3380;ms-received-cid=136F00
Content-Type: application/cccp+xml
$$end_record


Communicator Web Access (2007 R2 release) requests that a conference be created.
TL_INFO(TF_PROTOCOL) [1]0A2C.059C::06/22/2009-18:18:43.663.0009f07b
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018CF87
Direction: incoming
Peer: cwa.litwareinc.com:3380
Message-Type: request
Start-Line: SERVICE
sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory SIP/2.0
From: <sip:User1@litwareinc.com>;epid=B90980A18B;tag=435df06b43
To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory>
CSeq: 1502 SERVICE
Call-ID: 0c7c4e19ed654a39843622a26395cdc2
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bKa9722575
CONTENT-LENGTH: 1708
USER-AGENT: RTCC/3.5.0.0 CWA/3.5.0.0
CONTENT-TYPE: application/cccp+xml
$$end_record
The server (that is, the conf:focusfactory) responds with the conference Uniform Resource
Identifier (URI).
TL_INFO(TF_PROTOCOL) [1]0A2C.0F78::06/22/2009-18:18:43.663.0009f08a
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018CF88
Direction: outgoing;source="local"
Peer: cwa.litwareinc.com:3380
Message-Type: response
Start-Line: SIP/2.0 200 OK


                                                                                            142
From: "User1<sip:User1@litwareinc.com>;epid=B90980A18B;tag=435df06b43
To:
<sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory>;tag=04E32C
63BB6B7CF14891AD3423F629A0
CSeq: 1502 SERVICE
Call-ID: 0c7c4e19ed654a39843622a26395cdc2
Content-Length: 1262
Via: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bKa9722575;ms-received-
port=3380;ms-received-cid=136F00
Content-Type: application/cccp+xml
Message-Body: <response xmlns="urn:ietf:params:xml:ns:cccp"
<addConference>
<conference-info xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQ
XXSHEUZ2M0KVHY1C006F0T5D" state="partial" version="1"/>
</addConference>
</response>
$$end_record
Communicator Web Access (2007 R2 release) sends a SERVICE to request information for
conferences that are owned by User1 (with key).
TL_INFO(TF_PROTOCOL) [1]0A2C.059C::06/22/2009-18:18:43.976.0009f09b
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018CF91
Direction: incoming
Peer: cwa.litwareinc.com:3380
Message-Type: request
Start-Line: SERVICE
sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory SIP/2.0
From: <sip:User1@litwareinc.com>;epid=B90980A18B;tag=3b9871199e
To: <sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory>
CSeq: 1503 SERVICE
Call-ID: a24d629e06d24842a91fbafb752fc8c6
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bK9ac7efa1
CONTENT-LENGTH: 1329

                                                                                       143
USER-AGENT: RTCC/3.5.0.0 CWA/3.5.0.0
CONTENT-TYPE: application/cccp+xml
$$end_record
The pool server (that is, the conf:focusfactory) responds with encrypted information.
TL_INFO(TF_PROTOCOL) [1]0A2C.0F78::06/22/2009-18:18:43.976.0009f0aa
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018CF92
Direction: outgoing;source="local"
Peer: cwa.litwareinc.com:3380
Message-Type: response
Start-Line: SIP/2.0 200 OK
From: "User1<sip:User1@litwareinc.com>;epid=B90980A18B;tag=3b9871199e
To:
<sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory>;tag=04E32C
63BB6B7CF14891AD3423F629A0
CSeq: 1503 SERVICE
Call-ID: a24d629e06d24842a91fbafb752fc8c6
Content-Length: 4916
Via: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bK9ac7efa1;ms-received-
port=3380;ms-received-cid=136F00
Content-Type: application/cccp+xml
Message-Body: <response xmlns="urn:ietf:params:xml:ns:cccp"
from="sip:User1@litwareinc.com;gruu;opaque=app:conf:focusfactory"
to="sip:User1@litwareinc.com" code="success">
<getConference>
<conference-info xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQ
XXSHEUZ2M0KVHY1C006F0T5D" state="full" version="1">
<conference-description>
<conf-uris>
<entry>
<uri>http://schemas.microsoft.com/2008/05/confxmlenc#content</uri>
<purpose>web-internal</purpose>
</encrypted-uri>
</entry>
                                                                                        144
</conf-uris>
<conference-id
xmlns="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions">W52
Q3KCQXXSHEUZ2M0KVHY1C006F0T5D</conference-id>
$$end_record
Communicator Web Access (2007 R2 release) sends an INVITE to cause the Focus Factory to
join User1 to the conference by calling her.
TL_INFO(TF_PROTOCOL) [1]0A2C.059C::06/22/2009-18:18:44.413.0009f0d0
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018CFA6
Direction: incoming
Peer: cwa.litwareinc.com:3380
Message-Type: request
Start-Line: INVITE
sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ2
M0KVHY1C006F0T5D SIP/2.0
From: "User1<sip:User1@litwareinc.com>;epid=B90980A18B;tag=44aeda4dc
To:
<sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ
2M0KVHY1C006F0T5D>
CSeq: 1504 INVITE
Call-ID: 6d078771-8bad-41e9-a085-22323848d0c7
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bK5cace8f5
CONTACT: <sip:User1@litwareinc.com;opaque=user:epid:5C9sAvigE1KvpTRT-
qTSSgAA;gruu>;text;audio;video;applicationsharing
CONTENT-LENGTH: 947
SUPPORTED: ms-dialog-route-set-update
SUPPORTED: gruu-10
SUPPORTED: timer
SUPPORTED: 100rel
USER-AGENT: RTCC/3.5.0.0 CWA/3.5.0.0
CONTENT-TYPE: application/cccp+xml
ALLOW: UPDATE
Session-Expires: 1800

                                                                                      145
Min-SE: 90
ALLOW: Ack, Cancel, Bye,Invite,Message,Info,Service,Options,BeNotify
Message-Body: <request
  requestId="5"
  from="sip:User1@litwareinc.com"


to="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSH
EUZ2M0KVHY1C006F0T5D"
  C3PVersion="1"
xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions
" xmlns="urn:ietf:params:xml:ns:cccp">
  <addUser>
     <conferenceKeys


confEntity="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q
3KCQXXSHEUZ2M0KVHY1C006F0T5D" />
     <user
       entity="sip:User1@litwareinc.com"
xmlns="urn:ietf:params:xml:ns:conference-info">
       <display-text>User1)</display-text>
       <roles>
          <entry>attendee</entry>
       </roles>
       <endpoint
          entity="{0ef76ba1-7890-44b3-aeaa-3a26e3e0e29e}"
          msci:endpoint-
uri="sip:User1@litwareinc.com;opaque=user:epid:5C9sAvigE1KvpTRT-
qTSSgAA;gruu">
          <joining-method>dialed-in</joining-method>
       </endpoint>
     </user>
  </addUser>
</request>
$$end_record
After User1 is in the conference, Communicator Web Access (2007 R2 release) invites User2 to
the conference.

                                                                                          146
TL_INFO(TF_PROTOCOL) [1]0A2C.059C::06/22/2009-18:18:46.414.0009f842
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018D038
Direction: incoming
Peer: cwa.litwareinc.com:3380
Message-Type: request
Start-Line: INVITE
sip:User2@litwareinc.com;opaque=user:epid:Ub31lldjtFyGH5-ijiRSAgAA;gruu
SIP/2.0
From: "User1<sip:User1@litwareinc.com>;epid=B90980A18B;tag=29ff66d021
To: <sip:User2@litwareinc.com;opaque=user:epid:Ub31lldjtFyGH5-
ijiRSAgAA;gruu>
CSeq: 1513 INVITE
Call-ID: 784928e7-ab13-4853-a0f0-ba1cf93192b3
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 192.0.2.17:3380;branch=z9hG4bK7bfeabdf
CONTACT: <sip:User1@litwareinc.com;opaque=user:epid:5C9sAvigE1KvpTRT-
qTSSgAA;gruu>;text;audio;video;applicationsharing
CONTENT-LENGTH: 247
SUPPORTED: ms-dialog-route-set-update
SUPPORTED: gruu-10
SUPPORTED: 100rel
USER-AGENT: RTCC/3.5.0.0 CWA/3.5.0.0
CONTENT-TYPE: application/ms-conf-invite+xml
ALLOW: UPDATE
Ms-Conversation-ID: b45631df64ae40b880183043ca424cef
ALLOW: Ack, Cancel, Bye,Invite
Message-Body: <Conferencing version="2.0">
  <focus-
uri>sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSH
EUZ2M0KVHY1C006F0T5D</focus-uri>
  <subject />
  <im available="true" additional="false">
    <first-im />


                                                                        147
  </im>
</Conferencing>
$$end_record
User2 sends the INVITE to the Focus requesting to join the conference.
TL_INFO(TF_PROTOCOL) [1]0A2C.0A9C::06/22/2009-18:18:46.429.0009f8d1
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018D048
Direction: incoming
Peer: 192.0.2.143:1331
Message-Type: request
Start-Line: INVITE
sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ2
M0KVHY1C006F0T5D SIP/2.0
From: <sip:User2@litwareinc.com>;tag=9dde023949;epid=213be0ea4a
To:
<sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ
2M0KVHY1C006F0T5D>
CSeq: 1 INVITE
Call-ID: b4a3fe5a51c84d8e960874dbc88d3a68
Via: SIP/2.0/TLS 192.0.2.143:1331
Max-Forwards: 70
Contact: <sip:User2@litwareinc.com;opaque=user:epid:Ub31lldjtFyGH5-
ijiRSAgAA;gruu>
User-Agent: UCCAPI/3.5.6907.9 OC/3.5.6907.34 (Microsoft Office
Communicator 2007 R2)
Supported: timer
Supported: histinfo
Supported: ms-safe-transfer
Supported: ms-sender
Supported: ms-early-media
ms-keep-alive: UAC;hop-hop=yes
Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY,
OPTIONS
Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications
Service", opaque="24C84179", targetname="sip/u2r2ocs.litwareinc.com",

                                                                         148
crand="20d8c1a6", cnum="210",
response="602306092a864886f71201020201011100ffffffffe5ad48b79ad8d562fa8
656e4d7e23dd3"
Content-Type: application/cccp+xml
Content-Length: 736
Message-Body: <?xml version="1.0"?>
<request xmlns="urn:ietf:params:xml:ns:cccp"
xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions"
C3PVersion="1"
to="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSH
EUZ2M0KVHY1C006F0T5D" from="sip:User2@litwareinc.com"
requestId="0"><addUser><conferenceKeys
confEntity="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q
3KCQXXSHEUZ2M0KVHY1C006F0T5D"/><ci:user
xmlns:ci="urn:ietf:params:xml:ns:conference-info"
entity="sip:User2@litwareinc.com"><ci:roles><ci:entry>attendee</ci:entr
y></ci:roles><ci:endpoint entity="{AB2AAE94-59A9-494C-9537-
948C1182F595}"
xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions
"/></ci:user></addUser></request>
$$end_record
Session progress 200 OK and an invitation dialog box is created.


TL_INFO(TF_PROTOCOL) [0]0A2C.059C::06/22/2009-18:18:46.429.0009f96d
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018D052
Direction: outgoing;source="local"
Peer: 192.0.2.143:1331
Message-Type: response
Start-Line: SIP/2.0 200 Invite dialog created
From: "User2"<sip:User2@litwareinc.com>;tag=9dde023949;epid=213be0ea4a
To:
<sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ
2M0KVHY1C006F0T5D>;tag=4C0E0080
CSeq: 1 INVITE
Call-ID: b4a3fe5a51c84d8e960874dbc88d3a68


                                                                       149
ms-keep-alive: UAS; tcp=no; hop-hop=yes; end-end=no; timeout=300
Record-Route:
<sip:u2r2ocs.litwareinc.com:5061;transport=tls;opaque=state:F:T:Ci.R582
00;lr;ms-route-sig=he2YH1WGjERb6-ZiSxIlSV7l4oPU-dL1uKOYGPpwAA>
Proxy-Authentication-Info: Kerberos
rspauth="602306092A864886F71201020201011100FFFFFFFFE6E06C49850126316052
75E9A1B82B0B", srand="71F9906F", snum="285", opaque="24C84179",
qop="auth", targetname="sip/u2r2ocs.litwareinc.com", realm="SIP
Communications Service"
Content-Length: 1322
Via: SIP/2.0/TLS 192.0.2.143:1331;ms-received-port=1331;ms-received-
cid=58200
Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE
Contact:
<sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ
2M0KVHY1C006F0T5D>;isfocus
Content-Type: application/cccp+xml
Session-Expires: 7200;refresher=uac
Require: timer
Supported: timer
Message-Body: <response xmlns="urn:ietf:params:xml:ns:cccp"
xmlns:msacp="http://schemas.microsoft.com/rtc/2005/08/acpconfinfoextens
ions"
xmlns:msas="http://schemas.microsoft.com/rtc/2005/08/asconfinfoextensio
ns"
xmlns:tns="http://schemas.microsoft.com/rtc/2005/08/avconfinfoextension
s" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions"
xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions
"
xmlns:msdata="http://schemas.microsoft.com/rtc/2005/08/dataconfinfoexte
nsions"
xmlns:msim="http://schemas.microsoft.com/rtc/2005/08/imconfinfoextensio
ns"
xmlns:msci2="http://schemas.microsoft.com/rtc/2008/12/confinfoextension
s"
xmlns:msendpt="http://schemas.microsoft.com/rtc/2008/12/endpointinfoext
ensions" xmlns:ci="urn:ietf:params:xml:ns:conference-info"
xmlns:cis="urn:ietf:params:xml:ns:conference-info-separator"
xmlns:msls="urn:ietf:params:xml:ns:msls" requestId="0" C3PVersion="1"
                                                                        150
from="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXX
SHEUZ2M0KVHY1C006F0T5D" to="sip:User2@litwareinc.com" code="success">
<addUser>
<conferenceKeys
confEntity="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q
3KCQXXSHEUZ2M0KVHY1C006F0T5D"/>
<ci:user entity="sip:User2@litwareinc.com">
<ci:roles>
<ci:entry>attendee</ci:entry>
</ci:roles>
</ci:user>
</addUser>
</response>
$$end_record
INFO from User2 to the Focus with key.
TL_INFO(TF_PROTOCOL) [1]0A2C.0A9C::06/22/2009-18:18:46.460.0009f9a3
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018D05B
Direction: incoming
Peer: 192.0.2.143:1331
Message-Type: request
Start-Line: INFO
sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ2
M0KVHY1C006F0T5D SIP/2.0
From: <sip:User2@litwareinc.com>;tag=9dde023949;epid=213be0ea4a
To:
<sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ
2M0KVHY1C006F0T5D>;tag=4C0E0080
CSeq: 2 INFO
Call-ID: b4a3fe5a51c84d8e960874dbc88d3a68
Via: SIP/2.0/TLS 192.0.2.143:1331
Max-Forwards: 70
Route:
<sip:u2r2ocs.litwareinc.com:5061;transport=tls;opaque=state:F:T:Ci.R582
00;lr;ms-route-sig=he2YH1WGjERb6-ZiSxIlSV7l4oPU-dL1uKOYGPpwAA>

                                                                        151
User-Agent: UCCAPI/3.5.6907.9 OC/3.5.6907.34 (Microsoft Office
Communicator 2007 R2)
Supported: ms-dialog-route-set-update
Supported: timer
Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications
Service", opaque="24C84179", targetname="sip/u2r2ocs.litwareinc.com",
crand="ad9e7d8b", cnum="215",
response="602306092a864886f71201020201011100ffffffff981e07e5ea0f130ba57
cc2ed92da58b2"
Content-Type: application/cccp+xml
Content-Length: 1285
Message-Body: <?xml version="1.0"?>
$$end_record
202 accepted from User2 to conf:focus.
TL_INFO(TF_PROTOCOL) [1]0A2C.0F80::06/22/2009-18:18:46.460.0009f9b1
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018D05C
Direction: outgoing;source="local"
Peer: 192.0.2.143:1331
Message-Type: response
Start-Line: SIP/2.0 202 Accepted
From: <sip:User2@litwareinc.com>;tag=9dde023949;epid=213be0ea4a
To:
<sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ
2M0KVHY1C006F0T5D>;tag=4C0E0080
CSeq: 2 INFO
Call-ID: b4a3fe5a51c84d8e960874dbc88d3a68
Proxy-Authentication-Info: Kerberos
rspauth="602306092A864886F71201020201011100FFFFFFFFE0E9F269C783FF8AECB6
BF67028DDC0F", srand="89D8A03F", snum="287", opaque="24C84179",
qop="auth", targetname="sip/u2r2ocs.litwareinc.com", realm="SIP
Communications Service"
Via: SIP/2.0/TLS 192.0.2.143:1331;ms-received-port=1331;ms-received-
cid=58200
Content-Length: 0


                                                                       152
Message-Body: –
$$end_record
The pool server (that is, conf:focus) sends out INFO with details of the conference and the
participants.
TL_INFO(TF_PROTOCOL) [1]0A2C.0F80::06/22/2009-18:18:46.460.0009f9f5
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin
_record
Instance-Id: 0018D065
Direction: outgoing;source="local"
Peer: 192.0.2.143:1331
Message-Type: request
Start-Line: INFO sip:192.0.2.143:1331;transport=tls;ms-
opaque=6fe2ccfaed;ms-received-cid=58200;grid SIP/2.0
From:
<sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXXSHEUZ
2M0KVHY1C006F0T5D>;tag=4C0E0080
To: <sip:User2@litwareinc.com>;tag=9dde023949;epid=213be0ea4a
CSeq: 8 INFO
Call-ID: b4a3fe5a51c84d8e960874dbc88d3a68
Via: SIP/2.0/TLS
192.168.5.28:5061;branch=z9hG4bK2CBE513C.E418D77A2630C466;branched=FALS
E
Proxy-Authentication-Info: Kerberos
rspauth="602306092A864886F71201020201011100FFFFFFFF01B326A85CB03EB72670
27B3BCF95F4F", srand="BFC9387F", snum="289", opaque="24C84179",
qop="auth", targetname="sip/u2r2ocs.litwareinc.com", realm="SIP
Communications Service"
Max-Forwards: 70
Content-Length: 7893
Supported: ms-dialog-route-set-update
Content-Type: application/cccp+xml
Message-Body: <response xmlns="urn:ietf:params:xml:ns:cccp"
from="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQXX
SHEUZ2M0KVHY1C006F0T5D" to="sip:User2@litwareinc.com" code="success">
<getConference>




                                                                                              153
<ci:conference-info
entity="sip:User1@litwareinc.com;gruu;opaque=app:conf:focus:id:W52Q3KCQ
XXSHEUZ2M0KVHY1C006F0T5D"
</msci:cms-data>
</msci:conference-key>
<msci:admission-policy>anonymous</msci:admission-policy>
<msci:notification-data/>
</ci:conference-description>
<ci:users state="full">
<ci:user entity="sip:User1@litwareinc.com" state="full">
<ci:display-text>User1</ci:display-text>
<ci:roles>
<ci:entry>presenter</ci:entry>
</ci:roles>
<ci:endpoint entity="{0ef76ba1-7890-44b3-aeaa-3a26e3e0e29e}"
msci:session-type="focus"
</ci:endpoint>
</ci:user>
<ci:user entity="sip:User2@litwareinc.com" state="full">
<ci:display-text>User2</ci:display-text>
<ci:roles>
<ci:entry>attendee</ci:entry>
</ci:roles>
$$end_record


Outside Voice Control Scenario
Mobile phones are a key facet of information worker communications. Accordingly, incorporating
mobility into a unified communications plan is essential for true unification of communications.
Although the e-mail, instant messaging (IM), and federated telephony worlds are already
becoming unified by having a single Session Initiation Protocol (SIP) address (which is typically
the e-mail address) be the single point of contact for a person, this unification has not yet
extended to the mobile phone space. Information workers still end up exchanging mobile phone
numbers in addition to their work phone numbers as part of their contact information. This has led
to a suboptimal user experience. For example, a caller from the public switched telephone
network (PSTN) tries to reach a certain user by dialing the user’s office phone number. If she
cannot reach the user at his office phone, she bypasses the corporate voice mail system by
disconnecting the original call and dialing the user’s mobile phone number. If the caller cannot

                                                                                               154
reach the user on his mobile phone, the caller leaves a message on the user’s voice mail box in
the mobile phone network. As a result, the recipient ends up checking his Outlook inbox for e-
mails, corporate voice mail system for some voice mails, and his mobile phone provider’s voice
mailbox for other voice mails.
A unified communications solution needs to provide means for the user to control any
communication stream in a unified fashion at all times. By giving out a mobile phone number, a
secondary access channel to the user has been opened that currently bypasses the user’s unified
communications solution in the company. With Office Communications Server 2007 R2 a new
feature has been introduced, called Outside Voice Control, that enables users to hide their mobile
phone number for inbound and outbound calls. This feature is sometimes referred to as outside
voice.
To use this feature, a user needs to install Office Communicator Mobile (2007 R2 release) on a
Windows Mobile phone, and a data service such as General Packet Radio Service (GPRS) to
provide IP data communication between the mobile phone and the Internet. This network carries
SIP messages (that is, but not audio media) between the Office Communications Server 2007 R2
system (that is, by using the organization’s Edge Server) and the Communicator Mobile client.
The user also needs to be enabled for Enterprise Voice.
If the user receives an incoming call on his SIP Uniform Resource Identifier (URI), either from the
PSTN or from other Office Communications Server 2007 R2 users or from a federated contact,
Office Communications Server 2007 R2 sends a SIP INVITE to all of the user’s registered SIP
endpoints (for example, Office Communicator 2007 R2, Office Communicator Phone Edition) as
well as to the user’s Communicator Mobile client running on the Windows Mobile device. After
this SIP INVITE message reaches the Communicator Mobile client using the data channel of the
mobile phone, Communicator Mobile automatically accepts the incoming call and changes the
user’s presence to In a Call. Next, Office Communications Server 2007 R2 initiates an outbound
call to user’s mobile phone number by using an Office Communications Server 2007 R2
Mediation Server and PSTN access point (that is, by using a gateway, PBX, or SIP Trunk service
provider). The user receives a second incoming call through the mobile phone provider’s cellular
network and is able to accept the call. Note that the actual mobile phone call is not a Voice over
IP (VoIP) call where audio has been transmitted by using the mobile phone provider’s data packet
network to Communicator Mobile. Instead, it is a normal mobile phone call that uses the mobile
phone provider’s cellular network.
For an outbound call from her mobile phone, the user has the option to enter the phone number
to be dialed in Communicator Mobile or to initiate a call to a SIP contact using Communicator
Mobile. If the user chooses the Call menu option in Communicator Mobile, the call is placed by
the mobile phone by using the mobile phone network. However, if the user chooses the Call via
work option in Communicator Mobile, the phone first sends a SIP INVITE to Office
Communications Server 2007 R2. Office Communications Server 2007 R2 establishes a call to
the user’s mobile phone number over the PSTN. The user receives an incoming mobile phone
call from his company by using the mobile phone provider’s cellular network. Finally, after the
user accepts the call from his company, Office Communications Server 2007 R2 sets up a
second call leg to the designated called party and joins the two connections. (Note that if the
Called Party is on the PSTN, the two call legs can be over separate Mediation Servers that have

                                                                                               155
completely different PSTN break-out locations.) The called party receives a call from the user’s
company by using the user’s office phone number as the Calling Party number despite the fact
that the user is actually on her mobile phone.
Following are some of the benefits for the company and the user associated with this scenario:
   The user’s office phone number can become the only phone number that is published on
     business cards and other business materials. The mobile phone number can be shared with
     selected people.
   Activities on the user’s mobile phone (for example, when participating in a mobile phone call)
     can be aggregated to the user’s overall presence state.
   If the user is enabled for Enterprise Voice and Exchange 2007 SP1 Unified Messaging, the
     user can disable his mobile phone voice mail box and use Exchange 2007 SP1 Unified
     Messaging as his only voice mail repository. This has all the advantages of using an Outlook
     Inbox for all communications (for example, e-mail, missed call notifications, voice mail, team
     call pick-up notifications, and so on).
   By setting up an outbound mobile phone call through Office Communications Server 2007 R2
     by using the Outside Voice Control functionality, call charge reductions may occur. For
     example, if the user wants to call an international phone number from his mobile phone for a
     longer conference call, call charges can be lowered significantly by placing the call from the
     company to the international number through the PSTN, bypassing the mobile phone network
     (despite another call leg being established from the company to the user’s mobile phone
     number). Office Communications Server 2007 R2 Least-Cost Routing functionality helps save
     additional costs in these situations. Even more obvious are the savings what occur when the
     user calls a federated contact who has a phone number based in another country. Instead of
     calling the international number directly from the user’s mobile phone, Office
     Communications Server 2007 R2 can use an Office Communications Server Edge Server to
     connect this federated call leg with the call leg to the user’s mobile phone.
   All calls initiated through Office Communications Server 2007 R2 are captured for Call Detail
     Recording (CDR) and Quality-of-Experience (QoE) as part of the Office Communications
     Server 2007 R2 Monitoring Server. However, the QoE data is only on the VoIP legs of the
     call and does not reflect the quality of the PSTN or mobile provider network.


Outside Voice Control Architecture
To enable the Outside Voice Control scenario, the following prerequisites are required:
   As part of the Office Communications Server 2007 R2 installation, all applications are
     installed by default. During the deployment, the Outside Voice Control application needs to
     be activated as part of the Office Communications Server 2007 R2 installation.
   The unified communications Application Server needs to run on every Office
     Communications Server 2007 R2 Standard Edition server or Enterprise pool Front End
     Server. You need to start the Outside Voice Control application by using the Office
     Communications Server 2007 R2 snap-in.



                                                                                                 156
   One or more Office Communications Server 2007 R2 Mediation Servers with connected
     PSTN Gateways, IP PBXs, or SIP Carrier trunks need to be deployed for PSTN access.
   Users who want to benefit from this scenario need to be enabled for Enterprise Voice. To
     benefit from the single voice mail box functionality, which can only be provided by Exchange
     2007 Unified Messaging, users need to be enabled for Exchange 2007 Unified Messaging.
   Users need to have a Communicator Mobile (2007 R2 release) client installed on their
     Windows Mobile 6 or Windows Mobile 6.1 smartphone or Pocket PC phone device.
     Additionally, it is highly recommended that you have an unlimited data usage plan with the
     mobile phone provider.
   The user’s mobile phone needs to be enabled for data packet communication through GPRS,
     EDGE, CDMA, or other 3G connection, and a screen resolution of 240 x 320 pixels is
     required.
   An Office Communications Server 2007 R2 Access Edge server needs to be deployed to
     allow Communicator Mobile to exchange SIP messages with the corporate Office
     Communications Server 2007 R2 pool.
   You need to configure a location profile for each pool or user where Outside Voice Control is
     installed.
   To enable this scenario, you need to open the following ports:




                                                                                                  157
    Table 1. Required and Optional Ports

    Application          Port Number    Protocol            Place to open    Usage
                                                            ports

    Communicator         5060           SIP Transmission    Load balancer    Port range used by
    Mobile (2007 R2                     Control Protocol    in front of      Communicator
    release)                            (TCP)               home server      Mobile for SIP
                                                            (optional)       communications
                                                                             internally

    Communicator         5061           SIP TLS             Internal         Port range used by
    Mobile (2007 R2                                         firewall and     Communicator
    release)                                                load balancer    Mobile for SIP over
                                                            in front of      Transport Layer
                                                            home server      Security (TLS)
                                                            (required)       communications
                                                                             internally

    Communicator         443            TLS/HTTPS           External         Used by
    Mobile (2007 R2                                         firewall and     Communicator
    release)                                                load balancer    Mobile for
                                                            in front of      connecting from
                                                            external edge    outside the intranet
                                                            of Access        for SIP
                                                            Edge Server      communications

    Outside Voice        5074           TCP                 Load balancer    Used by Outside
    Control                                                 in front of      Voice Control for
                                                            home server      internal
                                                            where Outside    communications
                                                            Voice Control
                                                            is installed



Architectural Overview
The following figure shows the architecture required for the Outside Voice Control scenario.




                                                                                                 158
Figure 1. Outside Voice Control architecture




Protocols Used By Outside Voice Control
Outside Voice Control uses the following protocols:
   Session Initiation Protocol (SIP). Communicator Mobile exchanges SIP messages through
     the Office Communications Server 2007 R2, Access Edge Server with the Office
     Communications Server 2007 R2 pool.
   Third Party Control Protocol (TPCP). This protocol is transported by SIP messages
     between the Communicator Mobile client and the Office Communications Server 2007 R2
     Standard Edition server or Enterprise pool and is used to send call commands between the
     phone and the user’s Front End Server.


Call Flows
The following sections contain sample call flows for an outbound call and an inbound call (from
the perspective of the Windows Mobile phone user) by using the Enterprise Cellular Voice
scenario with a Communicator Mobile (2007 R2 release) client.


Outbound Call
The following steps occur when User A, who is running Communicator Mobile, establishes an
outbound call to User B, who is using Office Communicator, from a mobile telephone by using
Communicator Mobile in conjunction with the Outside Voice Control application. User B has
multiple endpoints: Office Communicator 2007 R2 and Communicator Mobile (2007 R2 release).
1. On his Communicator Mobile client, User A selects a contact from his contact list, and then
   selects Call via Work from the calling options.
2. Communicator Mobile uses a data channel to inform Outside Voice Control of the outbound
   call. This information is transmitted to Outside Voice Control by using SIP/TPCP. The
                                                                                                  159
    message is passed though the mobile provider’s data packet network through the Internet to
    their organization’s Office Communications Server 2007 R2 Access Edge server, and from
    there to their assigned Standard Edition server or Enterprise pool.
3. Outside Voice Control establishes a call to User A’s mobile phone by initiating a request
   through a Mediation Server to the mobile phone provider’s cellular voice network.
4. User A receives an incoming call on her mobile phone.
5. User A answers the call and the first call leg between the Office Communications Server
   2007 R2 environment and User A’s mobile phone has been established. Media is inactive.
6. Outside Voice Control now establishes a second call leg with the home pool of User B, where
   Office Communicator 2007 or Communicator 2007 R2 has been registered, by sending a SIP
   INVITE message.
7. A Front End Server in User B’s home pool looks up the User B’s registered endpoints and
   then forks the SIP INVITE message to all of them.
8. User B gets an incoming call notification.
9. As soon as User B answers the call on one of her registered devices, the second call leg has
   been established.
10. Outside Voice Control provides call management to bridge the two call legs between the
    mobile client (that is, User A) and the enterprise Office Communicator user (that is, User B).
    Media flows between User A’s mobile phone through the mobile phone provider’s cellular
    network, to the PSTN, then through the Mediation Server (that was selected by Outbound
    Routing) to Office Communicator 2007 or Communicator 2007 R2 client.




                                                                                                160
Figure 2. Outbound call flow




If call forwarding on the mobile telephone has been enabled, outbound calls on Communicator
Mobile are not supported.
For the normalization of telephone numbers dialed by Communicator Mobile, the user’s user-
specific location profile is applied on non RFC3966 compliant called party numbers.



                                                                                             161
Inbound Call
To continue with the example above but in the opposite direction, User B (that is, the Office
Communicator 2007 or Communicator 2007 R2 user) in the enterprise calls User A. User A has
Communicator Mobile installed on her mobile device. In this section, the call flow of this scenario
is outlined below.
1. User B initiates a call to User A by clicking on a contact in Office Communicator 2007 or
   Office Communicator 2007 R2.
2. User A’s Front End Server in the recipient’s home pool looks up User A’s registered
   endpoints, and then forks the call to all registered endpoints, including User A’s
   Communicator Mobile client.
3. When the request to establish a signaling channel reaches Communicator Mobile,
   Communicator Mobile determines that the incoming session is an audio call.
    Note: Communicator Mobile intercepts the incoming voice call only if the Calling Party
    number of the voice call matches the Calling Party number that is communicated through the
    data channel that gets established before the voice call. Otherwise, the incoming voice call is
    treated as a regular mobile telephone call and Communicator Mobile does not respond.
4. Communicator Mobile automatically accepts the call by using a data signaling channel in the
   data packet network of the mobile phone provider to pass this message to Outside Voice
   Control through the Internet and Office Communications Server 2007 R2.
5. Outside Voice Control initiates a call to User A’s mobile phone number. Outbound Routing
   selects a Mediation Server/gateway to send the call to the PSTN, which ultimately routes to
   the mobile phone provider’s cellular network.
6. When the user answers the incoming mobile phone call on his mobile phone, Outside Voice
   Control and Office Communications Server 2007 R2 connect the Office Communications
   Server 2007 R2 Mediation Server call leg with the originating call leg. Media flows directly
   between Office Communications Server 2007 R2, Mediation Server and the caller.
7. Outside Voice Control remains in the signaling path to provide call management until the call
   is terminated.




                                                                                                 162
Figure 3. Inbound call flow




To redirect the incoming INVITE, Communicator Mobile redirects the INVITE with a 303 SIP
response and introduces a new header called CancelForking. This header can have two possible
values: Yes or No. The absence of the header, which is consistent with Communicator Mobile
(2007 release), means that forks will be cancelled. Therefore, the absence of the header is equal
to CancelForking:Yes.

                                                                                              163
Group Chat Feature Scenario
The Office Communications Server 2007 R2 Group Chat Server is built on top of the Office
Communications Server infrastructure. This infrastructure handles user authentication, presence,
security, and routing. Any supported Office Communications Server topology also supports Group
Chat functionality, even if users are connecting from the Internet or belong to federated
organizations. After you have deployed the Group Chat clients and Group Chat Servers, only the
Group Chat Servers require additional configuration before the Group Chat feature is fully
operational.
You can deploy a Group Chat Server on a single computer or on an array of servers to provide
greater scalability and availability. You can also deploy Group Chat Servers at multiple locations if
you have a multi-pool Office Communications Server topology.
The Group Chat client integrates with the Office Communicator 2007 R2 client and is another
Session Initiation Protocol (SIP) endpoint that registers with a Standard Edition server or a Front
End Server of an Enterprise pool. The Group Chat Server uses the Unified Communications
Managed API (UCMA) 2.0 to communicate with the pool that you select when you install the
Group Chat Server.
This section of the Office Communication Server 2007 R2 Technical Reference is intended to
help Unified Communications administrators and specialists gain a deeper understanding of the
Group Chat architecture, protocols, and communication flows, which can be valuable for system
design and troubleshooting.
In This Section
This section contains the following topics:
   Group Chat Services
   Key Protocols and Windows Services Used by Group Chat
   Group Chat Call Flows


Group Chat Services
Group Chat Server consists of the following: the Channel service, the Lookup service, the Web
service, and a dedicated back-end database, which must reside on a separate computer. If you
choose to use Compliance service, which is optional, you must install it on a separate computer.
The Compliance service requires its own back-end SQL Server database, which can reside on
the same computer as the Compliance service or on a separate computer. If it is on a separate
computer from the Compliance service, the back-end database can be collocated with the main
Group Chat SQL Server database or be placed on a separate database server.
The back-end database stores configuration data for the Group Chat Servers and stores the chat
message history for each chat room.


Channel Service
Most of the workload of a Group Chat Server is performed by the Channel service. The Channel
service accepts incoming messages, registers and lists the online participants within a channel

                                                                                                 164
(known as a Chat Room in the user interface), and retransmits messages to the other channel
subscribers. The Channel service also implements logic for channel management, chat room
invitations, search, and new content notifications.
When the Group Chat feature is provided by an array of Group Chat Servers joined to the same
pool, each Channel service communicates with the others to relay new messages to the clients
connected to each member of the array, and each ascertains the operational health of the other
Group Chat Servers. Because each Channel service gets its configuration information from a
common back-end database, all are configured identically.
The Channel service registers as a trusted service in the Active Directory Domain Services
(AD DS) when the Group Chat Server is activated. When a deployment includes multiple Group
Chat Servers, each instance of the Channel service is assigned a unique Session Initiation
Protocol (SIP) Uniform Resource Identifier (URI), which is the Globally Routable User Agent URI
(GRUU) setting of the corresponding trusted service. These GRUUs allow the Lookup service to
assign users to specific Channel service servers.


Lookup Service
The Lookup service connects clients to a Channel service. If there is more than one Group Chat
Server in the deployment, the Lookup service also functions as a load balancer.
The Lookup service is represented by a URI that is provisioned to the Group Chat clients before
their users sign in. This URI can be the default value (OCSChat@<user’s SIP domain>), it can be
supplied to the Group Chat clients by Group Policy, or it can be configured manually. After a user
of a Group Chat client successfully signs in to a Front End Server, the Front End Server uses this
URI to initiate a session with a Lookup service on behalf of the client.
When a deployment includes multiple Group Chat Servers, the servers’ Lookup services can
share the same SIP URI. When a Group Chat client initiates a connection, the Lookup services
act as multiple points of presence (MPOP) for that SIP address, and the last Lookup service to
connect with the client is the one that assigns a Channel service to the client. If a Lookup service
instance fails, the Front End Server automatically routes subsequent connection requests to
another Lookup service. Even if one server is slower than the others and it is consistently the last
one to respond (and thereby gets all of the Lookup service requests), it is of little concern from a
scalability standpoint because the process of assigning Channel service URIs to clients is fairly
lightweight.
The Lookup service assigns Channel service instances so that the workload among all instances
is balanced. Every 10 seconds, each Channel service instance communicates its current user
load to all Lookup service instances. The Lookup services route new sessions to the least loaded
Channel service at the time.
If a Channel service fails, existing sessions are cancelled, and the clients contact the Lookup
service to receive the URI of a new Channel service. After they reconnect, the new Channel
service automatically pushes any missed messages to the clients.
When a Channel service resumes operation, the Lookup services do not redistribute existing
Group Chat sessions, but the resumed Channel service instance reports itself as available and


                                                                                                  165
will get all subsequent new client connections until its workload is balanced with those of the
other Channel service instances.


Web Service
Because files attached to chat messages must be available to multiple users within a channel and
from the chat history, peer-to-peer (P2P) file transfer is not sufficient. The Web service provides a
mechanism for file exchange within the context of channels.
Group Chat clients must provide specific tokens to upload or download files. These tokens are
provided in-band by the Channel service to authorized subscribers.
When a deployment includes multiple Group Chat Servers, all servers use a Universal Naming
Convention (UNC) path that points to a common Windows share where the actual files reside.
End users are not permitted direct access to this share. They must go through the Web service.
Although Group Chat clients never communicate directly with a Lookup service or Channel
service (that is, they are always proxied through one or more Front End Servers), clients connect
directly to a Web service instance when they upload and download files to and from a chat room.
For the file transfer function to be available to remote users without using a virtual private network
(VPN) or to federated users, the Web service URIs must be resolvable and routable from the
Internet.


Compliance Service
The Compliance service uses Microsoft Message Queuing (also known as MSMQ) to collect
Group Chat messages and events from Channel service instances and uploaded files from Web
service instances. The Compliance service archives these messages as files formatted according
to the type of Compliance adapter you selected during installation. The Compliance service
comes with a customizable XSLT transform that generates XML files for pickup and further
analysis by a custom program. Compliance adapters are also available from Akonix, Assentor,
and Facetime that enable the Compliance service to generate output file formats compatible with
archiving solutions from those vendors.
Before archival, messages are staged in a SQL Server database separate from the one used by
the Group Chat Server. The two databases can coexist on the same computer, but if the
workloads are high enough to degrade performance they should be located on separate SQL
Server instances.
Unlike the back-end database for the Office Communications Server 2007 R2 Archiving Server,
this database stores the messages for the duration of the archive retention period, the back-end
database for the Compliance service stores records only temporarily. The data is extracted
according to the Compliance server’s Conversation interval in minutes setting, is written to a
file, and then placed in a shared directory, where it can be picked up by the third-party or custom
compliance system. After the compliance system has picked up the data, the XML output files
and uploaded files can be deleted to prevent loss of available disk space.
You can also use the Compliance service to archive uploaded files.



                                                                                                   166
The Compliance Server does not archive instant messages, even if the instant messaging (IM)
session was launched from the Group Chat client. If your organization wants to archive IM
sessions, you must deploy the Archiving Server role on a separate server.


Key Protocols and Windows Services Used by Group Chat
The Group Chat feature relies on several protocols: Session Initiation Protocol (SIP)/Transport
Layer Security (TLS), Windows Communication Foundation (WCF), HTTPS, and Message
Queuing (also known as MSMQ).


Session Initiation Protocol (SIP)
By using SIP over TLS as its key client-server communications protocol, the Group Chat feature
harnesses the core real-time communications (RTC) capabilities of Office Communication Server
2007 R2, including the client-side and server side application programming interfaces (APIs),
authentication, encryption, registration, presence, and routing.
Furthermore, because SIP is a general-purpose signaling protocol that can transport payloads
that contain other protocols (for example, Session Description Protocol (SDP) or Centralized
Conferencing Control Protocol (C3P)), most of the Group Chat client-server traffic consists of SIP
INFO messages containing an XML-based protocol, XCCOS. XCCOS is a proprietary format for
transmitting data between Front End Servers and Group Chat clients. In addition to transporting
the chat messages, it provides support for federated Group Chat, channel invitations, activity
notifications, and posting of files.
The Group Chat Lookup and Channel services register as SIP endpoints with an Office
Communications Server Front End pool. Clients communicate with them by using SIP INFO
messages that contain XCCOS commands and responses.


Windows Communication Foundation (WCF)
When a deployment includes multiple Group Chat Servers, the Lookup service uses WCF over
TLS on each Group Chat Server to monitor the load on each server and determine which
Channel service instances should receive new client connections.
The Channel services also use WCF to relay messages with each other. Clients are balanced
across the available Channel service instance. As a result, when a new message comes in to a
Chat Room (channel) on one Channel service instance, in addition to rebroadcasting the
message to the other active participants subscribed to that Chat Room over SIP, the Channel
service forwards the message over WCF to the other Channel service instances in the array,
which in turn forwards the messages to the Chat Room subscribers actively connected to those
other instances.


HTTPS
Uploading and downloading files to and from Group Chat clients and the Web service occurs over
HTTPS.
This traffic is the only Group Chat client-server communication that does not occur over SIP.

                                                                                                  167
Message Queuing
For deployments that include the optional Compliance service, each Channel service uses
Message Queuing to publish the following events to the Compliance service:
   New chat messages
   A user entering or exiting a chat room
   File uploads and downloads
   Queries and searches against the chat history
The Compliance service temporarily stores the events and chat messages in its back-end
database. In addition to extracting the events and chat messages from the database and writing
them to files in a shared directory, the Compliance service also obtains copies of all uploaded
files and writes them to an Attachment subdirectory in the shared directory for pickup for pickup
by your archiving solution.


Group Chat Call Flows
This topic describes the call flows of a user signing in from a Group Chat client, subscribing to a
chat room, and then posting a message to it. In these examples, the architecture consists of a
single consolidated Group Chat Server that is in the same pool as the user.


Group Chat Client Sign In
Before users can participate in a group chat, they must sign in with the Group Chat client to a
Front End Server, be authenticated by the server, and then connect to the Chat Rooms to which
they have subscribed. In this example, the Lookup service and the Channel service are already
running and registered with the Front End Server.
The sequence of steps is as follows:
1. The Group Chat client uses the same techniques as the Office Communicator 2007 R2 client
   to locate its pool server (that is, Domain Name System (DNS) SRV records in most cases
   and a Director referral, if used). The client uses either the user’s Windows logon credentials
   or manually-entered alternate credentials, and then sends a set of SIP REGISTER messages
   to a Front End Server. If the user’s credentials are valid and the user is authorized to use
   Group Chat, he or she is authenticated.
2. The Group Chat client sends one or more SIP SUBSCRIBE messages to the Front End
   Server and then retrieves the user’s contact list.
3. The Group Chat client sends a SIP SERVICE message to the Front End Server to provide
   information about its endpoint capabilities. From this point onward (that is, in the context of
   Group Chat), the only function of the Front End Server is to proxy messages between the
   Group Chat client and one or more Group Chat Servers.
4. The Group Chat client sends a SIP INVITE message to the Uniform Resource Identifier (URI)
   of the Lookup service. If the client is set to use automatic configuration, this URI defaults to
   the name OCSChat@<user’s SIP domain>. If the organization has implemented Group
   Policy Object (GPO)-based configuration of the Group Chat client, it will use the URI that is

                                                                                                     168
    provided by the Specify lookup server URI GPO policy setting. (Users can also manually
    supply the URI of the Lookup service.) The Front End Server looks in its registration
    database and proxies the INVITE message to all Lookup service instances that are registered
    with it. In this example, there is only one. The INVITE sequence is followed up by the 200 OK
    and ACK, and the Group Chat client has now opened a SIP session with a Lookup service
    endpoint.
5. The Group Chat client sends a SIP INFO message containing the XCCOS requri (that is,
   request URI) command to the Lookup service, which queries the back-end database and
   returns the URI of the Channel service with the lowest current workload. When the client
   receives the URI, it sends a SIP BYE message and closes the session with the Lookup
   service.
6. The Group Chat client sends a SIP INVITE message to the URI of the Channel service that it
   obtained in the previous step. The INVITE sequence is followed by 200 OK and ACK, and the
   Group Chat client has now opened a SIP session with a Channel service endpoint. From this
   point forward, the client communicates with the Channel service by sending SIP INFO
   messages that contain either chat messages or commands requesting the server to take an
   action. All of these messages are acknowledged with either 200 OK or 503 Service
   Unavailable (that is, in the event of heavy server load). If the client receives a 503 response,
   it will retry the message. (This example does not include a 503 response.) If the server
   accepts the message or command and sends 200 OK, it will provide a response to the client
   in the form of a separate SIP INFO message. This response includes a reference to the
   originating command.
7. The Group Chat client sends a SIP INFO message containing the XCCOS getserverinfo
   command. The Channel service replies with a new SIP INFO message containing information
   about the Channel service configuration.
8. The Group Chat client sends a SIP INFO message containing a set of XCCOS getpref (that
   is, get preferences) commands. The client stores its state on the server in a set of
   compressed XML documents called preferences. The getpref command is a request from
   the client to the server for the latest copy of that data. If the client has a local copy of the
   preferences, it sends the version ID of the local copy in the command. The server responds
   to this command in a separate SIP INFO message with the requested data.
9. The Group Chat client sends a SIP INFO message containing a XCCOS bjoin (that is, batch
   join) command that contains a list of chat rooms that the user has previously joined. This list
   is obtained from the preferences document. The Channel service queries the back-end
   database, and then returns a separate SIP INFO message containing the user’s channel
   provisioning data and the contextual message history for those chat rooms.
10. The Group Chat client sends a SIP INFO message containing a XCCOS getinv (that is, get
    invitation) command to request any open channel invitations. In a separate SIP INFO
    message, the Channel service returns a list of those channels.
The following ladder diagram shows this call flow.




                                                                                                 169
Figure 1. Group Chat client sign in call flow




                                                170
Note:
    Messages from the Group Chat Server to the client are often batched. A single SIP INFO
    message can contain one or more messages. For example, in the case of a batch join
    (that is, bjoin) command, the server sends bjoin replies and contextual message history
    for each chat room that is being joined. But these messages may be delivered to the
    client as a single SIP INFO message or as multiple SIP INFO messages.
After the user of a Group Chat client is signed in and connected to a Channel service, his or her
client lists the message history of all currently subscribed chat rooms.
If the user’s Office Communications Server account was homed in pool different from that of the
Group Chat Server pool, a Front End Server in the user’s home pool would proxy the messages
to and from a Front End Server in the pool with which the Channel service is homed.


Subscribing to a Chat Room and Posting a Message
In this example, two users, User1 and User2, are signed in to a Channel service. User1 wants to
subscribe to a new Chat Room, to which User2 is already connected, and then participates by
posting a message with a file attachment.
The sequence of steps is as follows:
1. From the Group Chat client, User1 clicks Join a Chat Room, clicks Search, and then enters
   some search criteria. The client sends the Channel service a SIP INFO message containing
   the XCCOS chansrch (that is, channel search) command, along with the search criteria. The
   Channel service queries the back-end database and replies in a new SIP INFO message that
   contains a list of available channels (chat rooms) that meet the search criteria.
2. User1 selects the chat room he or she wishes to join and then clicks Join. The client sends
   the Channel service a SIP INFO message containing the XCCOS join command and the
   channel ID of the chat room the user selected. The Channel service replies with a SIP INFO
   message that contains the provisioning data.
3. The Group Chat client sends the Channel service a SIP INFO message that contains the
   XCCOS bccontext (that is, backchat context) command. The Channel service retrieves the
   chat history and returns it to the client in a separate SIP INFO message. At this point, the
   user enters the chat room and is ready to participate.
4. User1 enters a new message containing a file attachment reference and then clicks Send.
   The Group Chat client sends the Channel service a SIP INFO message containing the
   XCCOS getfutok (that is, get file upload token) command. The Channel service inserts a
   token into the back-end database and issues the token with the URI of the Web service
   instance to the client in a new SIP INFO message. This token is then used by the Group Chat
   client to upload the file to the URI of the Web service instance, which validates the token
   against the back-end database before allowing the upload to proceed. User1’s client
   simultaneously posts the message with the file attachment link to the chat room in a SIP



                                                                                               171
    INFO XCCOS grpchat command. The Channel service stores a copy of this new message in
    the SQL Server database.
5. The Channel service sends a separate copy of the SIP INFO XCCOS grpchat message to
   User2, who has already entered the chat room.
The following ladder diagram below shows the call flow.




                                                                                     172
Figure 2. Group Chat subscription and message posting call flow




                                                                  173
Technical Drilldowns
This section provides deeper drilldowns into specific technical aspects of Microsoft Office
Communications Server 2007 R2.
In This Section
   SIP Processing Drilldown
   User Replicator Drilldown
   Archiving and Monitoring Drilldown
   Edge Servers Drilldown
   Response Group Client Web Service Drilldown
   Client DNS Queries Drilldown
   Application Server Drilldown
   SIP Trunking Drilldown
   Address Book Server Drilldown


SIP Processing Drilldown
In versions of Office Communications Server prior to Office Communications Server 2007, the
server used a proprietary extension called End-point Identifier (EPID) to address a specific User
Agent. Starting with Office Communications Server 2007, Globally Routable User Agent URI
(GRUU) replaces EPID where possible. Office Communications Server 2007 R2 supports
backwards compatibility with EPID, but to the degree possible, all new applications and clients
use GRUU instead.


SIP Processing and GRUU
GRUU is an extension of Session Initiation Protocol (SIP) that is currently defined in an Internet
draft at http://go.microsoft.com/fwlink/?LinkId=144418. GRUU is specifically designed to
implement reliable routing to a specific device for an end user. While a plain SIP URI (for
example, janedoe@contoso.com), is a URI that refers to a user, GRUU is an URI that refers to a
specific device.
GRUU can be used within multiple separate SIP dialogs to reach the same device. This works not
just for client applications but also server applications (for example, the Mediation Server). The
Office Communicator client running on each computer has its own GRUU that allows other
applications to route messages specifically to that device.
GRUU is widely applied across the server to solve a variety of problems, including, but not limited
to, Enterprise Voice call transfer or conference escalation scenarios, which require the ability to
establish a new dialog with a specific endpoint in an existing dialog. GRUU is also used to
address scenarios where one endpoint in a dialog is server based and, therefore, the To/From
header in the dialog cannot be resolved to a specific endpoint. In the original SIP standard, it was


                                                                                                174
not possible to construct an URI which could be routed to from anywhere (including the Internet)
and reach a specific device or User Agent.
GRUU is a SIP URI that generally follows the form:
sip:<user>@<domain or FQDN>;opaque=<private>;grid=<optional
cookie>;gruu
For example:
sip:janedoe@contoso.com;opaque=user:epid:qIIWS2j5AVeD_HxnQdxmlwAA;gruu
The opaque parameter, in combination with the address of record (AOR), makes this URI unique
even though the prefix of the URI is still the standard user address. The gruu parameter specifies
that this URI has all the properties of a GRUU and can be used within multiple separate SIP
dialogs to reach the same user agent (device). The grid parameter is optional and is inserted by a
user agent instance when the user agent uses the GRUU to route to itself. If the grid is included
in a request, it helps the user agent instance determine the context of the request.


GRUU Creation
The server is responsible for creating a GRUU and returning it to the client through the SIP
registration mechanism, if the client requests one at registration time. The GRUU returned to the
client during the registration process is not managed or exposed to the administrator in any way.
This process is handled entirely by the User Services module and can be inspected only by
examining the registration database itself. The GRUU can be used anywhere you would typically
use a URI.


How GRUU Is Used by Office Communications Server
GRUU is used by Office Communications Server in the following ways:
   Office Communicator 2007 R2 clients request and receive a GRUU at registration time, which
     they will use in their Contact header for all subsequent SIP dialogs, such as Enterprise Voice
     calls, conferencing, and so on.
   The Microsoft Office Live Meeting client uses one aspect of GRUU known as the
     "sip.instance" to create a unique identifier for each meeting client in a conference. This is
     necessary since the meeting client does not actually register with the server and therefore
     cannot obtain a genuine GRUU from the server for use in its SIP Contact header.
   The client uses the GRUU of the Media Relay Authentication Server (MRAS) application
     (collocated with the A/V Conferencing Server) to send requests to the MRAS server, without
     necessarily having to know the FQDN of the server or be able to directly connect to the
     MRAS server. The client learns the MRAS applications GRUU through in-band provisioning.
     (The A/V Conferencing Server will use the MRAS application GRUU that is configured in
     WMI.)
   Enterprise Voice endpoints send their Quality of Service (QoS) metric reports to a GRUU,
     which identifies the metrics collection point. (The Mediation Server and A/V Conferencing
     Server will use the collection point GRUU configured in WMI.)

                                                                                                     175
   The voicemail server (generally Exchange Unified Messaging) for a given user will be
     identified by a GRUU. The client will learn this GRUU through in-band provisioning (for itself)
     and through presence (for someone else). An application running on the server, ExUM
     Routing, resolves the GRUU to a specific Exchange Unified Messaging server that handles
     user voice mailboxes. An application can be written that will resolve the GRUU for non-
     Exchange voice mail systems.
   Pools use GRUU to address other pools for batched subscriptions.
   The Mediation Server uses GRUU to identify different outbound gateways that are connected
     to the Mediation Server. This allows Office Communications Server to send messages to a
     single FQDN/port on the Mediation Server and have the messages routed correctly to the
     proper outbound IP-PSTN gateway. (This GRUU is not exposed in any way to the client; it is
     used only for server-to-server communications.)
During conference creation, the client addresses the Focus Factory by using a GRUU that is
composed in part by the meeting organizers SIP URI. This Focus Factory GRUU is sent to the
client through in-band provisioning.


User Replicator Drilldown
User Replicator uses the Lightweight Directory Access Protocol (LDAP) application programming
interface (API) to get information from Active Directory. User Replicator performs searches for
user data in Active Directory by using Active Directory directory synchronization (DirSync) control,
an LDAP server extension that enables User Replicator to track changes to user, contact, and
group objects in Active Directory as the changes are made. User Replicator is a read-only
component. It does not write data to Active Directory.
There can only be one instance of User Replicator running in an Enterprise pool at any given
time. Any errors that User Replicator encounters are logged as events on the Front End Server
that is running User Replicator at the time the error occurs. In the event that the Front End Server
on which User Replicator is running becomes unavailable, SQL Server dynamically assigns the
task of running User Replicator to the next available Front End Server.
To keep the presence store synchronized with user, contact, and group objects in Active
Directory, User Replicator gives Active Directory a list of attributes about which it wants to be
notified. The first time that User Replicator requests attribute changes from Active Directory, User
Replicator performs an "initial cycle" during which time it synchronizes all user, contact, and
group objects. Subsequently, after the initial cycle is complete, User Replicator requests only new
changes from Active Directory every one minute. After User Replicator obtains attribute values
that have changed from Active Directory, it sends those values to the SQL database for storage.
The DirSync API gives User Replicator a cookie which identifies a point in Active Directory's
change list. When User Replicator gives a cookie to DirSync, it gets every change after the point
identified by the cookie. Therefore, the only state that User Replicator stores across
synchronization is the cookie.
The following lists include attributes that User Replicator monitors for change in Active Directory.
(User Replicator also monitors all Address Book Server attributes in Active Directory.) When
there is a change in the attribute, User Replicator acts accordingly. Some of the attribute values
                                                                                                  176
are copied from Active Directory to the SQL store without modification. Other attribute values are
processed by User Replicator and then copied to the SQL store.
Office Communications Server specific attributes that User Replicator monitors include the
following:
   msRTCSIP-PrimaryUserAddress
   msRTCSIP-PrimaryHomeServer
   msRTCSIP-UserEnabled
   msRTCSIP-OriginatorSid
   msRTCSIP-FederationEnabled
   msRTCSIP-InternetAccessEnabled
   msRTCSIP-ArchivingEnabled
   msRTCSIP-OptionFlags
   msRTCSIP-Line
   msRTCSIP-LineServer
   msRTCSIP-UserLocationProfile
   msRTCSIP-UserPolicy
   msRTCSIP-ApplicationDestination
   msRTCSIP-SourceObjectType
   msDS-SourceObjectDN
Attributes that are not specific to Office Communications Server that User Replicator monitors
include the following:
   objectClass
   objectSid
   isDeleted
   displayName
   mail
   telephoneNumber
   proxyAddresses
   otherIpPhone
   facsimileTelephoneNumber
   streetAddress
   l
   st
   c
   postalCode
   wWWHomePage


                                                                                                 177
Archiving and Monitoring Drilldown
This section gives a detailed description of archiving and monitoring in Office Communications
Server 2007 R2.
In This Section
   Archiving and Monitoring Servers
   Archiving Database Schema
   CDR Database Schema
   QoE Database Schema
   Message Queuing Architecture and Configuration for Archiving
   Message Stamping
   Creating a Third-Party QoE Solution


Archiving and Monitoring Servers
Office Communications Server 2007 R2 separates the Archiving and Monitoring roles.


Archiving Server
The Archiving Server can archive all instant messaging (IM) conversations for all users or for
individual users that you specify.
Messages from each Office Communications Server configured for archiving are sent over the
Windows Server Message Queuing (also known as MSMQ) service to the Archiving Server,
which uses a Microsoft SQL Server database to store archived information.
Although the archiving and call detail recording (CDR) agent is automatically installed on Front
End Servers as part of the core Office Communications Server process, to archive IM traffic and
call data you must configure the archiving and CDR agent and install the Archiving Server, to
which the archiving and CDR agent connects. The Archiving Server consists of the following
three components:
   Destination queue, which is managed by Message Queuing.
   Archiving Service component.
   Archiving back-end database.
The Archiving Service component can reside on the same computer as the archiving database or
it can connect to a database on a different computer.


Monitoring Server
The Monitoring Server consists of the following three components:
   Destination queue, which is managed by Message Queuing.
   CDR and Quality of Experience (QoE) service components.
   The back-end databases, which consist of separate CDR and QoE databases that run in the
     same SQL Server instance.

                                                                                                 178
Additionally, you can install SQL Server Reporting Services and the Monitoring Server Report
Pack to view the reports that are included with Monitoring Server. And if you use System Center
Operations Manager, you can configure alerts based on Monitoring Server data, to employ near
real-time monitoring of media quality health state for network locations, Mediation Servers, and
conferencing servers.


Archiving Database Schema
This section describes the Archiving Server database schema for Office Communications Server
2007 R2. The schema is subject to change in future releases.


List of Tables
The database schema consists of the following tables.


Supporting Tables

Table                                            Description

ClientVersions                                   Stores the clients (both client type and version
                                                 number) of each client involved in a call with
                                                 information captured in this database.

Computers                                        Stores the name of each computer that hosts a
                                                 Front End Server.

ContentTypes                                     Stores the IM content types used in sessions
                                                 captured in this database.

Dialogs                                          Stores information about the DialogID for each
                                                 peer-to-peer session in the database.

Pools                                            Stores the names of pool on which IM
                                                 messages are captured.

Users                                            Stores the user URIs of users who have
                                                 participated in sessions recorded or archived in
                                                 this database.



Tables for Messages in IM Conferences

Table                                             Description

Conferences                                       Stores information about all conferences that
                                                  were archived or whose details were recorded,
                                                  including ConferenceURI, and start and end

                                                                                               179
Table                                              Description

                                                   time.

ConferenceMessageRecipientList                     For each message sent in a conference, stores
                                                   a list of recipients.

ConferenceMessages                                 Archives the content of all the messages sent
                                                   in a conference.



Tables for Peer-to-Peer IM Archiving

Table                                              Description

SessionDetails                                     Stores information about every peer-to-peer
                                                   session, including start and end time, user ID,
                                                   response code, and message count for each
                                                   user.

Messages                                           Archives the content of all the messages sent
                                                   in one-on-one IM sessions.


The tables in the following list are used internally by Office Communications Server (their details
are not described in this document).


Tables for Internal Use by Office Communications Server

Table                                              Description

DbConfigDateTime                                   For internal use only.

DbConfigInt                                        For internal use only.

DbErrorMessage                                     For internal use only.



Table Details
This section details the columns in each of the Archiving database schema tables.


ClientVersions Table
The ClientVersions table is a supporting table that stores a list of the various client types and
versions that have participated in sessions recorded in the database. Each record in the table
represents one client version.



                                                                                                    180
Column                   Data Type                  Key/Index                Details

VersionId                int                        Primary                  Unique number
                                                                             identifying this client
                                                                             type and version.

Version                  nvarchar(256)                                       Version name.



Computers Table
The Computers table is a supporting table that stores information about the various Front End
Servers. Each record in the table represents one Front End Server


Column                    Data Type                  Key/Index               Details

ComputerId                int                        Primary                 Unique number
                                                                             identifying this Front
                                                                             End Server.

Computer                  nvarchar(16)                                       Front End Server host
                                                                             name.



ContentTypes Table
The ContentTypes table is a supporting table that stores information about the various types of IM
content.


Column                    Data Type                Key/Index             Details

ContentTypeId             int                      Primary               Unique number
                                                                         identifying this IM content
                                                                         type.

ContentType               nvarchar(256)                                  Content type name (for
                                                                         example,
                                                                         text/plain, text/rtf) or a
                                                                         MIME type.



Dialogs Table
The Dialogs table is a supporting table that stores the information about DialogIds for peer-to-
peer sessions.




                                                                                                   181
Column                       Data Type           Key/Index         Details

DialogId                     int                 Primary           Unique number identifying this
                                                                   SIP dialog instance.

ExternalChecksum             Int                                   Checksum of the ExternalId.
                                                                   This field is used to increase
                                                                   the speed of database
                                                                   searches.

ExternalId                   varbinary(775)                        SIP dialog Id, stored as a
                                                                   binary. The format of the
                                                                   binary is:
                                                                   dialog;from-tag;to-tag
                                                                   This data can be converted to
                                                                   text format by using:
                                                                   cast(cast(ExternalId
                                                                   as varbinary(max)) as
                                                                   varchar(max))



Pools Table
The Pools table is a supporting table that stores information about the various Pools. Each record
in the table represents one Pool.


Column                   Data Type                  Key/Index                Details

PoolId                   int                        Primary                  Unique number
                                                                             identifying this Pool.

PoolFQDN                 nvarchar(256)                                       Pool FQDN



Users Table
The Users table is a supporting table; each record in the table stores information about one user
involved in calls or sessions that have records in the database.


Column                 Data Type                   Key/Index                 Details

UserId                 int                         Primary                   Unique number
                                                                             identifying this user.

UserUri                nvarchar(450)




                                                                                                  182
Conferences Table
Each record in this table contains call details about one conference.


Column                         Data Type               Key/Index            Details

ConferenceUri                  nvarchar(450)

Checksum                       Int                                          Checksum of
                                                                            ConferenceUri; used
                                                                            to increases the speed
                                                                            of database searches.

ConfInstance                   Int                                          Useful for recurring
                                                                            conferences; each
                                                                            instance of a recurring
                                                                            conference has the
                                                                            same ConferenceUri,
                                                                            but will have a different
                                                                            ConfInstance.

SessionIdTime                  datetime                Primary              Time that the
                                                                            conference request
                                                                            was captured by the
                                                                            Archiving agent. Used
                                                                            only as a primary key
                                                                            to uniquely identify a
                                                                            session.

SessionIdSeq                   int                     Primary              ID number to identify
                                                                            the session. Used in
                                                                            conjunction with
                                                                            SessionIDTime to
                                                                            uniquely identify a
                                                                            session. *

ConferenceStartTime            datetime

ConferenceEndTime              datetime

PoolId                         int                     Foreign              Unique number
                                                                            indentifying the pool on
                                                                            which the message is
                                                                            captured, reference to
                                                                            Pools table


* For most sessions, SessionIdSeq will have the value of 1. If two sessions start at exactly the
same time, the SessionIdSeq for one will be 1, and for the other will be 2, and so on.

                                                                                                   183
ConferenceMessageRecipientList Table
Each record in this table represents one combination of IM conference message and recipient. A
message that is sent to multiple recipients generates one record for each recipient.


Column                    Data Type             Key/Index             Details

MessageId                 int                   Primary               Unique number
                                                                      identifying this message
                                                                      in an IM conference.

SessionIdTime             datetime              Primary, Foreign      Time that the conference
                                                                      request was captured by
                                                                      the Archiving agent.

SessionIdSeq              int                   Primary, Foreign      ID number to identify the
                                                                      session. Used in
                                                                      conjunction with
                                                                      SessionIDTime to
                                                                      uniquely identify a
                                                                      session.

UserId                    Int                   Primary, Foreign      Unique number
                                                                      identifying this user,
                                                                      referenced from the
                                                                      Users table.

Date                      datetime                                    Message captured time.



ConferenceMessages Table
This table archives all messages sent in IM Conferences. Each record represents one message.


Column                   Data Type                Key/Index            Details

MessageId                uniqueidentifier         Primary              GUID identifying this
                                                                       message.

SessionIdTime            datetime                 Primary, Foreign     Time of session
                                                                       request; used in
                                                                       conjunction with
                                                                       SessionIDSeq to
                                                                       uniquely identify a
                                                                       session. Referenced
                                                                       from the Conferences
                                                                       table.

SessionIdSeq             int                      Primary, Foreign     ID number to identify

                                                                                               184
Column                    Data Type                 Key/Index             Details
                                                                          the session. Used in
                                                                          conjunction with
                                                                          SessionIDTime to
                                                                          uniquely identify a
                                                                          session. Referenced
                                                                          from the Conferences
                                                                          table.

Date                      datetime

FromId                    int                       Foreign               UserId of the message
                                                                          sender, referenced from
                                                                          the Users table.

ContentTypeId             Int                       Foreign               IM content type of this
                                                                          message. Referenced
                                                                          from the ContentTypes
                                                                          table.

ComputerId                int                       Foreign               Id of the Front End
                                                                          Server used for this
                                                                          message. Referenced
                                                                          from the Computers
                                                                          table.

Body                      ntext                                           Content of the message
                                                                          body.

Reserved1                 tinyint                                         Reserved for Microsoft
                                                                          use.

Reserved2                 tinyint                                         Reserved for Microsoft
                                                                          use.



SessionDetails Table
Each record represents one peer-to-peer session, which could be a VoIP-VoIP phone call, 2-
party IM session, or other type of session. To find the modalities used during a session, you must
do a table join with the Media table. Session type is not stored in the SessionDetails table.


Column                          Data Type          Key/Index             Details

SessionIdTime                   datetime           Primary               Time of session
                                                                         request; used in
                                                                         conjunction with
                                                                         SessionIDSeq to
                                                                                               185
Column               Data Type   Key/Index   Details
                                             uniquely identify a
                                             session.

SessionIdSeq         int         Primary     ID number to identify
                                             the session. Used in
                                             conjunction with
                                             SessionIDTime to
                                             uniquely identify a
                                             session.

DialogId             Int         Foreign     SIP dialog ID,
                                             referenced from the
                                             Dialogs table.

User1Id              Int         Foreign     Id of one user in the
                                             session, referenced
                                             from the Users table.

User2Id              int         Foreign     Id of the other user in
                                             the session, referenced
                                             from the Users table.

SessionStartedById   int         Foreign     Id of the user who
                                             started the session,
                                             referenced from the
                                             Users table.

ComputerId           Int         Foreign     Id of the Front End
                                             Server used for this
                                             session.

PoolId               Int         Foreign     Id of the Pool in which
                                             the session was
                                             captured.

User1ClientVerId     Int         Foreign     Client version used by
                                             User1, referenced from
                                             the ClientVersions table.

User2ClientVerId     int         Foreign     Client version used by
                                             User2, referenced from
                                             the ClientVersions table.

InviteTime           datetime

ResponseTime         datetime

ResponseCode         Int                     SIP response code to

                                                                     186
Column                            Data Type          Key/Index             Details

                                                                           the session invitation.

SessionEndTime                    datetime


* For most sessions, SessionIdSeq will have the value of 1. If multiple sessions start at exactly
the same time, the SessionIdSeq for one will be 1, for another will be 2, and so on.


Messages Table
This table archives all messages sent during one-to-one IM sessions. Each record represents
one message.


Column                      Data Type              Key/Index              Details

MessageIdTime               datetime               Primary                Time the message was
                                                                          sent.

MessageIdSeq                int                    Primary                ID number to identify the
                                                                          message. Used in
                                                                          conjunction with
                                                                          MessageIdTime to
                                                                          uniquely identify a
                                                                          message. *

SessionIdTime               datetime               Primary, Foreign       Time of session request;
                                                                          used in conjunction with
                                                                          SessionIDSeq to
                                                                          uniquely identify a
                                                                          session.

SessionIdSeq                int                    Primary, Foreign       ID number to identify the
                                                                          session. Used in
                                                                          conjunction with
                                                                          SessionIDTime to
                                                                          uniquely identify a
                                                                          session.

FromId                      int                    Foreign                UserId of the user
                                                                          sending the message,
                                                                          referenced from the
                                                                          Users table.

Told                        int                    Foreign                UserId of the user
                                                                          receiving the message,
                                                                          referenced from the
                                                                          Users table.

                                                                                                    187
Column                     Data Type             Key/Index              Details

ContentTypeId              int                   Foreign                Unique number
                                                                        identifying this IM content
                                                                        type, referenced from the
                                                                        ContentTypes table.

ComputerId                 int                   Foreign                Id of the Front End
                                                                        Server used for this
                                                                        message, referenced
                                                                        from the Computers
                                                                        table.

Body                       ntext                                        Content of the message
                                                                        body.

Toast                      bit                                          TRUE is this message
                                                                        was a toast message.

ContextNote                Bit                                          TRUE is this message
                                                                        was a context note.

Reserved1                  tinyint                                      Reserved for Microsoft
                                                                        use.

Reserved2                  tinyint                                      Reserved for Microsoft
                                                                        use.


* For most sessions, MessageIdSeq will have the value of 1. If multiple messages are sent at
exactly the same time, the MessageIdSeq for one will be 1, for another will be 2, and so on.


CDR Database Schema
This section outlines the schema for the CDR database.


List of Tables
The database schema consists of the following tables.


Static Tables

Table                                            Description

MediaList                                        Stores the list of media types that can generate
                                                 entries in the database (for example, IM, audio,
                                                 video, and file transfer).

Roles                                            Stores the list of possible conference roles (for

                                                                                                188
Table                               Description

                                    example, attendee and presenter).

UserAuthTypes                       Stores the list of possible user authentication
                                    type (for example, enterprise, federated, PIC
                                    and anonymous).



Supporting Tables

Table                               Description

ClientVersions                      Stores the clients (both client type and version
                                    number) of each client involved in a call with
                                    information captured in this database.

Computers                           Stores the name of each computer that hosts a
                                    Front End Server.

Dialogs                             Stores information about the DialogID for each
                                    peer-to-peer session in the database.

Gateways                            Stores a list of Mediation Servers that are used
                                    for VoIP calls.

Pools                               Stores the names of pool on which IM
                                    messages are captured.

Phones                              Stores all the phone numbers used in VoIP
                                    calls that were archived or whose call details
                                    were recorded.

Mcus                                Stores information about the various
                                    conferencing servers and their URIs.

Users                               Stores the user URIs of users who have
                                    participated in sessions recorded or archived in
                                    this database.



Tables Specific to Conference CDR Records

Table                               Description

Conferences                         Stores information about all conferences that
                                    were archived or whose details were recorded,
                                    including ConferenceURI, and start and end


                                                                                     189
Table                               Description

                                    time.

FocusJoinsAndLeaves                 Stores information about conference joins and
                                    leaves, including users’ role and client version.

McuJoinsAndLeaves                   Stores information about conferencing servers
                                    that are involved in a conference, and the user
                                    join and leave times.



Tables for Messages in IM Conferences

Table                               Description

ConferenceMessageCount              For each IM conference, stores the number of
                                    messages that were sent by each user.



Tables for Peer-to-Peer Sessions

Table                               Description

SessionDetails                      Stores information about every peer-to-peer
                                    session, including start and end time, user ID,
                                    response code, and message count for each
                                    user.

FileTransfers                       Stores information about file transfer sessions,
                                    including file name and result (accepted,
                                    rejected, or cancelled).

Media                               Stores information about the different media
                                    types involved in peer-to-peer sessions.



Table for VoIP Call Details

Table                               Description

VoIPDetails                         For each two-party VoIP/PSTN call, stores
                                    information about the call (for example, the
                                    phone ID of VoIP phone, gateway used, and
                                    which party disconnected). Refers to the
                                    SessionDetails table for call start/end times and


                                                                                   190
Table                                              Description

                                                   response code.

                                                   Note:
                                                       If one party on a call is a VoIP user or if
                                                       a Mediation Server was involved in the
                                                       call, a record will be created in this
                                                       table. Information about VoIP/VoIP
                                                       calls not involving a PSTN phone is
                                                       captured in the SessionDetails table.



Tables for Troubleshooting

Table                                              Description

Application                                        Stores information about various processes
                                                   within Office Communications Server that are
                                                   involved in routing and connections.

ErrorDef                                           Stores information about types of errors and
                                                   their definitions.

ErrorReport                                        Stores information about errors that have
                                                   occurred.

ProgressReport                                     Stores information about the progress reports
                                                   of various steps involved in Office
                                                   Communications Server processes.


The tables in the following list are used internally by Office Communications Server; their details
are not described in this document.


Tables for Internal Use by Office Communications Server

Table                                              Description

DbConfigDateTime                                   For internal use only.

DbConfigInt                                        For internal use only.

DbErrorMessage                                     For internal use only.



Table Details
This section details the columns in each of the CDR database schema tables.
                                                                                                     191
MediaList Table
The MediaList table is a static table that stores the list of various media types.


Column                            MediaId                           Media

Data Type                         tinyint                           nvarchar(256)

Key/Index                         Primary

Static Values                     1                                 IM

                                  2                                 File Transfer

                                  3                                 Remote Assistance

                                  4                                 Application Sharing

                                  5                                 Audio

                                  6                                 Video

                                  7                                 App Invite

                                  8                                 Meeting

                                  9                                 Phone



Roles Table
The Roles table is a static table that stores the list of possible conference roles, such as attendee
and presenter.


Column                            RoleId                            Role

Data Type                         tinyint                           nvarchar(256)

Key/Index                         Primary

Static Values                     0                                 Unknown

                                  1                                 Presenter

                                  2                                 Attendee



UserAuthTypes Table
The UserAuthTypes table is a static table that stores the list of possible user authentication types,
such as enterprise, federated, Public IM Connectivity (PIC), and anonymous.




                                                                                                  192
Column                           AuthTypeId                         AuthType

Data Type                        int                                nvarchar(256)

Key/Index                        Primary

Static Values                    0                                  Unknown

                                 1                                  Enterprise

                                 2                                  Federated

                                 3                                  Anonymous

                                 4                                  Public IM Connectivity



ClientVersions Table
The ClientVersions table is a supporting table that stores a list of the various client types and
versions that have participated in sessions recorded in the database. Each record in the table
represents one client version.


Column                   Data Type                   Key/Index                 Details

VersionId                int                         Primary                   Unique number
                                                                               identifying this client
                                                                               type and version.

Version                  nvarchar(256)                                         Version name.



Computers Table
The Computers table is a supporting table that stores information about the various Front End
Servers. Each record in the table represents one Front End Server.


Column                    Data Type                  Key/Index                 Details

ComputerId                int                        Primary                   Unique number
                                                                               identifying this Front
                                                                               End Server.

Computer                  nvarchar(16)                                         Front End Server host
                                                                               name.




                                                                                                    193
Pools Table
The Pools table is a supporting table that stores information about the various Pools. Each record
in the table represents one Pool


Column                   Data Type                   Key/Index                 Details

PoolId                   int                         Primary                   Unique number
                                                                               identifying this Pool.

PoolFQDN                 nvarchar(256)                                         Pool FQDN.



Dialogs Table
The Dialogs table is a supporting table that stores the information about DialogIds for peer-to-
peer sessions.


Column                     Data Type              Key/Index          Details

DialogId                   int                    Primary            Unique number identifying this
                                                                     SIP dialog instance.

ExternalChecksum           Int                                       Checksum of the ExternalId.
                                                                     This field is used to increase
                                                                     the speed of database
                                                                     searches.

ExternalId                 varbinary(775)                            SIP dialog Id, stored as a
                                                                     binary. The format of the
                                                                     binary is:
                                                                     dialog;from-tag;to-tag
                                                                     This data can be converted to
                                                                     text format by using:
                                                                     cast(cast(ExternalId
                                                                     as varbinary(max)) as
                                                                     varchar(max))



Gateways Table
The Gateways table is a supporting table. Each record stores information about one Mediation
Server that is involved in calls that have records in the database.


Column                   Data Type                   Key/Index                 Details

GatewayId                int                         Primary                   Unique number
                                                                               identifying this

                                                                                                   194
Column                   Data Type                  Key/Index               Details

                                                                            Mediation Server.

Gateway                  nvarchar(256)                                      Mediation Server
                                                                            name.



Mcus Table
The Mcus table is a supporting table; each record stores the information about one conferencing
server. These can include the IM Conferencing Server and the Telephony Conferencing Server
(which run as processes on Front End Servers), and the Web Conferencing Server and A/V
Conferencing Server.


Column                  Data Type                  Key/Index                Details

McuId                   int                        Primary                  Unique number
                                                                            identifying this MCU
                                                                            server.

McuUri                  nvarchar(450)

McuType                 nvarchar(256)                                       MCU type (for
                                                                            example, chat (for
                                                                            IMs) or audio-video).



Users Table
The Users table is a supporting table; each record in the table stores information about one user
involved in calls or sessions that have records in the database.


Column                  Data Type                 Key/Index              Details

UserId                  int                       Primary                Unique number
                                                                         identifying this user.

UserUri                 nvarchar(450)

AuthTypeId              Int                       Foreign                Unique number
                                                                         identifying this user’s
                                                                         authentication type.
                                                                         Reference to
                                                                         UserAuthTypes table.




                                                                                                  195
Phones Table
The Phones table is a supporting table; each record in the table stores information about one
phone number involved in VoIP calls that have records in the database.


Column                  Data Type                   Key/Index              Details

PhoneId                 int                         Primary                Unique number
                                                                           identifying this phone.

PhoneUri                nvarchar(450)



Conferences Table
Each record in this table contains call details about one conference.


Column                         Data Type               Key/Index          Details

ConferenceUri                  nvarchar(450)

Checksum                       Int                                        Checksum of
                                                                          ConferenceURi; used
                                                                          to increases the speed
                                                                          of database searches.

ConfInstance                   Int                                        Useful for recurring
                                                                          conferences; each
                                                                          instance of a recurring
                                                                          conference has the
                                                                          same ConferenceUri,
                                                                          but will have a different
                                                                          ConfInstance.

SessionIdTime                  datetime                Primary            Time that the
                                                                          conference request
                                                                          was captured by the
                                                                          CDR agent. Used only
                                                                          as a primary key to
                                                                          uniquely identify a
                                                                          session.

SessionIdSeq                   int                     Primary            ID number to identify
                                                                          the session. Used in
                                                                          conjunction with
                                                                          SessionIDTime to
                                                                          uniquely identify a
                                                                          session. *

                                                                                                196
Column                            Data Type            Key/Index           Details

ConferenceStartTime               datetime

ConferenceEndTime                 datetime

PoolId                            Int                  Foreign             ID number to identify
                                                                           the pool in which the
                                                                           conference was
                                                                           captured. Reference to
                                                                           Pools table.

OrganizerId                       Int                  Foreign             ID number to identify
                                                                           the organizer URI of
                                                                           this conference.
                                                                           Reference to Users
                                                                           table.


* For most sessions, SessionIdSeq will have the value of 1. If two sessions start at exactly the
same time, the SessionIdSeq for one will be 1, and for the other will be 2, and so on.


FocusJoinsAndLeaves Table
Each record in this table contains the CDR information about one user’s join and leave
information for one conference. Each conference is represented in this table by one record for
each time a user joins and leaves the conference.


Column                      Data Type              Key/Index              Details

UserId                      int                    Primary, Foreign       Unique number
                                                                          identifying this user,
                                                                          referenced from the
                                                                          Users table.

UserInstance                Int                    Primary                If a user is logged on at
                                                                          multiple computers or
                                                                          devices at once,
                                                                          UserInstance is used to
                                                                          uniquely identify the
                                                                          user/device combination.

IsUserInternal              Bit                                           Whether the user logged
                                                                          on from internal or not.

UserRole                    Int                                           This user’s role in the
                                                                          conference.

SessionIdTime               datetime               Primary, Foreign       Time of session request;

                                                                                                    197
Column                      Data Type             Key/Index               Details
                                                                          used in conjunction with
                                                                          SessionIDSeq to
                                                                          uniquely identify a
                                                                          session. Referenced
                                                                          from the Conferences
                                                                          table.

SessionIdSeq                int                   Primary, Foreign        ID number to identify the
                                                                          session. Used in
                                                                          conjunction with
                                                                          SessionIDTime to
                                                                          uniquely identify a
                                                                          session. Referenced
                                                                          from the Conferences
                                                                          table.

UserJoinTime                datetime

UserLeaveTime               datetime

ClientVerId                 int                   Foreign                 Version of the user’s
                                                                          client software,
                                                                          referenced from the
                                                                          ClientVersions table.



McuJoinsAndLeaves Table
Each record in this table contains call details about one combination of a user join or leave and
MCU device. For example, if a user joins a conference that includes Web conferencing and
audio/video elements, one record would be created for that user’s Web conferencing join, and
another record would be created for the user’s audio/video join.


Column                      Data Type             Key/Index               Details

UserId                      int                   Primary, Foreign        Unique number
                                                                          identifying this user,
                                                                          referenced from the
                                                                          Users table.

UserInstance                Int                   Primary                 If a user is logged on at
                                                                          multiple computers or
                                                                          devices at once,
                                                                          UserInstance uniquely
                                                                          identifies the user/device


                                                                                                   198
Column                     Data Type             Key/Index             Details

                                                                       combination.

IsFromPstn                 Bit                                         Whether the user is
                                                                       joining from PSTN or
                                                                       not.

McuId                      Int                   Primary, Foreign      Unique number
                                                                       identifying this MCU
                                                                       device, referenced from
                                                                       the Mcus table.

SessionIdTime              datetime              Primary, Foreign      Time of session request;
                                                                       used in conjunction with
                                                                       SessionIDSeq to
                                                                       uniquely identify a
                                                                       session. Referenced
                                                                       from the Conferences
                                                                       table.

SessionIdSeq               int                   Primary, Foreign      ID number to identify the
                                                                       session. Used in
                                                                       conjunction with
                                                                       SessionIDTime to
                                                                       uniquely identify a
                                                                       session. Referenced
                                                                       from the Conferences
                                                                       table.

UserJoinTime               datetime

UserLeaveTime              datetime



ConferenceMessageCount Table
Each record in this table represents one user in one IM conference and includes the number of
messages sent by that user. Each conference is represented by multiple records in this table; one
record for each user.


Column                     Data Type             Key/Index             Details

SessionIdTime              datetime              Primary, Foreign      Time of session request;
                                                                       used in conjunction with
                                                                       SessionIDSeq to
                                                                       uniquely identify a
                                                                       session. Referenced

                                                                                              199
Column                     Data Type             Key/Index              Details
                                                                        from the Conferences
                                                                        table.

SessionIdSeq               int                   Primary, Foreign       ID number to identify the
                                                                        session. Used in
                                                                        conjunction with
                                                                        SessionIDTime to
                                                                        uniquely identify a
                                                                        session. Referenced
                                                                        from the Conferences
                                                                        table.

UserId                     int                   Primary, Foreign       Unique number
                                                                        identifying this user,
                                                                        referenced from the
                                                                        Users table.

MessageCount               smallint                                     The number of
                                                                        messages sent by this
                                                                        user during this
                                                                        conference.



SessionDetails Table
Each record represents one peer-to-peer session, which could be a VoIP-VoIP phone call, 2-
party IM session, or other type of session. To find the modalities used during a session, you must
do a table join with the Media table. Session type is not stored in the SessionDetails table.


Column                           Data Type             Key/Index           Details

SessionIdTime                    datetime              Primary             Time of session
                                                                           request; used in
                                                                           conjunction with
                                                                           SessionIDSeq to
                                                                           uniquely identify a
                                                                           session.

SessionIdSeq                     int                   Primary             ID number to identify
                                                                           the session. Used in
                                                                           conjunction with
                                                                           SessionIDTime to
                                                                           uniquely identify a
                                                                           session. *


                                                                                                 200
Column               Data Type          Key/Index   Details

DialogId             Int                Foreign     SIP dialog ID,
                                                    referenced from the
                                                    Dialogs table.

CorrelationId        uniqueidentifier               A GUID to correlate
                                                    multiple sessions.

ReplaceDialogId      Int                Foreign     ID number to identify
                                                    the dialog which was
                                                    replaced by current
                                                    session. Reference to
                                                    Dialogs table

User1Id              Int                Foreign     Id of one user in the
                                                    session, referenced
                                                    from the Users table.

User2Id              int                Foreign     Id of the other user in
                                                    the session,
                                                    referenced from the
                                                    Users table.

TargetUserId         Int                            The original To user
                                                    URI in SIP request.
                                                    Reference to Users
                                                    table.

SessionStartedById   int                Foreign     Id of the user who
                                                    started the session,
                                                    referenced from the
                                                    Users table.

OnBehalfOfId         Int                            Indicate the Id of the
                                                    user of who the caller
                                                    is on behalf.
                                                    Reference Users table.

ReferredById         Int                Foreign     Id of the user by who
                                                    the call is referred.

ComputerId           Int                Foreign     Id of the Front End
                                                    Server used for this
                                                    session.

PoolId                                  Foreign     Id of the Pool in which
                                                    the session was
                                                    captured.

                                                                           201
Column                        Data Type                 Key/Index           Details

User1ClientVerId              Int                       Foreign             Client version used by
                                                                            User1, referenced
                                                                            from the
                                                                            ClientVersions table.

User2ClientVerId              int                       Foreign             Client version used by
                                                                            User2, referenced
                                                                            from the
                                                                            ClientVersions table.

IsUser1Internal               Bit                                           Whether user1 is
                                                                            logged on from internal
                                                                            or not.

IsUser2Internal               Bit                                           Whether user2 is
                                                                            logged on from internal
                                                                            or not.

InviteTime                    datetime

ResponseTime                  datetime

ResponseCode                  Int                                           SIP response code to
                                                                            the session invitation.

DianosticId                   Int                                           Diagnostic Id captured
                                                                            from SIP header.

User1MessageCount             Int                                           Number of messages
                                                                            sent by User1 during
                                                                            the session.

User2MessageCount             Int                                           Number of messages
                                                                            sent by User2 during
                                                                            the session.

SessionEndTime                datetime


* For most sessions, SessionIdSeq will have the value of 1. If multiple sessions start at exactly
the same time, the SessionIdSeq for one will be 1, for another will be 2, and so on.


FileTransfers Table
Each record represents one file transfer session.




                                                                                                    202
Column          Data Type       Key/Index          Details

SessionIdTime   datetime        Primary, Foreign   Time of session
                                                   request; used in
                                                   conjunction with
                                                   SessionIDSeq to
                                                   uniquely identify a
                                                   session.

SessionIdSeq    int             Primary, Foreign   ID number to identify
                                                   the session. Used in
                                                   conjunction with
                                                   SessionIDTime to
                                                   uniquely identify a
                                                   session.

FileName        nvarchar(256)

Cookie          int             Primary            Random number
                                                   between 1 and
                                                   4,294,967,295 (2^32 -
                                                   1)). Used to identify
                                                   every follow-up
                                                   message as being
                                                   associated with this
                                                   one.

Accept          bit                                Can be TRUE or NULL.
                                                   If TRUE, then Reject
                                                   and Cancel will be
                                                   NULL.

Reject          bit                                Can be TRUE or NULL.
                                                   If TRUE, then Accept
                                                   and Cancel will be
                                                   NULL.

Cancel          bit                                Can be TRUE or NULL.
                                                   If TRUE, then Accept
                                                   and Reject will be
                                                   NULL.


bit




                                                                           203
Media Table
Each record represents one media type used in a peer-to-peer session. One session would be
represented by multiple records in the table, if more than one media type is used.


Column                     Data Type             Key/Index              Details

SessionIdTime              datetime              Primary, Foreign       Time of session request;
                                                                        used in conjunction with
                                                                        SessionIDSeq to
                                                                        uniquely identify a
                                                                        session.

SessionIdSeq               int                   Primary, Foreign       ID number to identify the
                                                                        session. Used in
                                                                        conjunction with
                                                                        SessionIDTime to
                                                                        uniquely identify a
                                                                        session.

MediaId                    tinyint               Primary, Foreign       Unique number
                                                                        identifying this media
                                                                        type, referenced from the
                                                                        MediaList table.

StartTime                  datetime              Primary

EndTime                    datetime



VoipDetails Table
Each record represents one two-party call in which at least one user is a VoIP user.


Column                               Data Type       Key/Index            Details

SessionIdTime                        datetime        Primary, Foreign     Time of session
                                                                          request; used in
                                                                          conjunction with
                                                                          SessionIDSeq to
                                                                          uniquely identify a
                                                                          session.

SessionIdSeq                         int             Primary, Foreign     ID number to identify
                                                                          the session. Used in
                                                                          conjunction with
                                                                          SessionIDTime to
                                                                          uniquely identify a

                                                                                                204
Column                          Data Type           Key/Index           Details

                                                                        session.

FromNumberId                    int                 Foreign             PhoneId of the caller,
                                                                        referenced from the
                                                                        Phones table. If NULL,
                                                                        the caller was a PSTN
                                                                        user.

ConnectedNumberId               int                 Foreign             PhoneId of the call
                                                                        receiver, referenced
                                                                        from the Phones table.
                                                                        If NULL, the receiver
                                                                        was a PSTN user.

FromGatewayId                   int                 Foreign             Mediation Server the
                                                                        call is coming from,
                                                                        referenced from the
                                                                        Gateways table.

ToGatewayId                     Int                 Foreign             Mediation Server called
                                                                        is going to, reference to
                                                                        Gateways table.

DisconnectedbyURIId             int                 Foreign             URI of the user who
                                                                        disconnected the call, if
                                                                        the user has a URI.
                                                                        Referenced from the
                                                                        Users table.

DisconnectedbyPhoneId           int                 Foreign             ID of the phone that
                                                                        disconnected the call if
                                                                        the call was
                                                                        disconnected from a
                                                                        phone. Referenced
                                                                        from the Phones table.



Application Table
This table stores information about the various processes within Office Communications Server
involved in routing and connections.


Column                   Data Type                 Key/Index             Details

ApplicationId            int                       Primary               Unique number
                                                                         identifying this

                                                                                             205
Column                    Data Type                  Key/Index              Details

                                                                            application.

Name                      nvarchar(257)



ErrorDef Table
This table stores information about each type of error that may occur. Each record is one type of
error.
ErrorDef Table


Column                  Data Type              Key/Index          Details

ErrorId                 int                    Primary            Unique ID number identifying
                                                                  this type of error.

ResponseCode            int                                       Standard SIP response code
                                                                  associated with this error.

MsDiagId                int                                       Microsoft Diagnostic ID.

RequestType             varbinary(33)                             Type of request that failed.
                                                                  This data can be converted to
                                                                  text format by using:
                                                                  cast(cast(RequestType
                                                                  as varbinary(max)) as
                                                                  varchar(max))

ContentType             varbinary(257)                            Content type of the request that
                                                                  failed.
                                                                  This data can be converted to
                                                                  text format using:
                                                                  cast(cast(ContentType
                                                                  as varbinary(max)) as
                                                                  varchar(max))



ErrorReport Table
This table stores information about errors that have occurred. Each record is one error
occurrence.


Column                    Data Type            Key/Index             Details

ErrorTime                 datetime             Primary               Date and time the error
                                                                     occurred.

                                                                                                 206
Column                    Data Type            Key/Index              Details

ErrorId                   int                  Primary, Foreign       Unique ID of the error type,
                                                                      referenced from the
                                                                      ErrorDef table.

FromUserId                int                  Foreign                User who originated the
                                                                      request that caused the
                                                                      error. Referenced from the
                                                                      Users table.

ToUserId                  int                  Foreign                Destination user for the
                                                                      request that caused the
                                                                      error. Referenced from the
                                                                      Users table.

DialogId                  int                  Foreign                Referenced from the
                                                                      Dialogs table.

MsDiagHeader              image                                       More information about the
                                                                      error.
                                                                      This data can be converted
                                                                      to text format using:
                                                                      cast(cast(Detail as
                                                                      varbinary(max)) as
                                                                      varchar(max))



ProgressReport Table
Progress reports are based on data uploaded by the client to the database after a call or session
is completed. Progress reports will be written only for calls and sessions that Office
Communications Server determines might be useful for diagnostic purposes.
The ErrorTime and ErrorId fields do not necessarily refer to errors but to messages that indicate
the status of calls or messages.


Column                          Data Type        Key/Index            Details

ErrorTime                       datetime         Primary, Foreign     Date and time of the
                                                                      progress report.

ErrorId                         int              Primary, Foreign     Unique ID of the error type,
                                                                      referenced from the
                                                                      ErrorDef table.

ProgressReportSeq               int              Primary              ID number to identify the
                                                                      progress report. Used in


                                                                                                207
Column                         Data Type        Key/Index             Details
                                                                      conjunction with ErrorTime
                                                                      to uniquely identify a
                                                                      session.

ApplicationId                  int              Foreign               The Office
                                                                      Communications Server
                                                                      process that the report is
                                                                      about. Referenced from the
                                                                      Application table.

Detail                         image                                  Progress report details,
                                                                      stored in binary format to
                                                                      save space.
                                                                      This data can be converted
                                                                      to text format using:
                                                                      cast(cast(Detail as
                                                                      varbinary(max)) as
                                                                      varchar(max))


bit


Sample Database Queries
This section contains sample queries for the CDR database. The CDR Reporter tool in the Office
Communications Server 2007 Resource Kit has more.
To find the total number of PSTN to UC Calls:
Select Count(*) as 'Number Of PSTN to UC Calls' From VoipDetails as
voipd Join SessionDetails as sd on (voipd.SessionIdTime =
sd.SessionIdTime and voipd.SessionIdSeq = sd.SessionIdSeq and
sd.User1Id is null)           and FromNumberId in (SELECT PhoneId from Phones)
and GatewayId is not null
To find the total numbers of conferences that used Meeting Console:
SELECT count(distinct(c.ConferenceUri)) as DataMCU Conferences from                           as
mj inner join as m on (m.McuId = mj.McuId) inner join as c on
(c.SessionIdTime = mj.SessionIdTime and c.SessionIdSeq =
mj.SessionIdSeq) where m.McuType=meeting
RequestType = PKCS10
To find the total number of redirected calls:
SELECT count(*) as Number of Redirected Calls from VoipDetails where
ReferredById is not null


                                                                                               208
QoE Database Schema
This documents the schema of the QoE database in Office Communications Server 2007 R2.
In This Section


   List of Tables
   Table Details
   Sample Database Queries


List of Tables
The database schema consists of the following tables.
Supporting Tables


Table                                           Description

UserAgent Table                                 Stores SIP User Agent (UA) strings and UA
                                                types used in audio and video sessions.

User Table                                      Stores user, conference, and phone URIs used
                                                in audio and video sessions.

Endpoint Table                                  Stores FQDN computer names of endpoints
                                                participating in audio and video sessions.

Pool Table                                      Stores the names of pools to which metrics
                                                data belongs.

Device Table                                    Stores capture devices and render devices
                                                which are used in an audio/video calls.

Conference Table                                Stores Conference URIs for conference
                                                scenarios, or DialogID for other scenarios.

SessionCorrelation Table                        Stores CorrelationID for PSTN calls.


Tables for metrics data


Table                                           Description

Session Table                                   Stores overall information about an audio or
                                                audio/video session. A session is defined as an
                                                audio or video SIP dialog between two
                                                endpoints.

MediaLine Table                                 Stores information about each media line in a
                                                session. A media line is a collection of one or
                                                more audio and video streams. Typically, a
                                                                                              209
Table                                          Description
                                               single media line will have two streams, either
                                               audio or video.

AudioStream Table                              Stores audio media quality metrics for each
                                               audio stream in the media line.

VideoStream Table                              Stores video media quality metrics for each
                                               audio stream in the media line.


Tables for Internal Use by Monitoring Server


Table                                           Description

DbConfigDateTime                                For internal use only.

DbConfigInt                                     For internal use only.

DbErrorMessage                                  For internal use only.

MSFT_SIPQMSDBConfigSetting                      For internal use only.

MSFT_SIPQMSDynamicSubnet                        For internal use only.

MSFT_SIPQMSMonitoredAVMCU                       For internal use only.

MSFT_SIPQMSMonitoredMediationServer             For internal use only.

MSFT_SIPQMSSingleMaskSubnet                     For internal use only.

MSFT_SIPQMSStaticLocation                       For internal use only.

MSFT_SIPQMSStaticSubnet                         For internal use only.



Table Details
These sections detail the columns in each of the QoE database schema tables.
   UserAgent Table
   User Table
   Endpoint Table
   Pool Table
   Device Table
   Conference Table
   SessionCorrelation Table
   Session Table
   MediaLine Table


                                                                                             210
   AudioStream Table
   VideoStream Table

UserAgent Table
The UserAgent table is a supporting table that stores a list of the various User Agents that have
participated in sessions recorded in the database. Each record in the table represents one User
Agent


Column                    Data Type                 Key/Index            Details

UserAgentKey              int                       Primary              Unique number
                                                                         identifying this user
                                                                         agent.

UserAgent                 nvarchar(256)             Unique               User Agent string.

UAType                    smallint                                       1 is Mediation Server.
                                                                         2 is A/V Conferencing
                                                                         Server.
                                                                         4 is Office
                                                                         Communicator.
                                                                         8 is IP Phone.
                                                                         16 is Live Meeting
                                                                         Console.
                                                                         32 is Deployment
                                                                         Validation Tool (DVT).
                                                                         64 is Office
                                                                         Communicator on
                                                                         Macintosh computers.
                                                                         128 is Office
                                                                         Communications Server
                                                                         R2 Attendant.
                                                                         256 is Conferencing
                                                                         Announcement Service.
                                                                         512 is Conferencing
                                                                         Auto Attendant.
                                                                         1024 is Response Group
                                                                         Service.
                                                                         2048 is Outside Voice
                                                                         Control.

NextUpdateTS              Datetime                                       For internal use only.


                                                                                                  211
User Table
The User table is a supporting table that stores a list of the various users who have participated in
sessions recorded in the database. Each record in the table represents one user.


Column                     Data Type                  Key/Index               Details

UserKey                    int                        Primary                 Unique number
                                                                              identifying this user.

URI                        nvarchar(450)              Unique                  URI string

URIType                    int                                                1 is unknown URI
                                                                              type, 2 is user URI, 4
                                                                              is conference URI,
                                                                              and 8 is phone URI.

NextUpdateTS               Datetime                                           For internal use only.


Endpoint Table
The Endpoint table is a supporting table that stores information about the endpoints that have
participated in sessions recorded in the database. Each record in the table represents one
endpoint


Column                      Data Type                  Key/Index              Details

EndpointKey                 int                        Primary                Unique number
                                                                              identifying this
                                                                              endpoint.

Name                        nvarchar(256)              Unique                 Endpoint name.

NextUpdateTS                Datetime                                          For internal use only.


Pool Table
The Pool table is a supporting table that stores information about the various Enterprise pools.
Each record in the table represents one pool


Column                      Data Type                  Key/Index              Details

PoolKey                     int                        Primary                Unique number
                                                                              identifying this pool.

PoolName                    nvarchar(256)                                     Pool FQDN

NextUpdateTS                datetime                                          For internal use only.



                                                                                                   212
Device Table
The Device table is a supporting table that stores information about the various capture or render
devices. Each record in the table represents one device.


Column                    Data Type                 Key/Index               Details

DeviceKey                 Int                       Primary                 Unique number
                                                                            identifying this device

DeviceName                nvarchar(256)             DeviceName +            Device name.
                                                    DeviceType is unique

DeviceType                Bit                       DeviceName +            DeviceType, 1 is a
                                                    DeviceType is unique    capture device, 0 is a
                                                                            render device.

NextUpdateTS              Datetime                                          For internal use only.


Conference Table
The Conference table is a supporting table. Each record represents one conference or peer-to-
peer session.


Column                     Data Type                  Key/Index             Details

ConferenceKey              Int                        Primary               Unique number
                                                                            identifying this
                                                                            Conference record.

ConfURI                    nvarchar(450)              unique                Conference URI is
                                                                            this is a conference,
                                                                            or DialogID if this is a
                                                                            peer-to-peer session.

NextUpdateTS               Datetime                                         For internal use only.


SessionCorrelation Table
The SessionCorrelation table is a supporting table; each record represents one CorrelationID
which is used to correlate multiple sessions.


Column                     Data Type                 Key/Index             Details

CorrelationKey             int                       Primary               Unique number
                                                                           identifying this
                                                                           conferencing server.

CorrelationID              nvarchar(256)             unique                Sessions that are

                                                                                                 213
Column                    Data Type                Key/Index             Details
                                                                         correlated will have the
                                                                         same CorrelationID.

NextUpdateTS              Datetime                                       For internal use only.


Session Table
Each record represents one session which involves audio or audio/video; it contains overall
information about the session. A session is defined as an audio or video SIP dialog between two
endpoints.


Column                       Data Type            Key/Index         Details

ConferenceDateTime           Datetime             Primary           Time when the QoE agent
                                                                    receives the first report
                                                                    from either caller or callee;
                                                                    used in conjunction with
                                                                    SessionSeq to uniquely
                                                                    identify a session.

SessionSeq                   Int                  Primary           Sequence number to
                                                                    differentiate sessions when
                                                                    they have the same
                                                                    ConferenceDateTime.

SessionID                    varchar(256)                           DialogID which is globally
                                                                    unique.

Checksum                     Int                  Index             Checksum of SessionID, for
                                                                    internal use only.

ConferenceKey                Int                  Foreign           Conference key, referenced
                                                                    from the Conference Table.

CorrelationKey               Int                  Foreign           Correlation key, referenced
                                                                    from the SessionCorrelation
                                                                    Table.

DialogCategory               bit                                    Dialog category; 0 is OCS
                                                                    to Mediation Server Leg, 1
                                                                    is Mediation Server to
                                                                    PSTN gateway leg.

StartTime                    Datetime                               Call start time.

EndTime                      datetime                               Call end time.

CallerPool                   Int                  Foreign           The pool of the caller,

                                                                                               214
Column                       Data Type            Key/Index         Details
                                                                    referenced from the Pool
                                                                    Table.

CalleePool                   Int                  Foreign           The pool of the call
                                                                    receiver, referenced from
                                                                    the Pool Table.

CallerPAI                    Int                  Foreign           SIP URI in the SIP p-
                                                                    asserted identity (PAI) from
                                                                    the calling endpoint,
                                                                    referenced from the User
                                                                    Table.

CalleePAI                    int                  Foreign           SIP URI in the SIP p-
                                                                    asserted identity (PAI) of
                                                                    the receiving endpoint,
                                                                    referenced from the User
                                                                    Table.

CallerURI                    Int                  Foreign           Caller’s URI, referenced
                                                                    from the User Table.

CalleeURI                    int                  Foreign           Call receiver’s URI,
                                                                    referenced from the User
                                                                    Table.

CallerEndpoint               Int                  Foreign           Caller’s endpoint,
                                                                    referenced from the
                                                                    Endpoint Table.

CalleeEndpoint               int                  Foreign           Call receiver’s endpoint,
                                                                    referenced from the
                                                                    Endpoint Table.

CallerUserAgent              Bit                  Foreign           Caller’s user agent,
                                                                    referenced from the
                                                                    UserAgent Table.

CalleeUserAgent              Bit                  Foreign           Call receiver’s user agent,
                                                                    referenced from the
                                                                    UserAgent Table.


MediaLine Table
Each record represents one media line. (One audio session usually contains one audio media
line. One audio/video session usually contains one audio media line and one video media line,


                                                                                                215
although the session might contains two video media lines if the Microsoft RoundTable
conferencing device is used)


Column                              Data Type          Key/Index      Details

ConferenceDateTime                  Datetime           Primary        Referenced from Session
                                                                      Table.

SessionSeq                          Int                Primary        Referenced from Session
                                                                      Table.

MediaLineLabel                      tinyint            Primary        0 is main audio, 1 is main
                                                                      video, and 2 is panoramic
                                                                      video. This label must be
                                                                      unique within a single
                                                                      session.

ConnectivityIce                     tinyint                           Information about media
                                                                      path, such as direct or
                                                                      relayed.
                                                                      1 is DIRECT
                                                                      2 is RELAY
                                                                      4 is HTTP
                                                                      8 is FAILED

CallerIceWarningFlags               Int                               Information about ICE
                                                                      process described in bits
                                                                      flags. For more details,
                                                                      refer to the Quality of
                                                                      Experience Monitoring
                                                                      Server Protocol
                                                                      Specification, available
                                                                      for download.

CalleeIceWarningFlags               int                               Same as
                                                                      CallerIceWarningFlags,
                                                                      but on Callee side. For
                                                                      more details, refer to the
                                                                      Quality of Experience
                                                                      Monitoring Server
                                                                      Protocol Specification,
                                                                      available for download.

Offerer                             bit                               Not used.

Answerer                            bit                               Not used.


                                                                                              216
Column                        Data Type      Key/Index   Details

Security                      Tinyint                    The security profile in
                                                         use. 0 os NONE, 1 is
                                                         SRTP, 2 is V1.

Transport                     Tinyint                    0 is UDP, 1 is TCP.

CallerIPAddr                  Int                        IP Address of the caller.

CallerPort                    Int                        Port used by the caller.

CallerSubnetMask              int                        The subnet mask of the
                                                         caller.

CallerInside                  bit                        1 means caller is inside
                                                         the enterprise network, 0
                                                         means the caller is
                                                         outside the network.

CallerRelayIPAddr             int                        IP Address of the A/V
                                                         Edge service used by the
                                                         caller.

CallerRelayPort               Int                        Port used on the A/V
                                                         Edge service by the
                                                         caller.

CallerRelaySubnetMask         Int                        Subnet Mask of the A/V
                                                         Edge service used by the
                                                         caller.

CallerRelayInside             bit                        Not used.

CallerCaptureDev              int            foreign     Capture device used by
                                                         the caller, referenced
                                                         from the Device Table

CallerRenderDev               Int            foreign     Render device used by
                                                         caller, referenced from
                                                         Device table.

CallerCaptureDevDriver        varchar(256)               Driver for the caller’s
                                                         capture device.

CallerRenderDevDriver         varchar(256)               Driver for the caller’s
                                                         render device .

CallerNetworkConnectionType   tinyint                    The caller's network
                                                         connection type; 0 is
                                                         Wired, 1 is wireless.

                                                                                   217
Column                  Data Type       Key/Index   Details

CallerVPN               bit                         The Caller's link; 1 is
                                                    virtual private network
                                                    (VPN), 0 is non-VPN.

CallerLinkSpeed         decimal(18,0)               The network link speed in
                                                    bps for the caller's
                                                    endpoint.

CalleeIPAddr            bit                         IP Address of the call
                                                    receiver.

CalleePort              Bit                         Port used by the call
                                                    receiver.

CalleeSubnetMask        bit                         Subnet Mask of the A/V
                                                    Edge service used by the
                                                    call receiver.

CalleeInside            Bit                         1 means call receiver is
                                                    inside the enterprise
                                                    network, 0 means the call
                                                    receiver is outside the
                                                    network.

CalleeRelayIPAddr       Int                         IP Address of the A/V
                                                    Edge service used by the
                                                    call receiver.

CalleeRelayPort         Int                         Port used on the A/V
                                                    Edge Service by the call
                                                    receiver.

CalleeRelaySubnetMask   Int                         Subnet mask of the A/V
                                                    Edge service used by the
                                                    call receiver.

CalleeRelayInside       Bit                         Not used,

CalleeCaptureDev        Int             foreign     Capture device used by
                                                    the call receiver,
                                                    referenced from the
                                                    Device Table.

CalleeRenderDev         Int             foreign     Render device used by
                                                    the call receiver,
                                                    referenced from the
                                                    Device Table.


                                                                              218
Column                             Data Type          Key/Index     Details

CalleeCaptureDevDriver             varchar(256)                     Driver for the the call
                                                                    receiver’s capture device.

CalleeRenderDevDriver              varchar(256)                     Driver for the the call
                                                                    receiver’s render device.

CalleeNetworkConnectionType        tinyint                          The call receiver's
                                                                    network connection type;
                                                                    0 is Wired, 1 is wireless.

CalleeVPN                          bit                              The call receiver’s link; 1
                                                                    is virtual private network
                                                                    (VPN), 0 is non-VPN.

CalleeLinkSpeed                    decimal(18,0)                    The network link speed in
                                                                    bps for the call receiver’s
                                                                    endpoint.

ConversationalMOS                  decimal(3,2)                     Narrowband
                                                                    Conversational MOS of
                                                                    the audio sessions
                                                                    (based on both audio
                                                                    streams).

ConversationalMOSAlg               varchar(256)                     Not used.

Caller                             Bit                              Indicate whether metrics
                                                                    from the caller were
                                                                    received; 1 is yes, 0 is no.

Callee                             bit                              Indicate whether metrics
                                                                    from the call receiver
                                                                    were received; 1 is yes, 0
                                                                    is no.


AudioStream Table
Each record represents one audio stream. One audio media line usually contains two audio
streams.


Column                                   Data Type      Key/Index      Details

ConferenceDateTime                       Datetime       primary        Referenced from the
                                                                       MediaLine Table.

SessionSeq                               Int            primary        Referenced from the
                                                                       MediaLine Table.

                                                                                            219
Column                  Data Type      Key/Index   Details

MediaLineLabel          tinyint        primary     Referenced from the
                                                   MediaLine Table.

StreamID                int            primary     Unique ID within a
                                                   media line.

JitterInterArrival      Int                        Average Network jitter
                                                   from Real Time Control
                                                   Protocol (RTCP)
                                                   statistics.

JitterInterArrivalMax   Int                        Maximum Network
                                                   Jitter during the call.

PacketLossRate          decimal(5,4)               Average packet loss
                                                   rate during the call.

PacketLossRateMax       decimal(5,4)               Maximum packet loss
                                                   observed during the
                                                   call.

BurstDensity            decimal(9,4)               Average density of
                                                   packet Loss during
                                                   bursts of losses during
                                                   the call.

BurstDuration           Int                        Average duration of
                                                   packet loss during
                                                   bursts of losses during
                                                   the call.

BurstGapDensity         decimal(9,4)               Average density of
                                                   packet loss during
                                                   gaps between bursts of
                                                   packet loss.

BurstGapDuration        Int                        Average duration of
                                                   gaps between bursts of
                                                   packet loss.

PacketUtilization       Int                        Packet count for the
                                                   audio stream.

BandwidthEst            Int                        Bandwidth estimates
                                                   for the audio stream.

DegradationAvg          decimal(3,2)               Network MOS
                                                   Degradation for the

                                                                          220
Column                      Data Type      Key/Index   Details
                                                       whole call. Range is
                                                       0.0 to 5.0. This metric
                                                       shows the amount the
                                                       Network MOS was
                                                       reduced because of
                                                       jitter and packet loss.
                                                       For acceptable quality
                                                       it should less than 0.5.

DegradationMax              decimal(3,2)               Maximum Network
                                                       MOS degradation
                                                       during the call.

DegradationJitterAvg        decimal(3,2)               Network MOS
                                                       degradation caused by
                                                       Jitter.

DegradationPacketLossAvg    decimal(3,2)               Network MOS
                                                       degradation caused by
                                                       packet loss.

AudioPayloadDescription     varchar(256)               The audio codec used
                                                       for the call.

AudioPayloadType            int                        Not used.

AudioSampleRate             int                        Sampling rate for the
                                                       audio stream.

InboundAudioSignalLevel *   int                        Represents the Post-
                                                       Analog Gain Control
                                                       audio signal level. The
                                                       unit for this metric is
                                                       dBmo. For acceptable
                                                       quality it should be at
                                                       least 30 dBmo. This
                                                       metric is not reported
                                                       by the A/V
                                                       Conferencing Server or
                                                       IP phones. This is
                                                       reported by the
                                                       Mediation Server on
                                                       approximately 2% of
                                                       the calls on the
                                                       Mediation Server to


                                                                            221
Column                          Data Type   Key/Index   Details

                                                        gateway leg.

InboundAudioNoiseLevel *        int                     Represents the Post-
                                                        Analog Gain Control
                                                        audio noise level. The
                                                        unit for this metric is
                                                        dBmo. For acceptable
                                                        quality it should be less
                                                        than 35 dBmo. This
                                                        metric is not reported
                                                        by the A/V
                                                        Conferencing Server or
                                                        IP phones. This is
                                                        reported by the
                                                        Mediation Server on
                                                        approximately 2% of
                                                        the calls on the
                                                        Mediation Server to
                                                        gateway leg.

InboundAudioSignalEchoReturn*   int                     Echo Return Loss
                                                        Enhancement metric.
                                                        The unit for this metric
                                                        is dB. Lower values
                                                        represent less echo.
                                                        This metric is not
                                                        reported by the A/V
                                                        Conferencing Server or
                                                        IP phones. This is
                                                        reported by the
                                                        Mediation Server on
                                                        approximately 2% of
                                                        the calls on the
                                                        Mediation Server to
                                                        gateway leg.

OutboundAudioSignalLevel*       int                     Represents the Post
                                                        Analog Gain Control
                                                        audio Signal level. The
                                                        unit for this metric is
                                                        dBmo. For acceptable
                                                        quality it should be at
                                                        least dBmo. This
                                                        metric is not reported

                                                                             222
Column                           Data Type   Key/Index   Details
                                                         by the A/V
                                                         Conferencing Server or
                                                         IP phones. This is
                                                         reported by the
                                                         Mediation Server on
                                                         approximately 2% of
                                                         the calls on the
                                                         Mediation Server to
                                                         gateway leg.

OutboundAudioNoiseLevel*         int                     Represent the Post
                                                         Analog Gain control
                                                         audio noise level. The
                                                         unit for this metric is
                                                         dBmo. For acceptable
                                                         quality it should be less
                                                         than 35 dBmo. This
                                                         metric is not reported
                                                         by the A/V
                                                         Conferencing Server or
                                                         IP phones. This is
                                                         reported by the
                                                         Mediation Server on
                                                         approximately 2% of
                                                         the calls on the
                                                         Mediation Server to
                                                         gateway leg.

OutboundAudioSignalEchoReturn*   int                     Echo Return Loss
                                                         Enhancement metric.
                                                         The unit for this metric
                                                         is dB. Lower values
                                                         represent less echo.
                                                         This metric is not
                                                         reported by the A/V
                                                         Conferencing Server or
                                                         IP phones. This is
                                                         reported by the
                                                         Mediation Server on
                                                         approximately 2% of
                                                         the calls on the
                                                         Mediation Server to
                                                         gateway leg.

                                                                              223
Column                         Data Type   Key/Index   Details

AudioSpeakerFeedbackMicIn*     int                     This is the microphone
                                                       input level from the
                                                       loudspeaker signal
                                                       which comes from the
                                                       far end. The unit is
                                                       dBoV. For acceptable
                                                       quality this value
                                                       should be less than 20
                                                       dBoV. If this number is
                                                       too high, it means that
                                                       the near end
                                                       microphone is getting
                                                       too much feedback
                                                       from the near end
                                                       loudspeaker. Not
                                                       reported by A/V
                                                       Conferencing Servers,
                                                       Mediation Servers, or
                                                       IP phones.

AudioSpeechLevelMicIn*         int                     This is the speech level
                                                       into the microphone at
                                                       the near end. The unit
                                                       is dBoV. For
                                                       acceptable quality it
                                                       should be between -18
                                                       dBoV and -35 dBoV, if
                                                       greater than -18 dBoV,
                                                       then signal clipping or
                                                       echo is occurring when
                                                       both parties talk. If it is
                                                       less than -35 dBoV,
                                                       then speech might be
                                                       distorted. Not reported
                                                       by A/V Conferencing
                                                       Servers, Mediation
                                                       Servers, or IP phones.

AudioSpeechLevelPostProcess*   int                     Overall average
                                                       speech level sent to
                                                       the far end (after signal
                                                       processing) from the
                                                       near end. The unit for

                                                                              224
Column                         Data Type   Key/Index   Details
                                                       this metric is dBoV. For
                                                       acceptable quality it
                                                       should be within [-30 to
                                                       -18] dBoV. Not
                                                       reported by A/V
                                                       Conferencing Servers,
                                                       Mediation Servers, or
                                                       IP phones.

AudioSignalLevelLoudSpeaker*   int                     Speaker/Headphone
                                                       input level (at the near
                                                       end). The unit for this
                                                       metric is dBoV. For
                                                       acceptable quality it
                                                       should range between
                                                       [-35 to -15] dBoV. If
                                                       too high there may be
                                                       clipping. If too low then
                                                       there might be low
                                                       volume issues. Not
                                                       reported by A/V
                                                       Conferencing Servers,
                                                       Mediation Servers, or
                                                       IP phones.

AudioBackGroundNoiseMicIn*     int                     Background Noise
                                                       Input to the
                                                       microphone at the near
                                                       end. The unit for this
                                                       metric is dBoV. For
                                                       acceptable quality the
                                                       range should be less
                                                       than -35 dBoV. If
                                                       noise is too high, this
                                                       indicates a bad device
                                                       or bad device setup
                                                       which is degrading
                                                       audio quality. Not
                                                       reported by A/V
                                                       Conferencing Servers,
                                                       Mediation Servers, or
                                                       IP phones.



                                                                            225
Column                      Data Type   Key/Index   Details

AudioBackGroundNoiseSent*   int                     Background noise left
                                                    over after noise
                                                    suppression. This is
                                                    the noise sent to the
                                                    far end. The unit for
                                                    this is dBoV. For
                                                    acceptable call quality
                                                    this should be less
                                                    than -45 dBoV. Not
                                                    reported by A/V
                                                    Conferencing Servers,
                                                    Mediation Servers, or
                                                    IP phones.

AudioLocalSpeechToEcho*     int                     This the ratio of speech
                                                    to echo. The unit for
                                                    this is dB. For
                                                    acceptable quality it
                                                    should be greater than
                                                    10 dB. If less than
                                                    10dB then speech level
                                                    is too low compared to
                                                    echo level, and
                                                    distorted speech might
                                                    occur. Not reported by
                                                    A/V Conferencing
                                                    Servers, Mediation
                                                    Servers, or IP phones.

AudioSpeakerGlitchRate      int                     Average glitches per 5
                                                    minutes for the
                                                    loudspeaker rendering.
                                                    For good quality, this
                                                    should be less than 1
                                                    per 5 minutes. Not
                                                    reported by A/V
                                                    Conferencing Servers,
                                                    Mediation Servers, or
                                                    IP phones.

AudioMicGlitchRate          int                     Average glitches per 5
                                                    minutes for the
                                                    microphone capture.


                                                                        226
Column                   Data Type   Key/Index   Details
                                                 For good quality this
                                                 should be less than 1
                                                 per 5 minutes. Not
                                                 reported by A/V
                                                 Conferencing Servers,
                                                 Mediation Servers, or
                                                 IP phones.

AudioSpeakerClipRate     int                     Clipping occurrences
                                                 per 5 minutes for
                                                 loudspeaker rendering.
                                                 For good quality, this
                                                 should be less than 1
                                                 per 5 minutes. Not
                                                 reported by A/V
                                                 Conferencing Servers,
                                                 Mediation Servers, or
                                                 IP phones.

AudioMicClipRate         int                     Clipping per 5 minutes
                                                 for microphone
                                                 capture. For good
                                                 quality this should be
                                                 less than 1 per 5
                                                 minutes. Not reported
                                                 by A/V Conferencing
                                                 Servers, Mediation
                                                 Servers, or IP phones.

AudioRxAGCSignalLevel*   int                     Received signal level
                                                 on the Mediation
                                                 Server from the
                                                 gateway; this applies
                                                 only to the Mediation
                                                 Server. The unit of this
                                                 metric is dBoV. For
                                                 good quality, the
                                                 acceptable range
                                                 should be [-30 to -18]
                                                 dBoV.

AudioRxAGCNoiseLevel*    int                     Received Received
                                                 signal level on the
                                                 Mediation Server from

                                                                      227
Column                 Data Type      Key/Index   Details
                                                  the gateway; this
                                                  applies only to the
                                                  Mediation Server. The
                                                  unit of this metric is
                                                  dBoV. For good
                                                  quality, the acceptable
                                                  range should be less
                                                  than -50 dBoV.

RoundTrip              int                        Round trip time from
                                                  RTCP statistics. For
                                                  acceptable quality this
                                                  should be less than
                                                  100ms.

RoundTripMax           int                        Maximum round trip
                                                  time for the audio
                                                  stream.

OverallAvgNetworkMOS   decimal(3,2)               Average wideband
                                                  Network MOS for the
                                                  call. This metric
                                                  depends on the packet
                                                  loss, jitter and codec
                                                  used. Range is [1.0 to
                                                  5.0]

OverallMinNetworkMOS   decimal(3,2)               The minimum
                                                  wideband Network
                                                  MOS for the call.

SendListenMOS          decimal(3,2)               The average predicted
                                                  wideband Listening
                                                  MOS score for audio
                                                  sent, including speech
                                                  level, noise level and
                                                  capture device
                                                  characteristics.

SendListenMOSMin       decimal(3,2)               The minimum
                                                  SendListenMOS for the
                                                  call.

RecvListenMOS          decimal(3,2)               The average predicted
                                                  wideband Listening
                                                  MOS score for audio

                                                                       228
Column                                    Data Type      Key/Index     Details
                                                                       received from the
                                                                       network including
                                                                       speech level, noise
                                                                       level, codec, network
                                                                       conditions and capture
                                                                       device characteristics.

RecvListenMOSMin                          decimal(3,2)                 The minimum
                                                                       RecvListenMOS for the
                                                                       call.

Inbound                                   bit                          Stream data on
                                                                       receiver side is
                                                                       received.

Outbound                                  bit                          Stream data on sender
                                                                       side is received.

SenderIsCallerPAI                         bit                          1 means the stream
                                                                       direction is from Caller
                                                                       to Callee.
                                                                       0 means the stream
                                                                       direction is from Callee
                                                                       to Caller.


Note: * means, the metric is scaled by *-100 when stored in QoE DB. Dividing the number
by -100 will give the ranges listed in this table.

VideoStream Table
Each record represents one video stream. One video media line usually contains two video
streams.


Column                              Data Type            Key/Index         Details

ConferenceDateTime                  Datetime             primary           Referenced from
                                                                           the MediaLine
                                                                           Table.

SessionSeq                          Int                  primary           R Referenced from
                                                                           the MediaLine
                                                                           Table.

MediaLineLabel                      tinyint              primary           Referenced from
                                                                           the MediaLine
                                                                           Table.

                                                                                            229
Column                    Data Type      Key/Index   Details

StreamID                  int            primary     Unique ID within a
                                                     media line.

JitterInterArrival        Int                        Average network
                                                     jitter from Real
                                                     Time Control
                                                     Protocol (RTCP)
                                                     statistics.

JitterInterArrivalMax     Int                        Maximum network
                                                     jitter during the
                                                     video session.

RoundTrip                 int                        Round trip time
                                                     from RTCP
                                                     statistics.

RoundTripMax              int                        Maximum round
                                                     trip time for the
                                                     video stream.

PacketLossRate            decimal(5,4)               Average packet
                                                     loss rate during the
                                                     call.

PacketLossRateMax         decimal(5,4)               Maximum packet
                                                     loss observed
                                                     during the call.

BurstDensity              decimal(9,4)               Not available.

BurstDuration             Int                        Not available.

BurstGapDensity           decimal(9,4)               Not available.

BurstGapDuration          Int                        Not available.

PacketUtilization         Int                        Packet count for
                                                     the video stream
                                                     (Real Time
                                                     Transport Protocol,
                                                     RTP).

BandwidthEst              Int                        Bandwidth
                                                     estimates for the
                                                     video stream.

VideoPayloadDescription   varchar(256)               Video codec used.


                                                                         230
Column                      Data Type      Key/Index   Details

VideoPayloadType            int                        Not used.

VideoResolution             char(9)                    Resolution of the
                                                       video in pixels
                                                       width multiplied by
                                                       pixels height.
                                                       Reported as a
                                                       string.

VideoBitRateAvg             int                        Average bit rate of
                                                       the video stream.

InboundVideoFrameRateAvg    decimal(9,4)               The video frame
                                                       rate received.

OutboundVideoFrameRateAvg   decimal(9,4)               The video frame
                                                       rate sent.

VideoBitRateMax             int                        The maximum
                                                       video bit rate
                                                       during the video
                                                       session.

VideoPacketLossRate         decimal(5,4)               The average
                                                       fraction of video
                                                       packets lost as
                                                       specified in RFC
                                                       3550, computed
                                                       over the duration of
                                                       the session.

VideoFrameLossRate          decimal(9,4)               The percentage of
                                                       total video frames
                                                       that are lost.

VideoFrameEncodingTime      decimal(9,2)               Average encoding
                                                       time for video
                                                       frames during the
                                                       video session.

VideoFrameDecodingTime      decimal(9,2)               Average decoding
                                                       time for video
                                                       frames during the
                                                       video session.

VideoFEC                    bit                        Not available.


                                                                          231
Column                     Data Type       Key/Index   Details

FrozenVideoFreq            decimal(9,4)                Frequency of
                                                       frozen video
                                                       occurring
                                                       (occurrences per
                                                       second).

FrozenPeriodPercentAvg     decimal(7, 4)               A measure of the
                                                       percentage of the
                                                       duration of the
                                                       video call in which
                                                       frozen video was
                                                       experienced. For
                                                       good quality, this
                                                       should be less than
                                                       10%.

ConsecutivePacketLossAvg   decimal(20,2)               Average number of
                                                       consecutive video
                                                       packets lost during
                                                       the call. For good
                                                       quality this should
                                                       be less than 3.0 for
                                                       a video call.

RateMatchLevel             decimal(4,2)                Represents the
                                                       average level of
                                                       rate matching
                                                       applied by the
                                                       Audio/Video
                                                       Conferencing
                                                       Server on the send
                                                       channel. 0 is no
                                                       frame removal, 1 is
                                                       B frame removal, 2
                                                       is B and P frame
                                                       removal, and 3 is
                                                       B,P,SP removal.
                                                       For acceptable
                                                       temporal video
                                                       quality, this should
                                                       be 1 or less. An
                                                       average rate
                                                       matching level of 1


                                                                        232
Column                                Data Type              Key/Index   Details
                                                                         represents about
                                                                         7.5 fps for CIF
                                                                         sized video and
                                                                         12.5 fps for
                                                                         VGA/HD video.

Inbound                               bit                                Stream data on
                                                                         receiver side is
                                                                         received.

Outbound                              bit                                Stream data on
                                                                         sender side is
                                                                         received.

SenderIsCallerPAI                     bit                                1 means the
                                                                         stream direction is
                                                                         from Caller to
                                                                         Callee.
                                                                         0 means the
                                                                         stream direction is
                                                                         from Callee to
                                                                         Caller.



Sample Database Queries
This section contains sample queries for the QoE database.
To get jitter and packet loss average for all audio stream
select avg(cast(JitterInterArrival as bigint)) as JitterAvg,
avg(PacketLossRate) as PacketLossRateAvg from AudioStream
To find the total numbers of conferences that used Meeting Console
select avg(ConversationalMOS)
from Session s
inner join MediaLine m
on s.ConferenceDateTime = m.ConferenceDateTime
    and s.SessionSeq = m.SessionSeq
    and m.MediaLineLabel = 0 -- audio media line
inner join UserAgent uaCaller
    on s.CallerUserAgent = uaCaller.UserAgentKey
         and uaCaller.UAType = 4 – communicator


                                                                                            233
inner join UserAgent uaCallee
    on s.CalleeUserAgent = uaCallee.UserAgentKey
        and uaCallee.UAType = 4 -- communicator
To get ConversstionalMOS, SendingMOS and ListendingMOS per capture device
select t.DeviceName as Device, count(*) as SampleNum,
avg(ConversationalMOS) as ConversationalMOS, avg(SendListenMOS)
SendingMOS, avg(RecvListenMOS) as ListendingMOS
from
(
   select d.DeviceName, m.ConferenceDateTime, m.SessionSeq, a.StreamID,
m.ConversationalMOS,a.SendListenMOS, a.RecvListenMOS
    from MediaLine m
    inner join AudioStream a
    on m.ConferenceDateTime = a.ConferenceDateTime
        and m.SessionSeq = a.SessionSeq
        and m.MediaLineLabel = 0
    inner join Device d
        on m.CallerCaptureDev = d.DeviceKey
            and d.DeviceType = 1
    union
    select d.DeviceName, m.ConferenceDateTime, m.SessionSeq, a.StreamID,
m.ConversationalMOS,a.SendListenMOS, a.RecvListenMOS
    from MediaLine m
    inner join AudioStream a
    on m.ConferenceDateTime = a.ConferenceDateTime
        and m.SessionSeq = a.SessionSeq
        and m.MediaLineLabel = 0
    inner join Device d
        on m.CalleeCaptureDev = d.DeviceKey
            and d.DeviceType = 1
)as t
group by t.DeviceName
order by SampleNum desc




                                                                            234
Message Queuing Architecture and Configuration for Archiving
The archiving and CDR agent uses Message Queuing to receive notifications from the Archiving
and CDR Server destination queue. (Message Queuing also serves as a local temporary
transmission queue if the Archiving Server is unavailable.) Message Queuing must be installed
on all computers that participate in archiving, such as the following:
   An Office Communications Server with an archiving and CDR agent that connects to the
     Archiving Server.
   The Office Communications Server that is running the Archiving Server.
   You must install Message Queuing on each server that you want to associate with the
     Archiving Server. If you want to archive an Enterprise pool, you must install Message
     Queuing on each server in the pool.
   Because Message Queuing relies on the Active Directory Domain Services for encryption to
     the destination queue, Message Queuing must be installed with the Active Directory
     integration component, which is the default configuration during Message Queuing
     installation.

Note:
     In a two-tier topology where the Archiving service component and the message queue
     are on a separate computer from the archiving database, automatic setup of encryption is
     not supported for the messages that are sent by the Archiving service component to the
     archiving database. Instead, encryption of the link between the Archiving service
     component and the archiving database must be configured manually by using SQL
     Server SSL encryption. For details about configuring SQL Server SSL encryption, see the
     Microsoft Knowledge Base article 276553, How to enable SSL encryption for SQL Server
     2000 if you have a valid Certificate Server, at
     http://go.microsoft.com/fwlink/?LinkId=144421. For information about configuring the
     registry to establish and help enforce SQL encryption, see the Microsoft Knowledge Base
     article 841695, How to establish and enforce encrypted multiprotocol connections in SQL
     Server 2000, at http://go.microsoft.com/fwlink/?LinkId=144422.
Do not set the destination queue (that is, the private queue) privacy level to None on the server
that is running the Archiving Server. The privacy level must be set to either Body or Optional. The
default setting is Optional.
Do not set the privacy level to Body when the Archiving Server and the Front End Server are
installed on the same computer. When the Archiving Server and the Front End Server are
installed on the same computer and the privacy level on the destination queue is set to Body,
messages are not archived and the server stops running if archiving is running as a critical
service.
The Enterprise pool, Standard Edition server or the Proxy Server, if configured for archiving,
activates the archiving agent. The archiving agent then checks all outgoing SIP messages on the
Office Communications Server to determine whether it should be archived and in what form. This
requires the archiving agent to look up the archiving settings for the sender and receiver of the



                                                                                                235
message (set per user). Based on these archiving settings, the archiving agent takes one of the
following actions:
   Do not archive.
   Send message for archiving.
When messages are sent for archiving, the archiving agent queues the message to the
configured MSMQ. The Archiving service is listening to the destination message of the MSMQ
and on receiving this message, it writes it to the designated SQL Server.
Note that in Office Communications Server 2007 R2, the Archiving and CDR agent will not
archive a message if it does not receive a SIP response from another client. For example, if client
1 sends a message to client 2, and if the SIP response from client 2 fails to reach client 1 due to a
network glitch or a machine shut down, that message will not be archived.


Message Stamping
The Archiving and CDR agent contains message-stamping capabilities to provide administrators
control over whether messages are archived multiple times if they pass through multiple pools or
Front End servers in their path. In such a situation, administrators can effectively control the
number of times a message is archived.
To enable this control, the Archiving and CDR agent stamps every message that it archives.
The value of the stamp is specified in the following WMI property:
   WMI Class: MSFTSIPLogoptions
   WMI Property: ArchivingBEToken
   Value: backend_token
In an example where two archiving agents are involved, the first archiving agent stamps the
message with the value as backend_token and archives it. Subsequently, the second archiving
agent looks at the stamp and compares it to the value of the WMI property ArchivingBEToken.
If the administrator intends to have the second archiving agent archive the message, the
administrator needs to change the value of the WMI property to a value distinct from
backend_token (the value of that property for the first archiving agent). If the value is identical for
the second archiving agent, it will not archive that message.


Creating a Third-Party QoE Solution
You can use the data that Monitoring Server collects to build your own custom solution, such as
custom reports, integrating with other monitoring and management systems, or troubleshooting
and diagnostic tools.
The topics in this section present the information you will need to collect and process the audio
and video metrics for your custom solution.
For information on the QoE Database Schema, see QoE Database Schema.
In This Section
   Infrastructure Requirements and Prerequisites of Monitoring Server

                                                                                                    236
   Deploying a Custom QoE Solution
   WMI Reference for QoE Solutions
   Enabling or Disabling an HTTP Proxy for QoE Solutions


Infrastructure Requirements and Prerequisites of Monitoring Server
In Office Communications Server 2007 R2, QoE components reside in two primary areas, the
QoE Agent and the QoE service and database. The QoE Agent is automatically installed on Front
End Servers and Standard Edition servers. The QoE service and database are part of Monitoring
Server, which must be installed separately.
Before you begin developing your custom solution, ensure that you have deployed a Monitoring
Server and that it is operational. For deployment details, see the Deploying Monitoring Server
documentation.
At the end of each call, the unified communications (UC) endpoints send an A/V (audio/video)
metric report to the QoE Agent. If QoE is enabled on the pool and the QoE Agent is properly
configured, it will, in turn, transmit the report to your custom solution (metric report consumer) by
using HTTP POST. For each QoE Agent in your organization, you can configure only one metric
report consumer. You need to do this QoE Agent configuration work on each Front End Server.
For more details about requirements, see these sections:
   Certificate Requirements for Your QoE Solution
   Protocol Considerations for Your QoE Solution

Certificate Requirements for Your QoE Solution
When you deploy your custom solution, we recommend that the HTTPS protocol be used in order
to improve the security of your data and privacy of your users. By default, HTTPS will allow only
the client to authenticate the server; however, mutual certificate authentication will allow both the
client to authenticate the server and the server to authenticate the client. If HTTPS is used, you
will need to take the following certificate considerations into account:
   The Front End Server or Standard Edition server running the QoE Agent must trust the root
     CA that issued the certificate that is used by the Web server.
        The subject name of the server certificate must match the FQDN of the report consumer
          URL that is configured in the ConsumerURL property in WMI. For details, see WMI
          Reference for QoE Solutions.
   If you want to use mutual certificate authentication, a client certificate must be configured on
     the Front End Server or Standard Edition server running the QoE Agent. For the client
     certificate, you must ensure the following:
        The certificate is stored in the local computer store so that the QoE Monitoring Server
          can locate the certificate.
        The certificate has the enhanced key usage (EKU) extension for client authentication.
        The metric report consumer server is configured to trust the root certification authority
          (CA) that issued the client certificate. The root CA needs to be stored in the "Trusted
          Root Certification Authorization" folder under the local computer store.
                                                                                                      237
       Appropriate permissions are granted to the RTCComponentUniversalServices domain
         group for the certificate to be read.
       The certificate is configured in Microsoft Windows® Management Instrumentation (WMI)
         on the Front End Server or Standard Edition server running the QoE Agent. For details,
         see WMI Reference for QoE Solutions.

         Note:
            On a heterogeneous Windows environment that uses Windows Certificate
            Services, trust is usually implicit, but it may require some extra configuration if a
            non-Windows Web server is used for the metric report consumer.
For details about Certificate Services, see "Certificate Services" at the Microsoft Web site:
http://go.microsoft.com/fwlink/?LinkId=150367. For details about programming with Certificate
Services, see "Programming Certificate Services" at
http://go.microsoft.com/fwlink/?LinkId=150368.

Protocol Considerations for Your QoE Solution
There are a few protocol considerations that you should be aware of before you develop your
custom solution. In order to support persistent connections, the metric report consumer must be a
server that is compliant with HTTP 1.1.

Note:
    To improve the security of your data and the privacy of your users, we recommend that
    HTTPS with mutual certificate authorization be configured.
This sample call flow illustrates how the metric report consumer accepts an A/V metric report for
a single session. You will be responsible for the protocol implementation between the Monitoring
Agent and the metrics report consumer.




Figure 1. Metric Report Consumer Acceptance of an A/V Metric Report

                                                                                                    238
Protocol Requirements
The following protocol requirements should be taken into consideration when you develop your
custom solution:
    The metric report consumer must be able to handle multiple incoming HTTP connections and
      to simultaneously process requests that come in on these different connections. This will
      enable a single metric report consumer to communicate with multiple Monitoring Agents.
    Multiple A/V metrics reports may exist in a single POST body, up to the maximum configured
      value for the WMI setting MaxPostBatchSize.
    The A/V metrics reports will be sent in XML, UTF-8 encoded.
    The XML payload will have a root element of VQReportEventList. The ID attribute of
      VQReportEventList will be set to a unique value for the set of A/V metrics reports that it
      contains. If a transient network error or server error occurs or if the Monitoring Agent does not
      receive an HTTP response from your application, then the agent will repost the entire
      VQReportEventList document with the original ID. You can disable reposting when a
      transient network error or server error occurs by setting ErrorRetryEnabled to false in WMI.
    The QoE Agent performs only a basic level of validation against the A/V metrics report before
      it posts the report to the metric report consumer. None of the QoE Monitoring Server report
      aggregation logic is applied to the reports prior to the post.
    The QoE Agent will not throttle requests; the metric report consumer is expected to keep up
      with the normal volume of A/V metric reports.
    In order to handle A/V metric report bursts, such as might occur at the end of a large
      conference, the QoE Monitoring Server buffers A/V metrics reports, as needed, on behalf of
      the consumer. The buffer size itself is a configurable number of kilobytes. After the report
      bursts exceed the buffer size, the QoE Monitoring Server will drop the oldest reports. If the
      QoE Monitoring Server service or the computer is restarted, the contents of the buffer will not
      be retained.
    Upon receiving metrics reports, the report consumer should return the HTTP response
      immediately. Performing any additional synchronous processing on the reports before
      returning will cause a drop in the report throughput rate to the report consumer.
HTTP Status Codes
Table 1 defines the status codes that are used in the HTTP protocol between the QoE Monitoring
Server and the metric report consumer.

Note:
      Only HTTP 2xx and 400 status codes are expected from the metric report consumer. All
      other status codes will be treated as a transient network error or server error and will
      cause the QoE Monitoring Server to retry the POST request.
Table 1. Supported HTTP status codes


HTTP Status Code                   Metric Consumer Usage              QoE Monitoring Server Action

2xx                                Metric consumer is expected to The post transaction will be

                                                                                                   239
HTTP Status Code                   Metric Consumer Usage                 QoE Monitoring Server Action
                                   promptly return 202 Accepted          marked as complete.
                                   to valid metric CDR post
                                   requests.

400 Bad Request                    Metric consumer should return         The post transaction will be
                                   400 Bad Request whenever              abandoned and not retried.
                                   basic validation of the A/V
                                   metric report post request fails.

All other status codes             No other status codes are             The QoE Monitoring Server will
                                   expected from the metric              treat all other status codes as
                                   consumer.                             transient errors and will retry
                                                                         the post request.



Deploying a Custom QoE Solution
Deploying your custom solution requires only a few steps.

To deploy your solution
    1. Install an HTTP 1.1 compliant Web server, such as Internet Information Services.
    2. Install your application.
    3. If HTTPS will be used (recommended), install the appropriate certificate on the consumer
       and, as needed, on the Front End Servers that run the QoE Agent.
    4. Configure external consumer settings on the QoE Monitoring Server by using WMI. For
       details about WMI settings, see WMI Reference for QoE Solutions.
    5. By default, the QoE Monitoring Server will not use any HTTP proxy. For details about
       configuring the QoE Monitoring Server to use the configured HTTP proxy, see Enabling
       or Disabling an HTTP Proxy for QoE Solutions.




WMI Reference for QoE Solutions
The following table lists the various configuration settings that can be set through WMI for the
\\cimv2\MSFT_SIPQMSExternalConsumer singleton class. This class already exists, so you will
not need to create it.
Table 2. WMI Settings for Class MSFT_ SIPQMSExternalConsumer


Property Name       Description                     Type       Default            Range        Access
                                                                                               Type

InstanceID          Class identifier                GUID       53094317-          Up to        Read Only
                                                               4455-44ed-         1024

                                                                                                        240
Property Name      Description                    Type     Default      Range      Access
                                                                                   Type
                                                           B8D5-       character
                                                           A716972B334 s
                                                           4

ConsumerURL        The URL that A/V Metric     String      NULL         Valid      Read/Writ
                   Reports will be posted too.                          HTTPS      e
                                                                        or HTTP
                   Note:
                                                                        URL
                       The host name in
                       the URL must be
                       identical to
                       Subject field of the
                       server certificate.
                       For instance, if the
                       server certificate
                       is configured as
                       contoso.voip-
                       client1.com, the
                       consumer URL
                       must be
                       https://contoso.voi
                       p-client1.com.

ConsumerName       A display name for the         String   NULL         Up to 256 Read/Writ
                   consumer.                                            character e
                                                                        s

ClientCertIssuer   A binary array in raw data     uint8    NULL         N/A        Read/Writ
                   format that represents the                                      e
                   certification authority that
                   issued the certificate. This
                   data is in ASN.1 byte
                   array format.
                   This setting is used only if
                   ConsumerURL is an
                   HTTPS URL. This setting
                   should be NULL if the
                   client will not use a
                   certificate.

ClientCertSN       A binary array in raw data     uint8    NULL         N/A        Read/Writ
                   format that represents the                                      e
                   serial number of the client

                                                                                            241
Property Name      Description                    Type     Default   Range    Access
                                                                              Type
                   certificate.
                   This setting is used only if
                   ConsumerURL is an
                   HTTPS URL. This setting
                   should be NULL if the
                   client will not use a
                   certificate.

Enabled            If True, the QoE               Boolea   False     N/A      Read/Writ
                   Monitoring Server will         n                           e
                   send A/V Metric Reports
                   to the configured
                   consumer.

ErrorRetryEnable   If True, the QoE             Boolea     True      N/A      Read/Writ
d                  Monitoring Server will retry n                             e
                   when transient errors
                   occur.

MaxPostBatchSiz Maximum number of                 uint32   50        5-100    Read/Writ
e               reports to send in one                                        e
                transaction.

MaxQueueSize       The maximum amount of      uint32       50,000    0-      Read/Writ
                   memory (in KB) that is                            MAX_INT e
                   used to cache metric
                   reports on behalf of the
                   consumer. If the queue
                   limit is exceeded, the QoE
                   Monitoring Server will
                   discard the oldest reports
                   first. If MaxQueueSize is
                   set to 0, the buffer size
                   has no upper limit.
                   Because individual reports
                   may range from 2 KB to 8
                   KB, we recommend
                   against setting
                   MaxQueueSize to less
                   than 10.




                                                                                       242
Enabling or Disabling an HTTP Proxy for QoE Solutions
Both the Monitoring Server and the metric report consumer server will usually be located within
your organization’s internal network, so you will not need an HTTP proxy. By default, Monitoring
Server will not use any HTTP proxy, and it will send the reports directly to the FQDN of the metric
report consumer. You can, however, configure Monitoring Server to use the existing proxy
settings that are configured for the Monitoring Server by either local machine or Group Policy
settings.

To enable or disable an HTTP proxy
     1. Log on to the Monitoring Server as a member of the Administrators group.
     2. Start the Registry Editor: Click Start, and then click Run. In the Open box, type regedit,
        and then click OK.
     3. In the console tree, right-click HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Real-
        Time Communications\{B956FCFA-77F2-4ECA-A3EE-F864B8209C0D}. Create this
        registry key it is doesn’t exist.
     4. Point to New, and then click DWORD Value.
     5. In the details pane, in the Name column, type EnableProxyForMetricsConsumer for
        the new value, and then press ENTER.
     6. In the details pane, right-click EnableProxyForMetricsConsumer, and then click
        Modify.
     7. In the Edit DWORD Value dialog box, in the Value data box, do one of the following:
            To use the Internet Explorer HTTP proxy settings, type 1, and then click OK.
            To no longer use the Internet Explorer HTTP proxy settings, type 0, and then click
              OK.
     8. Restart the QoE Monitoring service for the changes to take effect.




Edge Servers Drilldown
For details about Edge Servers, see the Microsoft Office Communications Server 2007 R2 the
Edge Server Deployment Guidelines in the Planning and Architecture documentation.


Response Group Client Web Service Drilldown
The Response Group Service has a Client Web Service, which can be used by 3rd party
applications to retrieve information about the Agents, their Agent Group memberships, and sign-
in status.
The following operations are supported through the client web service:
   GetAgent
   GetGroups


                                                                                                   243
   IsAgent
   SignIn
   SignInMultiple
   SignOut
   SignOutMultiple


Service Descriptions
The following list the service descriptions of the operations within the Client Web Service
   GetAgent: Returns information about the currently authenticated agent.
   GetGroups: Returns information about the groups the currently authenticated agent is a
     member of. For each group, the following information is available:
   IsAgent: Returns true if the currently authenticated user is an agent.
   SignIn: Signs the current agent into the given group and returns true when the operation has
     successfully completed.
   SignInMultiple: Signs the current agent in to the given groups and returns true when the
     operation has successfully completed.
   SignOut: Signs the current agent out of the given group and returns true when the operation
     has successfully completed.
   SignOutMultiple: Signs the current agent out of the given groups and returns true when the
     operation has successfully completed.


Client DNS Queries Drilldown
This topic gives a brief description of how DNS queries work in Office Communications Server
2007 R2.
During DNS lookup, SRV records are queried in parallel and returned in the following order to the
client:
1. _sipinternaltls._tcp.<domain>— for internal TLS connections.
2. _sipinternal._tcp.<domain>— for internal TCP connections (performed only if TCP is
   allowed).
3. _sip._tls.<domain>— for external TLS connections.
Where <domain> is the SIP domain used by your internal clients.
The last query is useful when clients are connecting from outside your internal network. For
details about remote user access, see Planning for External User Access in the Planning and
Architecture documentation.
The client uses the SRV record that is returned and is successful. The client does not try any
other SRV records.
After the SRV record is returned, a query is performed for the DNS A record for the host name
that is returned by the SRV record. If no records are found during the DNS SRV query, the client

                                                                                                 244
performs an explicit lookup of sipinternal.<domain>. If the lookup does not produce results, the
client performs a lookup for sip.<domain>. If the client does not find sip.<domain>, it performs a
lookup for sipexternal.<domain>.
If your DNS infrastructure prohibits configuration of these DNS records, you can manually edit the
client registry to point to the appropriate home server. For details about editing the client registry
and configuring policy settings for the client, see Deploying Communicator in the Client Planning
and Deployment documentation.


Application Server Drilldown
Application Server is a platform introduced in Office Communications Server 2007 R2 that makes
it easier to build server-side applications that run on Standard Edition servers or Enterprise
Edition pool servers. Applications developed using the Unified Communication Managed APIs
(UCMA) 2.0 can use the Application Server platform as a common framework that leverages
Office Communications Server capabilities such as deployment, trust, administration, load
balancing and routing, and monitoring.
Without Application Server, each application developer would have to create his own deployment,
administration and integration story, leading to repeated effort, more time to market, and
inconsistent behavior. Proliferation of these different solutions would also lead to complexity in
deploying and maintaining the Office Communications Server deployment.
Application Server is designed to host server applications that act as SIP endpoints. It is not
intended to host Web applications and does not integrate with Internet Information Services (IIS),
although applications running on it can expose Windows Communication Foundation (WCF) Web
service endpoints.
Like the Office Communications Server Conferencing Servers, Application Server is another
server role, and when deployed on an Enterprise Edition consolidated pool topology each
Application Server application runs on all servers in the pool and together they share the overall
workload of the application.
The Application Server implementation in Office Communications Server 2007 R2 is the first
stage in the evolution of the platform, and in this release it hosts four new applications that come
with Office Communications Server 2007 R2: Response Group Service, Outside Voice Control
(also known as Call Control Service), Conferencing Attendant, and the Conferencing
Announcement Service. However, in this release, Application Server is not supported as a
platform for third-party applications.
The topics in this section is intended to help Office Communications Server administrators and
product specialists have a deeper understanding of the Application Server architecture and
applications and prepare them to troubleshoot any issues encountered involving the four
Application Server applications included with this release of the product.
In This Section
   Characteristics of the Office Communications Server 2007 R2 Application Server
   Application Server Configuration
   Application Server Application Configuration
                                                                                                  245
Characteristics of the Office Communications Server 2007 R2
Application Server


Architecture
Application Server consists of a single Windows service—Application Host
(OCSAppServerMaster.exe)—and one or more instances of another Windows service—
OCSAppServerHost.exe. Each instance of OCSAppServerHost.exe on a server hosts an
Application Server application unique to that server. There will never be multiple instances of any
particular Application Server application on a server.
In the Enterprise Edition consolidated pool topology, all Front End Servers run identical instances
of each Application Server application selected at the time of Office Communications Server
installation.
The Application Server applications themselves are written as .NET Framework 3.5 managed
assemblies. All OCSAppServerHost.exe process instances and the OCSAppServerMaster.exe
process run under the RTCComponentService account security context.
Each Application Server application leverages the following Office Communications Server 2007
R2 components:
   WMI – Each application uses the lcwmi WMI provider to store/retrieve global and pool
     settings. For each Application Server application, all instances in a pool use a common set of
     settings stored in the backend RTCConfig database. Global settings are stored in Active
     Directory Domain Services.
   Unified Communications Managed APIs (UCMA) 2.0 –Application Server applications
     interface these APIs to access the SIP and media stack on each front end server.
     Communications between the Application Server applications and other SIP endpoints all
     route through a SIP Proxy in the same pool as the application (but not necessarily on the
     same physical server).
   Contact Objects/Trusted Services – Application Server applications are SIP Application
     Endpoints and as such require a SIP Address of Record (AOR) in the form of a SIP URI or
     Tel URI. This is accomplished by assigning an Active Directory Domain Services Contact
     object to each application and setting the application as a Trusted Service. These
     assignments enable the application to act as a SIP User Agent without having to authenticate
     or register, and enables them to subscribe to the presence of registered users and publish
     presence on behalf of registered users.
   Management – The Office Communications Server 2007 R2 Management Console exposes
     service start-up and shut-down control of the Application Server services on a per-server
     basis in the same way it provides control of the other Office Communications Server 2007 R2
     services, such as the Front End services or Conferencing Servers. If an Application Server
     application requires pool-level configuration, the Management Console can list the application
     under the new Applications option under the pool’s Properties menu in Office
     Communications Server 2007 R2. This will launch a new snap-in for managing that

                                                                                                 246
     application’s pool level settings. (In R2, only the Response Group feature requires pool-level
     configuration.) The Management Console also can expose property sheets on the Forest
     container as needed to configure global properties associated with the Application Server
     application. In Office Communications Server 2007 R2, Communicator 2007 R2 Attendant is
     the only Application Server application that requires configuration at this level. Because all
     Application Server application instances in a pool are identical, configuration of Application
     Server applications on a per-server basis is unnecessary.
   Installation/Activation – the Application Server environment and each Application Server
     application are packaged as Windows installer (.MSI) files called from the main Office
     Communications Server installation program (if one or more Application Server applications
     were selected for installation). After you install it, they are activated or deactivated in AD DS
     using lcscmd.exe /server:<appserver> /action:Activate|Deactivate /Role:AppServer.
   Logging –Application Server applications can expose new components to the Office
     Communications Server 2007 R2 Logging Tool (OCSLogger.exe) for tracing communications
     with the application.


Other Key Application Server Characteristics


Distributed Workload
The Office Communications Server Application Host process does not listen on the network at all,
but like the Office Communications Server Conferencing Servers, each Application Server
application has a TCP port assigned to it. All servers in the pool listen on those assigned ports for
each the specific Application Server application they host, and the hardware load balancer also
listens on those ports and distributes inbound traffic to Application Server application instances
on a server in the pool. All SIP communications with an Application Server application occurs
over TLS between a SIP Proxy in its pool using the pool’s SSL certificate, even if the Application
Server application instance happens to be on the same physical server as the SIP Proxy. As with
other UC endpoints, media communications are direct between the client and the Application
Server application instance that took the call. For example, once a call has been routed to a
Conferencing Attendant instance, the audio media flows directly between it and the Mediation
Server that handled the call.

Stateless
Application Server applications are stateless in that they do not persist data between sessions,
and each instance operates autonomously of the other instances of that application in the pool or
across pools.
All Application Server instances of a particular application are equivalent across servers in pool
and do not communicate with each other or another server process (unlike the Conferencing
Servers, which communicate state information to the Conferencing Server Factory). Furthermore,
Application Server applications do not register with the SIP Registrar and thereby do not support
multiple points-of-presence. A call to an Application Server application is routed to only one
Application Server instance and the other instance remain unaware of that call.

                                                                                                    247
The Office Communications Server Application Host service (OCSAppServerMaster.exe) also
does not monitor the state of the Application Server applications on its server, other than
monitoring whether the instances are running and if it detects an unhandled exception in the
application, it will restart it automatically.


Application Server Configuration
In Office Communications Server 2007 R2, the Application Server infrastructure has no
configurable post-installation settings (during installation, the RTCComponentService service
account is assigned and the service is set for automatic start with a dependency on Windows
Management Instrumentation [WMI]). A WMI Class exists in the LCWMI provider for Application
Server settings— MSFT_SIPApplicationServerSetting—but currently there is no data store for
this class.
Because Application Server is a separate Office Communications Server 2007 R2 role, at the
time of activation an msRTCSIP-ApplicationServer Service Connection Point (SCP) for each
Application Server-role server is published in Active Directory Domain Services separate from
SCPs of the other roles, such as the Front-End services and the Conferencing Servers.


Application Server Application Configuration
In the Office Communications Server 2007 R2 implementation, the Application Server
applications retrieve settings information via WMI. Global settings are stored in AD, while pool
level application settings are stored in the RTCConfig database. As mentioned earlier, some of
these settings are established at time of activation, while others are configurable from the Office
Communications Server 2007 R2 Management Console. All are viewable and configurable using
the WBEMTEST utility and the global settings can also be accessed using ADSIEDIT.MSC.


Global Settings
   MSFT_SIPPoolSetting – each pool is represented by an instance of this class. One if its
     properties—Applications Property— is a multi-valued array containing the names of the
     Application Server applications installed in the pool.
   MSFT_SIPApplicationContactSetting – this class contains instances for each Contact object
     required by the Application Server applications. If all four R2 Application Server applications
     have been installed, activated, and configured, there will be instances for each pool’s
     Response Group Presence Watcher (RGSPresenceWatcher), Conferencing Announcement
     Service, Conferencing Attendant (CAAPrivateContactObject), plus one for each Dial-In
     Conferencing access number configured for the organization.
   MSFT_SIPTrustedServiceSetting – this class will contain one instance for each Application
     Server application for each pool, which stores the Distinguished Name (DN), GRUU address,
     and port number for the Application Server application instances in that pool.




                                                                                                  248
Pool Settings
   MSFT_SIPApplicationConfigSetting – Each pool’s RTCConfig database contains one
     instance of this class for each Application Server application installed in the pool, and each
     instance tells the Front End Server the name, labels, and location of the application’s
     assembly file.
   Other Pool-level Application settings – An Application Server application can also extend the
     Office Communications Server 2007 schema to add classes specific to itself. In Office
     Communications Server 2007 R2, the Response Group service added 11 new classes (and
     corresponding tables in the RTCConfig database) for storing settings. See Response Group
     Client Web Service Drilldown for details about these settings.


SIP Trunking Drilldown
Office Communications Server 2007 R2 enables basic call origination and termination using a
Session Initiation Protocol (SIP) trunk to a service provider.
In This Section
This section contains the following topics:
   SIP Trunking Drilldown: Supported Scenarios
   SIP Trunking Drilldown: Supported Topologies
   SIP Trunking Drilldown: Security Considerations
   SIP Trunking Drilldown: Bandwidth Considerations
   SIP Trunking Drilldown: Protocol Flow and Details
   SIP Trunking Drilldown: High Availability


SIP Trunking Drilldown: Supported Scenarios
Supported scenarios include the following:
   An enterprise Office Communications Server user is able to place a local or long distance
     outbound call to the public switched telephone network (PSTN) by using a service provider
     Session Initiation Protocol (SIP) trunk.
   An enterprise Office Communications Server user is able to receive an inbound PSTN call to
     his/her Direct Inward Dialing (DID) number by using a service provider SIP trunk. If the
     service provider supports number portability, you can keep your pre-existing DID.
   The Calling Party Number (that is, used to show caller ID) is supplied (if allowed) for inbound
     and outbound calls.
   An active call can be placed on hold and off hold.
Any other scenario is outside the scope for the Office Communications Server 2007 R2 release.
Some examples include the following:
   E.911 support for outbound calls.
   Invoking any service provider call conferencing functionality over the SIP trunk. (This is
     separate from the conferencing functionality provided by Office Communications Server.)
                                                                                                  249
   Invoking any service provider call forwarding/redirect functionality over the SIP trunk. (This is
     separate from the call forwarding/redirect functionality provided by Office Communications
     Server.)


SIP Trunking Drilldown: Supported Topologies
The interface for connecting Office Communications Server environment to the Session Initiation
Protocol (SIP) trunk of the service provider is made on the external side of a Mediation Server.
The following list contains the supported topologies that you can use to enable this connection to
your service provider’s SIP trunk:
   Private connection. In this configuration, the mediation server connects to the SIP trunk
     using a private network connection to the service provider. For instance, this could be a
     dedicated MPLS T1 connection installed for the purpose of SIP trunking.




   VPN connection. In this configuration, the mediation server connects to the SIP trunk using
     a virtual private network (VPN) connection to the service provider. This could run over a
     general Internet connection or an existing MPLS wide area network (WAN) connection.
     Unlike the private connection option, these multi-purpose connections are usually shared and
     used for multiple scenarios. The purpose for the VPN connection is to create an isolated,
     secure channel on which the SIP trunked calls are carried.




                                                                                                   250
   Public Connection. In this configuration, the Mediation Server connects to the SIP trunk by
     using a direct Internet connection. Unlike the private and VPN options, this topology does not
     leverage an isolated link to the SIP trunk.




SIP Trunking Drilldown: Security Considerations
Office Communications Server employs Transport Layer Security (TLS) to secure server/server
and client/server SIP signaling and secure real-time protocol (SRTP) to secure media flow. The
Mediation Server role has always supported TLS and SRTP on the Office Communications
Server facing non-gateway side. With the release of Office Communicator Server 2007 R2, the
Mediation Server role now supports TLS and SRTP on the gateway side. However, TLS/SRTP is

                                                                                                251
not supported by all service providers nor is it required in all SIP trunk topologies. This section
describes when it is necessary to enable TLS and SRTP on the gateway side of the Mediation
Server to ensure a secure deployment.
There is only one key condition that requires TLS and SRTP to be enabled. Namely, there is
some point in the network path between the Mediation Server and the service provider SIP trunk
that is accessible to more than a limited set of non-IT personnel.
   Private Connection. The connection to the service provider is dedicated and only used to
     carry SIP trunk packets. Because only authorized IT engineers at the company and the
     service provider are able to observe this traffic, TLS/SRTP is not required. However, if the
     service provider supports it, you may still implement TLS/SRTP for an added layer of
     protection. Be sure that the subnet linking the Mediation Server to the private connection is
     also private.
   VPN Connection. Although the network between the Mediation Server and the service
     provider is likely shared by a number of applications, the virtual private network (VPN)
     connection effectively creates a dedicated pipe used only to carry SIP trunk packets. The key
     difference from the physical connection topology is that network isolation is being provided by
     the encryption capabilities of the VPN rather than physical separation. At minimum, the VPN
     should encrypt all traffic at a level comparable or better than 128-bit Advanced Encryption
     Standard (AES). Assuming this is the case, the only people who could observe this SIP
     trunking traffic would be authorized IT engineers of the company and the service provider, so
     TLS/SRTP is not required. However, if the service provider supports it, you may still
     implement TLS/SRTP for an added layer of protection. If you use a VPN appliance, ensure
     that the subnet linking the Mediation Server to the VPN appliance is also private. Note that if
     the tunneling mechanism carries User Datagram Protocol (UDP) packets over a TCP
     transport, this may impact the latency characteristics of the call, given that TCP is a reliable
     transport while UDP is not.
   Public Connection. With a public connection, clearly no dedicated connection exists. Quite
     the contrary, it should be assumed that a large number of people will be able to inspect all
     SIP trunk-related packets. Enabling TLS and SRTP is strongly advised to ensure a secure
     deployment.


SIP Trunking Drilldown: Bandwidth Considerations
SIP trunking services are typically priced according to the maximum number of simultaneous
calls. Bandwidth availability needs to be taken into account so that you can take full advantage of
the peak capacity that you have paid for. The bandwidth needs are determined as follows:
     SIP Trunk Peak Bandwidth = Max Simultaneous Calls x 80kbps
The 80kbps value reflects 64kbps for the G711 codec plus 16kbps of packet overhead. In reality,
the bandwidth will be somewhat lower due to silence suppression. That means the Mediation
Server and the service provider stops sending real-time transport protocol (RTP) media packets
when the respective participant is not talking. For audio sent by the Mediation Server, silence
suppression will reduce the bandwidth by roughly 35%. The challenge is that bandwidth planning
is usually symmetric, and each service provider implements different degrees of silence

                                                                                                      252
suppression (or perhaps no silence suppression at all). Therefore, it is best to plan for the full
80kbps bandwidth unless you have further information regarding the silence suppression
characteristics of your particular service provider.
In the private connection topology, it is easy to plan your bandwidth because it is a dedicated link.
Simply compute your SIP trunk peak bandwidth, and then obtain at least that much bandwidth in
your dedicated connection.
In the virtual private network (VPN) connection topology, how you plan your bandwidth depends
on the network that the VPN is running over. If the VPN is running over a controlled link between
your company and the service provider (for example, a corporate MPLS link), compute your SIP
trunk peak bandwidth and set aside that much bandwidth on the link for the VPN connection. If
the VPN is running over an uncontrolled link (for example, a public internet connection), compute
your SIP trunk peak bandwidth and reserve that much bandwidth on your link for the VPN
connection. This prevents a saturated link from causing bandwidth issues for your SIP trunk.
However, this does not guarantee that your SIP trunk traffic will not be affected by congestion on
the Internet. Therefore, running a VPN over an Internet connection is not recommended for
deployments that require a high service level agreement (SLA).
From a bandwidth standpoint, the public connection topology is handled similarly to running a
VPN connection over an Internet connection. Compute your SIP trunk peak bandwidth and
reserve that much bandwidth on your public connection link. This prevents a saturated link from
causing bandwidth issues for your SIP trunk. However, this does not guarantee that your SIP
trunk traffic will not be affected by congestion on the Internet. Again, running a VPN over an
Internet connection is not recommended for deployments requiring a high SLA.


SIP Trunking Drilldown: Protocol Flow and Details
This topic describes the various Session Initiation Protocol (SIP) trunking protocol flows.


SIP Call Flow and State Machine
The implementation of SIP trunking in Office Communications Server 2007 R2 supports a
constrained set of call scenarios. The diagram below reflects a high-level state machine for a call
leg between the Mediation Server and the SIP trunk. From the Idle state, either the service
provider or the Mediation Server could send a SIP Invite, which indicates that a call is being
offered. Several provisional responses may be sent, such as 180 Ringing indications. However,
a final response will ultimately be sent, such as a 480 Temporarily Unavailable or a 200 OK. In
the former case, the SIP dialog fails to be established and the call state reverts to Idle. In the
latter case, the SIP dialog succeeds and the call state goes to the Active state. During the Active
state, the only supported call mediation command is to place the call on and off Hold. This may
be done by either endpoint of the SIP dialog by sending another SIP Invite that contains the
appropriate SDP command to indicate the call is active or on hold. From either the Active or On
Hold states, the call may be terminated by either endpoint by sending a Bye.




                                                                                                     253
Call Hold
The Mediation Server only supports one method for placing a call on and off hold. To place a call
on hold, an additional SIP Invite will be sent on an active call’s SIP dialog. The Session
Description Protocol (SDP) body of this dialog contains a full SDP body containing the line a=
inactive. To place a call off hold, an additional SIP Invite is sent on a held call’s SIP dialog. The
SDP body of this dialog contains a full SDP body containing the line a=sendrecv.


Dual-tone multifrequency (DTMF)
The Mediation Server supports sending and receiving DTMF according to RFC 4733. Effectively,
this passes a DTMF tone by sending a stream of real-time transport protocol (RTP) packets on
the media channel using a payload type specific to DTMF. This is the same mechanism used in
the rest of the Office Communications Server system to pass DTMF digits.


Early Media
New in Office Communications Server 2007 R2, the Mediation Server now supports the
negotiation of Early Media on the Mediation Server per RFC 3960. This enables the negotiation
and establishment of a media channel prior to the final 200 OK response. This would enable a
service provider to send carrier specific in-band ring tones and ensure that no audio is lost when
a user answers the phone. It is optional whether the service provider implements it.


Uniform Resource Identifier (URI) Formatting
All URI formatting is performed according to RFC 3966, where an E.164 number is preceded by a
+. The SIP URI must have a trailing user=phone parameter. For an example, see the following:

                                                                                                  254
INVITE sip:+14255550101@s1.ms.com;user=phone
From: <sip:+14255550101@g1.contoso.com;user=phone>
To: sip:+142575550155@s1.ms.com;user=phone


This coordinates nicely with the Office Communications Server design of passing numbers in
E.164 format. Incoming calls are already in the correct format and can be handled by Office
Communications Server inbound routing. Outgoing calls, once normalized, can be passed directly
to the SIP trunk as an E.164 number without having to perform any number translation.


Codec Support
The Mediation Server only supports G.711a and G.711u at a 20ms packet interval. This would be
shown in the SDP as follows:
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMU/8000
a=ptime:20
Per RFC 2198, you may have support for sending redundant media packet (also called forward
error correction). If it is supported, it is shown in the SDP list as follows:
a=rtpmap:97 RED/8000
Finally, you may see a final codec for DTMF as follows:
a=rtpmap:101 telephone-event/8000


SIP Trunking Drilldown: High Availability
Various degrees of high availability can be achieved with Session Initiation Protocol (SIP)
trunking. As with any failover solution, a higher the level of resiliency will come at an increased
cost. Following are some different scenarios along with their corresponding high availability
mitigation:
   Mediation Server failure. To protect against a Mediation Server failure, first install a second
     Mediation Server alongside the existing Mediation Server. Next, add this Mediation Server to
     any voice routes containing the existing Mediation Server. For outbound calls, Office
     Communications Server automatically load balances between the two Mediation Servers and
     route calls failover to just one of the Mediation Servers in case the other server goes down.
     Therefore, the service provider must be configured to accept SIP trunk calls originating from
     two source Internet Protocol (IP) addresses.
     Handling failover for incoming calls is done in an analogous fashion. The service provider
     should be configured with both gateway Internet Protocol (IP) addresses corresponding to the
     two Mediation Servers. The service provider should load balance between these servers by
     sending some calls to one server and some to the other. More importantly, if one server is no
     longer responding, the service provider must take that Mediation Server out of the pool and
     only send incoming calls to the active Mediation Servers.

                                                                                                      255
   Connection failure. To protect against a connection failure, use a second connection for the
     redundant Mediation Server instance. This second connection ensures that if one of the
     connections goes down, only one Mediation Server will be affected. The service provider
     must be able to detect this connection failure for incoming calls and send calls to the other
     connection.


Address Book Server Drilldown
The primary function of the Address Book Server and related services is to provide global
address list (GAL) information that is retrieved from Active Directory Domain Services (AD DS)
and make it available to clients through one of the following services:
   Address Book File Download Service. Where clients such as Office Communicator and
     devices such as Office Communicator Phone Edition download address book files, enabling
     clients to perform local address book queries.
   Address Book Web Query Service. Where clients such as Office Communicator Mobile
     send address book queries by using HTTPS to a Web service running on the Web
     Components Server.
If individual clients accessed AD DS directly, it could impact Active Directory and network
performance due to excessive Lightweight Directory Access Protocol (LDAP) queries. To make
address book updates faster and more efficient, the Address Book Server generates daily
address book file and address book database updates that are leveraged by the Address Book
File Download Service and Address Book Web Query Service respectively.
The secondary and optional function of the Address Book Server is to convert the format of
phone numbers that may in a local format (for example, 555-0101) into the RFC 3966/ITU E.164
standardized format (for example, +1.425.555.0101). This conversion is referred to as phone
number normalization. Phone numbers stored in Office Communications Server user and contact
objects can be normalized by Address Book Server so they can be easily used by the Office
Communications Server clients. Although it is preferable for normalized phone numbers to be
entered into Active Directory, Active Directory does not perform any phone number normalization
itself. The phone number normalization occurs when the Address Book Server reads the phone
numbers from the RTC database, normalizes them if necessary, and then writes them into
address book files and address book database (RTCAb).
Among its daily tasks, the Address Book Server generates a set of compressed full files and delta
files for use by the Address Book File Download Service. These files are stored in a standard
NTFS folder. The advantage of the full file and delta file generation is that it minimizes the impact
of the client download. When an Office Communicator 2007 R2 or Office Communicator Phone
Edition (2007 R2 release) client logs on to its Enterprise pool or Standard Edition server, it uses
one of two configured URLs (that is, one for internal access and the other for external access) to
access the file from the NTFS folder by using HTTPS, HTTP, or by the file URL. When the client
downloads the address book file for the first time, the full address book file is downloaded. On
subsequent days in most situations, a delta file containing the changes since the last update is
downloaded.


                                                                                                 256
Relative to Office Communications Server 2007, a key architectural improvement for Address
Book services in Office Communications Server 2007 R2 is the addition of an Address Book Web
Query Service for mobile clients such as Communicator Mobile (2007 R2 release). Rather than
download potentially large address book files, Communicator Mobile (2007 R2 release) clients
make on-demand address book queries to the Address Book Web Query Service.

Note:
     The Address Book logic described in the following sections apply to all Office
     Communications Server deployments except a few special environments with either a
     very large number of users or a relatively volatile directory. For these types of
     environments, Office Communications Server Address Book logic behaves differently in a
     small number of aspects, resulting in slight improvements in CPU and network efficiency.
     Exceptions for special environments are called out separately in the sections below.
In This Section
   Address Book Server Introduction
   Address Book Server: File and Database Generation
   Address Book Server: Address Book File Download Service
   Address Book Server: Address Book Web Query Service
   Address Book Server: Advanced Address Book Features


Address Book Server Introduction

Introduction
The primary function of the Address Book Server and related services is to provide global
address list information that is retrieved from Active Directory Domain Services and make it
available to clients through one of the following services:
   Address Book File Download Service, where clients such as Office Communicator and
     devices such as Office Communicator Phone Edition download address book files, which
     enable the clients to perform local address book queries, and
   Address Book Web Query Service, where clients such as Office Communicator Mobile send
     address book queries via HTTPS to a web service running on the Web Components Server.
If individual clients accessed the Active Directory Domain Services directly, it could impact Active
Directory (AD) and network performance due to excessive LDAP queries. To make address book
updates faster and more efficient, the Address Book Server generates daily address book file and
address book database updates that are leveraged by the Address Book File Download Service
and Address Book Web Query Service respectively.
The secondary and optional function of the Address Book Server is to convert the format of
phone numbers that may in a local format (e.g. 555-0101) into the RFC 3966/ITU E.164
standardized format (e.g. +1.425.555.0101). This conversion is referred to as phone number
normalization. Phone numbers stored in Office Communications Server (OCS) user and contact
objects can be normalized by Address Book Server so they can be easily used by the OCS

                                                                                                 257
clients. Although it is preferable for normalized phone numbers to be entered into Active
Directory, AD does not perform any phone number normalization itself. The Address Book Server
normalizes phone numbers for numbers read from the OCS’ Rtc database and then writes the
normalized numbers into the address book files and address book database.
Among its daily tasks, the Address Book Server generates a set of compressed full files and delta
files for use by the Address Book File Download Service. These files are stored in a standard
NTFS folder. The advantage of the full file and delta file generation is that it minimizes the impact
of the client download. When an Office Communicator 2007 R2 or Office Communicator Phone
Edition 2007 R2 client logs on to its Enterprise pool or Standard Edition Server, it uses a
configured URL to the Web Components Server Address Book location. IIS (Web Components
Server) then retrieves the AB file via the virtual directory pointing to the NTFS folder. By using this
URL, the client retrieves a full file the first day it connects to the server and, under most
conditions, delta files on subsequent days.
Relative to OCS 2007, a key architectural improvement for Address Book services in OCS 2007
R2 is the addition of an Address Book Web Query Service for mobile clients such as
Communicator Mobile 2007 R2. Rather than download potentially large address book files,
Communicator Mobile R2 clients make on-demand address book queries to the Address Book
Web Query Service.
NOTE: The Address Book logic described in the following sections applies to all OCS
deployments except a few special environments with either a very large number of users or a
relatively volatile Directory. For such environments, OCS Address Book logic behaves
differently in a small number of aspects, resulting in slight improvements in CPU and/or network
efficiency. Exceptions for special environments are called out separately in the sections below.


Address Book Server: File and Database Generation
This section covers the address book process and the functions of the ABServer.exe process.


Address Book Server Data Flow
The address book data is retrieved from Active Directory, stored in the RTC database, extracted
from the RTC database, and then placed in files and the RTCAb database for use by various
clients.


The following steps are performed:
   User Replicator (UR) reads the new or modified (that is, added, deleted, changed) user and
     contact object information from Active Directory and writes it into the RTC database. This
     process runs every 60 seconds.
   ABServer.exe reads the address book information from the RTC database and generates two
     sets of full and delta (that is, contains only the changes) address book files for use by Office
     Communicator (that is, with the file extension *.lsabs) and Office Communicator Phone
     Edition (that is, with the file extension *.dabs). These files are placed in a NTFS directory.
     ABServer.exe also creates a full database (that is, RTCAb) that is used by the Address Book

                                                                                                   258
     Web Query Service. By default, ABServer runs on a daily basis at 01:30. Also all phone
     numbers that cannot be normalized are placed into a .txt file in the same NTFS folder.
   Office Communicator, Office Communicator Phone Edition, and other related clients
     download either the full or delta file on a daily basis. They are access either through a file
     URL (also called a UNC path) to the NTFS folder or through a HTTPS URL (or HTTP if
     configured). The address book entries are then stored locally in the GalContacts.db and
     potentially in GalContactsDelta.db.
   Office Communicator Mobile clients leverage the Address Book Web Query Service, which
     leverages the latest daily updates in the RTCAb database.


Address Book Server Process
The Address Book Server process (C:\Program Files\Microsoft Office Communications Server
2007 R2\Server\Core\ABServer.exe) is responsible for generating the address book files (that is,
*.lsabs and *.dabs), address book database (that is, RTCAb), and normalizing phone numbers
(optional). This process is automatically run daily on one of the Office Communications Server
Front End Servers. By default, the first server added to the Office Communications Server pool is
given this role. The following table lists the various command-line options.

Table 1. ABServer.exe Command-Line Options

Command line options                Command line option              Description
                                    arguments

-?                                  None                             Displays all command switches
                                                                     for ABServer.exe.

-syncNow                            None                             Manually synchronizes the
                                                                     Address Book Server by
                                                                     pausing the service to perform
                                                                     synchronization, and then
                                                                     restarting the service. If you are
                                                                     in a failover scenario and failing
                                                                     over from one server to another
                                                                     and syncNow does not work,
                                                                     check the load-balancer
                                                                     settings. The health monitor for
                                                                     incoming port 135 should point
                                                                     to 5060 (or 5061) on the
                                                                     servers. By default, it will point
                                                                     to 135 on the servers and since
                                                                     135 is always up when the
                                                                     computer is running the server
                                                                     remains marked as being up
                                                                     even though Office
                                                                     Communications Server Front
                                                                                                      259
Command line options                 Command line option                Description
                                     arguments
                                                                        End service is down.

-regenUR                             None                               Forces user replication
                                                                        regeneration.

-dumpFile input-file [output-file]   Input-file [output-file]           Dumps the input file given as
                                                                        the first argument, formatted as
                                                                        text, to the output file given as
                                                                        the second argument. If the
                                                                        second argument is not given,
                                                                        the output file name defaults to
                                                                        the same path and file name as
                                                                        the input file with a .txt
                                                                        extension appended.

-testPhoneNorm                       Phone-number                       Loads the normalization rules
                                                                        text file and attempts to
                                                                        normalize the phone number
                                                                        arguments. The results are
                                                                        displayed in the command-line
                                                                        window. If the phone number
                                                                        argument contains spaces, the
                                                                        phone number must be
                                                                        enclosed in quotation marks
                                                                        (that is, ― ―).

-validateDB                          None                               Validates the schema and user
                                                                        data in the database.

-dumpRules                           None                               Displays all rules currently in
                                                                        effect, including generic and
                                                                        custom rules.


ABServer.exe also makes use of the following MSFT_SIPAddressBookSetting WMI properties
that control its behavior.

Table 2. ABServer.exe WMI Properties

Property name                            Type                   Default value     Description

MaxDeltaFileSizePer centage              Integer                1250              Delta file is not created
                                                                                  if percent change is
                                                                                  greater than this
                                                                                  number. (1250
                                                                                  INVALID USE OF

                                                                                                          260
Property name                         Type               Default value     Description

                                                                           SYMBOLS 12.5%)

OutputLocation                        String             None              File location, a valid
                                                                           folder.

RunTime                               Integer (0 to      130               Service start time
                                      2359)                                based on local time.
                                                                           (130 INVALID USE OF
                                                                           SYMBOLS O1:30 or
                                                                           1:30am)

SynchronizedPollingIntervalSecs       Integer            300               Number of seconds
                                                                           between checks for
                                                                           synchronization.

UseNormalizationRules                 Boolean            True              Flag to perform
                                                                           normalization or not.

PartitionOutputByOU                   Boolean            False             Flag to partition data
                                                                           by organizational unit
                                                                           (OU).

IgnoreGenericRules                    Boolean            False             Flag that determines
                                                                           whether or not to use
                                                                           the built-in generic
                                                                           rules.


Additionally, there are static Address Book Server settings that are compile-time constants in the
code as follows:
   Output file extension = .lsabs
   NumberOfDaysToKeep = 30
By default, the SQL maintenance interval is set for 02:00 local time each day. If the Address Book
Server runs during this time, its performance is likely to degrade. For this reason, the Address
Book Server runs by default at 01:30 local time each day which gives it 30 minutes to complete
before it overlaps with the SQL maintenance interval. The service can be configured to run and
generate the files in the Address Book Server file store at another time by configuring the
MSFT_SIPAddressBookSetting::RunTime WMI setting. You can also force the Address Book
Server to do a synchronization pass immediately by using the command ABServer -syncNow.
This command is useful in case the address book files are accidentally deleted. You can also
use it for testing purposes.
ABServer.exe generates various files for use by the Address Book File Download service and a
database for use by the Address Book Web Query service.




                                                                                                    261
For detailed information about the ABServer.exe process and the WMI attributes, see
Administering Address Book Servers in the Administering Office Communications Server 2007
R2 documentation.


Address Book Server: Address Book File Download Service
This topic describes how the address book file download service works.


File Generation
ABServer.exe generates two sets of files for use by 2 groups of clients. For clients that typically
have sufficient local storage space, ABServer.exe generates a file containing the full address
book that contains a large set of user and contact object attributes. To optimize download
efficiency, it also generates up to 29 delta files that contain incremental updates containing the
last one day, two days and up to 29 days worth of changes. These files have the *.lsabs file
extension.
For clients that have limited local storage such as Microsoft Communicator Phone Experience,
ABServer.exe generates a full address book file and up to 29 delta files that contain a restricted
set of user and contact object attributes. These files have the *.dabs file extension (that is, device
Address Book Server).
In Office Communications Server Standard Edition, the Address Book files are stored by default
in <drive>:\%ProgramFiles%\Office Communications Server 2007 R2\Web Components\Address
Book Files\Files. In Enterprise Edition, the Address Book file store is a shared NTFS folder that
the administrator manually creates during setup. The data gathered by the Address Book Server
is stored in a binary format in compressed files to minimize storage requirements. The number of
days that the delta files are kept is set at the static value of 30 days, and this number cannot be
changed. After 59 days (the first 29 days after a fresh start will contain fewer delta files), the
Address Book Server reaches a steady state where a set of up to 1800 files, which contain up to
900 *.lsabs and 900* .dabs files, each of which includes 30 full files and up to 870 (that is, 30
days * 29 files/day) delta files.
Each time the Address Book Server starts, it determines whether there are data files in the output
directory. If no data files are found, it will generate one full file. A delta file is not generated if there
are no initial full files from previous days to compare against. The output files are written to the
Address Book file store, a folder that can be assigned an access control list (ACL) by using the
standard NTFS share permissions.
The following table shows how the full files and delta files are generated for both *.lsabs and
*.dabs files.

Table 1. File Generation

Day                                  Generated and deleted *.lsabs        Generated and deleted *.dabs
                                     files                                files

Day 1                                Full (F1)                            Full (F1)


                                                                                                         262
Day                                Generated and deleted *.lsabs       Generated and deleted *.dabs
                                   files                               files

Day 2                              Full (F2)                           Full (F2)
                                   Delta of F2 - F1                    Delta of F2 - F1

Day 3                              Full (F3)                           Full (F3)
                                   Delta of F3 –F2                     Delta of F3 –F2
                                   Delta of F3 –F1                     Delta of F3 –F1

Day 4                              Full (F4)                           Full (F4)
                                   Delta of F4 - F3                    Delta of F4 - F3
                                   Delta of F4 - F2                    Delta of F4 - F2
                                   Delta of F4 - F1                    Delta of F4 - F1

Day 5-29                           …                                   …

Day 30                             Full (F30)                          Full (F30)
(reaches a steady state)           Delta of F30-F29                    Delta of F30-F29
                                   Delta of F30-F28                    Delta of F30-F28
                                   …                                   …
                                   Delta of F30-F1                     Delta of F30-F1

Day 31                             Full (F31)                          Full (F31)
(now needs to start deleting       Delta of F31-F30                    Delta of F31-F30
files older than 30 days)          Delta of F31-F29                    Delta of F31-F29
                                   …                                   …
                                   Delta of F31-F2                     Delta of F31-F2
                                   All files from D1 are deleted.      All files from D1 are deleted.

Day 32                             Full (F32)                          Full (F32)
                                   Delta of F32-F31                    Delta of F32-F31
                                   Delta of F32-F30                    Delta of F32-F30
                                   …                                   …
                                   Delta of F32-F3                     Delta of F32-F3
                                   All files from D2 are deleted.      All files from D2 are deleted.

Maximum Total Files                30 Full files + 30 days of up to    30 Full files + 30 days of up to
(Steady State)                     29 delta files/day = 900 files      29 delta files/day = 900 files

1800 files


By default (that is, without organizational unit (OU) partitioning), all data files are stored in one
directory. File names for full files are of the form F-xxxx, where xxxx is the file creation date
                                                                                                        263
expressed as the hexadecimal 0-based number of days since January 1, 2001. Delta file names
are of the form D-xxxx-yyyy.lsabs, where xxxx is the full file creation date, and yyyy is the delta
file creation date. Files are also assigned the appropriate *.lsabs or *.dabs file extension. Files
are created in memory and are written using a file handle that is created with no sharing allowed
so that client applications cannot access a file before it has been completely written.

Note:
    Exception: If a delta file size gets to beyond a certain percentage of the Full file size, a
    new Full file is generated instead of the incremental delta file. This percentage is
    specified by the server variable MaxDeltaFileSizePercentage. The default value for this
    is 1250, or 12.5%.
If this percentage is surpassed on the size of the server-side delta file, the server produces a full
file instead of a delta file. In this case, the server generates fewer than 30 days of delta file
information, which is an exception to its normal logic. If this number is set to a higher value, the
chances of forcing a full download decreases. However, there is more client-side processing
required to update its local database.
Additionally, any change to any attribute of an address book entry causes the entire record to be
updated. For example, if the Mobile phone number changes, the entire user address book entry is
updated.


Organizational Unit and Address Book File Generation
It is possible to create different sets of address book files based on the Organizational Unit (OU)
property in Active Directory. For example, Active Directory could leverage OUs to partition the
Active Directory into two or more logical groups based on business unit (for example,
Automotive, Marine) or business function (for example, Sales, Engineering, Manufacturing). By
setting the MSFT_SIPAddressBookSetting:PartitionOutputByOU WMI property to True,
ABServer.exe creates a number of sets of address book files in a tree of folder names that map
to the OU. This setting is passed to clients, which in turn access the address files under the
appropriate subdirectory as indicated by the user or contact object’s OU path setting.
PartitionOutputByOU can be leveraged in cases in large organizations where it is desirable to
restrict the number of contacts or the size of the address book files that are accessed by groups
of clients. It is also leveraged in Office Communications Server hosting environments where you
need to partition users based on the company.


Client and Address Book Server Communication
The Address Book URLs (that is, one internal and one external) are the paths that clients use to
access the data files in the Address Book Server file store. These URLs are configured under the
Address Book tab in the Web Components Properties for the given Standard Edition server or
Enterprise pool, and are retrieved through in-band provisioning (absInternalServerUrl and
absExternalServerUrl) by the client when it logs on to its Standard Edition server or Enterprise
pool. The clients can also have these URLs configured through Group Policy Objects.



                                                                                                   264
Office Communicator needs to be configured to access the Address Book file store by using an
URL defined in one of the following formats:
   HTTPS Format. A secure HTTP (HTTPS) URL is the recommended methodology for
     accessing address book files. HTTP can also be used but is not secure. This method uses
     the Internet Information Services (IIS) HTTP server(s) which is the core component of the
     Web Components Server. If you require the file store to be accessible by remote users who
     are connecting outside the intranet (outside the firewall), the IIS server is required and you
     must configure HTTPS on your virtual server.
   File URL Format. The file URL (also called an UNC path) is the other method for accessing
     address book files. This approach is not recommended because you cannot use it for remote
     access. The file URL is a standard file URL in the format \\server\share. Standard share and
     NTFS permissions are applicable to this URL. The clients connect to the file store through the
     Server Message Block (SMB) protocol. There are two cases when a File URL cannot be
     used: when remote access is required and if the Office Communications Server pool is set to
     require encryption. In both of these cases, a HTTPS URL is required.

Note:
     If your clients use an HTTPS URL to access the Address Book Server file store, verify
     that the client certificate is already trusted by Internet Explorer prior to an attempt by
     clients to access the Address Book URL. If the client certificate is not trusted, the
     download fails. The user is not prompted to check the certificate and to configure it as
     trusted. Consider using a certificate that is trusted by default on your client.
The type of authentication required for an Address Book URL varies depending on whether the
URL is used for internal or external clients. The following table shows the supported
authentication for each type of URL.

Table 2. Supported Authentication for Address Book URLs

Address Book URL Type                                Authentication

Internal                                             Integrated Windows Authentication (NTLM or
                                                     Kerberos)

External                                             NTLM or HTTPS (basic over Secure Sockets
                                                     Layer (SSL))



Address Book and Office Communicator
The Address Book Client Provider is a module within Office Communicator that is responsible for
synchronizing global address list (GAL) contacts with the Office Communicator contact database.
Since all GAL contacts are read-only, this synchronization is a one-way process as follows:
1. Office Communicator logs on to the Enterprise pool or Standard Edition server using its logon
   logic.



                                                                                                  265
2. Office Communicator accesses the internal and external address book shares by using the
   URLs provided either by the Group Policy Object (GPO) ABSInsideURL and ABSOutsideURL
   policy settings, or by retrieving them from the server during the logon process. These URLs
   are in either HTTPS, HTTP, or File URL format. The GPO settings take precedence over the
   settings retrieved from the server. If these GPOs are not set and depending on the setting of
   the AbsUseFallback Group Policy setting, the URLs are retrieved from either the Enterprise
   pool of the Standard Edition server. For details about these GPOs, see Deploying
   Communicator in the Client Planning and Deployment documentation and the Microsoft
   Office Communications Server 2007 R2 Group Policy Settings documentation at
   http://go.microsoft.com/fwlink/?LinkID=140494.
3. Office Communicator determines whether it is connecting from inside the intranet or
   connecting from outside through an Access Edge Server and then selects the appropriate
   URL for the connection.
    The logon credentials of the Office Communicator client are used to connect to the selected
    Address Book Server URL. Office Communicator uses the standard Internet Explorer
    application programming interface (API) to perform the URL authorization. If access is
    denied, one of the following occurs:
       If the user is inside the intranet, the client displays an icon indicating an Address Book
         download failure. The user is not asked for credentials again.
       If the user is outside the intranet, the user is prompted to enter proper URL credentials.

Note:
    Office Communicator supports the use of a fallback URL for high availability. For details
    about configuring additional URL entries, see Using WMI to Configure Address Book
    Server Settings in the Administering Office Communications Server 2007 R2
    documentation.


Client Download Process
If a client is accessing the URL for the first time and successfully connects, the client attempts to
download the current full data file. On subsequent days, the client attempts to download a delta
file based on the last full synchronization date. During daily client usage, this delta file is based on
the previous day’s changes. If the client is offline for a day or more, it determines which delta file
it must download to get up to date. For example, if the client is offline from Friday afternoon to
Monday morning, it will attempt to download a delta file containing 3 days of changes. If the client
is offline for more than 30 days, it is forced to attempt to download the full data file.
The client stores this information in the local GalContacts.db database. Storing this information in
a local database reduces the time taken to synchronize information on the client computer with
the latest information stored in Active Directory, thereby significantly improving the GAL search
process. The client will also create an index to the database which is stored in the file
GalContacts.db.idx.
In the event of a download failure because of network connectivity or other issues, the client
retries in time intervals that doubles on each previous failure (that is, 1 minute, 2 minutes, 4

                                                                                                      266
minutes, and so on, up to a maximum of 64 minutes, and then retries every 64 minutes). Any data
that was downloaded before the failure is discarded, and the retry begins again at the beginning.
If the failure persists for more than 24 hours, a warning is displayed, and an application event is
added to the Event Log.
When the client logs on, it determines if it has been more than 24 hours since the last download.
If so, then the current download occurs immediately. Otherwise, download is scheduled at 00:00
UTC (Universal Coordinated Time, also known as GMT).
The following exceptions apply:
   If the address book contains over 50K entries, the client maintains a separate delta database
     GalContactsDelta.db and index GalContactsDelta.db.idx for GAL contacts, and periodically
     merges updates into its main database GalContacts.db. This helps reduce the processing
     required on a daily basis on the client machine in very large environments.
    There are conditions when the server will not generate some of all of the delta files on the
     server. This happens when the MaxDeltaFileSizePercentage is exceeded. In this case the
     client will be forced to download the full address book file. This effectively causes the
     GalCaontacts.db to be completely replaced. Whenever a full download occurs in the case
     where there are over 50K entries, the GalContactsDelta.db database will be emptied (as
     there are no deltas).
   An additional client-side case is when the client cannot access the relevant delta file (that is,
     possibly locked, access denied, or not created due to time zones and file download time). In
     this case the client attempts to access relevant older delta files (that is, up to 2 additional
     days back). For example, after logging on at 09:00, the client cannot access a delta file
     containing 4 days of changes on Wednesday (after the files have been generated at 01:30).
     The client tries to access the delta file generated on Tuesday containing 3 days of changes,
     and if that cannot be accessed, it tries to access the delta file generated on Monday with 2
     days of changes. After successfully accessing one of these older delta files, the client does
     not try to access additional files until the next day. Although the client does not obtain the
     latest changes, it will likely get some previous changes, which in turn minimizes the amount
     of deltas it needs to process the following day.


Internet Explorer Dependencies
Because Office Communicator uses the standard Internet Explorer API to perform the URL
authorization, it depends on the following Internet Explorer settings:
   Security Settings, including the intranet URL settings. For example, if you are using an
     Internet (that is, external) type of URL, such as http://server.com/share, for intranet (that is,
     internal) users instead of an intranet URL, such as http://server/share, unless this URL is
     configured explicitly as an intranet URL in Internet Explorer, Office Communicator ignores
     this entry. We recommend that you use an intranet URL for internal users. If you have a
     specific need to use an Internet URL, you must manually configure this URL as an intranet
     URL in Internet Explorer, or you must use an Active Directory group policy to configure the
     URL.


                                                                                                     267
   Proxy Settings. If you use an HTTP proxy to manage your Web traffic and the Address Book
     data flows through this proxy, the client cannot access these URLs if the proxy becomes
     unavailable or if authorization problems occur with the proxy.


File Store Recommendations and File Size Guidelines
As a best practice, store Address Book data files on separate storage. The storage can be any of
the many types, for example a direct access storage device (DASD) or a storage area network
(SAN). The storage needs specific to the Address Book Server are very minimal and are
expected to be in the range of 20 MB to 5 GB, depending on the number of users in the forest.
The size of the full data files depends on the number of users and contacts stored in your Active
Directory. The size of the delta files increases with the number of daily changes that occur to
users and contacts in Active Directory. A large number of changes increases the delta file size
and the time it takes to generate the delta files.
On average the *.dabs files are about 25% of the size of the *.lsabs files. This depends on the
number of fields that are typically populated.


Office Communicator Local Address Book Database Files
Office Communicator 2007 R2 stores the local address book database and in the directory:
<drive>:\%LOCALAPPDATA%\Microsoft\Communicator\<user>\
The following table shows sample address book files for an organization with approximately
250,000 address book entries (that is, users, contact objects). The file sizes vary depending on
various factors such as the number of address book fields that are populated.

Table 3. Sample Address Book Files

Name                              Date modified           Type                 Size

GalContacts                       6/5/2009 9:32 AM        Data Base File       99,156 KB

GalContacts.db.idx                6/5/2009 9:32 AM        IDX File             52,394 KB

GalContactsDelta                  6/12/2009 8:30 AM       Data Base File       3,696 KB

GalContactsDelta.db.idx           6/12/2009 8:30 AM       IDX File             2,122 KB



Address Book and Office Communicator Phone Edition
The file download process on the Office Communicator Phone Edition (IP Phones) and related
devices is similar to on the process for Office Communicator, with the main difference being that it
downloads the smaller *.dabs files. These files contain a limited set of attributes, specifically
displayName, msRTCSIP_PrimaryUserAddress, telephoneNumber (that is, office), and mobile
(that is, telephone number). Although this search experience is not as robust as that of Office
Communicator, it is fairly effective. Additionally many users do not use the text search capability
on IP Phones because it is not as easy to use as using a keyboard with Office Communicator.


                                                                                                  268
Additionally predictive text searches may seem to return unexpected results, match phone
numbers and names, and have a limited screen for showing result sets.
The IP Phones locally implement a method of doing predictive search, enabling a user to query
address book text names by using dial pad digits. For example, the digit 2 could map to an ―A‖,
―B‖ or ―C‖ and 6 could map to ―M‖, ―N‖ or ―O‖. Thus, the digit sequence ―226‖ would match
address book entries with the name ―Cam‖, ―Bam‖, ―Can‖, and so on.


Address Book Web Query Service
In enterprise environments, Address Book files can get too large to be reasonably downloadable
by mobile clients, such as Communicator Mobile (2007 R2 release). To better target the needs
of mobile clients, Office Communications Server 2007 R2 introduces a parallel path for Mobile
Address Book data: The Address Book Web Query Service, which leverages the RTCAb
database to provide on-demand address book queries for mobile clients.


Address Book Server: Address Book Web Query Service
The Address Book Web Query Server queries are passed by the client to the Address Book Web
Query server by HTTPs (or HTTP if configured). The internal and external URLs are configured
on the server under which are leveraged for both Address Book Web Query Server and
Distribution List Expansion. These URLs are then passed to the clients through the dlxInternalUrl
and dlxExternalUrl in-band provisioning settings.
Queries are sent to the Address Book Web Query Server by using HTTPS (or HTTP if configured
through the URL). The ASP.net first pre-processes the query and forms an SQL query, which is
executed by the SQL Server (or SQL Server Express for SE) using the RTCAb database. Next,
post-processing of the results occurs (that is, constructing the information to be sent to the client).
The query results are then returned to the client.
Following are sample URLs for internal and external Address Book Web Server queries. The
specific search attributes are not included.




The following table lists the RTCAb database fields that are extracted from the RTC database by
ABServer.exe.

Table 1. RTCAb Database Fields

Name            Active Directory name                   Attribute ID     Example

Display         displayName                             4                ―Sara Davis‖, ―Dan G
Name                                                                     Fennell‖

Office          telephoneNumber                         10               1.425.555.0101
Number

Mobile          Mobile                                  13               1.425.555.0198


                                                                                                   269
Name               Active Directory name               Attribute ID      Example

Number

SIP Address        msRTCSIP_PrimaryUserAddress         9                 sarad@contoso.com

Primary            proxyAddress                        18                sarad@contoso.com ,
email                                                                    sara.davis@contoso.com
address


The RTCAb database is designed so that additional search fields can be easily added to the
database (adding additional fields is currently not supported). The example in the following table
shows sample data in the AbAttributeValue table, which is the primary table in the RTCAb
database that is used for queries. The UserID column maps to an address book entry (for
example, a user or contact object). The AttrID column identifies the attribute (see the previous
table), the Value column is the alpha-numeric value of the attribute (for example, ―Bill Malone‖),
and the DTMF column encodes the string value in a numeric format for predictive text dial pad.

Table 2. Sample AbAttributeValue Table

Ptrn      UserId        AttrId     Value                          DTMF (dial pad index)

1         365649        10         +1 (425) 5550198 X50198        1*425*5550198*50198

1         365649        10         14255550198                    14255550198

1         365649        10         4255550198                     4255550198

1         365649        10         5550198                        5550198

1         365649        10         0198                           0198

1         365649        4          Bill Malone                    2455*42837

1         365649        9          Billm                          24556

1         365649        9          billm@contoso.com              24556126686761266

1         365649        17         billm@contoso.com              24556126686761266

1         365649        18         billm@contoso.com              24556126686761266

1         365649        18         billm@msg.Contoso.com          245561674126686761266

1         365649        18         billm@titanium.contoso.com     24556184826486126686761266

1         365649        18         billmcontoso.com               2455626686761266

1         365649        18         2455626686761266               24556674126686761266

1         365649        18         billmtitanium.contoso.com      2455684826486126686761266




                                                                                               270
Note:
       The digit 1 in the dual-tone multifrequency (DTMF) interface is used for various
       characters (for example, !, @, ., -) and the digits 0 and 1. The symbol * is used to
       represent a space or other separators.


Office Communicator Address Book Queries
Currently, Office Communicator is the only client that leverages the Address Book Web Query
Service. The Address Book Web Query Service supports a wide set of query options.
The following table contains the parameters and default values that can be processed by the
Address Book Web Query Service. Although it is not possible for users or administrators to
modify this query, this table helps demonstrate how Address Book Query works and how queries
may differ for future clients that may leverage this service.

Table 3. Parameters and Default Values

Parameter                      Type              Default                             Notes

QueryString                    String                                                Expression for
                                                                                     the query

Dial                           Boolean           True                                Determines
                                                                                     whether a
                                                                                     predictive search
                                                                                     query is
                                                                                     performed (for
                                                                                     example, dial pad
                                                                                     queries that
                                                                                     leverage the
                                                                                     DTMF index)

PrefixQueryAttributes          String            displayName, msRTCSIP-              Attributes where
                                                 PrimaryUserAddress,                 a SQL LIKE
                                                 proxyAddress,                       comparison
                                                 telephoneNumber, mobile             operator is used
                                                                                     (for example,
                                                                                     ―Cam‖ matches
                                                                                     ―Cameron)

ExactQueryAttributes           String            displayName, msRTCSIP-              Attributes where
                                                 PrimaryUserAddress,                 a SQL =
                                                 proxyAddress,                       comparison
                                                 telephoneNumber, mobile             operator is used
                                                                                     (for example,
                                                                                     ―Cam‖ does NOT
                                                                                     match


                                                                                                      271
Parameter                  Type             Default                          Notes

                                                                             ―Cameron‖)

RequestTimeout                                                               Query timeout

MaxResult                  Int              50                               Maximum results
                                                                             to return

ReturnAttributes           String           givenName, sn, displayName,      Default set of
                                            mailNickName,                    attributes to be
                                            physicalDeliveryOfficeName,      returned to the
                                            msRTCSIP-                        user. Many of
                                            PrimaryUserAddress,              these attributes
                                            proxyAddress,                    cannot be used in
                                            telephoneNumber, homePhone,      the query string
                                            otherHomePhone, mobile,          expression
                                            otherMobile, otherTelephone,
                                            ipPhone, mail, manager


The following table lists parameters that Communicator Mobile uses. These are hardwired into
Communicator Mobile and cannot be changed.

Table 4. Communicator Mobile Parameters

Parameter                  Type             Default                           Notes

QueryString                String                                             Expression for
                                                                              the query

Dial                       Boolean          False                             Does not support
                                                                              dial pad queries

PrefixQueryAttributes      String           displayName, msRTCSIP-            Uses prefix
                                            PrimaryUserAddress,               match (SQL
                                            proxyAddress,                     LIKE)
                                            telephoneNumber, mobile

ExactQueryAttributes       String

RequestTimeout                                                                Query timeout

MaxResult                  Int              20                                Saves network
                                                                              bandwidth

ReturnAttributes           String           givenName, sn, displayName,       Default set of
                                            mailNickName,                     attributes to be
                                            physicalDeliveryOfficeName,       returned to the
                                            msRTCSIP-                         user. Many of
                                            PrimaryUserAddress,               these attributes

                                                                                               272
Parameter                    Type              Default                             Notes
                                               proxyAddress,                cannot be used
                                               telephoneNumber, homePhone, in the query
                                               otherHomePhone, mobile,      string expression
                                               otherMobile, otherTelephone,
                                               ipPhone, mail, manager



Queries on Display Name
Currently the Address Book Server only supports name-based queries based on display name. It
does not support queries based on the Active Directory entries for last name (that is, SN), first
name (that is, givenName), and so on. It may also match the user part of the Session Initiation
Protocol (SIP) Uniform Resource Identifier (URI) or e-mail address. To support names typed in
different orders (for example, ―Sara Davis‖, ―Davis, Sara‖, and ―Davis Sara‖) and users with
multiple first or last names (for example, ―Pablo Rovira Diez‖), multiple entries are placed into the
AbAttributeValue table for the display name. For example, the following entries are placed in the
table for Pablo Rovira Diez:
Pablo Rovira Diez
Diez Pablo Rovira
Diez, Pablo Rovira
Rovira Diez Pablo
Rovira Diez, Pablo
Since the Address Book Web Query Service leverages the SQL LIKE string matching expression,
all of the following strings will match at least one of the table entries, and will return ―Diez Pablo
Rovira‖ as a match (in addition to other possible matches).
Pa
Pablo
Pablo Rovira
Diez Pablo
Diez, P
Rovira
Rovira Diez P
Rovira Diez, P
However the following strings will not create a match:
Rovira Pablo
Pablo Diez
The general case for display name index generation is as follows:
   Simple Case


                                                                                                  273
        DisplayName = "A B" will support
             AB
             B a (Inversed)
             B,A (Inversed with Comma)
             Generates 3 indices
   Complex Case
        Display Name = ―A B C D E‖ will support
             ABCDE
             D E A B C (Last 2 words)
             D,E A B C (Last 2 words with Comma)
             E A B C D (Last word)
             E, A B C D (Last word with Comma)
             Generates 5 indices (no more, no less)
In the case where there are more than two words in the last name, the index based on the display
name will most likely need to be leveraged to obtain the desired match.


Queries on Phone Numbers
To support practical queries based on phone numbers, a number of indices are created. By
leveraging the SQL LIKE expression (that is, partial match), you can use a number of useful
options for searching phone numbers.
The RFC 3966/E.164 phone number ―+1.425.555.0101‖ will get entries with the following indexes:
   +1.425.555.0101
   4255550101
   5550101
   0101
   14255550101
   Tel:+14255550101
   14255550101
The RFC 3966/E.164 phone number ―+01 (23) 456789 x01‖ will get entries with the following
indexes:
   +01.23.456789.01
   012345678901
   2345678901
   45678901
   01
   0123456789
   Tel:+0123456789;ext=01


                                                                                              274
Address Book Web Query also pre-processes queries to remove any extraneous symbols. For
example, the string +1(425) 555-0101 would be translated to 14255550101 before running the
query.


Sorting Query Results
Currently, Communicator Mobile only retrieves for the first 20 matches for a given query. The
Address Book Query Server searches for the first 100 matches for any query, of which only the
first 20 entries in the result set are passed back to the client (that is, based on the actual query
sent by the client). For performance reasons the Address Book Query Server does not attempt to
process more than 100 matches. For example, if a user tries to query ―Bo‖, only the first 100
matches that SQL Server finds are returned. In cases where there are more than 100 potential
matches, the query does not fetch every attribute that begins with a ―Bo‖ (for example, every
user with a first name or last name that begins with a ―Bo‖, a SIP URI that begins with a ―Bo‖, and
so on) and sort them, as this would take up significant database cycles. Although this is not
optimal, it achieves a decent tradeoff between functionality and performance. In general, most
users refine their query and re-submit it rather than scrolling through pages of query results.
There are a few issues when a user attempts to search for a common name. For example, if a
user searched for ―Daniel‖ and there were more than 100 ―Daniels‖ in the address book, 100
random matches would be returned and subsequently sorted. The user may see ―Daniel Park‖
and ―Daniel Taylor‖ sequentially and assume that ―Daniel Roman‖ (that is, alphabetically between
Park and Taylor) is not in the address book. However, this is not necessarily the case because
―Daniel Roman‖ may not have been in the set of 100 entries returned and would not be presented
in the list. In this case the user would be expected to enter a more refined query.


Predictive Text Queries
The AbAttributeValue database table also has a column for DTMF queries. This is a special index
created to support predictive text queries where telephone dial pads are used to enter queries.
For example, the digit 2 could represent an ―A‖, ―B‖ or ―C‖. Thus if a user keyed in ―226‖, it would
match any existing entries that start with ―226‖ in the DTMF column (for example, ―Cam‖,
―Cameron‖, ―Candice‖, ―Bam‖, etc.). Although this query is supported by the Address Book Web
Query Server, there are no clients that currently leverage this interface.

Note:
    Communicator Mobile performs numeric matches on office and mobile phone numbers
    and any SIP or e-mail address that leverages digits. However these queries do not
    leverage the predictive text query algorithms.


Address Book Web Query Database
The Address Book Web Query RTCAb database is collocated as a separate SQL Server instance
on the same SQL Server as the RTC database for the given pool. The database leverages the
same high availability features as the RTC database. The database should also be included in



                                                                                                275
any backup plan, although historical copies are not relevant and the database can be
regenerated by using the ABServer –syncnow command.
The database is implemented by using two database partitions, where each partition contains a
complete copy of the address book. At any given point in time, one partition is active, which
means it is being used by Address Book Web Query Server for handling queries from clients. The
other partition is then available to the ABServer.exe process for the next nightly update. After the
update process is finished (that is, committed to the database), this new partition becomes active.
This technique helps enable optimal performance as there are no locking contention issues in the
database (that is, all queries are read-only).
The size of the RTCAb is modest and is dependent on the number of contacts in the address
book and the number of fields populated. SQL Server also reserves significant space for the
creation and maintenance of the database and various indices.


Address Book Web Query Database Language Support
The Address Book Web Query RTCAb database currently uses the Latin1_General_CI_AI (that
is, Case Insensitive, Accent Insensitive) database collation. In SQL Server, collations control
various language-specific rules for how comparisons (that is, SQL = and LIKE) and sorts (that is,
SQL ORDER BY) behave. The Latin1_General collation supports various Latin-based languages
that have the same superset of order and sorting rules, including Dutch, English, German, Italian,
and Portuguese/ Brazilian.
There are languages where the general rules of Latin largely apply to (for example, Modern
Spanish and French) but may have some subtle issues around comparison and sorting (for
example, certain ligatures may not be correctly sorted). For other languages, such as Japanese
and Simplified Chinese, where the rules of Latin have no influence, sorting and comparison are
dictated by the underlying characteristics of Unicode. In languages with a large number of
characters, users often rely on exact match and not necessarily matches based on a partial letter
match. Not having correct alphabetical ordering may not be as much of an issue as it is with
languages like English.


Address Book Web Query Server Performance
The Address Book Web Query Server and RTCAb database generally only have a minimal
impact on performance the Web Components Server (typically running on the Front-End servers)
and the back-end server. Currently, only the Communicator Mobile clients use Address Book
Web Query Server and queries on this device are explicitly controlled by the user when they use
the Search function, as opposed to being performed automatically as a user types in a name or
phone number.
The Address Book Web Query ASP.net process is relatively lightweight and the back-end
database processing is all read-only queries on a database that is updated once per day. The
Address Book Query service does not pose any significant performance bottleneck, and whatever
impact it has can be resolved by general performance tuning on the front-end and back-end
servers.


                                                                                                 276
Address Book Server: Advanced Address Book Features
This topic discusses advanced Address Book Server features, like phone number normalization,
User Replicator, and filtering.



Address Book Server Phone Number Normalization
Office Communicator requires standardized RFC 3966/E.164 phone numbers. To use phone
numbers that are unstructured or inconsistently formatted, Office Communications Server relies
on the Address Book Server to perform phone number translation in conjunction with mapping
rules. If the UseNormalizationRules WMI property is set to TRUE, ABServer.exe reads the
phone numbers from the RTC database, normalizes them (if necessary), and then writes the
normalized values into the address book (that is, download) files and the Address Book Web
Query database RTCAb. Clients, such as Office Communicator and Communicator Mobile, can
use these normalized numbers.
You can apply two types of rules to phone numbers. One type is the set of generic rules that are
automatically performed by the server. The other type is a set of sample company rules that can
be edited and is included in the installation folder alongside ABServer.exe. The sample company
rules include a comment at the start of the file informing the administrator that if they want specific
rules for their company, they should copy the sample file to the output location for the pool and
change the name to Company_Phone_Number_Normalization_Rules.txt, so that it will be used
for future synchronization passes.
If the UseNormalizationRules WMI flag is set to TRUE, the rules are applied to those Active
Directory attributes with 0x2000 bit set in the Flags column value. If the 0x1000 bit is set in the
Flags column value, the associated Active Directory attribute value is always normalized.
Sample_Company_Phone_Number_Normalization_Rules.txt is the sample file in which you
configure rules specific to your company requirements. To use this file, copy it to
Company_Phone_Number_Normalization_Rules.txt. Otherwise, Address Book Server will use
only the generic rules configured by default on the server.

Note:
    When you remove the Address Book Server,
    Company_Phone_Number_Normalization_Rules.txt is not deleted. If you want to remove
    this file, you must delete it manually.

User Replicator and Address Book Server
The Address Book Server uses data provided by User Replicator to update the information that it
initially obtains from the global address list (GAL). User Replicator writes the Active Directory
attributes for each user, contact, and group into the AbUserEntry table in the database and the
Address Book Server syncs the user data from the database into files in the Address Book Server
file store and into the Address Book Web Query database RTCab. The schema for the
AbUserEntry table uses two columns, UserGuid and UserData. UserGuid is the index column
and contains the 16-byte GUID of the Active Directory object. UserData is an image column
which contains all of the previously mentioned Active Directory attributes for that contact.

                                                                                                   277
User Replicator determines which Active Directory attributes to write by reading a configuration
table located in the same SQL instance as the AbUserEntry table. The AbAttribute table contains
three columns, ID, Name and Flags. The table is created during database setup. If the
AbAttribute table is empty, User Replicator skips its AbUserEntry table processing logic. Address
Book Server attributes are dynamic and are retrieved from the AbAttribute table, which is initially
written by the Address Book Server when the Address Book Server is activated.
Address Book Server activation populates the AbAttribute table with the values needed to support
Office Communicator 2007 R2. The following table shows those current values.

Table 1. AbAttribute Table Values

ID                         Name                                     Flags

1                          msExchHideFromAddressLists               0xFF000003

2                          givenName                                0x01000000

3                          Sn                                       0x02000000

4                          displayName                              0x03020000

5                          Title                                    0x04000000

6                          mailNickname                             0x05000400

7                          Company                                  0x06000000

8                          physicalDeliveryOfficeName               0x07000000

9                          msRTCSIP-PrimaryUserAddress              0x08020800

10                         telephoneNumber                          0x09022800

11                         homeNumber                               0x0A002800

12                         otherHomeNumber                          0x0A002000

13                         Mobile                                   0x0B022800

14                         otherMobile                              0x0B002000

15                         otherTelephone                           0x0C002000

16                         ipPhone                                  0x0D002000

17                         Mail                                     0x0E000000

18                         proxyAddresses                           0x00000105

19                         groupType                                0x0F010800

20                         ManagerouPathId                          0x10000000

21                                                                  0x11000800



                                                                                                278
The numbers in the ID column must be unique and should never be reused. Also, keeping the ID
values below 256 saves space in the output files written by the Address Book Server. However,
the maximum ID value is 65535. The Name column corresponds to the Active Directory attribute
name that User Replicator should put in the AbUserEntry table for each contact. The value in the
Flags column is used to define the type of attribute. The following types of Address Book Server
attributes are recognized by User Replicator, indicated by the low byte of the value in the Flags
column.

Table 2. Address Book Server Attributes Recognized by User Replicator

Attribute                                         Description

0x0                                               A string attribute. User Replicator converts this
                                                  type to UTF-8 before storing it in the
                                                  AbUserEntry table.

0x1                                               A binary attribute. User Replicator stores this in
                                                  the blob without any conversion.

0x2                                               A string attribute, but is included only if the
                                                  attribute value begins with "tel:". This is
                                                  primarily for multi-valued string attributes,
                                                  specifically proxyAddresses. In this case,
                                                  Address Book Server is interested only in
                                                  proxyAddresses entries that begin with "tel:".
                                                  Therefore, in the interest of saving space, User
                                                  Replicator stores only the entries that begin
                                                  with "tel:".

0x3                                               A Boolean string attribute, which if TRUE
                                                  causes User Replicator to not include this
                                                  contact in the AbUserEntry table. If FALSE, it
                                                  causes User Replicator to include the attributes
                                                  for this contact in the AbUserEntry table, but
                                                  not the particular attribute with this flag. This is
                                                  another special case type that is primarily for
                                                  the msExchHideFromAddressLists attribute.

0x4                                               A string attribute, but is included only if the
                                                  attribute value begins with "smtp:" and includes
                                                  the "@" symbol.

0x5                                               A string attribute, but is included only if the
                                                  attribute value begins with either "tel:" or
                                                  "smtp:" and includes the "@" symbol.

0x100                                             If set, this is a multi-valued attribute that can
                                                  appear more than once for each contact.

                                                                                                      279
Attribute   Description

0x400       If set, this identifies the e-mail alias attribute for
            a contact. Address Book Server uses this flag
            to identify which attribute value to show in the
            phone normalization event log entry.

0x800       If set, this identifies a required attribute for a
            contact. Address Book Server includes a user
            in the AbUserEntry table only if there is a value
            for this attribute in Active Directory. If there is
            more than one required attribute, only one of
            them is required to have a value to include the
            user in the AbUserEntry table.

0x1000      If set, Address Book Server always normalizes
            the value of this attribute.

0x2000      If set, Address Book Server uses the
            normalized number from proxyAddresses, if
            the UseNormalizationRules WMI setting is
            FALSE; otherwise it behaves the same as
            when the flag bit is 0x1000.

0x4000      If set, Address Book Server does not include
            objects in the AbUserEntry table that have this
            value for the specified attribute. For example, if
            the msRTCSIP-PrimaryUserAddress attribute
            has this flag bit set, then contacts that have this
            attribute are not written to the database.

0x8000      If set, Address Book Server does not include
            objects in the AbUserEntry table that do not
            have this value for the specified attribute. If
            both the 0x4000 and 0x8000 flag bits are set on
            an object, the attribute with the flag bit value set
            to 0x4000 takes precedence, and the object is
            excluded from the AbUserEntry table.

0x10000     If set, this represents a group object. User
            Replicator uses this flag bit to include contacts
            with the groupType attribute whose presence
            indicates a group (for example, a distribution list
            or security group).

0x20000     If set, User Replicator uses this flag bit to
            include this attribute in device-specific Address


                                                               280
Attribute                                              Description
                                                       Book Server files (that is, files with a .dabs
                                                       extension).


Filtering the Address Book
The users populated in the Address Book Server files can be controlled based on certain Active
Directory Attributes listed in the AbAttribute table. One such attribute used for filtering is the
msExchangeHideFromAddressBook attribute. This is a user attribute added by the Exchange
schema. If the value of this attribute is TRUE, Exchange Server uses this attribute to hide the
contact from the Outlook GAL. Similarly, if the value of this attribute is TRUE, User Replicator
does not include that user in the AbUserEntry table and this user will not be in the Address Book
Server files.
You can use some flag bits to define a filter to use on Address Book Server attributes. For
example, the presence of certain flag bits can identify an attribute as an include attribute or an
exclude attribute. User Replicator filters out contacts that contain an exclude attribute and filters
out contains that do not contain an include attribute.
Currently, there are three different filters. The following table lists these filers.

Table 3. Filters

Attribute                                              Description

0x800                                                  If set, this identifies a required attribute for a
                                                       contact. User Replicator uses this flag bit to
                                                       filter out contacts that do not contain at least
                                                       one required attribute. The OuPathId is a
                                                       required attribute, which is always set. So at
                                                       least one of other required attributes should be
                                                       set. Otherwise, contact (that is, with value of
                                                       required attribute OuPathId) will still not be
                                                       written to database. For example, if
                                                       telephoneNumber and homePhone are
                                                       defined as required attributes, only the contacts
                                                       that have at least one of these attributes are
                                                       written to the database.

0x4000                                                 If set, this identifies an exclude attribute. User
                                                       Replicator uses this flag bit to filter out contacts
                                                       that contain this attribute. For example, if
                                                       msRTCSIP-PrimaryUserAddress is defined
                                                       as an exclude attribute, contacts that have this
                                                       attribute are not written to the database.

0x8000                                                 If set, this identifies an include attribute. User

                                                                                                        281
Attribute                                          Description
                                                   Replicator uses this flag bit to filter out contacts
                                                   that do not contain this attribute. For example, if
                                                   msRTCSIP-PrimaryUserAddress is defined
                                                   as an include attribute, only the contacts that
                                                   have this attribute are written to the database.




Note:
    If both the 0x4000 (exclude attribute) and 0x8000 (include attribute) flag bits are set, the
    0x4000 bit overrides the 0x8000 bit and the contact is excluded.
Although you can filter the Address Book to include only certain users, limiting entries does not
limit other users' ability to contact the filtered users or to see their presence status. Users can
always find, manually send instant messages, or manually initiate calls to users not in the
Address Book by entering a user's complete sign-in name. Also, Office Communicator 2007 R2
can use contact information for a user in Outlook or the Windows Address Book.
While having full contact records in the Address Book files enables you to use Office
Communicator 2007 R2 to initiate e-mail, telephone, or Enterprise Voice calls (that is, if
Enterprise Voice is enabled on the server) with users that are not configured for Session Initiation
Protocol (SIP), some organizations prefer to include only SIP-enabled users in their Address
Book Server entries. You can filter the Address Book to include only SIP-enabled users by
clearing the 0x800 bit in the Flags column of the following required attributes: mailNickname,
telephoneNumber, homePhone, and mobile. You can also filter the Address Book to include
only SIP-enabled users by setting the 0x8000 (include attribute) in the Flags column of the
msRTCSIP-PrimaryUserAddress attribute. This also helps to exclude service accounts from the
Address Book files.
After you modify the AbAttribute table, you can refresh the data in the AbUserEntry table by
running the abserver.exe –regenUR command. After UR replication completes, you can update
the file in the Address Book Server file store by manually running the abserver.exe –syncNow
command.



Management of Office Communications
Server 2007 R2
Office Communications Server 2007 R2 provides several administrative tools to facilitate the
management of servers and users in an Office Communications Server 2007 R2 deployment.
This section provides a description of the tools and information about key management and
operations tasks for Office Communications Server 2007 R2.
In This Section


                                                                                                   282
   Administrative Tools Overview
   Installation and Use of Administrative Tools
   Troubleshooting for Office Communications Server 2007 R2
   Load Balancers for Office Communications Server 2007 R2
   Media Ports
   Voice Quality of Service (QoS)
   WMI Settings for Office Communications Server 2007 R2
   Client Registry Keys/GPO for Office Communications Server 2007 R2
   In-Band Provisioning over SIP


Administrative Tools Overview
Office Communications Server 2007 R2 provides dedicated administrative tools.
To manage Office Communications Server 2007 R2, you can do either of the following:
   Install the administrative tools on any server on which Office Communications
     Server 2007 R2 and its components are installed.
   Install the administrative tools on a separate computer, such as a centralized administration
     console on which Office Communications Server 2007 R2 is not installed.

Note:
     The Office Communications Server administrative tools are no longer installed
     automatically on servers running Office Communications Server, but you can install the
     tools by using the same Deployment Wizard that you use to install Office
     Communications Server 2007 R2. The exception is the Office Communications
     Server 2007 R2 Group Chat Server Configuration Tool, which is installed by default on
     each computer running Group Chat Server or the Group Chat Compliance service.


Administrative Tools
The following table describes the tools available for administering Office Communications
Server 2007 R2 and its components.

Table 1. Administrative Tools

Tool                              Description                       Availability and use

Office Communications             A Microsoft Management            Available on any other
Server 2007 R2 snap-in            Console (MMC) snap-in that is     computer in the domain on
                                  the primary administrative tool   which the Office
                                  for Office Communications         Communications
                                  Server 2007 R2 servers in an      Server 2007 R2 administrative
                                  Active Directory domain.          tools are installed. It cannot be
                                                                    used to manage Edge Servers,

                                                                                                 283
Tool                            Description                       Availability and use
                                                                  Proxy Servers, or other
                                                                  computers not in the domain.
                                                                  Use it to view and configure
                                                                  Office Communications
                                                                  Server 2007 R2 pools, servers,
                                                                  and users, including the
                                                                  settings for the servers and
                                                                  users on Standard Edition
                                                                  servers and in Enterprise pools
                                                                  that are in the Active Directory
                                                                  forest.

Office Communications           Additional functionality for      Available in Active Directory
Server 2007 R2 management       management of Office              Users and Computers on
components for Active           Communications Server 2007        computers on which the Office
Directory Users and             R2 servers in Active Directory    Communications Server 2007
Computers                       Domain Services (AD DS). It is    R2 administrative tools are
                                required for initially enabling   installed, but can be used only
                                each user for Office              if the server is in a domain.
                                Communications Server. You
                                can also use it for managing
                                user settings for Office
                                Communications
                                Server 2007 R2 users in the
                                domain, based on the
                                organizational unit (OU) or
                                folder in which they reside, by
                                using the Active Directory
                                Users and Computers snap-in.

Office Communications Server    An MMC snap-in that is the        Available on any computer on
2007 R2 snap-in extension for   primary tool for management       which the Office
the Computer Management         of Office Communications          Communications
console                         Server 2007 R2 servers that       Server 2007 R2 administrative
                                are not in an Active Directory    tools are installed. On the local
                                domain, such as Edge Servers      computer, only server-level
                                in the perimeter network, as      settings can be managed with
                                well as Proxy Servers.            this snap-in extension. If the
                                                                  local computer is not running
                                                                  Office Communications
                                                                  Server 2007 R2, you can use
                                                                  Computer Management to
                                                                  connect to an Office

                                                                                               284
Tool                          Description                       Availability and use
                                                                Communications
                                                                Server 2007 R2 server and
                                                                then use the Office
                                                                Communications
                                                                Server 2007 R2 snap-in
                                                                extension to manage the
                                                                server-level settings of that
                                                                computer.

The 2007 R2 version of        An MMC snap-in that is the        Available on any server in the
Communicator Web Access       primary administrative tool for   domain on which the Office
snap-in                       Communicator Web Access.          Communications
                                                                Server 2007 R2 administrative
                                                                tools are installed.

Response Group Service        An MMC snap-in that is the        Available in the Office
snap-in                       primary administrative tool for   Communications Server 2007
                              Office Communications             R2 snap-in.
                              Server 2007 R2 servers.

Response Group Configuration A Web-based tool that is used      Installed with the Web
Tool                         to create and manage               Components Server or
                             Response Groups.                   Standard Edition server. Any
                                                                computer that is in the same
                                                                forest as the server that is
                                                                running the Response Group
                                                                Service can use the Internet
                                                                Explorer Internet browser to
                                                                access the Response Group
                                                                Configuration Tool.

Office Communications         A Group Chat tool to create       Can be installed on any
Server 2007 R2 Group Chat     categories and chat rooms,        computer in the domain
Administration Tool           define their scope and            available for installation of the
                              membership, create federated      Group Chat Administration
                              users and groups, manage          Tool.
                              how users can use the chat
                              rooms, and specify which
                              users are administrators and
                              managers.

Group Chat Server             A Group Chat tool to start, Available on any server
Configuration Tool            stop, and configure Group   running Group Chat Server or
                              Chat Servers, configure the the Compliance service.
                              Group Chat database, manage

                                                                                                285
Tool                            Description                         Availability and use
                                compliance, and set logging
                                levels.

LCSCmd.exe                      A command-line tool used to         Available on any computer in
                                prepare Active Directory            the domain on which the Office
                                Domain Services, create             Communications
                                Enterprise pools, perform           Server 2007 R2 administrative
                                XML-based logging, manage           tools are installed.
                                permissions, and install,           This tool is used initially for
                                activate, check the status of, or   Active Directory preparation,
                                deactivate servers, as well as      and then for ongoing backup
                                to perform backup and               and restoration operations, so
                                restoration operations for          it is not covered in this
                                Office Communications               documentation. For details
                                Server 2007 R2 servers and          about how to use this tool for
                                Enterprise pools.                   Active Directory preparation
                                                                    and other command-line
                                                                    management tasks, see
                                                                    Preparing Active Directory
                                                                    Domain Services for Office
                                                                    Communications Server 2007
                                                                    R2 in the Deployment
                                                                    documentation and the
                                                                    Command Line Reference in
                                                                    the Reference documentation.

RGSCOT.exe                      A command-line tool used to         Available on any server in the
                                create and manage Response          domain on which the Office
                                Group Service Contact               Communications
                                objects.                            Server 2007 R2 administrative
                                                                    tools are installed.


In addition to the administrative tools described in the table, you can use Windows Management
Instrumentation Tester (WBEMTest), which ships with the Windows Server 2008 and Windows
Server 2003 operating systems, to modify Windows Management Instrumentation (WMI) settings.
Run the WBEMTest tool on any computer on which Office Communications Server 2007 R2 is
installed. This guide includes specific procedures for using WBEMTest to change WMI settings.
For details about WBEMTest, see "Using WBEMTest user interface" at
http://go.microsoft.com/fwlink/?LinkId=139797.

Note:
   The Group Chat and Communicator Web Access tools listed in the table are described in
   separate administration documentation. For details about administering Group Chat and

                                                                                                286
     Communicator Web Access, see the Administering Group Chat documentation and the
     Administering Communicator Web Access documentation.


Permissions
Installation of Office Communications Server 2007 R2 administrative tools on a computer that is
not running Office Communications Server 2007 R2 requires using an account that is a member
of the Administrators group (or an account with equivalent privileges).
Using administrative tools requires the following:
   To administer user account settings, an account that is a member of the
     RTCUniversalUserAdmins group, or an account with equivalent privileges.
   For all other Office Communications Server 2007 R2 administration tasks, an account that is
     a member of the RTCUniversalServerAdmins group, or an account with equivalent privileges.


Installation and Use of Administrative Tools
You can install and use the Office Communications Server 2007 R2 administrative tools on any
computer in the domain that meets the administrative tools prerequisites, such as on a computer
that you use as a central administrative console. For details about installation prerequisites, see
Internal Office Communications Server Component Requirements in the Supported Topologies
and Infrastructure Requirements documentation.

Note:
     Installation and use of Office Communications Server requires that users be members of
     specific groups. For details about providing appropriate permissions and delegation, see
     Accounts and Permissions Requirements in the Planning and Architecture
     documentation.
This section covers primarily the use of the Office Communications Server 2007 R2
administrative tools to manage Office Communications Server. For details about installing and
using the administrative tools, including the Office Communications Server user management
functionality in Active Directory Users and Computers, see the Administering Office
Communications Server 2007 R2 documentation. For details about using the LCSCmd.exe
command-line tool to manage Office Communications Server, see the Command Line Reference
in the Reference documentation. For details about other tools for administering other Office
Communications Server 2007 R2 components, see the Administering Communicator Web
Access documentation and the Administering Group Chat documentation.
In This Section
This section includes the following topics:
   Version Restrictions
   Remote Administration Requirements
   Installing Administrative Tools



                                                                                                 287
Version Restrictions
Installing Office Communications Server 2007 R2 administrative tools on the same computer as
Office Communications Server 2007 administrative tools or Live Communications Server 2005
with Service Pack 1 (SP1) administrative tools is not supported. Additionally, you cannot
administer servers and users from previous versions of Office Communications Server or
Microsoft Live Communications Server with the Office Communications Server 2007 R2
administrative tools, nor can you administer Office Communications Server 2007 R2 servers and
users with previous versions of the Office Communications Server or Live Communications
Server administrative tools.
You can use the Move Users Wizard in Office Communications Server 2007 R2 to move users
from Office Communications Server 2007. For details about migrating from Office
Communications Server 2007 to Office Communications Server 2007 R2, see Supported
Migration Paths and Coexistence Scenarios in the Supported Topologies and Infrastructure
Requirements documentation and the migration documentation in the Office Communications
Server 2007 R2 TechNet Library at http://go.microsoft.com/fwlink/?LinkID=132106.


Remote Administration Requirements
If you want to use remote administration to deploy or administer Office Communications Server
2007 R2 while Windows Firewall is running, you must configure Windows Firewall to enable the
remote administration exception. For details, see "Help: Enable or disable the remote
administration exception" in the Windows Server product documentation at
http://go.microsoft.com/fwlink/?LinkId=137361.
To remotely administer or deploy the Web Components Server, you must also add Inetinfo.exe to
the Windows Firewall exceptions list. For details, see "Help: Add a program to the Windows
Firewall exceptions list" in the Windows Server product documentation at
http://go.microsoft.com/fwlink/?LinkId=137362.


Installing Administrative Tools
In Office Communications Server 2007 R2, the Office Communications Server administrative
tools are not installed by default. To install the administrative tools on a computer running Office
Communications Server 2007 R2 or on another computer, such as a management console from
which you want to centrally manage Office Communications Server 2007 R2 servers and users,
you can use the Deployment Wizard to install the administrative tools, including Response Group
Service and Communicator Web Access. For a description of each of these tools, see
Administrative Consoles in the Planning and Architecture documentation.

Important:
    Before installing the administrative tools, verify that all prerequisites have been met,
    including operating system requirements and installation of required updates. For details,
    see Administrative Tools Software Requirements in the Supported Topologies and
    Infrastructure Requirements documentation.


                                                                                                 288
Use one of the following two procedures to install the Office Communications Server 2007 R2
administrative tools on a computer running a 64-bit version of the operating system or a 32-bit
version of the operating system.

Note:
    This topic covers the installation of the Office Communications Server 2007 R2
    administrative tools, which are the primary tools for managing Office Communications
    Server. For information about other tools for managing other optional Office
    Communications Server 2007 R2 components, see the Administering Communicator
    Web Access documentation and the Administering Group Chat documentation.

To install the Office Communications Server 2007 R2 administrative tools on a computer
    running a 64-bit version of the operating system

    1. On the computer on which you want to install the Office Communications Server 2007 R2
       administrative tools, log on using an account that is a member of the Administrators
       group (or an account with equivalent privileges) and the Domain Admins group.
    2. Do one of the following:
           Insert the Microsoft Office Communications Server CD, and then click Enterprise
             Edition.
           Insert the Microsoft Office Communications Server CD, and then click Standard
             Edition.
           If you are installing from a network share to a 64-bit computer, browse to the
             \setup\amd64 folder on the network share, and then double-click setupEE.exe or
             setupSE.exe.
    3. On the Office Communications Server 2007 R2 Deployment Wizard page, click
       Administrative Tools.
    4. Review the license agreement, click I accept the terms in the license agreement to
       proceed, and then click OK.
    5. Take the appropriate action on each page of the wizard to complete the installation.

        Note:
             Installing or removing the administrative tools on a computer running the
             Windows Vista operating system on which the Security Center service is running
             with the startup mode set to Automatic may result in the following error
             message: "Error stopping service since one or more dependent services failed to
             stop. Please try again." If you close the error message, the process should
             complete successfully.

To install the Office Communications Server 2007 R2 administrative tools on a computer
    running a 32-bit version of the operating system
    1. On the computer on which you want to install the Office Communications Server 2007 R2
       administrative tools, log on using an account that is a member of the Administrators
       group (or an account with equivalent privileges) and the Domain Admins group.

                                                                                                  289
     2. On the Microsoft Office Communications Server CD or a network share containing the
        installation files, browse to the \support\i86 folder.
     3. Run vcredist_x86.exe to start the Microsoft Visual C++ 2008 Redistributable Setup
        wizard. Take the appropriate action on each page of the wizard to complete the
        installation.
     4. Run SQLServer2005_BC.msi to start the Microsoft SQL Server 2005 Backward
        Compatibility Setup Wizard. Take the appropriate action on each page of the wizard,
        including using the default for Feature Selection, to complete the installation.
     5. Run sqlncli.msi to start the wizard for Microsoft SQL Server Native Client. Take the
        appropriate action on each page of the wizard, including using the default for Feature
        Selection, to complete the installation.
     6. Run OCSCore.msi to start the Office Communications Server 2007 R2 Core Components
        Setup Wizard. Take the appropriate action on each page of the wizard to complete the
        installation.
     7. Run AdminTools.msi to start the Office Communications Server 2007 R2 Administrative
        Tools Setup Wizard. Take the appropriate action on each page of the wizard to complete
        the installation.

         Note:
             Installing or removing the administrative tools on a computer running Windows
             Vista on which the Security Center service is running with the startup mode set to
             Automatic may result in the following error message: "Error stopping service
             since one or more dependent services failed to stop. Please try again." If you
             close the error message, the process should complete successfully.




Troubleshooting for Office Communications
Server 2007 R2
Office Communications Server 2007 R2 includes several logging and diagnostics tools that can
help troubleshoot an Office Communications Server deployment. The tools include:
   OCSLogger. Generates logs for different server components while the server is running.
   Snooper. Protocol analysis tool designed to view logs generated by the OCSLogger tool;
     loads the supplied log file and shows the messages in its display. Snooper is part of Microsoft
     Office Communications Server 2007 R2 Resource Kit Tools. The Resource Kit includes
     documentation for using the tool.
Office Communications Server also includes ms-diagnostics headers that are error code
extensions that solve the need for more granular SIP error codes to communicate diagnostic
information through a new ms-diagnostics header. There are two purposes of these error code
extensions:



                                                                                                  290
   Convey diagnostic information to help troubleshoot infrastructure (server) problems,
     misconfigurations, syntactical problems and other reasons for a non-successful SIP
     response.
   Convey actionable error codes to the client, which can then be used by the client
     applications, such as the Live Meeting client and Office Communicator, to display appropriate
     errors to the user.
The error IDs and reason values for ms-diagnostic headers are documented in the ―Appendix A:
Diagnostics Header Error ID and Reason Values‖ section of the [MS-OCER]: Client Error
Reporting Protocol Specification at http://go.microsoft.com/fwlink/?LinkId=144413.


Load Balancers for Office Communications Server
2007 R2
A hardware load balancer is required in an Enterprise pool with more than one Enterprise Edition
server. A load balancer is not required for a Standard Edition server or a single Enterprise Edition
Front End Server. A load balancer is required, for arrays of Office Communications Server 2007
R2 Edge Servers. The load balancer performs the critical role of delivering scalability and high
availability across multiple servers connected to a centralized database on the Office
Communications Server 2007 R2, Back-End Database.


Prerequisites for a Load Balancer Connecting to a Pool
Before configuring a load balancer to connect to the Office Communications Server 2007 R2
Enterprise pool, you must configure the following:
   A static IP address for servers within your pool.
   For each server within the pool, a certificate issued for server authentication by a certification
     authority in the pools local domain.
   A virtual IP (VIP) address and a DNS record for the load balancer.
   Test users created and SIP-enabled in the pool.
   Install root certificate from the certification authority (CA) in the domain (or trusted CA) on
     client computers.
   Log on to all servers in the pool using TLS to ensure certificates are working.


Load Balancer Requirements
A load balancer for the Office Communications Server 2007 R2 Enterprise pool must meet the
following requirements:
   Must expose a VIP Address through ARP (Address Resolution Protocol).
   The VIP must have a single DNS entry, called Pool FQDN.
   The VIP must be a static IP address.



                                                                                                       291
   Must allow multiple ports to be opened on the same VIP. Specifically, it must expose the
     ports described in the following table.


     Ports Required                                 Port Use

     5060                                           SIP communication over TCP.

     5061                                           SIP communication over TLS.

     135                                            To move users from a pool and other remote
                                                    DCOM-based operations.

     443                                            HTTPS traffic to the pool URLs.

     444                                            Communication between the focus (Office
                                                    Communications Server 2007 R2 component
                                                    that manages conference state) and the
                                                    conferencing servers.

     5065                                           SIP listening requests for Application Sharing.

     5069                                           Monitoring Server.

     5071                                           SIP listening requests for Response Group
                                                    Service.

     5072                                           SIP listening requests for Conferencing
                                                    Attendant.

     5073                                           SIP listening requests for Conferencing
                                                    Announcement Server.

     5074                                           SIP listening requests for Outside Voice
                                                    Control.

     8404                                           TLS (remoting over MTLS) listening for inter-
                                                    server communications for Response Group
                                                    Service.


   The load balancer must provide TCP-level affinity. This means that the load balancer must
     ensure that TCP connections can be established with one Office Communications Server
     2007 R2 in the pool and all traffic on that connection destined for that same Office
     Communications Server 2007 R2.
   The load balancer must provide a configurable TCP idle-timeout interval with a maximum
     value greater than or equal to the minimum of the REGISTER refresh or SIP Keep-Alive
     interval of 30 minutes.
   The load balancer should support a rich set of metrics (round robin, least connections,
     weighted, and so forth). A weighted least connections-based load balancing mechanism is
     recommended for the load balancer. This means that the load balancer will rank all Office

                                                                                                 292
     Communications Servers 2007 R2 based on the weight assigned to them and the number of
     outstanding connections. This rank will then be used to pick the Office Communications
     Server 2007 R2 to be used for the next connection request.
   The load balancer must be able to detect Office Communications Server 2007 R2 availability
     by establishing TCP connections to either port 5060 (SIP over TCP), 5061 (SIP over TLS),
     and 444 (conferencing over HTTPS), depending on which is active (often called a heartbeat
     or monitor). The polling interval must be a configurable value with a minimum value of at least
     five seconds. The load balancer must not select an Office Communications Server 2007 R2
     that shuts down until a successful TCP connection (heartbeat) can be established again.
   Every Office Communications Server 2007 R2 must have exactly one network adapter.
     Multihoming an Office Communications Server 2007 R2 is not supported.
   The network adapter must have exactly one static IP address. This IP address will be used
     for the incoming load-balanced traffic.
   The computer must have a registered FQDN. The IP address registered for this FQDN must
     be publicly accessible from within the enterprise.
   The load balancer must allow for adding and removing servers to the pool without shutting
     down.
   The load balancer must be NAT (network address translation) capable.
When you configure the load balancer, you need to request the relevant network and DNS
administrator for a VIP (virtual IP) address for the load balancer, as well as a static IP address for
every server that you plan to deploy in the Enterprise pool.


Supported Load Balancer Configurations
Most load balancers can be configured to operate in either Secure Network Address Translation
(SNAT) mode or Destination Network Address Translation (DNAT) mode. With SNAT, both the
source and IP destinations are changed as a TCP request passes through the Load Balancer.
With DNAT, only the destination IP address is changed and the source IP address is passed
through intact.
Destination network address translation (DNAT) is not supported for load balancing of an
Enterprise pool or Communicator Web Access, but both DNAT and source network address
translation (SNAT) are supported for load balancing of Edge Servers and HTTP The issues with
DNAT are related to inter-server communication within a pool (specifically, members of a pool
trying to connect to their own VIP), which will fail in a DNAT configuration. For details about load
balancing pools, see Enterprise Edition in the Planning and Architecture documentation. For
details about load balancing Edge Servers, see External User Access Components in the
Planning and Architecture documentation. For details about load balancing Communicator Web
Access, see Communicator Web Access Support in the Planning and Architecture
documentation. For details about Directors, see Director Component in the Supported Topologies
and Infrastructure Requirements documentation. For details about load balancing support in
Office Communications Server 2007 R2, see Environmental Requirements in the Supported
Topologies and Infrastructure Requirements documentation.

                                                                                                   293
Also, Direct Server Return is a third variant of NAT. Direct Server Return is not supported.


Media Ports
This section describes port range requirements for media traffic. For information on configuring
non-media ports (for example, an overall system-wide ports table), see the Planning and
Architecture documentation.
For a complete list of all edge server, firewall, and external load balancer port settings, see the
Deploying Edge Servers for External User Access documentation. For details about load balancer
configuration, see Load Balancers for Office Communications Server 2007 R2.
In This Section
   Mediation Server for Office Communications Server 2007 R2
   Media Port Range for Office Communications Server 2007 R2


Mediation Server for Office Communications Server 2007 R2
The internal edge of a Mediation Server should be configured to correspond to a unique static
route that is described by an IP address and a port number. This IP address must be the one
corresponding to the IP address from the DNS resolution of the FQDN of the Mediation Server.
The default port is 5061.
The external edge of a Mediation Server should be configured as the internal next-hop proxy for
the media gateway. It should be identified by a unique combination of IP address and port
number. The IP address should not be the same as that of the internal edge, and the default port
is 5060.
When configuring Mediation Server, you are advised to accept the default media port gateway
range of 60,000 to 64,000. The default range media port range enables the server to handle up to
1,000 simultaneous voice calls. Reducing the port range greatly reduces server capacity and
should be undertaken only for specific reasons by an administrator who is knowledgeable about
media port requirements and scenarios. For this reasons, altering the default port range is not
recommended.

Note:
     Organizations that use IPSec for packet security are advised to disable it for media ports
     because the security handshake required by IPSec delays call setup. IPSec is
     unnecessary for media ports because SRTP encryption secures all media traffic between
     the Mediation Server and the internal Communications Server network.


Media Gateway
Depending on the gateway vendor, there are potentially many attributes that must be set, but to
use the gateway for Enterprise Voice, port 5060 must be configured as the listening port that is
used for TCP connections to the Mediation Server.



                                                                                                  294
Media Port Range for Office Communications Server 2007 R2
This section describes the minimum media port allocation requirements for the client and server.
The default UDP/TCP port range used by the Office Communicator 2007 R2 client is 1024-65535.
The Real Time Media Communications stack in Office Communicator 2007 R2 allocates the
media port dynamically in this range. To maintain an adequate level of performance, you can
specify a smaller port range for Office Communicator 2007 R2 to use.
To control the specific range of ports that need to be open on a firewall, a registry key setting is
provided to force the media stack to reduce the range of port values that can be used for real-
time media communications. On the Office Communicator client, the port range registry settings
are as follows:
   HKLM\Software\Policies\Microsoft\Communicator\PortRange\Enabled
   HKLM\Software\Policies\Microsoft\Communicator\PortRange\MaxMediaPort
   HKLM\Software\Policies\Microsoft\Communicator\PortRange\MinMediaPort
By default none of these registry keys is set.


Minimum Number of Ports
If you use the port range registry key settings to reduce the ports that can be used for media, it is
recommended that you do so according to the minimums described in this section.
For client endpoints, the port range should not be reduced to the point where it can compromise
the ability of the media stack to negotiate audio, video, and desktop sharing communication ports
during session setup or during a call. More specifically, for an Office Communicator 2007 R2
client, the minimum port range is 40. A smaller range of ports can result in errors during call
transfer and conference escalation scenarios.
By configuring a minimum of 40 ports, you enable the client to evaluate the candidate transport
addresses that it can use to stream audio, video, and desktop sharing to another client, as
described in the Internet Engineering Task Force (IETF) Interactive Connectivity Establishment
(ICE) protocol. Candidate addresses include a local address and an address on the A/V Access
Edge server. A minimum of 40 ports in the port range will also accommodate any escalations
from a peer-to-peer call to a conference.

Note:
     An escalation of a peer-to-peer call to a conference triggers a temporary doubling of the
     ports in use.
Different call scenarios can dictate whether to deliver by using User Datagram Protocol (UDP) or
Transmission Control Protocol (TCP). However, whenever UDP can be used to deliver media, it
will be used instead of TCP.

Note:
     Secure Real-Time Transport Protocol (SRTP) and Secure Real-Time Transport Control
     Protocol (SRTCP) streams are multiplexed over TCP but are delivered separately in the
     case of UDP. UDP connections are more resilient to packet loss than TCP. When a UDP
     packet is lost, there is no transport impact to subsequent packets. When packet loss
                                                                                                  295
    occurs over TCP, all subsequent packets are held at the transport level to ensure a
    reliable stream of data. As a result, overall latency in the media delivery chain may
    increase over TCP.
The following set of tables show the detailed port requirements for call setup:

Table 1.0 Port Requirements for Call Setup

                      Voice ICE v6   Voice ICE v6     Voice ICE v6    Voice ICE v19   Voice ICE v19
                      UDP RTP        UDP RTCP         TCP RTP+        UDP RDP         UDP RTCP
                                                      RTCP

ICE Local             1              1                1               1               1
Candidate

ICE A/V Edge          1              1                1               1               1
Server Candidate

Voice Maximum         4              4                4               4               4
Number of Ports

Consultative Call     4              4                4               4               4
Transfer, Number
of Additional Ports

Total Audio           8              8                8               8               8
Maximum Number
of Ports

Audio Video           16             16               16              16              16
Maximum Number
of Ports

Consultative Call     16             16               16              16              16
Transfer Maximum
Number of Ports

Total Audio Video     32             32               32              32              32
Maximum Number
of Ports

Audio Video           16             16               16              16              16
Desktop Sharing
Maximum Number
of Ports

Consultative Call     16             16               16              16              16
Transfer Maximum
Number of Ports

Total Audio Video     32             32               32              32              32

                                                                                                 296
                      Voice ICE v6    Voice ICE v6   Voice ICE v6   Voice ICE v19   Voice ICE v19
                      UDP RTP         UDP RTCP       TCP RTP+       UDP RDP         UDP RTCP
                                                     RTCP
Desktop Sharing
Maximum Number
of Ports


Table 1.1 Port Requirements for Call Setup

                      Voice ICE v19   CIF/VGA/HD Video    CIF/VGA/HD Video    CIF/VGA/HD Video
                      TCP RTP+        ICE v6 UDP RTP      ICE v6 UDP RTCP     ICE v6 TCP RTP+
                      RTCP                                                    RTCP

ICE Local             1               1                   1                   1
Candidate

ICE A/V Edge          1               1                   1                   1
Server Candidate

Voice Maximum         4               N/A                 N/A                 N/A
Number of Ports

Consultative Call     4               N/A                 N/A                 N/A
Transfer, Number
of Additional Ports

Total Audio           8               N/A                 N/A                 N/A
Maximum Number
of Ports

Audio Video           16              16                  16                  16
Maximum Number
of Ports

Consultative Call     16              16                  16                  16
Transfer Maximum
Number of Ports

Total Audio Video     32              32                  32                  32
Maximum Number
of Ports

Audio Video           16              16                  16                  16
Desktop Sharing
Maximum Number
of Ports

Consultative Call     16              16                  16                  16

                                                                                               297
                      Voice ICE v19   CIF/VGA/HD Video   CIF/VGA/HD Video    CIF/VGA/HD Video
                      TCP RTP+        ICE v6 UDP RTP     ICE v6 UDP RTCP     ICE v6 TCP RTP+
                      RTCP                                                   RTCP
Transfer Maximum
Number of Ports

Total Audio Video     32              32                 32                  32
Desktop Sharing
Maximum Number
of Ports


Table 1.2 Port Requirements for Call Setup

                      CIF/VGA/HD Video     CIF/VGA/HD Video   CIF/VGA/HD Video    Desktop
                      ICE v19 UDP RTP      ICE v19 UDP RTCP   ICE v19 TCP RTP+    Sharing TCP
                                                              RTCP                RTP+ RTCP

ICE Local             1                    1                  1                   2
Candidate

ICE A/V Edge          1                    1                  1                   1
Server Candidate

Voice Maximum         N/A                  N/A                N/A                 N/A
Number of Ports

Consultative Call     N/A                  N/A                N/A                 N/A
Transfer, Number
of Additional Ports

Total Audio           N/A                  N/A                N/A                 N/A
Maximum Number
of Ports

Audio Video           16                   16                 16                  N/A
Maximum Number
of Ports

Consultative Call 16                       16                 16                  N/A
Transfer Maximum
Number of Ports

Total Audio Video     32                   32                 32                  N/A
Maximum Number
of Ports

Audio Video           16                   16                 16                  16
Desktop Sharing

                                                                                              298
                     CIF/VGA/HD Video     CIF/VGA/HD Video     CIF/VGA/HD Video       Desktop
                     ICE v19 UDP RTP      ICE v19 UDP RTCP     ICE v19 TCP RTP+       Sharing TCP
                                                               RTCP                   RTP+ RTCP
Maximum Number
of Ports

Consultative Call 16                      16                   16                     16
Transfer Maximum
Number of Ports

Total Audio Video    32                   32                   32                     32
Desktop Sharing
Maximum Number
of Ports



The following set of tables show the detailed port requirements for escalation during a call:

Table 2.0 Port Requirements for Escalation During a Call

                     Voice ICE v6    Voice ICE v6    Voice ICE v6     Voice ICE v19    Voice ICE v19
                     UDP RTP         UDP RTCP        TCP RTP+         UDP RDP          UDP RTCP
                                                     RTCP

Established P2P      1               1               1                1                1
or Conference

Escalation From      1               1               1                1                1
P2P to
Conference

Total Audio    4                     4               4                4                4
Maximum Number
of Ports

Total Audio Video 16                 16              16               16               16
Maximum Number
of Ports

Total Audio Video 16                 16              16               16               16
Desktop Sharing
Maximum Number
of Ports




                                                                                                  299
Table 2.1 Port Requirements for Escalation During a Call

                    Voice ICE v19   CIF/VGA/HD Video     CIF/VGA/HD Video     CIF/VGA/HD Video
                    TCP RTP+        ICE v6 UDP RTP       ICE v6 UDP RTCP      ICE v6 TCP RTP+
                    RTCP                                                      RTCP

Established P2P     1               1                    1                    1
or Conference

Escalation From     1               1                    1                    1
P2P to
Conference

Total Audio         4               N/A                  N/A                  N/A
Maximum Number
of Ports

Total Audio Video   16              16                   16                   16
Maximum Number
of Ports

Total Audio Video   16              16                   16                   16
Desktop Sharing
Maximum Number
of Ports


Table 2.2 Port Requirements for Escalation During a Call

                    CIF/VGA/HD Video      CIF/VGA/HD Video     CIF/VGA/HD Video    Desktop
                    ICE v19 UDP RTP       ICE v19 UDP RTCP     ICE v19 TCP RTP+    Sharing TCP
                                                               RTCP                RTP+ RTCP

Established P2P     1                     1                    1                   2
or Conference

Escalation From     1                     1                    1                   1
P2P to
Conference

Total Audio    N/A                        N/A                  N/A                 N/A
Maximum Number
of Ports

Total Audio Video 16                      16                   16                  N/A
Maximum Number
of Ports

Total Audio Video   16                    16                   16                  16
Desktop Sharing


                                                                                                 300
                     CIF/VGA/HD Video     CIF/VGA/HD Video       CIF/VGA/HD Video       Desktop
                     ICE v19 UDP RTP      ICE v19 UDP RTCP       ICE v19 TCP RTP+       Sharing TCP
                                                                 RTCP                   RTP+ RTCP
Maximum Number
of Ports



The following set of tables show the detailed overall requirements for ports:

Table 3.0 Overall Requirements for Ports

                   Voice ICE v6     Voice ICE v6    Voice ICE v6        Voice ICE v19    Voice ICE v19
                   UDP RTP          UDP RTCP        TCP RTP+            UDP RDP          UDP RTCP
                                                    RTCP

Minimum Ports      16               16              16                  16               16
Required for
Audio

Minimum Ports      32               32              32                  32               32
Required for
Audio Video

Minimum Ports      32               32              32                  32               32
Required for
Audio Video
Desktop Sharing

ALL *              32               32              32                  32               32


Table 3.1 Overall Requirements for Ports

                   Voice ICE v19    CIF/VGA/HD Video       CIF/VGA/HD Video       CIF/VGA/HD Video
                   TCP RTP+         ICE v6 UDP RTP         ICE v6 UDP RTCP        ICE v6 TCP RTP+
                   RTCP                                                           RTCP

Minimum Ports      16               N/A                    N/A                    N/A
Required for
Audio

Minimum Ports      32               32                     32                     32
Required for
Audio Video

Minimum Ports      32               32                     32                     32
Required for
Audio Video

                                                                                                      301
                    Voice ICE v19    CIF/VGA/HD Video     CIF/VGA/HD Video      CIF/VGA/HD Video
                    TCP RTP+         ICE v6 UDP RTP       ICE v6 UDP RTCP       ICE v6 TCP RTP+
                    RTCP                                                        RTCP
Desktop Sharing

ALL *               32               32                   32                    32


Table 3.2 Overall Requirements for Ports

                    CIF/VGA/HD Video      CIF/VGA/HD Video     CIF/VGA/HD Video      Desktop
                    ICE v19 UDP RTP       ICE v19 UDP RTCP     ICE v19 TCP RTP+      Sharing TCP
                                                               RTCP                  RTP+ RTCP

Minimum Ports       N/A                   N/A                  N/A                   N/A
Required for
Audio

Minimum Ports       32                    32                   32                    N/A
Required for
Audio Video

Minimum Ports   32                        32                   32                    32
Required for
Audio Video
Desktop Sharing

ALL *               32                    32                   32                    32




Note:
     * 8 additional ports required to accommodate any third party applications. At least 40
     ports needed for allocating ports in the same range at the same time.
As described in the tables, the minimum number of ports that must be allocated on a client
platform is 40. During a normal call, the number of ports used will not exceed 2, 4, or 5 depending
on whether audio, audio/video, or audio/video/Desktop sharing are streamed.


Server Port Allocation
Changing the default port range on the server is not recommended. However, if your organization
has a need to establish port ranges on the server, you can use the following WMI settings to
configure the port range:
   MSFT_SIPPoolConfigSetting
   MSFT_SIPDataMCUSetting
   MSFT_SIPMediationServerConfigSetting

                                                                                                   302
For an A/V Conferencing Server as well as all other server components terminating Audio/Video
media (for example, Front-Ends hosting Conferencing Attendant, Response Group Service), the
port range must be at least six times the maximum number of concurrent call legs that can be
supported on the server (that is, two ports for the RTP and RTCP traffic for each modality –
audio, video, and panoramic video).
For an A/V Access Edge server, the port range must be at least twelve times the maximum
number of outside user calls that can be supported on the server (two ports for the RTP and
RTCP traffic for each modality – audio, video and panoramic video, or audio, video, and desktop
sharing for ICE v6 and ICE v19.
For a Mediation Server, the port range must be at least eight times the maximum number of
concurrent calls that can be supported on the server (that is, two ports for the RTP and RTCP
traffic for audio multiplied by two because the Mediation Server is a back-to-back User Agent for
ICE v6 and also for ICE v19).


Voice Quality of Service (QoS)
The quality of the service associated with synchronous traffic like audio or video can be impacted
by delay, jitter, and packet loss in the IP network. Although Office Communications Server 2007
R2 has been designed to work without any Quality of Service (QoS) framework, it can be
deployed in IP networks with QoS implemented using Differentiated Services (DiffServ). To
support the QoS environment, endpoints are configured to mark the IP traffic conveying the real-
time audio and video IP traffic according to well-established classes of services designed to
protect the real-time communication traffic from other asynchronous traffic in the IP network,
including instant messaging (IM), application sharing data, and file downloads. These markings
can be changed to map to different classes of services as desired by an enterprise.


QoS with Office Communications Server 2007 R2
A network enabled for Differentiated Services (DiffServ) provides class-level prioritization based
on Differentiated Services Code Point (DSCP) marking of the IP packets. Each DSCP value
corresponds to a class of service for forwarding packets from the sender or intermediary router to
the next router or receiver in the network. The forwarding behaviors can be implemented by using
a variety of techniques, including priority queuing, weighted fair queuing, or conventional leaky
bucket-based techniques. Relevant classes for the delivery of audio and video media streams are
the Expedited Forwarding (EF) and Assured Forwarding (AF) classes, respectively. For a
description of the 6-bit DSCP field values in the Type of Service byte of any IP packet, see IETF
RFC 2474.
In Office Communications Server 2007 R2, DSCP marking can be enabled to configure the media
stack to mark the IP traffic conveying the real-time audio and video IP traffic according to well-
established classes of services. By default, DSCP marking is not enabled. If enabled, the marking
of the IP packets is done by the QoS Packet Scheduler service. The resulting marked packets
can subsequently be recognized by network entities (end systems and routers) to manage the
media traffic according to the QoS priorities. The QoS marking is applied to all media ports and
regardless of whether the audio/video traffic is delivered over Real-Time Protocol (RTP; see IETF
                                                                                               303
RFC 3350) or Secure Real-Time Protocol (SRTP; see IETF RFC 3711). Because QoS policies
are often tied to UDP or TCP ports, Office Communications Server 2007 R2 also includes a
Group Policy registry setting (on client platforms) or a WMI setting (on server platforms) to specify
the port range for the UDP and TCP ports used in delivering media streams.
Before enabling QoS for Office Communications Server 2007 R2, you must provision the network
correctly. Relevant classes for the delivery of audio and video media streams in Office
Communications Server 2007 R2 are the following:
   For audio, the Expedited Forwarding (EF) class. Audio streams affected by this marking
     include DTMF, Comfort Noise, and Audio with Forward Error Correction (FEC) streams.
   For video, the Assured Forwarding (AF) class. Video streams affected by this marking include
     Video streams with FEC packets.
After ensuring that the network is correctly configured, Office Communications Server 2007 R2
can be configured to support a QoS environment by enabling DSCP marking, which includes
doing the following:
   Enabling QoS on the appropriate servers and clients
   Running QoS on computers
   Ensuring that Group Policy settings are correct on servers and client computers
The procedures in Enabling DSCP Marking describe how to configure Office Communications
Server components to support a QoS environment.

Note:
     Generally, a QoS environment is set up before Office Communications Server is
     deployed, and the procedures in this documentation are implemented after the
     Communications Server components are deployed. If you add Differentiated Services
     capability to the Enterprise network after you deploy Office Communications Server 2007
     R2, use the information in Implementing Support for a QoS Environment in the
     Administering Office Communications Server 2007 R2 documentation to enable and
     configure Office Communications Server media traffic to take advantage of this new
     capability.


Enabling DSCP Marking
The procedures in this section describe how to configure components to enable Differentiated
Services Code Point (DSCP) marking for Office Communications Server 2007 R2. This includes:
   Enabling QoS.
   Installing the QoS Packet Scheduler on computers.
   Verifying Group Policy settings on computers.

Note:
     DSCP marking is generally enabled at the time of deployment in a QoS environment. If
     you add Differentiated Services capability to the Enterprise network after deploying Office



                                                                                                   304
     Communications Server 2007 R2, you can configure Office Communications Server
     media traffic to take advantage of this new capability at that time.


Enabling QoS
To enable DSCP marking for Office Communications Server 2007 R2, you must enable QoS on
the following components:
   Media servers, which are configured via in-band provisioning. These servers include the
     following:
        A/V Conferencing Server.
        Front End Servers or Standard Edition servers running Conferencing Attendant or
          Response Group Service.
        Unified Communications Managed API server.
   Mediation Servers, which are configured using WMI settings.
   Office Communicator 2007 R2 clients, including Communicator 2007 R2 Attendant, which are
     configured by creating a registry key.
   Office Communicator 2007 R2 Phone Edition clients, which are configured using Office
     Communicator property settings via in-band provisioning.

Note:
     After completing these procedures for enabling QoS, you must verify that the QoS Packet
     Scheduler is running and the Group Policy settings are correct on each client and server,
     using the procedures provided later in this topic.

To enable QoS on media servers

     1. Log on to the Office Communications Server 2007 R2 server as a member of the
        RTCUniversalServerAdmins group or an account with equivalent user rights.
     2. Click Start, and then click Run.
     3. In the Open box, type wbemtest, and then click OK.
     4. In the Windows Management Instrumentation Tester dialog box, click Connect.
     5. In the Connect dialog box, in Namespace, specify root\cimv2, and then click Connect.
     6. In the Windows Management Instrumentation Tester dialog box, click Query.
     7. In the Query dialog box, in Enter Query, do one of the following:
             For Standard Edition Server, specify select * from MSFT_SIPPoolConfigSetting
               where backend="(local)\\rtc", and then click Apply.
             For an Enterprise pool, specify select * from MSFT_SIPPoolConfigSetting where
               backend=”<SQL Server>\\<database instance>", and then click Apply. (RTC is
               the default database instance name.)
     8. In the Query Result dialog box, double-click the MSFT_SIPPoolConfigSetting instance
        (which should be the only instance available on this media server).
     9. In the Object editor dialog box, in Properties, click ServerQoSEnabled, and then click

                                                                                                 305
       Edit Property.
   10. In the Property Editor dialog box, in Value, specify True, and then click Save Property.
   11. Repeat the preceding steps for each Office Communications Server 2007 R2 server that
       is in a different pool in your environment, including each A/V Conferencing Server, server
       running the Response Group Service, and Unified Communications Managed API server.
       Media servers within the same pool will share the settings after they have been set on the
       Office Communications Server 2007 R2 server for that pool. Mediation Server does not
       join a pool, so the settings need to be run separately as a WMI setting on that platform.


   Important
          After completing this procedure, ensure that the QoS Packet Scheduler is installed
            and that Windows Group Policy settings are appropriately configured on each
            computer.
          Policies are propagated via in-band provisioning, so for the policies to become
            effective, you must do one of the following:

To enable QoS on Mediation Servers
   1. Log on to the Mediation Server as a member of the RTCUniversalServerAdmins group or
      an account with equivalent user rights.
   2. Click Start, and then click Run.
   3. In the Open box, type wbemtest, and then click OK.
   4. In the Windows Management Instrumentation Tester dialog box, click Connect.
   5. In the Connect dialog box, in Namespace, type root\cimv2, and then click Connect.
      and then click Enum Classes.
   6. In the Windows Management Instrumentation Tester dialog box, click Enum Classes.
   7. In the Superclass info dialog box, leave the name blank, and then click OK.
   8. In the Query Result dialog box, double-click the class name
      MSFT_SIPMediationServerConfigSetting.
   9. In the Object editor for MSFT_SIPMediationServerConfigSetting dialog box, click
      Instances.
   10. In the Query Result dialog box, double-click the
       MSFT_SIPMediationServerConfigSettingInstanceID instance (which should be the
       only instance available on this Mediation Server).
   11. In the Object editor dialog box, in Properties, click QoSEnabled, and then click Edit
       Property.
   12. In the Property Editor dialog box, in Value, specify True, and then click Save Property.
   13. In the ObjectEditor dialog box, click Save Object.
   14. Restart the Mediation Server service.
   15. Repeat the preceding steps on each Office Communications Server 2007 R2 Mediation

                                                                                               306
       Server.

   Note:
       This procedure only enables DSCP in the WMI settings of the Mediation Server. After
       completing this procedure, ensure that the QoS Packet Scheduler is installed and
       that Group Policy settings are appropriately configured on each computer, and then
       restart the services.

To enable QoS on Communicator clients
   1. Log on to the desktop, laptop, or Attendant client as a member of the Administrator group
      or an account with equivalent user rights.
   2. Open the Registry Editor.
   3. Create the following registry key:
       HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RTC\Transport


   4. Restart the Office Communicator 2007 R2 service.
   5. Repeat the preceding steps on each desktop, laptop, and attendant client.

   Note:
       This procedure only enables DSCP on the client. After completing this procedure,
       ensure that the QoS Packet Scheduler is installed and that Group Policy settings are
       appropriately configured on each computer, and then restart the services.

To enable QoS on Office Communications Server 2007 R2 Phone Edition

   1. Log on to a server running Office Communications Server 2007 R2 or a computer on
      which Office Communications Server 2007 R2 administrative tools are installed, as a
      member of the RTCUniversalServerAdmins group or an account with equivalent user
      rights.
   2. Open the Office Communications Server 2007 R2 snap-in.
   3. In the console tree, expand the forest node, and then do one of the following:
          For an Enterprise pool, expand Enterprise pools, expand the pool, right-click Front
            Ends, and then click Properties.
          For a Standard Edition server, expand Standard Edition servers, right-click the
            pool, click Properties, and then click Front End Properties.
   4. In the Front End Properties dialog box, on the Voice tab, next to Advanced options,
      click Configure.
   5. Verify the IP QoS value (default is 40) and the 802.1p Voice value (default is 0) For
      optimum quality of service, we recommend that you use the default values. To turn off
      DSCP marking, set both values to 0.
   6. For the new settings to take effect, restart the device or log off and log on to the device.
   7. Click OK, twice.

                                                                                                 307
Installing the QoS Packet Scheduler on Computers
The QoS Packet Scheduler needs to be active and configured properly in order for Office
Communications Server 2007 R2 servers and clients in order to make the marking active. For
details about the QoS Packet Scheduler service, see Voice Quality of Service (QoS) in the
Technical Reference for Office Communications Server 2007 R2 in the Reference
documentation.
By default, the QoS Packet Scheduler is installed on computers running Windows XP, Windows
Vista, and Windows 2008. By default, the QoS Packet Scheduler is not installed on Windows
Server 2003. Use the following procedures to determine whether the QoS Packet Scheduler is
installed and, if not, install it.

To install the QoS Packet Scheduler on Windows XP or Windows Server 2003
    1. Log on to the computer as a member of the Administrators group or an account with
       equivalent user rights.
    2. Click Start, and then click Control Panel.
    3. Click Network Connections.
    4. Right-click the network interface on which you want to enable the QoS Packet Scheduler,
       and then click Properties.
    5. Click Install.
    6. In Select Network Component Type, click Service.
    7. Click Add.
    8. In Select Network Service, click QoS Packet Scheduler, and then click OK.

To install the QoS Packet Scheduler on Windows Vista or Windows Server 2008
    1. Log on to the computer as a member of the Administrator group or an account with
       equivalent user rights.
    2. Click Start, and then click Control Panel.
    3. Click Network and Sharing Center.
    4. Right-click the network interface on which you want to enable the QoS Packet Scheduler,
       and then click Properties.
    5. Click Install.
    6. In Select Network Feature, click Service.
    7. Click Add.
    8. In Select Network Service, click QoS Packet Scheduler, and then click OK.


Verifying Group Policy Settings on Computers
In order to support DSCP marking on the servers and client computers in your organization, the
Group Policy settings for conforming packets for the two service types used by QoS Packet
Scheduler must be enabled and cannot be set to zero. This includes the following:

                                                                                             308
   SERVICETYPE_GUARANTEED. This setting guarantees that IP datagrams will arrive within
     the guaranteed delivery time and will not be discarded due to queue overflows, provided the
     flow's traffic stays within its specified traffic parameters. This service is intended for
     applications that need a firm guarantee that a datagram will arrive no later than a certain time
     after it was transmitted by its source.
      The Real Time Media Communications stack marks the RTP/SRTP audio packets (default
     payload type value equal to 0, 3, 4, 8, 13, 97, 101, 111, 112, 114, 115, 116, or 118) as
     SERVICETYPE_GUARANTEED. This marking is off by default. To enable QoS on high-
     definition video, also update the following registry key to set the value to 250000 bytes per
     sec (2 Mbps):
     HKEY_LOCAL_MACHINE\Software\Microsoft\RTC\Transport\VideoBandwidthDiscardThresh
     oldBytesPerSec
   The SERVICETYPE_CONTROLLEDLOAD setting provides an end-to-end QoS that closely
     approximates transmission quality provided by best-effort service, as expected under
     unloaded conditions from the associated network components along the data path.
     Applications that use SERVICETYPE_CONTROLLEDLOAD may therefore assume the
     following:
        The network will deliver a very high percentage of transmitted packets to its intended
          receivers. In other words, packet loss will closely approximate the basic packet error rate
          of the transmission medium.
        Transmission delay for a very high percentage of the delivered packets will not greatly
          exceed the minimum transit delay experienced by any successfully delivered packet.
        The Real Time Media Communications stack marks the RTP/SRTP video packets
          (default payload type value equal to 34 or 121) as
          SERVICETYPE_CONTROLLEDLOAD. This marking is off by default.
Use the following procedure on each client and server to ensure that the Group Policy settings for
the two service types are set correctly.

To verify service type settings on a computer

     1. Log on to the computer as a member of the Administrators group or an account with
        equivalent user rights.
     2. Click Start, and then click Run.
     3. In the Open box, type gpedit.msc.
     4. In the Group Policy Object Editor dialog box, expand Computer Configuration,
        expand Administrative Template, expand Network, expand QoS Packet Scheduler,
        and then click DSCP value of conforming packets.
     5. In DSCP value of conforming packets, verify that Guaranteed service type and
        Controlled load service each have one of the following settings:
             Not configured.
             Enabled with a nonzero value. To see the value, right-click the setting, and then click


                                                                                                    309
             Properties.
           Disabled.

        Note:
             To ensure that the policies are applied, you may need to run the gpupdate
             /target:computer /force command. This command may need to be run
             each time the computer is restarted. For details, see Knowledge Base article
             973779, ―Some QoS Group Policy settings are not retained after you restart a
             client computer that is running Windows Vista or Windows Server 2008‖ at
             http://support.microsoft.com/kb/973779 and Knowledge Base article 972878,
             ―The "Guaranteed service type" Group Policy setting returns to the default value
             after you restart a client computer that is running Windows XP or Windows
             Server 2003‖ at http://support.microsoft.com/kb/972878.




WMI Settings for Office Communications Server
2007 R2
For details about Office Communications Server WMI settings, see the Office Communications
Server SDK at the Microsoft Web site http://go.microsoft.com/fwlink/?LinkId=144486.


Client Registry Keys/GPO for Office
Communications Server 2007 R2
For details about Office Communicator registry settings, see the Office Communicator 2007
policy documentation available at the Microsoft Web site
http://go.microsoft.com/fwlink/?LinkID=140494.


In-Band Provisioning over SIP
After the client is signed in, the client receives settings from the server pool through in-band
provisioning. Specific settings that have been configured in the Office Communications Server
properties are propagated to the client during this process. Unlike Group Policy, which is
delivered by using a separate mechanism that is based on Windows and Active Directory, in-
band provisioning carries settings within the Session Initiation Protocol (SIP) and does not require
a separate communications channel.
For example, Office Communicator clients receive server locations, security information, and
settings related to specific client features during in-band provisioning. Office Communicator
Phone Edition devices receive the list of supported location profiles and pool-level defaults
through in-band provisioning.
The following table outlines the settings that are sent to Office Communicator clients during in-
band provisioning and the location where these settings are configured on the server.

                                                                                                    310
Table 1. In-Band Provisioning Settings

Settings sent through in-band provisioning     Location in server properties

Internal and external URLs for the Address     In the pool properties, Web Component
Book Server and Web Service for Distribution   Properties, Address Book tab, Internal URL
Group expansion.                               and External URL

Location of the Media Relay Access server      In the forest properties, Global Properties,
(MRAS, part of A/V Edge Server)                Edge Servers tab, under A/V Edge Servers.

SIP high security mode                         In the pool properties, Front End Properties,
                                               Voice tab, in the Advanced Voice Options
                                               page (after Advanced Options, click
                                               Configure), under SIP security mode.

Telephony Mode, which determines whether       Voice license: In the user’s Active Directory
enterprise and voice telephony features,       properties, Communications tab, Telephony
remote call control, computer-to-computer      options. Enterprise license: In the forest
calling, are enabled                           properties, Global Settings, Meetings, Global
                                               Policies Enterprise with Voice license: Both of
                                               the above settings

Audio/video conferencing and data              In the forest properties, Global Properties,
conferencing,                                  Meetings, Global Policies

Simultaneous ringing                           In the forest properties, Voice Properties,
                                               Policy tab, edit the policy and select or clear
                                               the Allow simultaneous ringing of phones
                                               check box

Whether encryption is supported or required    Pool Properties, Media tab, under Security
when making and receiving audio and video      Settings, Encryption Level
calls

Default location context for phone calls       In the forest properties, Voice Properties,
                                               Location tab

Line information for the UC phone line         In the user’s Active Directory properties,
                                               Communications tab, Telephony options,
                                               Line URI.

Maximum video rate allowed                     In the pool properties, Front End Properties,
                                               Video tab, select the appropriate setting for
                                               Maximum video quality

Enforce pin lock                               In the pool properties, Front End Properties,
                                               Voice tab, select or clear the Enforce phone
                                               lock check box


                                                                                              311
Why Use In-Band Provisioning?
To ensure a consistent user experience across all endpoints, Office Communications Server uses
in-band provisioning. This enables policies and settings (for example, the MRAS setting) to be
sent to non-domain joined clients as well as devices such as Office Communicator Phone Edition,
Office Communicator Mobile (2007 R2 release).
For endpoints like Office Communicator 2007 R2, an advantage of using in-band provisioning is
that information critical to client functionality is stored on the server and not on the computer or
the specific endpoint.
In-band provisioning simplifies the application of policies and server settings across the
organization because the settings apply to all clients that sign in to the server pool. However,
some organizations may need to apply distinct settings and policies to different groups within the
organization. Administrators can achieve this greater level of granularity by using Group Policy to
apply separate client settings to different Active Directory groups.

Note:
     Office Communicator Phone Edition clients receive all settings from the server through in-
     band provisioning and are not configurable through registry-based Group Policy.
Some application layer settings are common between Office Communicator 2007 R2 and Office
Communicator Phone Edition. Because Office Communicator Phone Edition has no group policy
mechanism, certain application layer settings that were previously controlled solely through
Group Policy have moved in-band in the Office Communications Server 2007 R2 release. This
change was made so that Office Communicator Phone Edition clients could receive these
settings through in-band provisioning. However, before you remove any group policies because
the settings have moved in-band, you should consider the effect on Office Communicator 2007
R2 clients. Following are the affected settings:
   Portrange (Specify dynamic port ranges) and the Enabled, MaxMediaPort, and MinMediaPort
     subkeys
   EnableTracing (Turn on tracing for Office Communicator)
   EnableSIPHighSecurityMode (Configure SIP security mode)
Of these settings, the SIP Security Mode setting is used during the bootstrapping process to
specify whether Transport Layer Security (TLS) is required. If your organization requires a TLS
connection between clients and servers in previous versions of Office Communications Server,
you have probably already set the Group Policy for SIP Security Mode. Even though the setting
has moved in-band for Office Communications Server 2007 R2, you should retain the SIP
Security Mode group policy because it is still used during bootstrapping, before the client is able
to receive settings through in-band provisioning. Maintaining the SIP Security Mode policy retains
security during the bootstrapping process.


Office Communicator 2007 R2 Group Policy Precedence
Some Office Communicator 2007 R2 features and behaviors can be configured by the
administrator by using Office Communications Server 2007 R2 in-band provisioning, or by the


                                                                                                  312
user through the Communicator 2007 R2 Options dialog box. However, Group Policies take
precedence over both of these methods.
The following table summarizes the order in which settings take precedence when a conflict
occurs.

Table 2. Group Policy Precedence

Precedence                  Location or Method of Setting

1                           HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator

2                           HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator

3                           Office Communications Server 2007 R2 In-Band provisioning

4                           Office Communications Server 2007 R2 In-Band provisioning



Policy transport
In-band settings are requested when a client signs in. The client sends a sequence of messages
and the server responds. The following shows the sequence of interactions between the client
and the server.
The client first sends a SERVICE request for the location profile settings. The following is an
example of the start-line.
SERVICE
sip:amst@litwareinc.com;gruu;opaque=app:locationprofile:get;default
SIP/2.0
The server responds with a 200 OK message that contains the location profile settings. The
content type of the response is application/ms-location-profile-definition+xml. The message body
contains the dialing rule patterns and corresponding translations. An example of a message body
is as follows:
<LocationProfileDescription
xmlns="http://schemas.microsoft.com/2007/03/locationProfileDescription"
>
    <Name>Local.LitwareInc.com</Name>
    <Rule>
        <Pattern>^(112)$</Pattern>
        <Translation>$1</Translation>
        <InternalEnterpriseExtension>false</InternalEnterpriseExtension>
        <ApplicableForDeviceDialing>true</ApplicableForDeviceDialing>
    </Rule>
</LocationProfileDescription>


                                                                                                  313
The client then sends a SUBSCRIBE request for the contact list. The Event header in the
SUBSCRIBE message has a value of vnd-microsoft-roaming-contacts. The server responds with
a 200 OK message that contains the contact list, the various groups that the users has created
and contacts who belong to each group. The Content type header of the response is
application/vnd-microsoft-roaming-contacts+xml. The following snippet shows an example of the
response that contains the contact list.
<contactList deltaNum="248" >
<group id="1" name="~" externalURI=""              />
<group id="2" name="Sales Team" externalURI=""                 />
<group id="3" name="Accounts Team" externalURI=""                   />
<contact uri="amst@contoso.com" name="" groups="2 3" subscribed="true"
externalURI=""       />
<contact uri="hc@contoso.com" name="" groups="1" subscribed="true"
externalURI=""       />
<contact uri="gy@contoso.com" name="" groups="1" subscribed="true"
externalURI=""       />
<contact uri="va@contoso.com" name="" groups="1 2" subscribed="true"
externalURI=""       />
</contactList>


A client endpoint also sends a SUBSCRIBE message for various provisioning settings. This
SUBSCRIBE message contains an Event header with a value of vnd-microsoft-provisioning-v2.
The Content type of the message is application/vnd-microsoft-roaming-provisioning-v2+xml.
An example of a SUBSCRIBE message for the roaming provisioning settings is as follows:
<provisioningGroupList
xmlns="http://schemas.microsoft.com/2006/09/sip/provisioninggrouplist">
    <provisioningGroup name="ServerConfiguration"/>
    <provisioningGroup name="meetingPolicy"/>
    <provisioningGroup name="ucPolicy"/>
    <provisioningGroup name="publicationGrammar"/>
    <provisioningGroup name="userSetting"/>
</provisioningGroupList>


The server responds with a 200 OK message that contains the settings for the requested
provisioning groups. The Content type of the response is application/vnd-microsoft-roaming-
provisioning-v2+xml. The response contains server configuration such as update server URLs,

                                                                                           314
Address book server URLs, Console download URLs. The following settings are new in Office
Communications Server 2007 R2: Call Control Server Uri, Pool Uri, and Maximum video rate
allowed. An example of the response containing the roaming provisioning settings is as follows:
<provisionGroupList
xmlns="http://schemas.microsoft.com/2006/09/sip/provisiongrouplist-
notification">
 <provisionGroup name="ServerConfiguration" >
    <ucMaxVideoRateAllowed>VGA-600K</ucMaxVideoRateAllowed>


<absInternalServerUrl>https://absint.contoso.com/Abs/Int/Handler</absIn
ternalServerUrl>


<absExternalServerUrl>https://absext.contoso.com/Abs/Ext/Handler</absEx
ternalServerUrl>
    <absWebServiceEnabled>true</absWebServiceEnabled>
    <ucPC2PCAVEncryption>RequireEncryption</ucPC2PCAVEncryption>
    <organization>Contoso, Inc.</organization>


<consoleDownloadInternalUrl>http://r.office.microsoft.com/r/rlidOCSR2?c
lid=1033&amp;p1=livemeeting</consoleDownloadInternalUrl>


<consoleDownloadExternalUrl>http://r.office.microsoft.com/r/rlidOCSR2?c
lid=1033&amp;p1=livemeeting</consoleDownloadExternalUrl>


<dlxInternalUrl>https://ocs.contoso.com/GroupExpansion/Int/service.asmx
</dlxInternalUrl>


<dlxExternalUrl>https://ocs.contoso.com/GroupExpansion/Ext/service.asmx
</dlxExternalUrl>
    <dlxEnabled>true</dlxEnabled>
    <ucDiffServVoice>40</ucDiffServVoice>
    <ucVoice802_1p>0</ucVoice802_1p>
    <ucEnforcePinLock>true</ucEnforcePinLock>
    <ucMinPinLength>6</ucMinPinLength>
    <ucPhoneTimeOut>10</ucPhoneTimeOut>
    <ucExchangeMWIPoll>3</ucExchangeMWIPoll>
    <ucEnableSIPSecurityMode>High</ucEnableSIPSecurityMode>

                                                                                              315
      <ucEnableUserLogging>false</ucEnableUserLogging>
…
</provisionGroup>
    <provisionGroup name="meetingPolicy" instanceId="{6B151D61-D98B-4A16-
9D6C-8BBB3111228A}" >
      <instance>
      <property name="Name"><![CDATA[Default Policy]]></property>
      <property name="ColorDepth"><![CDATA[High colors]]></property>
      <property
name="AllowPresenterToDelegateRecording"><![CDATA[false]]></property>
      <property name="EnableAppDesktopSharing"><![CDATA[true]]></property>
      <property
name="AllowAppSharingForExternalMeeting"><![CDATA[Desktop]]></property>
      <property name="MeetingSize"><![CDATA[50]]></property
      …
      </instance>
</provisionGroup>
    <provisionGroup name="ucPolicy" instanceId="{6B41BE99-5C45-41E5-B34C-
F6B8D0079E7B}" >
      <instance>
      <property name="Name"><![CDATA[Default Policy]]></property>
      <property
name="AllowUsersToChangeTeamSettings"><![CDATA[true]]></property>
   <property
name="AllowSimultaneousRinging"><![CDATA[true]]></property>
      </instance>
                  </provisionGroup>
              </provisionGroup>
    <provisionGroup name="userSetting" >
      <ucUserLocationProfile >Main.Contoso.com</ucUserLocationProfile>
    </provisionGroup>
</provisionGroupList>




                                                                         316
Provisioning Groups
There are different provisioning groups, each group deals with a specific area of category of
settings. The various provisioning groups and the settings they contain are as follows:
   Server Configuration. Contains update server URLs, Address Book server URLs, console
     download URLs, distribution list URLs, media relay server URL, Quality of Service (QoS)
     server URL, Communicator Web Access URLs, call control server URLs.
   Meeting Policy. Settings that control whether the presenter is allowed to record a meeting,
     whether application sharing is allowed, IP audio and IP video.
   User setting. User specific location profile.
   ucPolicy. Contains settings for simultaneous ringing, phone usages, and so on.
   Publication Grammar. A fixed manifest sent out by the server. It allows the client endpoint to
     control the aggregation logic and the manifest is server agnostic.




                                                                                                317

				
DOCUMENT INFO
Description: Micrsoft Office Communications Server 2007 R2 Documentation and Updates