This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

Copyright © 2011 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Lync, Outlook, PowerPoint, and SQL Server are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.

This chapter is part of the Microsoft Lync Server 2010 Resource Kit book that is currently being developed. Chapters will be available for download while this book is being completed. To help us improve it, we need your feedback. You can contact us at [e-mail]. Please include the chapter name.

For information about the continuing release of Lync Server 2010 Resource Kit chapters, check the DrRez blog at http://go.microsoft.com/fwlink/?LinkId=204593.

Contributors

Project Manager: Susan S. Bradley

Content Architect: Rui Maximo

Chapter Lead: Seth Paul

Lead Writer: Seth Paul

Technical Reviewers: Hao Yan, Arish Alreja, Tarang Mittal, Mei Lu, Duy Tran, Ramesh Narayanan, Josh Marshak, Venkat Addanki

Lead Editor: Katrina Purcell

Art Manager: Jim Bradley

Cover Design: Jim Bradley

Production Editor: Kelly Fuller Blue

Table of Contents

Introduction

Microsoft® Lync™ Server 2010 provides a complete set of tools that you can use for conferencing and collaboration, including servers and services that support audio and video conferences, application sharing, web conferencing, and dial-in conferencing, in addition to clients for connecting to a conference. Following a brief introduction of how these tools work together, this chapter will describe the technical details of what happens behind the scenes when a user schedules and joins a conference.

Scenarios

Fundamentally, a conference consists of two separate actions:

• Scheduling a conference

• Joining a conference

The conference organizer uses Microsoft® Outlook® to schedule a conference, and then Outlook communicates with Microsoft Lync Server 2010 by using an Outlook add-in that is included as part of the Microsoft® Lync™ 2010 installation. Outlook uses the information supplied by the server to create a new invitation, which includes a conference URL for attendees who are joining the conference by using one of the supported Lync clients, and telephone numbers and a conference ID for attendees who are joining by phone.

When it's time to join the conference, an attendee clicks the link included in the Outlook meeting invitation, and then selects a client to use (unless they are joining by phone, in which case they would dial the included number). The link opens the Meeting Join webpage, which detects whether a Lync Server client is already installed on the user's computer. If a client is already installed, the default client opens and joins the conference. If a client is not installed, the Meeting Join webpage displays options for joining the meeting with alternate clients:

• If Microsoft Lync 2010 or Microsoft® Lync™ 2010 Attendant is installed, the client starts and joins the meeting.

• If neither Lync 2010 nor Lync 2010 Attendant is installed and Microsoft® Lync™ 2010 Attendee is installed, Lync 2010 Attendee starts and joins the meeting.

• If no Lync Server client is installed, the Meeting Join page opens and gives the user the following options:

• Use Microsoft® Lync™ Web App

• Download Lync 2010 Attendee (This link is hidden by default)

• Use Microsoft® Office Communicator 2007 R2 or Microsoft® Office Communicator 2007 (This link is hidden by default)

For details about the differences in using these clients, see “Planning for Clients” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?LinkId=205087.

A conference can support any combination of the following conference types (also called modalities):

• Audio

• Video

• Web conferencing

• Application sharing

• Dial-in conferencing

Administrators control the modalities that are enabled for a new conference by using the CsMeetingConfiguration cmdlet. By default, all modalities are enabled. This means, for example, that if a presenter shares a file while a conference is in progress (thus enabling web conferencing), the conference is already configured for web conferencing. There may be some instances where an administrator wants to disable certain modalities for specific users. For example, the company policy may be to disable application sharing for users that work with highly sensitive data.

If an attendee is an anonymous user, or they are dialing in to the meeting, they may be transferred to the lobby until a conference presenter allows them access. Administrators can also use the CsMeetingConfiguration cmdlet to configure this behavior. For example, you can configure meetings so that anyone dialing in over the public switched telephone network (PSTN) is automatically admitted to the meeting. Alternatively, you can configure meetings so that dial-in users are not automatically admitted the meeting, but are instead routed to the meeting lobby. These dial-in users remain on hold in the lobby until a presenter admits them to the meeting. For details, see “Configuring the Meeting Join Experience,” http://go.microsoft.com/fwlink/?LinkId=216794, and “Dial-In Conferencing Capabilities,” http://go.microsoft.com/fwlink/?LinkId=206593, in the Lync Server 2010 documentation.

The following sections provide more information about what happens when a conference is scheduled and joined.

Internals

Conferencing Architecture

In a Lync Server 2010 deployment, there are several conferencing components that work together to provide conferencing functionality. They include the Focus, Focus Factory, Web Conferencing service, A/V Conferencing Server, IM Conferencing service, and Application Sharing Conferencing service. Figure 7-1 shows the process boundaries for these conferencing components.

Note. The A/V Conferencing Server can also be collocated with the Front End Server.

Figure 7-1. Process boundaries for conferencing components

For a more in-depth description of these components, see the “Conferencing Services” section in Chapter 3: Technical Overview.

For more details about the basics of conferencing, including planning for conferencing, required components, and hardware and software requirements, see “Planning for Conferencing” in the Lync Server 2010 documentation at http://go.microsoft.com/fwlink/?linkid=205562. If you need detailed instructions about how to deploy the various components shown in Figure 7-1, see “Deployment” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?linkid=206142.

How the Components Work Together

Figure 7-2 provides an overview of how the various conferencing protocols interact with the Lync Server 2010 components shown in Figure 7-1.

Figure 7-2. Interaction of conferencing protocols

To help understand this diagram, let's go over the protocols that are used to move data between components. These protocols will be the basis for all call flow discussions later in this chapter.

Signaling Protocols: These are protocols that facilitate session establishment, state and capability exchange, and conference control.

Session Initiation Protocol (SIP): SIP is the primary signaling protocol used by Lync Server. It defines a standard way to perform session setup, termination, and media negotiation.

Centralized Conferencing Control Protocol (C3P): C3P is an XML-based protocol that provides a thin wrapper around the Conference Event package and media specific extensions. It is responsible for various conference control and state modification tasks. Between the clients and the Focus, C3P is carried through SIP inside SIP INFO or SIP SERVICE. The Focus also uses C3P to talk to the various conferencing services. HTTPS is used as the carrier protocol in these cases.

Media Protocols: These are protocols that facilitate the exchange of specific types of media between clients and conferencing services.

Persistent Shared Object Messaging (PSOM): PSOM is the web conferencing protocol used for exchanging data collaboration content and control.

Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE): SIMPLE is used for instant messaging (IM).

Real-time transport protocol (RTP)/Real-time transport control protocol (RTCP): RTP and RTCP allow an A/V Conferencing service to exchange audio and video streams with conferencing clients. RTP defines the standard for audio and video packaging. RTCP provides control information for the RTP flow. It conveys information about signal quality for an audio/video (A/V) conferencing session. The secure versions of these protocols are secure real-time transport protocol (SRTP) and secure real-time transport control protocol (SRTCP).

