Instant Messaging Architecture

[Previous] [Next]

When Microsoft first started to consider incorporating instant messaging capabilities into the Exchange product, it identified several market requirements that such a service would need to incorporate. Table 19-1 lists these requirements and indicates how the IM architecture has met each one.

Table 19-1. Market requirements for Instant Messaging

Market Requirement	How Implemented
Perform at large installations	Scalable architecture
Allow communication between businesses	Federated architecture
Work with firewalls	Firewall compatibility
Provide security and privacy	Authentication and access control list (ACL) mechanisms
Leverage existing infrastructure	Integration with Microsoft Windows 2000 and Exchange 2000 Server
Offer interoperability between products	Use of standard protocols, such as HTTP, LDAP, and WebDAV

Rendezvous Protocol Architecture

All IM communication occurs over the rendezvous protocol (RVP). RVP is an extended subset of the WebDAV protocol, which is an extension to HTTP 1.1. As such, RVP can leverage existing technologies, such as firewall support and proxy servers. In addition, the issue of client authentication need not be addressed in RVP, since it has been settled within HTTP.

RVP is designed to enable subscriptions and notifications within an organization and across multiple organizations and businesses, whether over a LAN connection or over the Internet. Instant messaging clients always communicate with IM servers, but IM servers are not required to communicate directly with each other. Therefore, many different servers can be installed within separate Active Directories.

RVP allows for watchers to obtain presence information, for presentities (we will use the term "user" in place of "presentity" henceforth) to determine which watchers are obtaining their presence information, and for instant messages to be sent to instant message inboxes inside the current domain or to a different domain.

The home server is the IM server responsible for maintaining current presence information for any user assigned to it and for issuing notifications of changes in a user's status to any subscriber. Messages sent to a user must first pass through the user's home server. The instant messaging client software represents the user to the home server and acts as the inbox for that user.

In order for a client to find the correct IM server to perform the requested tasks, such as updating a user's presence information or sending an instant message, it must first perform a DNS service (SRV) record lookup for the domain containing the IM server. The domain can be either local or remote, but it must support SRV records. The SRV lookup returns the host name of the IM server responsible for that domain. If no SRV record exists, DNS searches for an address (A) record for the IM server.

The client then connects to this server and sends it a request for some type of action. If the server is the user's home server, it handles the request. If the server is a routing server, it either proxies the request or uses HTTP to redirect the client to a specific home server. To improve the speed of lookups, the client caches the destination home server for a period of time.

Because all this activity occurs over HTTP and port 80, RVP allows presence information and instant messages to be transmitted over the Internet between dissimilar networks and domains.

RVP is an asynchronous protocol that requires little bandwidth to operate. Therefore, network bandwidth should not be an issue when considering where to place the IM servers, except in environments with exceptionally heavy message usage. However, it's generally best to place the IM servers near the users who subscribe to them.

All IM communication between clients and servers uses an extended subset of the WebDAV commands. Table 19-2 lists the commands that Instant Messaging uses.

Table 19-2. WebDAV commands used by Instant Messaging

Command	Description
SUBSCRIBE	Asks the home server of the target user to send back presence information and to update that information should it change.
UNSUBSCRIBE	Asks the home server of the target user to stop sending presence information.
PROPPATCH	Updates or patches a property of the target user. Most often used for updating the subscriber's status, such as changing between offline, online, and busy.
PROPFIND	Retrieves a property or set of properties for subscriptions. Most often used to obtain status information when first logging on.
NOTIFY	Used in server-to-server communications to update the remote server regarding subscriber's status changes. Also used to send instant messages between users.

Instant Message Addressing

Once a user account is enabled for Instant Messaging, you can display the Exchange Features tab of the user's property sheet, select Instant Messaging, and click Properties to see the addresses that are used behind the scenes by IM (Figure 19-1). For more information about enabling an account for IM, see the section "Giving Users Access to Instant Messaging" later in this chapter.

Figure 19-1. Instant Messaging addresses for a user account

Instant Messaging uses URLs to route messages to users. It is important to understand what these URLs represent and why they are constructed as they are. Each user has two URLs: a home server URL and a default URL.

