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