Remote Desktop Protocol (RDP): Application Sharing Conferencing service uses RDP wrapped in SRTP/RTP to transmit application-sharing data, such as the stream of bitmaps from the sharer's desktop to the other conference participants. If another participant takes control, RDP transfers the controller's keyboard and mouse inputs back to the sharer's desktop.

The Focus Factory, shown in figure 7-2, is responsible for creating conferences. When a user schedules a new conference, the Focus Factory creates a new instance of the conference in the conference database and returns information about the newly created conference to the client. The Focus uses the information stored by the Focus Factory in the conference database to act as the conference manager. It is responsible for managing the state of the conference, enforcing security, managing roles and privileges, and providing conference state updates to all the clients joined to the conference.

Conference information is stored in the SQL Server-based Back End Server, which is used to synchronize information between the Focus and Focus Factory.

Now that we have covered the basics, we can discuss how this all works. First, we will take a deeper look into how a conference is scheduled, and then we will talk about joining a conference.

Scheduling a Conference

The default settings for conferences have been adjusted to meet the most common collaboration demands. Most importantly, by default all modalities are enabled (including A/V, IM, web conferencing, and application sharing). Public switched telephone network (PSTN) dial-in conferencing is also enabled (selected by default in the default global conferencing policy), and all PSTN users are configured to automatically skip the lobby (PstnCallersBypassLobby on the CsMeetingConfiguration cmdlet is set to true).

Lync Server 2010 uses an Outlook add-in, Online Meeting Add-in for Microsoft Lync 2010, to schedule conferences. This add-in is installed as part of a basic Lync client installation. With this add-in, Outlook can use Lync APIs to communicate directly with the Focus Factory on the Front End Server, thus simplifying the process of scheduling and configuring new conferences. For details about configuring the add-in, see “Customizing the Online Meeting Add-in for Lync 2010” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?linkid=217196.

Note the following when using Outlook to schedule conferences:

• A new conference cannot be scheduled unless the Lync client is running and the user accounts for Outlook and Lync match.

• Online Meeting Add-in for Lync 2010 does not support Microsoft Office Live Meeting service. You can support existing Live Meeting service meetings and users with a side-by-side installation of the Conferencing Add-in for Microsoft® Office Communications Server 2007 R2 add-in and the Online Meeting Add-in for Lync 2010. For details about migrating conferencing to Lync Server 2010, see “Migration Considerations for Meetings” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?linkid=214617.

Before the user can schedule conferences, the add-in must provision Outlook. Server configuration and conference policies control how a conference can be configured. The add-in needs information about these capabilities so that it can expose the appropriate functionality available for use in Outlook.

To set the capabilities of the client, the add-in creates a one-time subscription with the Focus Factory over SIP by using a C3P getConferencingCapabilities command. The Focus Factory then translates the generic server configuration settings to a specific set of rules for the client, and returns the rules along with the user-specific conference policy (including settings such as whether the user is allowed to schedule a conference with external anonymous users or whether PSTN dial-in conferencing is enabled) to the add-in. Based on these capabilities, the add-in enables or disables user interface features in Outlook.

After the client has been provisioned, the user can begin to schedule conferences. Figure 7-3 is a truncated version of figure 7-2, and shows the process for scheduling a conference.

Figure 7-3. Conference scheduling process

Note. The SERVICE method is the only SIP-method that the Focus Factory understands. All C3P commands are carried in the body of the SERVICE request.

The flow for scheduling a conference can be broken up into three distinct steps.

1. The Online Meeting Add-in for Lync 2010 uses the
   Lync APIs and the Domain Name System (DNS) lookup or the manually configured server address to connect Outlook, through the Lync client, to the Focus Factory. The add-in then bundles the following information, required by the Focus Factory to create a conference, into a SIP SERVICE request:

• The conference ID

• A participant list

• User role information

• An expiration date

2. The Focus Factory writes the following conferencing information to the conferencing database located in the Back End Server:

• Conference ID

• PSTN Meeting ID

• Expiration date and time of conference

• List of conference participant roles and the privileges associated with those roles

• Conference key for participants without an identity in Active Directory® Domain Services (AD DS)

• Supported media types

• Authorization types (including locked, invited attendee, my company, and everyone)

The conferencing data is contained within two databases: RTC and RTCDyn. The information listed previously is stored in real-time communications (RTC). The RTCDyn database contains the run-time conference state. This data is transient and will be removed as soon as the conference is over.

Warning. You should not modify the data located in these databases.

The Focus will access the information located in RTC when the first client attempts to join the conference.

Note. The conferencing database does not maintain calendar information (such as conference start and end times and recurrence). Instead, conference calendar information is maintained by the scheduling client or in Microsoft Exchange Server. Because the Focus Factory does not collect this information, it treats scheduled and ad-hoc conferences in the same way.

3. The Focus Factory sends a 200 OK response that includes conference information such as the meeting URL and dial-in conferencing numbers to the Outlook add-in. This information can then be included in the meeting invitation.

In Lync Server 2010, meeting URLs are discoverable, easy to remember, and easy to communicate. Every URL, for both public and private conferences, contains the following structure:

• A base URL that is specific to each domain. The default base URL is http://meet.<sip domain>, but you can customize this to fit the requirements of your organization.

• A suffix that is the user portion of the organizer's SIP Uniform Resource Identifier (URI).

• A randomly generated string of alphanumeric characters.

For example, each of the following URLs is valid:

• http://meet.contoso.com/user/Z4A57TQ

• http://contoso.meet.building1.com/user/Z4A57TQ

For details about using the simplified meeting URLs, see “Planning for Simple URLs” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?linkid=215452.

The flow for scheduling a conference can be summarized by the call flow shown in figure 7-4.

Figure 7-4. Schedule call flow

Joining a Conference

After a conference (also called a meeting) has been scheduled, participants can join using one of four options:

Microsoft Lync 2010: The default client for Lync Server 2010 conferences.

Microsoft Lync 2010 Attendee: A conferencing client that allows users who have not installed Lync 2010 to fully participate in conferences.

Microsoft Lync Web App: A web-based application that supports all Lync 2010 collaboration and sharing features except for IP audio and IP video. Users can dial-out from the conference for PSTN-based audio.

Dial-In conferencing: A feature that enables users to use a PSTN phone to join the audio portion of a conference. Dial-in conferencing is described in greater detail later in this chapter.

For details about the differences between the various clients, see “Client Comparison Tables” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?linkid=205086.