At this point, you might be wondering why we are using URLs at the desktop for the instant messaging client. Think of the instant messaging client as a mini-browser that registers itself with the home server when it logs on and is assigned a port number above 1024. It connects to the home server at port 80, so that it can send messages to and receive messages from the IM home server.

The home server URL for the user in Figure 19-1 is http:// Indianapolis/instmsg/local/tucson.hr.oaktree.com/instmsg/aliases/jmustard, and it is parsed in the following manner:

• Indianapolis The home server to which the user will connect.
• instmsg A virtual directory that is created dynamically in the Web site chosen to be associated with the home server.
• local Reserved for future use. There is no immediate use for this tag; it does not mean that the URL is pointing to a local resource.
• tucson.hr.oaktree.com The routing server from which messages will arrive. This section indicates the source of incoming messages only. Outgoing messages can be routed through different routing servers when, for example, a message is destined for a user in another domain.
• instmsg References the router's virtual directory. This path is good for keeping track of how to send messages back along the same path if it is best to do so.
• aliases Specifies the type of account, not the alias attribute for a user account. In the future, IM will be able to include groups, printers, and other addressable entities, such as cell phones.
• jmustard Gives the Windows 2000 logon name of the user.

TIP

---

Configure the IM domain to be the same as the SMTP domain. This will make Instant Messaging easier for your users and will simplify naming conventions used on your network. See the section "Configuring DNS for Instant Messaging" later in this chapter to learn how to configure the IM domain.

Instant Message Authentication and Client Logon

Although users can authenticate to their home server, RVP does not require them to do so. Authentication for IM users is accomplished using either Windows Integrated Authentication (WIA) Challenge/Response or the Digest authentication method. (WIA was formerly known as Windows NT Lan Manager, or NTLM.) The Digest authentication method verifies that both parties share a secret (that is, a password) without communicating this secret in the open to each other. This scheme can be used by clients on non-WIA platforms, such as UNIX. Kerberos is not used as part of the authentication process.

MORE INFO

---

The Digest authentication method is outlined in RFC 2617, "HTTP Authentication: Basic and Digest Access Authentication."

When a user logs on to IM, the following processes occur, all of which are transparent to the user:

1. The user's computer queries DNS for an SRV resource record for the RVP protocol, and DNS returns the resolution referring the user to the routing server.
2. The user connects to the IM router.
3. The IM router queries Active Directory for the user's IM home server.
4. The IM router returns the home server's URL address to the user.
5. The IM user uses the home server URL address to connect to his or her IM home server.
6. The IM home server validates the user's Active Directory user name and password.

When a user logs on to Instant Messaging, the user doesn't use the regular logon profile. Instead, the Microsoft Internet Explorer profile is used. This profile's logon uses NTLM authentication, which cannot pass through a proxy server. Thus, if the user's browser is configured with the address of a proxy server, you'll need to configure an exclusion for the IM server's IP address, as described in the section "Users Can't Log On," later in this chapter.

TIP

---

If the Internet Explorer settings need to be changed, you'll need to exit the instant messaging client and restart it before the new Internet Explorer settings will take effect for the client.

Presence Information

Presence information is information regarding whether an individual is online, out of the office, or busy, as illustrated in Figure 19-2. By checking another user's presence information, an individual can determine whether that user would be likely to read an instant message immediately.

When a user logs on, this fact is sent as a status notification to the IM server, which then passes this knowledge to those who have subscribed to presence information for that user. A user subscribes to presence information for another user by adding that person to his or her contact list, causing the local instant messaging client to send a subscription message to the new contact's home server. The home server is then responsible for sending the subscribing user a status notification whenever the presence information for the new contact changes. Figure 19-3 shows the current presence information for a user's contacts.

An instant messaging client has seven presence settings:

• Online
• Invisible
• Busy
• Be Right Back
• Away From Computer
• On The Phone
• Out To Lunch



Figure 19-2. Presence information settings.

Instant Messaging is not meant to be used to know the current status of everyone in an organization but is rather a way to track the presence of individual team members. It is common for users to list their boss and several other team members as well as a few external contacts in their instant messaging client. If the contact list becomes too large, the client interface becomes less attractive, and the number of status notifications that update presence information can rapidly add up. It is recommended that each user maintain no more than 1000 contacts. Most users will need to list only 15 or 20 users in their contact list.

Figure 19-3. Presence information for a user's contacts.