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.
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.
To create an Anonymous-Allowed Live Meeting with Dial-In Conferencing support
- 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.
- 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.
- 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
- 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.
- 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.
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:
- 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
- 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
- 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
- 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
msRTCSIP Line URI.
- The Front End Server routes the call to the Conferencing
Attendant Service on the pool bound to the Conferencing Attendant
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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.