Inside Windows Messenger - How it Communicates

  • Article

Published: October 01, 2001 | Updated: October 15, 2001

By Tom Fout

Operating System

Abstract

This article discusses Microsoft® .NET Messenger Service, Microsoft Exchange 2000 Instant Messaging Server and Session Initiation Protocol- (SIP) based server options for configuring the servers and services that provide for instant communication using Microsoft Windows® Messenger. Also covered is how to monitor the online status of contacts.

On This Page

Introduction
Server Solutions for Windows Messenger
How Windows Messenger Communicates
Appendix: Glossary of Acronyms Used
Summary
Related Links
Acknowledgements

Introduction

Using Microsoft® Windows® Messenger you can instantly communicate and collaborate with your contacts. You build your list of contacts (or "buddies") by providing a friendly name such as "Paul" and an address, such as paul@reskit.com. The power of Presence in Windows Messenger makes instant communication and collaboration with contacts more effective. Presence gives users the ability to find each other, Rendezvous, and stay constantly updated with each other's online status. (The powerful capabilities of Presence and Rendezvous are usually provided by a server or service.)

Server Solutions for Windows Messenger

This section discusses the different server solutions that facilitate Windows Messenger communication and collaboration sessions.

Windows Messenger clients initiate communications between one another through a server component that provides for client registration, configuration and presence. This server component may also act as a broker in the client-to-client communication, such as when Instant Messaging (IM) is used. There is currently a server solution for Internet-based communications (Microsoft .NET Messenger Service) and a server solution for enterprise instant messaging (Microsoft Exchange 2000 IM Server). Additional server solutions are planned.

.NET Messenger Service

The .NET Messenger Service—formerly called MSN Messenger—provides the Presence and Rendezvous services required for user-to-user communications. Presence, instant messaging, data collaboration and computer-to-computer voice and video communications are supported in Windows Messenger version 4.0. In the next release of Windows Messenger—version 4.5 is planned for release during the Microsoft Windows XP release—additional features will be included, such as: computer-to-phone calling, sending an instant message to a pager, and access to Microsoft Hotmail® directly from Windows Messenger. In order to use this service, a Passport or a Hotmail account is required.

Computer-to-computer communication using .NET Messenger Service sends and receives data in clear text over the public Internet.

Caution: Sending and receiving data in clear text over the public Internet means that no encryption or similar security feature is protecting that communication.

Exchange 2000 Instant Messaging Server

Microsoft included IM and Presence support with Microsoft Exchange 2000 Server—this product is called Exchange 2000 Instant Messaging (IM) Server. Exchange 2000 IM Server enables Presence and Instant Messaging to be used in a corporate environment. Currently, Exchange 2000 IM Server uses the MSN Messenger client; For Windows XP users, Windows Messenger will replace the MSN Messenger client and seamlessly provide all of the additional Windows Messenger communications and collaboration functionality. New installations will require Windows Messenger version 4.5. This corporate solution requires an existing or new installation of Exchange 2000.

When you deploy an Exchange IM Server you will be running your own Presence and Rendezvous service. You can use your corporate directory to add people from your organization to your contact list. At the same time you can simultaneously use the .NET Messenger Service to add external contacts.

Note: Keep in mind that communication with external contacts will be in clear text over the public Internet and that no encryption or similar security feature protects that communication.

SIP Proxy and Registrar Servers

Instant communication functionality for servers can also be provided using the Internet Engineering Task Force- (IETF) defined Session Initiation Protocol (SIP) (RFC 2543) together with the SIMPLE extensions for Instant Messaging and Presence. Products created using these protocols provide an additional way to deploy a Real Time Communications (RTC) solution of your own.

These protocols and the RTC solution will be supported by the Windows Messenger client.

Real Time Communications

RTC unifies the various forms of live interpersonal communications supported by Windows Messenger. The server solutions discussed above enable the services supported by Windows Messenger to be used or experienced on a variety of devices.

RTC is Unique

The following features make RTC unique:

Presence lets you know which device or devices you have access to at different times of the day and helps you make smart decisions about routing communications attempts.

Notifications play a key role by alerting you—on the device of your choice—when someone is trying to reach you or when some form of information needs to be delivered.

Multi-modal communications let you dynamically establish Windows Messenger services one-at-a-time or all-at -once, as needed.

How Windows Messenger Communicates

This section provides an overview of how Windows Messenger works with several Servers and services to enable users to communicate and collaborate.