A conference begins when the first participant using any of these client options joins the conference. A participant can join a conference when the conference is not locked and when the participant can be authenticated, which is based on the participant's Active Directory identity or a supplied meeting key. The following set of steps occurs when an attendee either clicks the meeting URL included in the invitation or manually enters the meeting URL into a web browser.

1. The web browser opens the Meeting Join page, which, if installed, opens Lync 2010 or Lync 2010 Attendee. If neither client is available, the attendee will join the user by using the Microsoft Lync Web App. For details about the Meeting Join page, see “Configure the Meeting Join Page” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?linkid=214478.

The Meeting Join Launcher application converts the conference URL that is included in the invitation to the conference URI, which the client needs to join the conference. The Meeting Join Launcher application extracts three pieces of information from the meeting URL to construct the conference URI:

• The base meeting URL (for example, meet.contoso.com)

• The user portion of the organizer's SIP URI

• The randomly generated string of alpha-numeric characters that is the conference ID

Lync Server maintains a mapping of meeting URLs to SIP domains, which it uses to convert the base meeting URL extracted from the meeting URL to the SIP domain required by the conferencing service.

For example, using the sample meeting URL described earlier in the Scheduling section (http://meet.contoso.com/user/Z4A57TQ), the domain is identified by using http://meet.contoso.com, the conference organizer is “user”, and the conference ID is Z4A57TQ. The converted conference URI for this example would then be:

sip:user@ <domain>;gruu;opaque=app:conf:focus:id:Z4A57TQ

4. The browser opens the selected Lync Server client, and then passes it the meeting URL and any other information required to join the meeting. The client then closes the browser.

5. The client uses the procedures described later in this section to join the meeting.

A conference ends when one of the following cases is true:

• All participants have left

• The presenter has terminated the conference

• If only unauthenticated users are left in the conference, ten minutes after the last authenticated user has left the conference

• 24 hours have passed with no conferencing activity

When a conference ends, the conference is deactivated. This means that any remaining participants are ejected, real-time media stops streaming, and the conference state and conference content are purged from the database. If a conference is a recurring meeting, the conference can be reactivated after the previous instance has been deactivated, if it has not already expired. Any content that was uploaded previously is available when the recurrent meeting starts again.

A conference has four possible access levels:

Locked: The conference is closed to include only those people already participating in the conference. Except for the organizer, no new members are allowed to join.

Invited Attendees: Only invited attendees are automatically allowed into the conference. Anyone else that wishes to attend the conference must wait in the lobby until they are admitted. This access level applies only to private conferences. If the meeting level is set to public, Invited Attendees is disabled.

My Company: Only attendees originating from the same AD DS are automatically allowed into the conference.

Everyone: The door is open to all attendees both inside and outside of the company. No one is sent to the lobby.

Users who are not authorized to join a conference are placed in the lobby. A presenter can then decide to allow users into the conference on a case-by-case basis. The lobby provides a mechanism for the presenter to make changes to the conference, thus correcting any errors or omissions from when the conference was originally scheduled. Client authorization is based on conference access settings and the attendee's authentication type. Dialed-out users or those added through an invitation are not placed in lobby, but instead are allowed to directly connect to the conference.

This model is summarized in the following table.

Table 1-1. Conference access levels

Access Level	Client Join Company		Client Join Federated	Client Join Anonymous	PSTN Join Anonymous	PSTN Join Company (authenticated)
	Invited	Not Invited				Invited	Not Invited
Everyone	In	In	In	In	In, after one company user joined	In	In
Company (default)	In	In	Lobby	Lobby	In, unless bypass is off	In	In
Invited only	In	Lobby	Lobby	Lobby	In, unless bypass is off	In	In, unless bypass is off
Locked	Lobby, unless organizer	Lobby	Lobby	Lobby	Lobby	Lobby unless organizer	Lobby

Even after a conference has started, the presenter can change the access level (the default is Invited) or select or clear the Always allow PSTN Users to Skip the Lobby option.

Figure 7-5, a truncated version of figure 7-2, shows the process of a Lync Server 2010 client attempting to join a conference. For a description of how a user can dial into a conference, see the “Dial-in Conferencing” section in this chapter.

Figure 7-5. Conference joining process

The process shown in figure 7-5 can be divided into six steps.

1. When a user attempts to join the conference, the Lync Server 2010 client sends a SIP INVITE request to the Focus. The INVITE has two purposes. First, it indicates that the client wants to join the conference. Second, it carries conference control operations, contained in an INFO request, to the Focus.

Note. The Focus understands the following SIP messages: INVITE, ACK, BYE, UPDATE, CANCEL, INFO, and SUBSCRIBE. The INVITE, ACK, BYE, UPDATE, CANCEL group establishes a signaling dialog with the Focus referred to as the “Conference Join Dialog.” SUBSCRIBE is used to establish a subscription dialog with the Focus, and is discussed in Step 6.

The INVITE dialog uses a C3P addUser request containing the conference URI and the user URI to request access to the conference:

<addUser request>

The conference URI must match the SIP To: URI, and the user URI must match the SIP From: URI.

If the Focus returns the following diagnostic code, then the user is attempting to join an unknown conference:

Ms-diagnostic: 3032;reason=” Conference does not exist”

The most common reason for this is that a user is using a conference link from an outdated meeting request, or copying and pasting an incomplete link from a current meeting request.

6. After accepting the INVITE, the Focus queries the Back End Server for the conference record. It uses this information to determine the modalities that will be used in the conference and to authenticate the client and determine if it meets the security policy criteria defined when the conference was scheduled.

If accepted, the Focus responds to the client with the granted role in a 200 response.

If, according to the policies described previously, the user is placed in the lobby, the following happens:

1. The Focus will send a notification to all watchers of the conference that there is an attendee waiting for admittance in the lobby.

2. The client waiting in the lobby then sends SUBSCRIBE to the conferencing package. Because the attendee is waiting in the lobby, the client receives the bare minimum conference details and information stating he is waiting in the lobby. A subscription failure with the following diagnostic code means that the user was unable to join the conference because the conference subscription received a failure response:

Ms-diagnostic: 52119;reason=”Conference join failed because a subscription channel could not be established”

In this case, you should check the diagnostic headers in client side logs to determine why the SIP SUBSCRIBE was rejected.

3. Participants in the conference who are designated as Presenters will receive a notification that attendees are waiting in the lobby. They can then either allow or deny access by sending a C3P setLobbyAccess command to the Focus.

4. If the presenter allows access, the attendee's status is changed from pending to allowed, and he is sent the full conference notification along with all of the conference details.

5. If the presenter denies access, the attendee's status is sent a BYE on the join INVITE dialog and NOTIFY (exp:0) on the SUBSCRIBE dialog with language explaining the reason for denial. The BYE message terminates the INVITE dialog, while the NOTIFY message causes the immediate expiration of the SUBCSRIPTION dialog.

6. If the attendee is neither admitted nor denied access to the conference, they continue to wait in the lobby until the conference ends (unless they leave first).

7. The Focus will try to allocate the available servers running the conferencing services for each type of conferencing required in the conference, and then return to the client the address of all the servers assigned to the conference by using SIP NOTIFY.

The client is expected to initiate dialogs with each conferencing service to start participating in individual modalities. The client embeds a C3P addUser request in a SIP INFO, and sends the request to each conferencing service (through the Focus) to request permission to create a connection with it. The conferencing service responds with connection information that the client can use to establish signaling and media sessions.

8. The Focus communicates with the conferencing service to issue commands that begin or end the conference, change the participant list, or otherwise change the conference state.

9. The client establishes a direct connection with the conferencing service. If the service is an A/V Conferencing Server, the signaling protocol is SIP and the media is transported over RTP/RTCP. If the service is the Web Conferencing service, both signaling and media are sent using the PSOM protocol. If the service is the Application Sharing Conferencing service, the signaling protocol is SIP and the media is transported over RDP encapsulated within RTP. Lync Server also supports sharing RDP wrapped in RTP PSOM side-by-side for a scenario where features such as desktop sharing (RDP), whiteboard, and polling are used simultaneously.

For a more detailed description of what happens when the client contacts each specific modality, see the “Web Conferencing and Application Sharing”, “Audio and Video Conferencing”, and “Dial-In Conferencing” sections later in this chapter.

10. If the client meets the criteria of the access type defined for the conference, the attendee is admitted to the conference. After the client joins the conference, it establishes a subscription dialog with the Focus to receive conference roster notifications.

The Focus then processes the subscription. If no corresponding active signaling dialog is found, the Focus fails the subscribe. After the subscribe is accepted, the Focus responds, and then generates a notification.

The subscription dialog is periodically refreshed following standard RFC 3265 procedures. The subscription dialog is terminated upon termination of the signaling dialog.

The detailed process of joining a conferencing is summarized in the call flow shown in figure 7-6.

Figure 7-6. Joining conference call flow

Audio and Video Conferencing

The A/V Conferencing Server provides audio and video conferencing support for conferencing by using either the Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP) or the encrypted Secure Real-time Transport Protocol (SRTP) and Secure Real-time Transport Control Protocol (SRTCP). You can set the required level of encryption by using the EncryptionLevel parameter of the Set-CsMediaConfiguration cmdlet. For details, see “Set-CsMediaConfiguration” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?linkid=215504.

