Enabling Web conferencing with external users requires an Access Edge service to handle the SIP signaling that is necessary to set up and tear down a conference. It also requires a Web Conferencing Edge service to act as a proxy for the transfer of meeting content, such as slides, whiteboard, and questions and answers between internal and external users. In addition, an HTTP reverse proxy is needed to enable slide download and decryption. The call sequence, illustrated in Figure 1, is as follows.

Figure 1. Call sequence to enable Web conferencing with outside users

  1. An external user receives e-mail containing an invitation to join a Web conference. The e-mail contains a conference key and a URI linking to the conference. Both the key and the URI are unique for this particular meeting.

    The meeting URL is not an HTTP-based URI. Therefore, an end user cannot join a conference by copying the URI and pasting it into a browser. The URI is of the form meet:sip:Organizer@domain;ms-app=conf;ms-conf-id=1234. When the invited user clicks the meeting URI, the Live Meeting Console starts and attempts to connect to the server per the Live Meeting Console configuration (either manual or automatic configuration).

  2. The external user initiates the join procedure by clicking the meeting URI in the e-mail. This starts the Live Meeting console, which sends a SIP INVITE containing the user’s credentials. A federated or remote user joins a conferencing using their enterprise credentials. For a federated user, the SIP INVITE is first sent to his or her home server, which authenticates the user and forwards the INVITE to the enterprise hosting the conference. An anonymous user is required to pass digest authentication. For details about digest authentication, see Authentication for Office Communications Server 2007 R2

  3. A Director or Front End Server authenticates the remote or anonymous user and notifies the client. (As mentioned in step 2, federated users joining a conference are authenticated by their enterprise.)

  4. The client sends an INFO request to add user to the web conference.

  5. The Web conferences sends an add User response that contains the token to present to the Web Conferencing Edge service among other information.

    Notice that all the preceding SIP traffic flowed through the Access Edge service.

  6. The client connects to the Web Conference Server, which validates the token and proxies the request, which contains another authorization token, to the internal Web Conferencing Server. The Web Conferencing Server validates the Authorization Token, which it originally issued over the SIP channel, to further ensure that a valid user is joining the conference.

  7. The Web Conferencing Server sends the external user the slide URL for the meeting, along with a key for decrypting the slide.

    The URL to the slide content is generated randomly and is not visible to the user. It is not included in the initial e-mail and is not discoverable on the client. Directory browsing is forbidden on the Web Components Server as well. The key to the slides is separate from the conference key and is unique for this conference resource and this particular meeting. The user receives this key only after being authenticated on the SIP channel.

  8. The external user downloads the slides and decrypts them using the unique slide key.

    The slides and other conference resources are encrypted using 128-bit AES. With AES encryption, the only way to decrypt the content is by brute force, and the number of possible keys is so large that it is computationally infeasible to stage a successful brute-force attack in the short amount of time that would be available. Note that the meeting content and the key are only stored in process and are not physically stored on the end user’s hard drive.