Office Communications Server 2007 R2 introduces a new Centralized Conference Control Protocol (C3P) command: getConferencingCapabilities. The client sends a SIP SERVICE request containing a getConferencingCapabilitiesrequest to the Focus Factory to discover capabilities of the hosting pool. The Focus Factory returns information that the client uses to form AddConferenceand ModifyConferencerequests. For dial-in conferencing to be offered to the person scheduling the meeting, the Pstn-bridging Enabledvalue must be set to True.

The client will use this information when it issues subsequent AddConferenceand ModifyConferenceSERVICE requests.

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 GetConferencingCapabilitiesrequest that gets proxied to a Focus Factory globally-routable User Agent URI (GRUU) in the pool where the user is homed.
   
   
2. The Focus Factory extracts meeting capability information from its database and returns the information to the client. This information includes all of the dial-in conferencing dial-in access numbers categorized by region. The user’s location profile region determines the access numbers for the conference.
   
   
3. The client sends a SIP SERVICE request containing an AddConferencerequest to the Focus Factory with an msci:pstn-accessattribute 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 GetConferencerequest 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 Nowbutton 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.

Authenticated Office Communicator and Live Meeting users (including federated users) who have a computer with audio capability can connect to the conference as they did in Office Communications Server 2007.

Assuming dial-in attendees call in from the PSTN on an ISDN-PRI trunk that is connected to the hosting organization’s PBX and a media gateway is employed in the solution, the call flow for joining the meeting is as follows:

1. The first Office Communicator or Live Meeting–based attendee joins the meeting, which activates the meeting and causes RTCSrv.exe to instantiate a meeting Focus on a Front End Server in the pool that is hosting the meeting. The Focus, in turn, requests the Conferencing Server Factory on that server to assign an A/V Conferencing Server to the meeting (and other Conferencing Servers).
   
   
2. A dial-in attendee dials the conference access number listed in his or her e-mail invitation, and the PSTN routes the call to the organization’s PBX.
   
   
3. The PBX uses the called-party number to route the call to the media gateway. The media gateway then transforms the call from ISDN-PRI to SIP/RTP and routes the call to an Office Communications Server Mediation Server. (The media gateway may not be required if the organization has an IP-PBX that can transform the call from ISDN-PRI to SIP/RTP and route the call directly to the Mediation Server.)
   
   
4. If the number passed to the Mediation Server is not in E.164 format, the configured 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.
   
   
   
8. The Conferencing Attendant Service passes the Conference ID back to the Front End Server in a SIP SERVICE request. The Front End Server looks up the conference ID from the database and responds back to the Conferencing Attendant Service with the conference URI of the Focus, the meeting ID, and the organizer’s SIP address.
   
   
9. The Conferencing Attendant requests and encryption key from the Focus. If the caller is an Enterprise User, the Conferencing Attendant encrypts the caller’s internal phone extension and PIN and sends it in a request to the Front End Server to validate the caller’s identity. If the caller is an anonymous user and a passcode is required, the Conferencing Attendant sends the passcode (encrypted) to the Front End Server for validation.
   
   
10. If an enterprise user has not yet entered the meeting and the caller is joining the meeting as an anonymous attendee, the Conferencing Attendant Service plays its on-hold music to the caller until an enterprise user joins the conference.
    
    
11. When user authentication is complete, the Conferencing Attendant adds the user to the Focus (which adds the user in the meeting rosters of on-line participants), and the Focus adds the user to the A/V Conferencing Server. The A/V Conferencing Server invites the Mediation Server and establishes an audio connection with it, and tells the Mediation Server to drop its connection with the Conferencing Attendant.
    
    
12. When the first dial-in user joins the meeting, the A/V Conferencing Server invites a Conferencing Announcement Service in its pool and a media connection is established between it and the A/V Conferencing Server. (This step is done only once for any particular meeting.) The Conferencing Announcement Service is trusted by the Focus and by the A/V Conferencing Server, so additional authentication is not required. The Conferencing Announcement Server joins the Focus and listens for state changes. It plays an entry tone for other dial-in participants to announce that a participant has just joined or left the meeting, and it plays a spoken announcement message for each dial-in participant when that participant’s line has been muted or unmuted.
    
    

The following diagram shows a simplified call flow on an anonymous user dialing into a meeting that requires a passcode. In this example, the Conferencing Attendant is in the same pool as the meeting Focus.

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.