There are three conferencing policies that affect the client's experience when connecting to a conference:

AllowIPAudio: If this is set to true, the A/V Conferencing Server will allow audio in the conference and the client will be able to connect to the A/V Conferencing Server and initiate an audio conference.

AllowIPVideo: If this is set to true, the A/V Conferencing Server will allow video in the conference and the client will be able to connect to the A/V Conferencing Server and initiate a video conference.

MaxVideoConferenceResolution: Defines the maximum allowed resolution for video conferencing. This can be set to either Common Intermediate Format (CIF) or VGA. The default is VGA.

An administrator can modify these policies by using the Set-CsConferencingPolicy cmdlet.

In previous sections we discussed how a conference is scheduled and joined. Now let's look at what happens when the client initiates a connection to the A/V Conferencing Server.

For the purposes of this section, let's assume that the conference is scheduled, joined, and the Focus has used the C3P getConferencingCapabilities command to provide the client with the relevant information for the conference.

Note. The conference must already exist before the client can send an invitation to the A/V Conferencing Server.

At a high level, the client initiates the communication with the A/V Conferencing Server by inviting the A/V Conferencing Server to enter into a media session. The invitation includes a Session Description Protocol (SDP) offer that describes the capabilities of the client. The A/V Conferencing Server sends back a response containing its capabilities. Next, the client and the A/V Conferencing Server negotiate Interactive Connectivity Establishment (ICE) checks, and use the matching capabilities included in the SDP offers to initiate a media connection.

This process is shown in figure 7-7.

Figure 7-7. A client initiates a connection to the A/V Conferencing Server.

Now let's take a closer look at the steps shown in figure 7-7.

1. The client uses the information it receives from the Focus during the join process to initiate contact with the A/V Conferencing Server. To do this, the client first embeds a C3P adduser request in a SIP INFO, and then sends the request to the Focus. The request includes a parameter that specifies whether the invitation to join the conference is dial-out or dial-in. In a dial-in request, the A/V Conferencing Server receives the request. In a dial-out request, the A/V Conferencing Server sends out the request.

11. The Focus takes the XML C3P adduser request out of the SIP request, wraps it in HTTPS, and forwards it to the A/V Conferencing Server. The A/V Conferencing Server sends a C3P adduser response back to the client—routed through the Focus—that tells the client to join the conference.

The A/V Conferencing Server has now created a logical representation of the client and is waiting for the client to send a media offer.

12. The next step is to set up the media connection. After receiving the success message, the client embeds the SDP offer in a SIP INVITE to the focus, which then forwards this information on to the A/V Conferencing Server.

The SDP Offer contains information (called an m-line) about client support for each modality supported by the A/V Conferencing Server, including audio, video, and panoramic. Each m-line contains some combination of the following:

Transport candidates: Describes the ports available to the client. This information will be used for ICE Connectivity checks.

Codecs: Describes the codecs that the client will support. The A/V Conferencing Server will respond with the codecs that it supports.

Resolution (video only): Describes the video resolution that the client supports. For details, see the “Video” section in this chapter.

Cryptokeys: This is used for encrypted media.

Each piece of information contained in the m-line is ordered. For example, of the available transport candidates, a local-to-local connection is preferred. If both the A/V Conferencing Server and client support a local IP address, or an Edge Server IP address, the local IP address is preferred.

Similarly, codecs and resolutions are listed in order of preference. The highest order codec or resolution that matches from each list will be used in the session.

After receiving the INVITE, the A/V Conferencing Server compares the client's SDP offer with its own capabilities (based on the conference policies). If there is a difference, the A/V Conferencing Server ignores any capabilities that it does not support. For example, if the A/V Conferencing Server does not support video, the Video and Panoramic lines of the client SDP offer are ignored.

The A/V Conferencing Server then responds with a 200 OK containing its SDP answer. The SDP answer contains the same type of information that the client offer contained, except that it describes what the A/V Conferencing Server supports. In other words, the SDP offer and SDP answer provide a way for the client and A/V Conferencing Server to compare media capabilities.

13. After exchanging capabilities, the A/V Conferencing Server and the client negotiate ICE connectivity checks. The client will first specify a set of IP and TCP and UDP port combinations that can send and receive media. The A/V Conferencing Server responds with its list of TCP and UDP combinations.

