Understanding Basic Remote Access Scenarios

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

Understanding Basic Remote Access for IM and Presence

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.

Basic remote access scenario/topology

Figure 6-4. Basic remote access scenario/topology

Examining the Basic Remote Access Scenario in Detail

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.

Understanding Web Conferencing Remote Access

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.

Web conferencing remote access scenario/topology

Figure 6-5. Web conferencing remote access scenario/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.

Use Office Communicator to Start a Conference (Step 1)

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.

Initiating a data conference from Office Communicator

Figure 6-6. Initiating a data conference from Office Communicator

Joining a Web Conference with the Live Meeting 2007 client

Figure 6-7. Joining a Web Conference with the Live Meeting 2007 client

Accept and Join a Web Conferencing Invitation (Step 2)

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.)

Begin Sharing an Application (Step 3)

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.

Web conferencing session with application sharing

Figure 6-8. Web conferencing session with application sharing

Examining the Web Conferencing Remote Access Scenario in Detail

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:

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:[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.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: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:

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: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.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 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):

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

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:

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 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.

Understanding Audio and Video Conferencing Remote 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.

Audio/video conferencing remote access scenario/topology

Figure 6-9. Audio/video conferencing remote access scenario/topology

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.219.174