The following sections describe the three basic remote access scenarios:
Basic remote access (for IM and presence information). Uses Office Communicator to log on to the enterprise network
Web Conferencing remote access. Uses the Live Meeting 2007 client to connect to a data conference
A/V Conferencing remote access. Uses Office Communicator for audio/video conferencing
Basic remote access uses Office Communicator to log on from an external network to connect to the Access Edge Server in the enterprise edge network. This scenario does not require the use of a virtual private network (VPN) and is an easy way for enterprise users to connect from home or external sites. The basic remote access scenario involves a user experience that is identical to that described in the internal access scenario in Chapter 5, in the section titled "Understanding the Login Process." The scenario, shown in Figure 7-4, uses the Office Communicator client to connect via the Access Edge Server to a Director that passes the traffic (after authentication and authorization) to the internal home server (or pool) for the user.
Office Communicator uses the same logic during a remote access logon as it does during a logon procedure on an internal network. The client does not know what network it is on until some exploration is done through discovery of DNS SRV and host (A) records. These records are used to discover internal and external Office Communications Server contact points. For basic remote access, three main records are used, shown here for the example domain Litwareinc.com.
_sip._tls.litwareinc.com (SRV record)
sipexternal.litwareinc.com (a record for single-server use)
vipexternal.litwareinc.com (a record if a load balancer is used)
After the connection point for basic remote access is identified, Office Communicator always negotiates TLS over a TCP connection. This is mandated by the clients and servers to maintain data privacy and to prevent man-in-the-middle intrusions on the external network. Note that certificate problems are the primary cause of connection failures with the front-end server. It is highly recommended that you use a certificate from a public CA. Your clients must trust the certificate on the external interface of the Access Edge Server. A root CA certificate from the issuing CA of the certificate installed on the Access Edge Server establishes this trust. If the client cannot trust the certificate on the Access Edge Server, Office Communicator clearly identifies this problem with an alert and with entries in the event log. If trace logs are enabled on the client, the error information is written in the trace log for additional troubleshooting.
The connection point will always be an Access Edge Server for supported topologies, and this server is responsible for performing simple message validation based on the supported enterprise domains and for protecting the enterprise network against network-level and protocol-level attacks. The Access Edge Server also has the ability to filter messages to provide additional functionality or protection. The Access Edge Server tags the messages as remote access requests and passes them to the next internal server (usually a Director server). The following header is added to the request to identify it as being from an external user and to track the name of the Access Edge Server that handled the request.
ms-edge-proxy-message-trust: ms-source-type=InternetUser; ms-ep-fqdn=server22.litwareinc.local; ms-source-verified-user=verified
The Director, which is an Office Communications Server Standard Edition Server or an Office Communications Server Enterprise Edition pool server, enforces authentication against Active Directory by the NT LAN Manager (NTLM), validates the user’s right to log on to the Office Communications Server infrastructure, and determines whether the user has a right to use remote access. This server supports the rest of the network infrastructure by pre-authenticating the incoming requests against Active Directory. The Director then uses its knowledge of the other Office Communications Server R2 servers to forward requests to the user’s home server or pool. From this point, the logon process is identical to a standard internal network logon process. However, an additional header is placed in responses to help Office Communicator identify that it is in a remote access scenario.
ms-user-logon-data: RemoteUser
The reverse proxy has a distinction in that it tracks edges during protocol operations so that it can differentiate messages that are proxied from the outside in and from the inside out. This tracking shows up in the trace logs and can be confusing when an incoming message comes from the internal network or an outgoing message is being routed to the internal network. Messages are logged as they come in and as they are forwarded, both to and from the internal and external networks.
Web conferencing remote access uses the Live Meeting 2007 R2 client from a remote network to conduct a meeting or share information with other enterprise or federated users. This section contains an example of a simple conference and presents the technical details that make it possible. Conducting a Web conference is similar to basic remote access for the SIP communications channel, but it also involves the Web Conferencing Edge Server to bridge application-sharing sessions to internal Web Conferencing Servers that form the conference hub. Additionally, a reverse proxy in the edge network provides access to the internal Web server where conference content is available. Figure 7-5 provides a functional diagram of this topology.
The following scenario involves two external users, Vadim N. Korepin and Jeremy Los, who are active contacts with each other. The scenario assumes that Office Communicator 2007 R2 and Office Live Meeting 2007 R2 clients are installed on each user’s workstation. This scenario also assumes that the users are logged on remotely and are enabled for remote access. The users have the ability to schedule conferences and to access Web conferencing. Vadim wants to share a game of FreeCell that he is working on so that he can get Jeremy’s advice about what to do next in a timely manner. This scenario uses Office Communicator 2007 R2 to establish and connect to the conference, but these two users can also use the Live Meeting 2007 R2 client to join a scheduled conference either directly or by clicking a conference URL.
Vadim N. Korepin opens a session in Office Communicator with Jeremy Los, clicks the sharing button, and selects Share Information Using Live Meeting, as shown in Figure 7-6. Vadim’s Office Communicator launches the Live Meeting 2007 client, which creates the conference and joins it directly.
At this point, Jeremy receives a message that informs him that Vadim would like to start an application-sharing session. If he accepts the invitation that he received in Office Communicator, both his and Vadim’s workstations will open the Live Meeting 2007 R2 client to begin a Web conference.
After Vadim and Jeremy connect to the session, Vadim shares his application by using the Content menu to select Share and then Share A Program, which shows a list of running programs. From this list, Vadim selects FreeCell.exe. This enables him to share the application for Jeremy to view so that their analysis can begin, as shown in Figure 7-7. From here, Vadim can delegate application control to Jeremy or make other applications, tools, and data available.
When a user connects remotely, he uses Office Communicator to log on through an Access Edge Server role, which uses SIP signaling to establish the session. He is then connected to the Web Conferencing edge role as a data conferencing connection point, which was reserved by the SIP session and will receive the HTTP reverse proxy as the URL for establishing a Web-based session. In an internal scenario, a local Web Conferencing Server and URL are used to access data conferencing services directly.
When Vadim creates an unscheduled conference and invites Jeremy, Vadim’s instance of Office Communicator makes a SIP SERVICE request asking that a conference be created, as shown in the following example:
SERVICE sip:[email protected];gruu;opaque=app:conf:focusfactory SIP/2.0 From: <sip:[email protected]>;tag=54268ccbd8;epid=0b28f0b0b5 To: sip:[email protected];gruu;opaque=app:conf:focusfactory CSeq: 1 SERVICE ... Content-Type: application/cccp+xml Content-Length: 1233 <?xml version="1.0"?> <request xmlns="urn:ietf:params:xml:ns:cccp" xmlns:mscp=http://schemas.microsoft.com/rtc/2005/08/cccpextensions C3PVersion="1" to=sip:[email protected];gruu;opaque=app:conf:focusfactory from="sip:vadim@ litwareinc.com" requestId="26587488"> <addConference> <ci:conference-info xmlns:ci="urn:ietf:params:xml:ns:conference-info" entity="" xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions"> <ci:conference-description> <ci:subject></ci:subject> <msci:conference-id>6CD0FA33C0F133499647246DA968BF6B </msci:conference-id> <msci:expiry-time>2007-09-25T13:44:34Z</msci:expiry-time> <msci:admission-policy>openAuthenticated</msci:admission-policy> </ci:conference-description> <msci:conference-view> <msci:entity-view entity="chat"/> <msci:entity-view entity="audio-video"/> <msci:entity-view entity="meeting"> <msci:entity-settings> <msdata:settings xmlns:msdata="http://schemas.microsoft.com/rtc/2005/08/ dataconfinfoextensions"> <msdata:app-viewing-behavior>enableWithFullSharing </msdata:app-viewing-behavior> <msdata:conferencing-type>collaboration </msdata:conferencing-type> </msdata:settings> </msci:entity-settings> </msci:entity-view> </msci:conference-view> </ci:conference-info> </addConference> </request>
This message is sent to the user’s Uniform Resource Identifier (URI), but with an additional parameter, ;opaque=app:conf:focusfactory, which specifies that the request is destined for the conference Focus Factory that is responsible for creating the meeting. In the body of the message, the request also specifies information about the conference to be created. Examples of data in the body of the message include the msci:conference-id attribute, which specifies the conference ID that should be used, and the msci:admission-policy attribute, which specifies the security level for the meeting (in this case, openAuthenticated means that all authenticated users can join, but anonymous Internet users cannot). It is also important to note that even though the conference type terminology has changed (as mentioned earlier in the section "Understanding On-Premises Conferencing Rules for Federated and Nonfederated Users"), the wire protocol has not, as shown in the msci:admission-policy which is still communicated as openAuthentication. In the following example, the SERVICE request receives a 200 OK response that passes back some basic information about the conference that was just created.
SIP/2.0 200 OK From: "Vadim N. Korepin"<sip:[email protected]>;tag=54268ccbd8;epid=0b28f0b0b5 To: <sip:[email protected];gruu;opaque=app:conf:focusfactory>;tag=38971651 CSeq: 1 SERVICE ... Content-Type: application/cccp+xml <response xmlns="urn:ietf:params:xml:ns:cccp" xmlns:msacp= "http://schemas.microsoft.com/rtc/2005/08/acpconfinfoextensions" xmlns:msav="http://schemas.microsoft.com/rtc/2005/08/avconfinfoextensions" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions" xmlns:msdata="http://schemas.microsoft.com/rtc/2005/08/dataconfinfoextensions" xmlns:msim="http://schemas.microsoft.com/rtc/2005/08/imconfinfoextensions" xmlns:ci="urn:ietf:params:xml:ns:conference-info" xmlns:cis="urn:ietf:params:xml:ns:conference-info-separator" xmlns:msls="urn:ietf:params:xml:ns:msls" requestId="26587488" C3PVersion="1" from="sip:[email protected];gruu;opaque=app:conf:focusfactory" to="sip:[email protected]" code="success"> <addConference> <conference-info xmlns="urn:ietf:params:xml:ns:conference-info" entity="sip:[email protected];gruu;opaque=app:conf:focus:id:6CD0FA33C0F13349964724 6DA968BF6B" state="partial" version="1"/> </addConference> </response>
Next, Vadim’s Office Communicator sends a SIP INVITE message to the conference that was just created to establish a session and add Vadim as an attendee for the conference, as shown in the following example:
INVITE sip:[email protected];gruu;opaque=app:conf:focus:id: 6CD0FA33C0F133499647246DA968BF6B SIP/2.0 From: <sip:[email protected]>;tag=80fd98dd31;epid=0b28f0b0b5 To: <sip:[email protected];gruu;opaque=app:conf:focus:id: 6CD0FA33C0F133499647246DA968BF6B> CSeq: 1 INVITE ... Content-Type: application/cccp+xml Content-Length: 716 <?xml version="1.0"?> <request xmlns="urn:ietf:params:xml:ns:cccp" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" C3PVersion="1" to="sip:[email protected];gruu;opaque=app:conf:focus:id:6CD0FA33C0F13349964724 6DA968BF6B" from="sip:[email protected]" requestId="0"> <addUser> <conferenceKeys confEntity= "sip:[email protected];gruu;opaque=app:conf:focus:id:6CD0FA33C0F133499647246DA968B F6B"/> <ci:user xmlns:ci="urn:ietf:params:xml:ns:conference-info"entity="sip:vadim@ litwareinc.com"> <ci:roles> <ci:entry>attendee</ci:entry> </ci:roles> <ci:endpoint entity="{4BB86066-3927-424B-A7DD-2E07FD6B611C}" xmlns:msci="http:// schemas.microsoft.com/rtc/2005/08/confinfoextensions"/> </ci:user> </addUser> </request>
The conference Focus responds with a 200 Invite dialog created message, confirming that Vadim is added as a presenter for the conference, as shown in the following example. Vadim’s client sends back an acknowledge (ACK) to confirm the invitation (which is not shown for this example).
SIP/2.0 200 Invite dialog created From: "Vadim N. Korepin"<sip:[email protected]>;tag=80fd98dd31; epid=0b28f0b0b5 To:<sip:[email protected];gruu;opaque=app:conf:focus:id: 6CD0FA33C0F133499647246DA968BF6B>;tag=84670080 CSeq: 1 INVITE ... Content-Type: application/cccp+xml <response xmlns="urn:ietf:params:xml:ns:cccp" xmlns:msacp="http://schemas.microsoft.com/ rtc/2005/08/acpconfinfoextensions" xmlns:msav="http://schemas.microsoft.com/rtc/2005/08/avconfinfoextensions" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions" xmlns:msdata="http://schemas.microsoft.com/rtc/2005/08/dataconfinfoextensions" xmlns:msim="http://schemas.microsoft.com/rtc/2005/08/imconfinfoextensions" xmlns:ci="urn:ietf:params:xml:ns:conference-info" xmlns:cis="urn:ietf:params:xml:ns:conference-info-separator" xmlns:msls="urn:ietf:params:xml:ns:msls" requestId="0" C3PVersion="1" from="sip:[email protected];gruu;opaque=app:conf:focus:id: 6CD0FA33C0F133499647246DA968BF6B" to="sip:[email protected]" code="success"> <addUser> <conferenceKeys confEntity="sip:[email protected];gruu;opaque=app:conf:focus:id: 6CD0FA33C0F133499647246DA968BF6B"/> <ci:user entity="sip:[email protected]"> <ci:roles> <ci:entry>presenter</ci:entry> </ci:roles> </ci:user> </addUser> </response>
Next, Vadim’s Office Communicator client sends a SUBSCRIBE message to the conference to receive notifications from the conference as events occur (such as when other users join), as shown in the following example:
SUBSCRIBE sip:[email protected];gruu;opaque=app:conf:focus:id: 6CD0FA33C0F133499647246DA968BF6B SIP/2.0 From: <sip:[email protected]>;tag=694f84821b;epid=0b28f0b0b5 To: <sip:[email protected];gruu;opaque=app:conf:focus:id: 6CD0FA33C0F133499647246DA968BF6B> CSeq: 1 SUBSCRIBE ... Event: conference Accept: application/conference-info+xml Content-Length: 0
Vadim’s Live Meeting client then connects to the Web Conferencing Edge Server after connecting through the HTTP reverse proxy with which it was provisioned during logon. His Office Communicator client sends the following invitation, which provides information about the conference that has been established, to Jeremy.
INVITE sip:[email protected] SIP/2.0 From: <sip:[email protected]>; tag=7bf3e5f500;epid=0b28f0b0b5 To: <sip:[email protected]> CSeq: 1 INVITE ... Content-Type: application/ms-conf-invite+xml Content-Length: 193 <Conferencing version="2.0"> <focus-uri>sip:[email protected];gruu;opaque=app:conf:focus:id: 6CD0FA33C0F133499647246DA968BF6B</focus-uri> <subject></subject> <data available="true"/> </Conferencing>
This invitation is accepted, and then Jeremy’s Office Communicator and Live Meeting clients will process the same interactions that Vadim’s Office Communicator and Live Meeting client did.
Note that if a user joined anonymously by using the Live Meeting client, he would have to authenticate by using Digest authentication to pass a hash of the meeting password. This authentication ensures that all servers the user connects to in the edge network can validate the user. This first-level authentication hands back meeting keys that are passed to the Web Conferencing Edge Server to prevent unauthorized access.
Audio and video conferencing remote access enables enterprise users in the external network to share video and audio sessions with internal and other external users. Figure 7-8 shows an example of the topology, with the SIP connections (TLS over TCP) shown as gray lines and the media sessions shown as black lines.
The A/V Edge Server provides a single, trusted connection point through which inbound and outbound media traffic can securely traverse NATs and firewalls. The industry-standard solution for multimedia traversal of firewalls is Interactive Connectivity Establishment (ICE), which is based on STUN and Traversal Using Relay NAT (TURN) protocols. The A/V Edge Server is a STUN server. All users are authenticated to secure access to the enterprise and use the firewall traversal service that the A/V Edge Server provides. Authenticated users receive a token from the authenticating server, and this token can be used to validate the user’s requests of the A/V Edge Server. To send media inside the enterprise, an external user must be authenticated and must have an authenticated internal user agree to communicate with them through the A/V Edge Server. The media streams themselves are exchanged using Secure Real-Time Protocol (SRTP) and Secure Real-Time Control Protocol (SRTCP), which is an industry standard for real-time media transmission and reception over IP.
Office Communicator remote access forces authentication over the SIP session with the Access Edge Server. After Office Communicator has logged on and authenticated, it can contact the A/V Edge Server on the public IP address by using a secure token that it can retrieve from the MS-AVEDGEA server—this is what prevents anonymous and unauthenticated users from using the A/V Edge Server for malicious purposes. The A/V Edge service allocates the user a port to use for the session. Office Communicator can then invite (through SIP) another user by using the internal A/V MCU as a bridge point. The recipient of the invitation can use a secure token (after authenticating to the Microsoft extensions to Traversal Using Relay NAT [MSTURN] service) to register directly with the A/V Edge Server or internal A/V MCU based on the recipient’s network location. Finally, media is exchanged over the negotiated ports, using the servers to bridge traffic.