From these two lists, the client and the A/V Conferencing Server will start to ping each possible match.

Consider the example where there are four possible candidates for the client and the server. This means that there will be a total of 16 checks (4 x 4). This is called the ICE connectivity checks. At a basic level, the client and the A/V Conferencing Server will ping each other until they figure out which routes work best for sending media. They will then order the routes based on an algorithm that, for example, prefers local candidates over remote relay candidates.

Now, the media is set up, the relevant audio, video, or panorama media begins to stream, and the A/V Conferencing Server sends a roster notification to inform the other attendees that a new user has joined the conference. The client is fully engaged in the conference.

During an A/V conference, if the media session ends due to a timeout, the following diagnostic code is returned:

Ms-diagnostic: 7027;reason=”The media connection with the client was lost”

The most likely cause is the client either stopped responding or lost network connectivity before it could properly close the SIP session.

The process of joining a client to the A/V Conferencing Server is summarized in the call flow shown in figure 7-8.

Figure 7-8. A/V conferencing call flow

In the next section we will discuss concepts specific to video conferencing, including codecs and resolution.

Video Conferencing

As we discussed earlier, the client SDP offer contains information describing the video capabilities that the client supports. There are two factors that determine the video that the client can receive:

The user policy: The user policy dictates what level of video that the client can receive. For example, if the user policy specifies CIF only, than the offer will only contain the CIF capability. The client can support up to the following three resolutions:

• CIF (352 x 288)

• VGA (640 x 480)

• HD720p (1280 x 720)

Note. Conferencing does not support high definition (HD) video. HD video can only be used for peer-to-peer calls between users running Lync 2010 on high-end computers.

Hardware of the client computer: For example, if the client is located on a computer that is using a single core processer, only the CIF resolution is supported.

For details about supported video resolutions, see “Media Traffic Network Usage” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?linkid=215512.

The SDP offer describes the supported resolutions by using the following format:

A=x-capabilities;[capability 1];[capability 2];[capability 3];

Where capability is represented by the form:

[resolution];[number of concurrent video streams];[frame rate]

For example, a client SDP could take the following form:

a=x-capabilities;352x288;1;15;640x480;1;25;1280x720;1;30

In this example, 352x288;1;15 represents a capability for CIF video. The resolution is 352 x 288, the number of concurrent streams allowed is 1, and the frame rate is 15 frames per second (fps). Similarly, 640x480;1;25 represents a capability for VGA video and 1280x720;1;30 represents a capability for HD video.

Note. Lync Server 2010 does not support multiple video streams, so only one capability can be used at a time.

As part of the SIP answer, the A/V Conferencing Server responds with its own capabilities for video.

The A/V Conferencing Server response partly depends on the conference organizer's policy. If video is not enabled for the conference (the server determines this by reading the EnableP2PVideo parameter on the conference policy), the A/V Conferencing Server will respond only to the offer with audio. If video is enabled, the conference policy can further control the resolution of the video supported for the conference by using the MaxVideoConferenceResolution parameter. In Lync Server 2010, this can be set to either CIF or VGA. The default value is VGA.

Based on the conference policies settings, the A/V Conferencing Server will respond to the client in the preceding example with the following capabilities line:

a=x-capabilities;352x288;1;15;640x480;1;25

Notice that this only contains CIF or VGA capabilities. The maximum resolution that is common to both the client and the A/V Conferencing Server will be used in the specific session.

Note. The agreed upon resolution does not necessarily guarantee the resolution of the conference. If the conference is set to VGA, but a percentage of the participants in the conference can receive only CIF, then the conference resolution will be set to CIF.

The focus of the video is driven by the active speaker. The A/V Conferencing Server uses the strength of the audio signal coming from each client to decide which video signal it should stream to the conference. Panoramic video works in the same way. If there is more than one round table being used in a conference, the conference will show active video.

A video conferencing session typically involves the transmission of both audio and video streams. To conserve network bandwidth while maintaining the highest possible quality and data fidelity, information is first coded and compressed before it is put onto the wire for transmission. At the receiving end, decompression takes place to reconstruct (or decode) the information before it can be played back in a meaningful fashion. This function is the task of a codec, a common abbreviation for compression and decompression, and can be performed completely in software or as part of the function of an A/V conferencing device. For a complete list of the codecs used by Lync Server 2010, see “Media Traffic Network Usage” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?linkid=215512.

An administrator can throttle the audio and video bit rates by using the AudioBitRateKB and VideoBitRateKB parameters on the Set-CsConferencingPolicy cmdlet. At the time of creation, a conferencing policy will take on the maximum settable values of 200 and 2000 kilobytes respectively for audio and video sent from the client to the conferencing service.

Dial-in Conferencing

Dial-in conferencing enables users who want or need to use a PSTN phone to join the audio portion of an on-premises conference. This means that users who do not have access to a computer or smartphone can still participate in a conference.

For details about planning for dial-in conferencing, see “Dial-In Conferencing in Lync Server 2010” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?linkid=215514. For details about managing dial-in conferencing, see “Managing On-Premises Meetings” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?linkid=215515.

In order to use dial-in conferencing, the following conferencing policy needs to be set to true:

EnableDialInConferencing: Indicates whether users are able to join the conference by dialing in with a PSTN telephone. The default value is True.

This setting applies to the user who organizes the conference. If it is set to False, no conference created by a user affected by this policy will allow dial-in conferencing. However, the user can take part in other conferences where dial-in conferencing is allowed.

An administrator can modify this policy by using the Set-CsConferencingPolicy cmdlet.

As with the previous discussion of audio and video conferencing, Lync Server 2010 uses the A/V Conferencing Server to provide support for dial-in conferencing. In the next section we will take a detailed look at how dial-in conferencing works in Lync Server 2010.

When a user schedules a conference that includes dial-in conferencing, the Online Meeting Add-in for Lync 2010 verifies that dial-in conferencing is configured on Lync Server and that the user has permission to schedule a conference with dial-in conferencing enabled. It also checks to see what the default settings for the conference are, including whether PSTN callers should bypass the lobby, and whether entry and exit announcements should be turned on.

After the add-in has completed these checks, the Focus returns a list of access numbers to the add-in, which then automatically adds them to the meeting invitation. The access numbers are generated by using the dial-in region specified by the user's dial plan.

Access numbers can be scoped globally or to a specific site. For details on using access numbers, see Configure Dial-in Conferencing Access Numbers. An access number has one primary language with which it initially answers the phone call, and a list of up to five secondary languages from which the caller can choose.

Note. If the user who scheduled the conference decides to make a change to the conference by using Outlook, the add-in immediately communicates with the server to implement the change; it does not wait for the invitation to be sent again.

Figure 7-9 shows the process of joining a conference by using dial-in conferencing.

Figure 7-9. Dial-in conferencing process

