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.
- 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).
- 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
for Office Communications Server 2007 R2
- 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
- The client sends an INFO request to add user to the web
- The Web conferences sends an add User response that contains
the token to present to the Web Conferencing Edge service among
Notice that all the preceding SIP traffic flowed through the Access Edge service.
- 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.
- 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.
- 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.