Office Communications Server 2007 R2 adds a new msRTCSIP-ApplicationContactscontainer 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 Propertiestab of the Forest Propertiesdialog 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-PrimaryUserAddressattribute 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 PrimaryURIattribute of the corresponding Windows Management Instrumentation (WMI) Conference Announcement Serviceand CAAPrivateContactObjectinstances, which are located in the MSFT_SIPApplicationContactSettingtop-level class.

Dial-in Contact objects cannot be shared across pools; each must be bound to an Enterprise pool or one Standard Edition server.

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-LocationContactMappingclass, 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 Regionstab of the Conferencing Attendant Propertiesdialog 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.

Authorizing users to create dial-in conferences is managed through the global Meeting Policytab. This tab is not new, but in Office Communications Server 2007 R2 the schema is extended with two more settings, Enable PSTN conference dial-inand 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-PolicyContentattribute that contains flags for EnablePSTNConferencingand TrustedConferencingPinRequired.

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 Servicescontainer 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-TrustedServiceTypeattribute of either Microsoft.RTC.Applications.CAAor Microsoft.RTC.Applications.CAS.

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_SIPGlobalCWAServerConfigSettingfor the InternalURL, ExternalURL, PhoneConfURLSuffix, and WebJoinURLSuffixattributes. (In Active Directory Domain Services, these values are stored in the RTC Services, Global Settingscontainer 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.

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 Conferencingtab in the Front End Propertiesdialog box of the selected pool.

These settings can also be accessed through the MSFT_SIPPSTNConferencingSettingWMI object, in addition to the PINExpiration, PINLength, and PINRetriesproperty values.

Note:

The pool-level MSFT_SIPPSTNConferencingSettingWMI object also contains values for InternalURLand ExternalURLproperties. 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.

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.

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.

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.

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.

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.

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.

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 InternalURLand ExternalURLattributes of the MSFT_SIPGlobalCWAServerConfigSettingobject, 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 /dialinto 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.