This diagram assumes that the conference has already been scheduled. Now, let's take a closer look at the steps.

1. A user places a call to one of the Lync 2010 Attendant numbers listed in the Outlook meeting invitation. The call is routed through the Mediation Server to a Lync Server Director or Front End pool, which then routes the call to the pool where the Attendant located. After connecting, the user is asked to enter a numeric conference ID that identifies the conference.

The Attendant first uses this conference ID to verify that it is not already an active conference passcode by verifying a null conference passcode with the Focus. This is important because even though you cannot schedule conferences with passcodes by using the add-in, it is possible for the conference ID to map to an Office Communications Server 2007 R2 meeting with an active passcode.

14. The Attendant passes the conference ID to the Focus, which returns the correct conference. If the conference is hosted on another pool, the call is transferred to the correct Attendant.

The Attendant then attempts to join the conference by issuing a C3P AddUser command to the Focus.

Because the Attendant is a trusted server entity, it is able to join any conference. As part of this dialog, the Attendant receives the Attendant pool Globally Routable User Agent URI (GRUU) that corresponds to the Attendant instance in the pool where the conference is homed. If the GRUU does not match the GRUU of the Attendant, then the conference is being hosted in another pool. In this case, the Attendant blindly transfers the call to the correct GRUU, which corresponds to the correct Attendant that is serving the pool where the conference is homed. As a result, the remote pool's Attendant will serve the remainder of the interactive voice response (IVR).

The process of transferring between Attendants is called interpool transfer. In Lync Server 2010, the Attendant can recognize incoming blind transfers that correspond to interpool transfers and resume from the appropriate stage in the IVR. This functionality enables coexistence and interoperation by ensuring that the version of Attendant serving the call is the Attendant serving the pool where the conference is homed.

Note. The Attendant will not transfer the call to an older version of Attendant.

15. After joining the conference, the Attendant SUBSCRIBEs to roster updates to obtain information about the current state of the conference. This is important if, for example, the conference was scheduled as an anonymous conference, but was later locked.

The Attendant then determines whether to prompt the user for identification. If authorization is required, the caller is asked to provide credentials. If the caller does not provide the correct credentials, they are routed to the lobby. Because prompting for identification can be confusing to users, unless the conference is Invite Only or Locked, or the server policies don't allow anonymous join, the Attendant will attempt to join the user to the conference anonymously without asking for identification.

As part of this step, the Attendant asks the user if they are the leader, and if yes directs the user to press `*'. The user is then asked to enter a personal identification number (PIN), or if they are not the organizer, but instead another leader, they are asked to press `*' again and enter a phone number, extension, and PIN.

All dialogs that are responsible for PIN communication between the Attendant and the Focus use the User Pin Service (UserPinSvc). UserPinSvc is responsible for managing PINs, including locking them when there are too many failed attempts or expiring them when server policies dictate that PINs have an expiry (by default they do not). The PIN that is used to authenticate the user is also the same PIN that the user uses to unlock their desk phone.

Note. This is not the same PIN that is used for Microsoft Exchange scenarios such as voice mail.

You can use several different policies to control PINs, including control of their complexity, expiration, and history. An administrator can reset a user's PIN using the PIN Policy page in the Lync Server Control Panel. For details about changing a PIN, see “Modify the Default Dial-in Conferencing PIN Settings” in the Lync Server 2010 documentation, http://go.microsoft.com/fwlink/?linkid=217200. PINs can be one of the following states:

• PIN is locked because there have been too many consecutive failed attempts on the PIN

• PIN is expired because the PIN was last reset too far in the past (as defined by policy)

• PIN is not set because the user has never set their PIN, and the administrator has never set it for them

• (Normal — none of the above)

The Attendant can only use a PIN that is in the normal state to authenticate users.

After the Attendant has verified the user to be authenticated, the user is identified by entity=sip:<user>@<domain>.com in communication with other components. Because the Attendant is a trusted entity, the user does not need to be authenticated by any other component.

If the user cannot be authenticated, and there is not a SIP authenticated user in the conference, then the Attendant does not attempt to join the user to the Focus, but instead informs the user that leader is not present and places them on hold with music. As soon as any authenticated user arrives in the conference, the Attendant will continue with the join process.

16. The Attendant joins the conference, transfers the user to the conference, and then indicates that entry and exit announcements are required.

The Attendant joins the conference, and then attempts to join the user to the Focus by issuing another C3P AddUser command on behalf of the user (by specifying entity=sip:<user>@<domain>.com). The Focus will return an AddUser status of one of the following:

Connected: The user is accepted into the conference.

Deleted: The user is not allowed into the conference.

onHold: The user is placed in the lobby.

If the status is onHold, the Attendant informs the user that they need to wait for a leader to admit them, and starts streaming music. Because the Attendant is subscribed to the conference, it receives a BENOTIFY when the user is admitted or rejected from the lobby, and takes the appropriate action. If no event is received within 15 minutes, the Attendant will inform the user the timeout expired and then disconnect.

The Focus uses three pieces of information to decide the status of the client:

• The current permission level of the conference, with possible settings of either Everyone, Company, Invite only, or Locked / Organizer only.

• Whether the conference was scheduled by using the Conferencing Add-in for Outlook or the Online Meeting Add-in for Lync 2010.

• Whether PSTN lobby bypass is on.

The Attendant includes a flag in the C3P AddUser command that indicates whether the user has dialed in from the PSTN. The Attendant knows that the user is a PSTN caller if it detects the isGateway flag during its dialog with the Mediation Server. If the PSTN lobby bypass is enabled for this conference, the Focus will change any results of Admit to the lobby to Admit to the conference for PSTN callers only.

As such, if non-federated external callers place a call by using Lync or another Lync Server client such as Microsoft® Lync™ 2010 Phone Edition, they will be considered a PSTN caller if the audio comes through the gateway and not over Voice over Internet Protocol (VOIP). If this is the case, the user will be admitted to the audio part of the conference, but will not be able to see any shared data or other modalities. PSTN lobby bypass callers have access only to the audio modality.

As part of the CP3 AddUser command, Attendant will always specify the participant property entryExitAnnouncements=true, which we'll see later will result in the user receiving certain in-conference support. The result from the AddUser command also indicates whether the user entered the conference as a leader or an attendee.

17. The A/V Conferencing Server invites the Conferencing Announcement Service application and the Group Virtual Assistant application into the conference. The Conferencing Announcement service monitors the roster to make sure that the correct Group Virtual Assistants and Personal Virtual Assistants are provisioned. The Group Virtual Assistant provides the entry and exit announcements.

The administrator can use the entryExitAnnouncements property on the Set-CsDialInConferencingConfiguration cmdlet to turn the announcements off, or use the EntryExitAnnoucementsType property to configure the style of announcement that is played (either a tone or the name of the person entering or exiting the conference). A user can turn announcements on or off in the conference, but they cannot change the style of announcement.

