In the same way as with other types of meetings, inter-server control communications between the Focus, the Application Sharing Conferencing Server, and the Conferencing Server Factory occur over HTTPS/C3P over TCP Port 444.

The Office Communicator client and the Communicator Web Access server use SDP and C3P commands embedded in SIP messages in order to initiate and respond to desktop sharing requests. If the session is between only two parties and both are using Office Communicator, one or more SIP proxies relay the control traffic to the other client.

As with IM or audio/video, if three or more participants are in the meeting, it becomes a conference, and the Focus Factory generates a Focus for the meeting and assigns it a conference URI. The Focus is instantiated as a SIP User Agent on one of the Front End Servers of the pool assigned to the person who initiated the meeting.

When a user initiates a multiparty meeting flagged for desktop sharing or when a user in a multiparty IM session escalates it to include desktop sharing, the Focus uses HTTP/C3P to request an Application Sharing Conferencing Server for the meeting from the Conferencing Server Factory, after which desktop sharing sessions between all participating clients and the Application Sharing Conferencing Server can be established.

Note:
If one or both of the participants in a two-party desktop sharing session are using Communicator Web Access as a client, the call is treated as a conference and incorporates a Focus and an Application Sharing Conferencing Server.

After the control information for the desktop sharing session has been exchanged and sharing has been initiated, the Remote Desktop Protocol (RDP) carries the stream of bitmaps (or JPEG images, in the case of Communicator Web Access communicating with the Application Sharing Conferencing Server) from the sharer’s desktop to the other meeting participants. If another participant takes control, RDP carries the controller’s keyboard and mouse inputs back to the sharer’s desktop.

Because desktop sharing was designed to support peer-to-peer sharing when the session is between only two parties, it faces the same challenges as audio/video media with network address translation (NAT) devices and communication between endpoints on the internal network and others on the Internet. To address this issue, Microsoft decided to use the same Office Communications Server infrastructure to handle both audio/video data and desktop sharing data. This infrastructure includes the Interactive Connectivity Establishment (ICE) support built into the Office Communicator clients and the Office Communications Server Edge Server, and the use of Secure Real-time Protocol (SRTP) and Secure Real-time Control Protocol (SRTCP) for carrying the data, which in the desktop sharing case is RDP data instead of RTAudio or RTVideo media.

Encapsulating RDP in SRTP packets means that desktop sharing can reuse a great deal of existing functionality and security already implemented in Office Communications Server and Office Communicator to support audio and video, and it means that Edge Servers require no additional functionality to support desktop sharing with remote and federated users.

However, RDP-over-SRTP differs from RTAudio/RTVideo-over-RTP in that the underlying transport protocol for SRTP is always TCP rather than the UDP normally used for audio and video streams. This choice also means that much of the packet overhead imposed by SRTP/SRTCP provides little or no benefit to the RDP data that is carried over it. For example, SRTP/SRTCP provides sequence numbering and delivery monitoring, which duplicates a process already handled by the TCP transport, and RTP/RTCP time stamping function (to allow synchronization and jitter calculation) is unnecessary because desktop sharing can tolerate much more latency and dropped packets than voice/video and still remain intelligible.

Note:

If the Security Settingsunder the Pool Properties:Mediamenu for pools are set to Do not support encryption, both A/V and desktop sharing data to and from users and Conferencing Servers in that pool will tunnel through RTP/RTCP rather than SRTP/SRTCP. Although RTP/RTCP provides all the same functions as SRTP/SRTCP sans encryption, this means that desktop sharing data carried over RTP/RTCP is no longer inherently secure from eavesdropping. Even though RDP offers native encryption (enabled by default on Windows server and client operating systems), RDP encryption is turned off in Office Communications Server 2007 R2 and Office Communicator 2007 R2 to eliminate the overhead of needless double-encryption.

Because desktop sharing is designed to support browser-based clients on a variety of operating systems, Communicator Web Access renders desktop sharing data into AJAX-based Dynamic HTML so that it can be displayed on a variety of browsers and operating system platforms without requiring special add-ins. Users can even send keyboard and mouse movements back to the Communicator Web Access server over DHTML, thereby enabling them to remotely control sharer’s desktops without needing an RDP client.

However, to share display data from a browser connected to Communicator Web Access, the browser must be running a special add-on that provides the required RDP-over-RTP and ICE support. At present this add-on is available only for Internet Explorer and Firefox for Windows.

As with the other Office Communications Server Conferencing Servers (for example, IM, Web Conferencing, A/V, and Telephony Conferencing), the Application Sharing Conferencing Server (Asmcusvc.exe) is a Windows service that runs on each front end server in a consolidated topology independently of the Front End Service (RTCSRV.EXE) that hosts the SIP Proxy, Registrar, Focus Factory, and Focus instances. In an Enterprise pool, the hardware load balancer distributes requests for an Application Sharing Conferencing Server, which listens on TCP port 5065, among the pool servers.

An Application Sharing Conferencing Server is used only when the application sharing session contains three or more participants or whenever one of the participants is using Communicator Web Access.

An Application Sharing Conferencing Server communicates with clients, whether Office Communicator or Communicator Web Access, using SIP/SDP and SIP/C3P for signaling and RDP-over-SRTP for the display and remote control data. The SIP communications are secured by MTLS, and they use the same 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, which is negotiated and exchanged securely over the signaling channel, to encrypt and decrypt the RDP traffic that it transports.

The Application Sharing Conferencing Server also communicates with the Focus and Conferencing Server Factory over HTTPS/C3P using the same SSL certificate that is assigned to the other Office Communications Server services on the Front End Server.