Windows Messenger users can register with a variety of servers or services and subscribe to their contacts' online status—also known as presence. Users can also establish communication sessions for instant messaging, voice and/or video, to collaborate with peers, or take advantage of other communication features. Windows Messenger provides this capability by supporting a number of different protocols.

Main Servers Supported by Windows Messenger

The main servers supported by Windows Messenger are:

  • .NET Messenger Service: Most Windows XP residential users, using Home Edition or Pro will use the .NET Messenger Service.

  • Exchange 2000 IM Server: Businesses and enterprises may choose to use the Exchange 2000 IM Server for their global address book functions. This Server provides IM and Presence support.

  • IETF SIP Proxy Servers: For complete RTC functionality, businesses and enterprises may choose to deploy a SIP-based solution. The additional protocols used here include Session Initiation Protocol (SIP) RFC 2543 and Session Description Protocol (SDP) RFC 2327 (SDP).

Windows Messenger can work with multiple Server types and protocols concurrently. This might be appropriate in a corporate environment where Exchange IM is used for internal communications and .NET Messenger for external communications.

Main Services Supported by Windows Messenger

The main services supported by Windows Messenger are:

Presence

Presence in Windows Messenger tells you about the online status of the people on your contacts list. When a user logs on to Windows Messenger an attempt is made to log on to each configured network. Although each of these networks is different and may use different protocols, the result is that the user's presence is registered on each network. Part of this process involves establishing a relationship with a Presence and Rendezvous Server.

In the case of .NET Messenger and Exchange IM, this is a Transmission Control Protocol (TCP) connection, but the protocols used over that TCP connection to provide presence are different. This connection will be used for server-mediated communications—including forwarding IM messages. If a SIP server solution is used, the relationship is established through SIP REGISTER, SUBSCRIBE, and NOTIFY methods, usually using User Datagram Protocol (UDP) as a transport.

A user adds a contact to Windows Messenger by specifying information about the contact, including an address and the service used by the contact. Windows Messenger will register (subscribe) for notification of presence and status update from the service configured for that contact.

Subsequently, whenever the user logs on to Windows Messenger, the underlying protocol support will register with the appropriate server and/or service. The server and/or service will then update the user, and all contacts on his or her contact list, with the correct online status.

Windows Messenger users can instantly communicate with contacts that are currently online; contacts who are online are listed in a green colored typeface.

Instant Messaging

Instant Messaging is a mode of communication and collaboration in Windows Messenger. The protocol used for initialization and communication on the IM session depends upon the server or service being used. For .NET Messenger or Exchange IM, the IM text is carried over a TCP connection. When a SIP Proxy server is used for IM, the server can be configured to transfer the text over TCP UDP or Secure Sockets Layer (SSL)— a security protocol that runs over TCP.

The initiating client sends a request to start a conversation with the contact to the server, which is then forwarded to the other client. The IM communication can then proceed.

The message text is sent to the server and forwarded to the other client. How the message text is delimited depends upon the server and protocols being used; generally this will be a Hypertext Transfer Protocol (HTTP) or Extensible Markup Language (XML) in HTTP message encapsulated in the TCP connection with the server. When using SIP IM, the ability to send the message text directly between peers is configurable, but when using a SIP Proxy server configuration a server will be involved.

Voice and Video

Voice and video calls, another mode of communication and collaboration in Windows Messenger, require more than a server-mediated session. A peer-to-peer session is needed to avoid creating a bottle neck and introducing latency through the server. In this case, the servers and/or services are used to initiate the session setup and media type negotiation using SIP and SDP respectively. The Real-time Transport Protocol (RTP) is used over UDP for the actual voice or video streams.