18. The Conferencing Announcement service invites the Personal Virtual Assistant into the conference.

After the user's state in the roster maintained by the Focus is connected, the Attendant attempts to join the call to an A/V Conferencing Server for audio. Because the Focus already provisioned an A/V Conferencing Server for the conference, it can use the conference information populated by the Focus to find the correct A/V Conferencing Server. Attendant sends another C3P AddUser request on behalf of the user, this time directed to the A/V Conferencing Server. This invitation has a refer-to-URI with REPLACEs.

This causes the A/V Conferencing Server to send an INVITE with referred-by to the Mediation Server. This invitation replaces the audio leg between the Mediation Server and Attendant, effectively joining the user to the conference. When this dialog is complete, the user can hear conference audio and participate in the conference.

The dial-in conferencing process is summarized in the call flow shown in figure 7-10.

Figure 7-10. Dial-in conferencing call flow

Web Conferencing and Application Sharing

Lync Server 2010 supports a rich mix of data collaboration possibilities. Users can share and collaborate on documents, such as Microsoft® PowerPoint® presentations, by using the Web Conferencing service. Additionally, users can take advantage of the Application Sharing Conferencing service to share all or part of their desktop with each other in real time, making it seem as though the attendees are gathered around the same table in the conference.

The next two sections discuss technical details associated with the Web Conferencing and Application Sharing Conferencing services.

Web Conferencing

The Web Conferencing service manages conference data collaboration, including native support for PowerPoint presentations, document sharing, whiteboard, polling, compliance logging, annotations, and handouts. While scheduling and joining a conference remain the same as with other modalities, the client communicates with the Web Conferencing service by using the Persistent Shared Object Model (PSOM) protocol. PSOM is a custom protocol that is used for transporting web conferencing content.

You can use web conferencing to:

• Share a PowerPoint presentation. You can also make the presentation available for download.

• Share any file, such as a document or media file, as a handout. The administrator can choose to disallow specific extensions.

• Use the integrated whiteboard and annotation functionality. You can also upload images as annotations, cut and paste, and annotate PowerPoint presentations.

• Set up polls.

There are three conferencing policies that affect the client's experience when connecting to a web conference:

EnableDataCollaboration: When this is set to true, a user can schedule a new conference that includes web conferencing. If this is set to false, the user cannot schedule a conference with web conferencing. They can, however, take part in another conference where web conferencing is enabled.

AllowAnnotations: Indicates whether or not participants are allowed to make on-screen annotations on any content shared during the conference. This also determines whether whiteboard functionality is allowed in the conference. The default value is True. This setting applies to the user who organizes the conference: if set to False, no conference created by a user affected by this policy will include annotations. However, the user can participate in other conferences where annotations are allowed.

AllowExternalUsersToSaveContent: Indicates whether external users (that is, users not currently logged on to your network) are allowed to save handouts, slides, and other conference content. The default value is True. This setting applies to the user who organizes the conference: if set to False, no conference created by a user affected by this policy will allow external users to save content. However, the user can take part in other conferences where external users are allowed to save content.

An administrator can modify these policies by using the Set-CsConferencingPolicy cmdlet.

Figure 7-11 illustrates the basic movement of data between the conferencing components.

Figure 7-11. Web conferencing process

The following steps provide a detailed look at the web conferencing process.

1. A user uploads content to the Web Conferencing service over PSOM by using a Lync client. Typically this file is combined with an XML file manifest (named manifest.xml) and is uploaded as a ZIP file. The XML file manifest describes the content, including whether it is meant to be a handout or content for a PowerPoint presentation.

19. The Web Conferencing service uses shared folders on a file system to store conference state and conference contents. After unzipping the file, the Web Conferencing service reads the manifest, and then stores the associated content in two places: the metadata file share and the content file share.

Metadata file share: The metadata folder stores the conference metadata (for example, the number of slides, the slide names, and the slide types) that the Web Conferencing service shares with the clients. Under the metadata folder root, the Web Conferencing service creates the following structure of subfolders:

• For each conference organizer, the Web Conferencing service creates a separate folder below the metadata folder root. The organizer folder name is a hash value computed by using the organizer URI.

• For each conference, the Web Conferencing service creates a separate folder below the organizer subfolder. The conference folder name is the same as the conference ID.

• Metadata files for a conference are stored in the conference folder.

Figure 7-12 shows the structure of the metadata file share.

Figure 7-12. Metadata file share

The Web Conferencing service creates these folders and subfolders when it receives a C3P addConference request from the Focus. If a folder for an organizer does not exist, the Web Conferencing service creates a new organizer folder. If a folder for an organizer already exists, the Web Conferencing service creates the conference subfolder below the existing organizer folder. If a folder for a conference does not exist, the Web Conferencing service creates a new conference folder. If a conference folder already exists, the Web Conferencing service saves the metadata files in the existing conference folder.

When the Web Conferencing service needs to create a metadata folder for a conference, it extracts the organizer URI from the addConference XML. The URI is passed as input for a hash function. The result of this call is used to search through the subfolders of the metadata root folder to determine whether there is already an existing organizer subfolder. If no organizer subfolder exists, the Web Conferencing service creates a new one.

The conference folder contains all the information that is used by Web Conferencing service to recreate the content of a conference.

Content file share: The content folder stores the content that is shared between the Web Conferencing service and clients using the Web Components Server. The content folder contains the following:

• A separate subfolder for each organizer; the folder name is a hash based on the organizer URI.

• Under the organizer subfolder, there is a separate folder for each conference; the folder name is the same as the conference ID.

Figure 7-13 shows the structure of the content folder.

Figure 7-13. Content folder

After the client uploads the file, the Web Conferencing service stores the content file share. As part of the process of storing the file in the content file share, the server both encrypts the file and obfuscates the file name. For example, if you upload a file called quarterly_results.ppt, it might end up looking like this: sample.bin. This is done for two reasons. First, since IT administrators have access to this folder, sensitive data may need to be protected. Second, because the file is encrypted, you can make a file available for download before you are ready for people to view it. You can then send the decryption information at a separate time when you are ready to present the file in the conference.

20. The other clients in the conference download the file from Internet Information Services (IIS). The Web Conferencing service uses an IIS server as the mechanism for making the files available to the client. When a file is available for download, the client is sent a web URL that points to the IIS server. The IIS folder is configured so that it knows how to read the content folder, but not the metadata folder.

Note. The connection to the IIS server is configured during deployment. The IIS server where the files are stored is configured so that you cannot browse directly to the content in the folder. You can only access the content using the URL sent out by the Web Conferencing service.

The IIS server reads from the content folder.