The Application Sharing Conferencing Server retrieves its configuration data by using Windows Management Instrumentation (WMI), but the only configurable settings for the service are the listening port and IP address, the range of media ports that RTP/SRTP can use, the maximum number of users across all meetings, the maximum number of meetings, and the maximum meeting size.

The Office Communications Server 2007 R2 Focus and Conferencing Server Factory have been updated to be aware of the Application Sharing Conferencing Server and to communicate with it in the same manner as the other conferencing servers, primarily over HTTPS/C3P.

Office Communicator 2007 R2 has been extended to support desktop sharing so that users can participate in desktop sharing sessions without installing the Live Meeting client or any special plug-ins, and if the user has been assigned a global meeting policy that includes the Enable Program and Desktop Sharingoption, there is nothing more for the user or the administrator to do.

Because Office Communicator 2007 R2 is an ICE-enabled client, it can find the most efficient way to establish peer-to-peer desktop sharing sessions with other Office Communicator 2007 R2 clients. The new version of Office Communicator also adds RDP support needed for desktop sharing. (This RDP support is completely independent of the RDP support in Windows.)

The user interface for invoking and responding to desktop sharing is described in the Office Communicator Help and in the Office Communicator 2007 R2 Technical Reference.

Microsoft has extensively enhanced the 2007 R2 release of Communicator Web Access in order to provide support for participants who do not have access to a computer with either the Office Communicator or Live Meeting client.

The addition of dial-in and dial-out conferencing allows users with access to a phone to participate in the audio portion of Office Communicator-based meetings, and new anonymous sign-in support in Communicator Web Access desktop sharing allows even an anonymous user with access to a browser to participate in online meetings that involve desktop sharing (if permitted by Office Communications Server global Meeting policy).

In order to support Macintosh and Linux users, Communicator Web Access displays the sharer’s desktop in the user’s browser window using AJAX Dynamic HTML (DHTML) over HTTPS. The Communicator Web Access server gets the sharer’s RDP stream from the Application Sharing Conferencing Server, which knows it is communicating with a Communicator Web Access Server and converts the bitmaps normally used for Office Communicator viewing into JPEG format before streaming them to the Communicator Web Access server over RDP/SRTP (there is only one stream no matter how many users viewing the particular desktop sharing session are connected to that Communicator Web Access server). The Communicator Web Access server translates this stream into AJAX DHTML and sends it over HTTPS to each participating browser, thereby enabling many non-Windows systems to display it properly. (The JPEG conversion that occurs on the Application Sharing Conferencing Server is the reason why two-party calls involving a Communicator Web Access client do not route desktop viewing and control data directly to the other client.)

In addition to viewing shared desktops, users connecting from any supported browser can also take control of the sharer’s desktop (that is, if permission has been granted by the sharer) without requiring any special browser add-ins or controls.

In order to view desktop sharing sessions from Internet Explorer or Firefox, the client computer needs to resolve two DNS CNAMES, as.< CWAserverFQDN >and download.< CWAserverFQDN >. This requirement exists because these browsers will open no more than two connections per URL (for example, https://cwa.contoso.com); however, for optimum performance, desktop viewing requires additional open connections. The two CNAME records allow the browsers to open four more connections.

If Communicator Web Access is published to the Internet, the external DNS must be able to resolve these CNAME records to the IP address of the reverse proxy relaying external traffic to the Communicator Web Access server. Furthermore, because the connections to the Communicator Web Access server or its associated reverse proxy are over HTTPS, the certificates on both servers must include the two CNAMES in its Subject Alternate Name (SAN) field.

To allow users without Active Directory credentials to join the meeting, Communicator Web Access was also enhanced in Office Communications Server 2007 R2 to support anonymous sign-in upon receipt of a meeting invitation, and these participants get the same access to the roster, IM, and desktop sharing capabilities as do authenticated users. If the organization has published Communicator Web Access to the Internet, then users with any of the supported Web browsers can view desktop sharing sessions over the Internet.

If a meeting participant who is using Communicator Web Access wants to share his or her desktop, he or she must be using Windows XP SP2 or Vista and either Internet Explorer 6 SP2, Internet Explorer 7, or Firefox 3.0.x with the CWAPlugin.exe add-on installed on it. This add-on provides the required support for ICE, SRTP/SRTCP, and RDP.

If the user’s computer does not already have this add-on, upon the user’s first attempt to share their desktop the browser will prompt him or her to download it from the Communicator Web Access server as shown in the following:

The user interface of the add-on setup program is available in 15 different languages. By default, the browser’s current language setting will determine the language that the user sees. Users do not need to have administrative privileges to install the add-in, but on Vista systems, the user must have User Account Control enabled.

After CWAPlugin.exe is downloaded, it installs and registers a set of files into the user’s Windows profile. CWAPlugin.exe registers the AppSharingHostClassand AsVersionQueryClassActiveX controls in Internet Explorer or the npCwaAppSh.dllplug-in in Firefox.

Note:
The add-on is not supported on 64-bit versions of Internet Explorer; users of 64-bit Windows must launch the 32-bit version of Internet Explorer in order to install and use the add-in. The add-on does not install on Windows Server 2008.

Following are the browser management dialog boxes that indicate (in highlight) successful installation (the one on the left is for Internet Explorer and the right for Firefox).

The add-in files get installed into the user’s Windows profile as shown in the following (the installation folder for Internet Explorer is shown in the top screen shot and the Firefox install folder in the bottom screen shot).

From Office Communicator, if you have multiple monitors you can choose to share just one monitor. However, when using the Communicator Web Access with the browser add-in on a computer with multiple monitors, you have to share your entire desktop across all monitors.