Server-Based Dial-In Conferencing Components

Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

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; 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, 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.

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 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 Mediation Server’s next hop pool. If a load balancer is used, it listens on TCP port 5072 as well and redirects requests to a Conferencing Attendant service running on one of the pool servers.

There are only a few pool-level settings stored in the back-end SQL Server database. The Office Communications Server administrative snap-in exposes the settings for minimum PIN length, retry lockout count, and PIN aging policy settings through the PSTN Conferencing tab in the Front End Properties dialog box of the selected pool.

These settings can also be accessed through the MSFT_SIPPSTNConferencingSetting WMI object, in addition to the PINExpiration, PINLength, and PINRetries property values.

Note

The pool-level MSFT_SIPPSTNConferencingSetting WMI object also contains values for InternalURL and ExternalURL properties. These last two settings are left-over artifacts of an earlier development build and can be disregarded. They refer to a Web component named PhoneConferencing that was used during development and did not get removed from the final release of Office Communications Server 2007 R2 product. This component is visible from the Internet Information Services (IIS) Manager connected to Front End servers, but it is superfluous.

Conferencing Announcement Service

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

The Conference Announcement Service on each Front End Server listens on TCP port 5073 for requests from a Focus that is running on one of the Front End Servers in the pool. If a load balancer is used, it also listens on TCP port 5063 and redirects requests to the Conferencing Attendant service on one of the pool servers.

Focus Factory

The Focus Factory is responsible for scheduling meetings and writing them to the back-end database. When a user creates a new meeting, the meeting client sends a SIP SERVICE message to a Focus Factory, which creates a new instance of the meeting in the database and returns information about the newly created meeting to the client.

The Focus Factory functionality has been enhanced in Office Communications Server 2007 R2 to support dial-in conferences. When a client (which could be Office Communicator, the Conferencing Add-in for Outlook, or the Live Meeting client) creates a scheduled or unscheduled meeting, if the meeting creator requests and is permitted to include dial-in participants, the Front End Server communicates with a Focus Factory to generate a dial-in Conference ID.

Conference IDs are short numeric conference identifiers that are entered by dial-in attendees (by using the phone keypad) to indicate the meeting that they want to join. Conference IDs consist of a non-unique pool ID concatenated with a unique portion generated by the hosting pool when the meeting is created. The pool portion of the Conference ID routes the dial-in caller to the specific pool where the meeting is hosted.

Although Meeting IDs (16 to 32 character hexadecimal identifiers used in the Conference URI to uniquely identify meetings), the short Conference IDs of expired conferences can be reused and are unique only within the scope of a single Office Communications Server organization. The mappings between the Conference IDs and Meeting IDs are stored in the RTC database. Users do not normally need to enter Meeting IDs manually, but dial-in users manually enter Conference IDs using their keypads to tell the Conferencing Attendant Service which meeting they want to join.

The overall length of Conference IDs not fixed and will expand as needed to support the number of pools in the organization and the number of unexpired meetings in the pool, and the pool portion (that is, the pool ID) will be at least two digits. As a minimum security consideration to minimize effortless guessing of consecutive Conference IDs, after the complete conference ID is generated, it is obfuscated by Office Communications Server (that is, the number the user sees cannot be parsed into a pool portion and a meeting portion).

The Conference ID is generated at the home pool of the user who schedules it, and it designates the pool that will host the meeting. However, since the conference creator’s pool always hosts the conference, this means that conference IDs must be released and reissued whenever a conference’s creator has been moved to another pool. This action is automatically taken by Office Communications Server. Unlike Meeting IDs, Conference IDs may be reused after the conference mapped to has been deleted or moved.

The Front End Server passes the Conference ID back to the conference client, where it is conveyed to dial-in participants through some other means, such as in an e-mail message.

Focus

An instance of the Focus for each active meeting exists on one of the servers in the pool that is hosting the meeting, and it maintains the conference state and can be monitored by other components. For example, the Conference Announcement Service monitors the Focus to determine when users arrive or leave the meeting and when users have been muted or unmuted.

The Focus publishes the meeting roster, which has been updated in Office Communications Server 2007 R2 to include dial-in callers. If the caller has an Active Directory Domain Services account and has provided his or her extension number and corporate PIN, he or she will be listed in the roster lists of Live Meeting clients under the display name assigned to their user account. However, if the caller has provided only the Conference ID (and passcode if required), he or she will be listed in the roster by Caller ID (if the number is passed to the Mediation Server by the PBX or gateway). If not, such callers will be listed as Unidentified Participant 1, Unidentified Participant 2, and so forth.

From the roster list in the Live Meeting client, presenters can forcibly mute, unmute, and eject dial-in participants just as if they were Live Meeting client users.

Conferencing Server Factory

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

Audio/Video Conferencing Server

An A/V Conferencing Server acts as a relay hub for audio and video used by the meetings assigned to it. Dial-in callers appear to the A/V Conferencing Server as just another audio endpoint. After a dial-in caller has been authenticated, the Conferencing Attendant signals the A/V Conferencing Server in the pool hosting the meeting to establish an audio leg with the Mediation server handling the dial-in participant.

When a dial-in user is connected to the A/V Conferencing Server, it in turn invites a Conference Announcement Service in its pool to the meeting (unless one is already running), which in turn joins the Focus as a trusted participant. The Conference Announcement Service monitors the Focus, and announces certain state change events to all dial-in participants, such as when a participant enters or leaves the meeting, or to individual dial-in participants, such as when his or her microphone has been muted.

Mediation Servers

In order for the Dial-in Conferencing feature to service PSTN callers, the organization must have either one or more Mediation Servers connected to the PSTN using a Media Gateway connected to the PSTN or to a PBX, or Direct SIP Integration with a PBX or external SIP Trunking service provider. As with Enterprise Voice user Direct Inward Dialing (DID) numbers and Exchange Auto Attendant and Subscriber Access numbers, calls from the PSTN to the published dial-in access numbers must also be routed to a Mediation Server. Inbound routing normalizes the called-party number according to the default location profile rules on the Mediation Server and routes calls to the address of the next-hop pool.

No special Mediation Server configuration is required to support dial-in conferencing, but the normalization rules for the Mediation Server’s default location profile must normalize the dialed number to a form (typically E.164) matching the Line URI of a Conferencing Attendant contact object.

Routing of Conferencing Attendant contact numbers to a Mediation Server may also require additional routing rules on the PBX and/or Media Gateway if the phone number patterns differ from those of Enterprise Voice users (or if Enterprise Voice has not been deployed).

When planning for dial-in conferencing, keep in mind that each dial-in user will consume a channel on a trunk connecting the PBX and/or Media Gateway to the PSTN. For organizations who size their number of PSTN trunks and Mediation servers to accommodate normal levels of inbound and outbound call volumes, this means they may not be able to support large numbers of dial-in users; however, for such meetings they could still use an audio conferencing provider (ACP) or the Web-hosted Live Meeting Service.

In Office Communications Server 2007 R2, it is not possible to link an ACP conferencing bridge to an Office Communications Server A/V Conferencing Server.

Communicator Web Access Server

As noted earlier, the 2007 R2 release of Communicator Web Access serves a role in dial-in conferencing that is unrelated to its primary role of hosting a browser-based client for Office Communications Server. Using the InternalURL and ExternalURL attributes of the MSFT_SIPGlobalCWAServerConfigSetting object, which are provisioned to the client during 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.