21. These files are still encrypted. So the Web Conferencing service sends the client a message telling the client how to decrypt the file. The file and the key are sent separately for optimization purposes. You can send the download link before the conference time, and client can download the file and store it locally. When the file officially becomes shared, all the client needs to do is download the key to decrypt it.

This process can be summarized by the call flow shown in figure 7-14.

Figure 7-14. Web conferencing call flow

Application Sharing

As with other conference modalities, the Application Sharing Conferencing service communicates with Lync clients by using SIP/SDP and SIP/C3P for signaling. However, it is different in that it uses RDP-over-SRTP as the media protocol for transmitting the display and remote control data. RDP is the protocol that is used for all Microsoft Remote Desktop services. For details about using RDP, see “Remote Desktop Protocol” in the MSDN Library, http://go.microsoft.com/fwlink/?linkid=217201.

The SIP communications use mutual TLS (MTLS) for security, and they use the same Secure Sockets Layer (SSL) server certificate that is assigned to the Front End Server. As with A/V traffic, the RDP/SRTP traffic does not use a certificate and instead uses Advanced Encryption Standard (AES) and a shared key to encrypt and decrypt the RDP traffic that it transports.

There are four conferencing policies that affect how application sharing works:

AllowUserToScheduleMeetingsWithAppSharing: This policy determines if the user can organize a conference that includes Application Sharing. This setting is based on the conference organizer. It applies to the user who organizes the conference: if set to False, no conference created by a user affected by this policy will allow application sharing. However, the user can take part in other conferences where application sharing is allowed.

EnableAppDesktopSharing: This policy is enforced on a per user basis. This setting determines if a user can share their desktop or their desktop and application. The possible settings are:

• Desktop. The user can share their entire desktop.

• SingleApplication. The user can share only a single application. This is useful for the scenario where a user may have potentially sensitive information located on their desktop.

• None. The user is not allowed to share an application or their desktop.

AllowParticipantControl: This setting determines who in the conference can take control of the conference. This setting is enforced at the per-user level, and for both conferences and peer-to-peer communication sessions. This means that some users in a session might be allowed to give up control of a shared application or desktop to an external user while other users might not be allowed to give up control.

AllowExternalUserControl: Indicates whether external users (either anonymous users or federated users) are allowed to take control of shared applications or desktops. If this setting is set to true, it determines that anonymous users can take control of a desktop. This setting is enforced at the per-user level, and for both conferences and peer-to-peer communication sessions. That means that some users in a session might be allowed to give up control of a shared application or desktop to an external user while other users might not be allowed to give up control.

An administrator can modify these policies by using the Set-CsConferencingPolicy cmdlet.

During a conference, if the Application Sharing session ends due to a connection error on the media channel, the following diagnostic code is returned:

Ms-diagnostic: 21012;reason=”The media connection with the client was disconnected.”

The most likely cause is the client either stopped responding or lost network connectivity before it could properly close the SIP session. The application sharing process is illustrated in the call flow in figure 7-15.

Figure 7-15. Application sharing call flow

Summary

Organizations can take advantage of the tools included in Lync Server 2010 to provide their users with a rich conferencing and collaboration solution. Lync Server conferences are divided into two separate actions: scheduling a conference using Microsoft Outlook, and joining a conference by using one of the provided Lync clients, the web-based client, or dial-in conferencing. Each conference can consist of any combination of audio conferencing, video conferencing, web conferencing, or application sharing.

To schedule a conference, the Focus Factory takes the information provided by Outlook and creates a new conference record, which is stored in the Back End Server running Microsoft SQL Server database software.

When an attendee clicks the link included in the Outlook meeting invitation, the client connects to the Focus, which pulls information about the conference from the Back End Server. Based on these settings, the Focus allocates an A/V Conferencing Server, or other conferencing service, for each modality that will be used in the conference. Possible modalities include audio conferencing, video conferencing, dial-in conferencing, web conferencing, and application sharing. The Focus then tells the client how to connect to each server or service.

After joining the conference, it is the client's responsibility to initiate a connection with each conferencing service.

Additional Resources

For more information, see the following:

• Planning for Conferencing, http://go.microsoft.com/fwlink/?LinkID=205562

• Deploying Stand-alone A/V Conferencing Servers, http://go.microsoft.com/fwlink/?LinkId=217146

• Configuring Dial-in Conferencing, http://go.microsoft.com/fwlink/?LinkId=217147

• Managing On-Premises Meetings, http://go.microsoft.com/fwlink/?LinkId=215515

• Planning for Clients and Devices in Lync Server 2010, http://go.microsoft.com/fwlink/?LinkID=205571

Notes from the Field

Is There a 250 Participant Limit for Conferencing?

Byron Spurlock

Principal Architect and Founder, Quadrantechnologies

Microsoft Lync Server 2010 provides an on-premises conferencing solution for organizations. While planning to deploy Lync Server 2010 as your conferencing solution, you should consider the following information about conferencing limits.

Lync Server can support a maximum of 250 participants per conference. While a single conference with 250 participants is taking place, the pool can still support a total of 5% of pool users participating in concurrent conferences. For example, in a pool of five Front End Servers and 50,000 users, while a single 250-user conference is occurring, Lync Server can support 2,250 other users participating in smaller concurrent conferences. Lync Server supports these users participating in smaller conferences during a 250-user conference regardless of the number of users homed on the five Front End pools or Standard Edition Server.

Two hundred and fifty participants in a conference is the supported maximum limit that has been tested within Microsoft. So what happens when a conference is scheduled with 300 users? First, the default meeting policy has to be modified to allow an individual to send an invitation with more than 250 users because 250 is the default maximum number of participants for a conference.

Let's say a 300-user meeting invitation is sent out, and that is how many people attempt to connect to the on-premises meeting. Whether all 300 invited participants will be admitted into the conference depends on the available resources of the Front End Servers or A\V Conferencing pool. With each user that attempts to connect to the scheduled meeting, the Conferencing Server Factory notifies the Focus of the current load on the Conferencing services hosting the meeting, and also notifies the Focus of availability for admittance into the conference for additional users.

For large conferences, we recommend creating a dedicated meeting policy for organizers who are responsible for sending out large meeting requests. To do this:

1. Equip the server infrastructure above the minimum hardware specifications for memory and processor in order to run multiple conferences without a strain on the CPU.

2. If there are more than 10,000 users in a pool, branch out the A\V Conferencing Server to its own pool and increase the number of servers in the pool to support your organization's conferencing need.

For details, see the “Lync Server 2010 Capacity Planning Calculator Guide” at the Microsoft Download Center, http://go.microsoft.com/fwlink/?LinkId=217400.

Microsoft Lync Server 2010 Resource Kit Conferencing and Collaboration Page 2

---