This section describes the three basic remote access scenarios in detail:
Basic Remote Access (for IM and presence) Involves remotely using Office Communicator to log in to the enterprise network
Web Conferencing Remote Access Involves remotely using the Live Meeting 2007 client to connect to a data conference
A/V Conferencing Remote Access Involves remotely using Office Communicator for an audio/video conference
Basic remote access involves the use of Office Communicator to log in from an external network to connect to an 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 what is covered in Chapter 4, in the Understanding the Login Process section. The topology, shown in Figure 6-4 involves the Office Communicator client connecting via the Access Edge Server to an internal Standard Edition server. For most deployments, this server will actually be a Director that passes the traffic on (after authentication and authorization) to the internal home server (or pool) for the user. The technical details, which vary from what was shown in Chapter 4, are described in the next section.
Office Communicator walks through the same logic during a remote access login as it would during a login procedure on an internal network—it simply has no idea 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. More information about this DNS discovery is shown in Chapter 4, in the "Understanding Client Automatic Configuration and DNS Discovery" section. For basic remote access, two main records are leveraged and these are shown for the example domain contoso.com:
_sip._tls.contoso.com (SRV record)
sipexternal.contoso.com (A record)
Once 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 validation can have more problems during remote access—especially if a public CA isn't used to issue the Access Edge Server certificate, because the client might not trust it. Office Communicator clearly identifies this problem with an alert as well as entries in the event log, as well as trace logs (if they are enabled).
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-hop internal server (usually a Director role). 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.contoso.local; ms-source-verified-user=verified
The Director (which is either a Standard Edition server or an Enterprise Edition pool server) enforces authentication against Active Directory (using NTLM), validates the user's right to log in 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 offloading authentication and potentially larger numbers of requests if a denial of service (DoS) attack is made against the enterprise. The Director then uses its knowledge of the other Office Communications Server 2007 servers to forward requests to the user's home server or pool. From this point, the login is identical to a standard internal network login. However, an additional header is placed in responses to help Office Communicator identify itself as being in a remote access scenario:
ms-user-logon-data: RemoteUser
The Access Edge 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 a point of confusion when an incoming message comes from the internal network or an outgoing message is headed to the internal network. Messages are logged as they come in and as they are forwarded on, both to and from the internal and external networks.
Web conferencing remote access involves use of the Live Meeting 2007 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 multipoint control unit (MCU) 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 6-5 provides an overview diagram of this topology.
The usage scenario example involves two external users (Vadim N. Korepin and Jeremy Los) who are active contacts with each other. The example assumes that Office Communicator 2007 and Office Live Meeting 2007 clients have been installed on each user's workstation. Additionally, both users are assumed to have already logged in remotely and have been enabled for remote access, for the ability to schedule conferences, and for access to Web conferencing. In this example, Vadim has a desire to share a game of FreeCell he is working on so that he can get Jeremy's advice on what to do next. (Mission-critical applications like this can be extremely time sensitive—especially for the person involved in the game.) This example uses Office Communicator to establish and connect to the conference, but the Live Meeting 2007 client could have also been used to join a scheduled conference either directly or by clicking on a conference URL.
Vadim N. Korepin opens a session in Office Communicator with Jeremy Los and then uses the sharing button and selects Share Information Using Live Meeting. (See Figure 6-6.) Vadim's Office Communicator launches the Live Meeting 2007 client, which creates the conference and joins it (as shown in Figure 6-7) directly.
At this point, Jeremy sees a message pop up that informs him that Vadim would like to start an application-sharing session. If he accepts the invitation he received in Office Communicator, both his and Vadim's workstations will launch the Live Meeting 2007 client to begin a Web conference. (See Figure 6-7.)
Once Vadim and Jeremy are connected to the session, Vadim shares his application by using the Content menu to select Share and finally Share A Program, which shows a list of running programs. From this list, Vadim selects FreeCell.exe. This enables the application to be shared for Jeremy to view so that their analysis can begin. (See Figure 6-8.) From here, application control can be delegated to Jeremy or other applications, tools, and data can be made available.
The primary difference between the internal and remote access Web Conferencing scenarios simply involves Office Communicator logging in through an Access Edge Server and thereby being given the Web Conferencing Edge Server as a data conferencing connection point, as well as being given the HTTP reverse proxy as the URL for establishing a Web-based session. Internally, a local Web Conferencing Server and URL are given to access data conferencing services directly.
When Vadim creates an unscheduled conference and invites Jeremy, Office Communicator makes a SIP SERVICE request asking that a conference be created. The request looks like the following message:
SERVICEsip:[email protected];gruu;opaque=app:conf:focusfactorySIP/2.0 From: <sip:[email protected]>;tag=54268ccbd8;epid=0b28f0b0b5To:sip:[email protected];gruu;opaque=app:conf:focusfactoryCSeq: 1 SERVICE ... Content-Type: application/cccp+xml Content-Length: 1233 <?xml version="1.0"?> <requestxmlns="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:[email protected]" 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 URI, but with the 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). In the following example, the SERVICE request is responded to with a 200 OK response that passes back some basic information about the conference that was just created:
SIP/2.0200 OKFrom: "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 <responsexmlns="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:6CD0FA33C0F133499647246DA968BF6B" state="partial" version="1"/> </addConference> </response>
Next, Vadim's Office Communicator sends a SIP INVITE message to the conference that was just created in order to establish a session and add Vadim as an attendee for the conference:
INVITEsip:[email protected];gruu;opaque=app:conf:focus:id:6CD0FA33C0F133499647246DA968BF6BSIP/2.0 From: <sip:[email protected]>;tag=80fd98dd31;epid=0b28f0b0b5To:<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"?> <requestxmlns="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:6CD0FA33C0F133499647246DA968BF6B" from="sip:[email protected]" requestId="0"> <addUser> <conferenceKeys confEntity= "sip:[email protected];gruu;opaque=app:conf:focus:id:6CD0FA33C0F133499647246DA968BF6B"/> <ci:user xmlns:ci="urn:ietf:params:xml:ns:conference-info"entity="sip:[email protected]"> <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, shown next, confirming that Vadim is added as a presenter for the conference. Vadim sends back an ACK to confirm (which isn't shown for this example):
SIP/2.0200 Invite dialog createdFrom: "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 <responsexmlns="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 sends a SUBSCRIBE message to the conference in order to receive notifications from the conference as events occur (such as when other users join, and so on):
SUBSCRIBEsip:[email protected];gruu;opaque=app:conf:focus:id:6CD0FA33C0F133499647246DA968BF6BSIP/2.0 From: <sip:[email protected]>;tag=694f84821b;epid=0b28f0b0b5To:<sip:[email protected];gruu;opaque=app:conf:focus:id:6CD0FA33C0F133499647246DA968BF6B> CSeq: 1 SUBSCRIBE ... Event: conference Accept: application/conference-info+xml Content-Length: 0
At this point, Vadim's Live Meeting client connects to the Web Conferencing Edge Server after connecting through the HTTP reverse proxy that it was provisioned with during login. His Office Communicator client sends the invitation, which provides information about the conference that has been established, to Jeremy:
INVITEsip:[email protected]SIP/2.0From:<sip:[email protected]>;tag=7bf3e5f500;epid=0b28f0b0b5To:<sip:[email protected]> CSeq: 1 INVITE ... Content-Type: application/ms-conf-invite+xml Content-Length: 193 <Conferencingversion="2.0"> <focus-uri>sip:[email protected];gruu;opaque=app:conf:focus:id:6CD0FA33C0F133499647246DA968BF6B</focus-uri> <subject></subject> <data available="true"/> </Conferencing>
This invitation will be accepted, and Jeremy's Office Communicator and Live Meeting clients will go through the same interactions that Vadim's Office Communicator and Live Meeting client did.
As an aside, if a user were joining anonymously using the Live Meeting client, she would need to authenticate through the use of Digest to pass a hash of the meeting password. This authentication (Digest for anonymous users using conference passwords, and NTLM for enterprise users utilizing remote access) 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 6-9 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 both access to the enterprise and use of the firewall traversal service that is provided by the A/V Edge Server. 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 him through the A/V Edge Server. The media streams themselves are exchanged using Secure Real-time Protocol (SRTP), which is an industry standard for real-time media transmission and reception over the Internet Protocol (IP).
Office Communicator remote access forces authentication over the SIP session with the Access Edge Server. Once Office Communicator has logged in and authenticated, it can contact the A/V Edge Server on the public IP address through the use of a secure token that it can retrieve—this is what prevents anonymous and unauthenticated users from leveraging the A/V Edge Server for their own purposes. The A/V Edge Server allocates to the user a port to use on the external/internal interface, and Office Communicator can then invite (through SIP) the recipient by using the internal A/V MCU as a bridge point. The recipient can use a secure token (after authenticating) 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 by using the servers to bridge traffic.
Note
The A/V Authentication Service is consolidated with, and provides authentication services for, the A/V Edge Server. Outside users attempting to connect to the A/V Edge Server require an authentication token provided by the A/V Authentication Service before their calls can go through.
Troubleshooting Remote Access
Here are a few tips for troubleshooting Remote Access issues, particularly those associated with the consolidated install (single edge server) topology scenario.
A common issue involves users who are not on the local area network (LAN) being unable to sign in remotely. This problem can occur for either of the following reasons:
The user has not been provisioned for remote access.
No users are able to log in remotely.
Checking both of these cases helps to isolate the issue to an individual, or to a group of people when the server infrastructure itself could be causing the problem.
Another common issue that can prevent remote access from functioning properly is when internal and external servers are not able to connect to each other properly. If this happens, use the Office Communications Server 2007 Microsoft Management Console (MMC) on the internal network. Look under global properties, where there are settings that enable the internal servers to see the edge servers. Similarly, on the edge servers there are settings that specify which servers in your internal organization are the next-hop destinations.
For example, consider the situation where the internal servers are not able to route outbound to the appropriate Web Conferencing Servers or Remote Access Servers. In Office Communications Server 2007, there are global properties that specify the list of trusted edge servers. This list must be configured for the internal servers (such as the front-end servers) to allow communication with the Access, Web Conferencing, and A/V Edge Servers. (See Figure 6-10.) If the edge servers are not listed, outbound communication will not be established from the internal servers, leading to internal users failing to send outbound SIP messages or make outbound calls.