The process for setting up an Audio/Video (AV) conversation between two clients (A and B), using Windows Messenger 4.0, is similar to the following:

  1. User A initiates an AV call to User B. This results in Windows Messenger sending a session invitation to the Windows Messenger Server, which is forwarded to User B.

  2. Windows Messenger on B notifies User B that there is an incoming call and gives User B the opportunity to accept or decline the call. If User B accepts the call, Windows Messenger will send an acceptance message to the server, which is forwarded back to Windows Messenger on A.

  3. Windows Messenger on A retrieves the network Internet Protocol (IP) address for User A's computer and a UDP port number to be used for SIP signaling. This can be the external, NAT-translated address for user A if a Universal Plug and Play- (UpnP) enabled gateway device is used. (See Windows Messenger in Windows XP: Issues With Firewalls and Network Address Translation Devices: https://www.microsoft.com/technet/prodtechnol/winxppro/deploy/worki01.mspx). Otherwise, this is the local interface address for A. This address is sent to the server along with a session acceptance. User A's Windows Messenger is also prepared to listen for incoming calls to this address and port.

  4. The server forwards the session acceptance to Windows Messenger on User B's computer. Windows Messenger will retrieve A's IP address and use this address to request a SIP session for the audio and/or video stream. This results in a SIP INVITE being sent to A. In this invitation B provides its own IP address and the ports it expects to receive the RTP stream (data) from A. This INVITE comes to A on the IP address that A sent to B in the acceptance message—possibly an internal address rather than the NAT-translated address. B will also start listening for incoming AV traffic, via RTP, on its local IP address and port number.

  5. A acknowledges the session invite to B, passing along information (in session description protocol) regarding its expectations for the conversation—including the dynamic ports for RTP streams. A final acknowledgement is sent from B to A; the session is now in place and the media destination addresses are known. UDP data streams can be sent between A and B.

With Windows Messenger 4.5, and a SIP-based service environment, the sequence above will be slightly modified. In this environment the initial session invitation is removed and the sequence starts with a SIP invitation. The sequence for this scenario is similar to the following.

  1. User A calls User B. This causes a session creation request, but in this case B is a SIP peer. This results in a SIP INVITE being sent to the SIP server. The SIP INVITE, contains information about the session, including A's address for the data stream.

  2. The SIP server resolves B's IP address and sends the INVITE to B. B receives the INVITE and the dialog is raised asking User B whether the call should be accepted or rejected. If User B accepts, an SIP OK message is sent back to A through the server containing B's AV stream data.

  3. A final acknowledgement is sent from A to B and the AV data can now be sent.

Application Sharing and Whiteboard

Application Sharing and Whiteboard, modes of communication and collaboration in Windows Messenger, start out the same as a voice or video session. The Rendezvous server is used to exchange the initial invitations, followed by a SIP invitation and acknowledgement in which the session information is exchanged. The differences between AV and Application Sharing and Whiteboard are:

  • The actual media exchange is done using T.120 over a TCP connection as opposed to UDP. This connection may be initiated by the one being called, as are many Windows Messenger calls.

  • The port used for the TCP connection is set at port 1503 on the called station.

File Transfer

File Transfer is a mode of communication and collaboration in Windows Messenger. A file transfer session, used when the client requests to send a file to a peer, is initiated similarly to AV and Application Sharing and Whiteboard—without the SIP invitation and acceptance exchange. Once the session is configured through the server, file transfer is accomplished using a TCP connection between the peers over a fixed range of ports.

Remote Assistance

Remote Assistance is a mode of communication and collaboration in Windows Messenger that uses Remote Desktop Protocol (RDP)—the same protocol used by Microsoft Terminal Services. RDP is built on top of a TCP connection. Windows Messenger sets up the Remote Assistance session using the server-based session invite logic; this is similar to File Transfer. The additional SIP INVITE signaling is only added if a voice session is added in support of Remote Assistance.

Appendix: Glossary of Acronyms Used

AV – Audio and Video

IM – Instant Messaging

ISP – Internet Service Provider

NAT – Network Address Translation

RDP – Remote Desktop Protocol

RTP – Real-time Transport Protocol

SDP – Session Description Protocol

SIP – Session Initiation Protocol

SSL – Secure Sockets Layer

TCP – Transmission Control Protocol

UDP – User Datagram Protocol

UPnP – Universal Plug and Play

Summary

This article discusses how Microsoft Windows Messenger in Windows XP communicates. It focuses on Microsoft .NET Messenger Service, Microsoft Exchange 2000 Instant Messaging Server and Session Initiation Protocol- (SIP) based server options for configuring the servers and services that provide for instant communication using Windows Messenger. Presence—the functionality in Windows Messenger used to determine the online status of contacts is covered, along with the various modes of communication and collaboration: Instant Messaging, Voice and Video, Application Sharing and Whiteboard, File Transfer and Remote Assistance.

For more information about Windows Messenger, its underlying protocols and standards, and how it functions with UPnP, NAT and firewall devices follow the links below:

Acknowledgements

Ann Demirtjis, Lead Program Manager, Microsoft Corporation

Imad Yanni, Product Manager, Microsoft Corporation

Michael Kessler, Technical Editor, Microsoft Corporation