Real Time Communications in .NET

1. Introduction

This white paper shares concepts of real time communications in .Net and its applicability in real world. A real-time communication system is used in applications where time is a critical factor.

1.1 Application Scenarios for Real Time Communications
There are two classes of applications: client and server. Client class applications have one real-time client per computer, such as the traditional instant messenger (IM) application. Server class applications typically act on behalf of multiple users or communicate with many hundreds of users simultaneously. Server class applications are often based around intelligent applications that interact with users. These applications can be divided into two categories: notification Apps that send information to a client and interactive Apps that accept and respond to a client. A third type of server class applications, Web-based clients, interacts with users through a Web server.

1.2 Notification Applications
Notification Apps are real-time applications that send information to multiple clients from a centralized server (see Figure 1). The one-way transmission means that clients cannot communicate directly with the notification App. Instead, clients must choose which events they wish to receive by using some other technique, such as a Web application.

One example of a notification App is an application that notifies all of the users of a particular e-mail server that the server is about to go offline. Another useful notification App would send alerts in cases of severe weather.



Figure 1. A notification App transmits information to multiple IM clients.

1.3 Interactive Apps
Interactive Apps are applications that allow multiple clients to communicate with a central server in real-time, as Figure 2 shows. They are different from notification bots in that interactive bots support two-way communications with a client. Using this approach, you can build an application that interacts with users in real-time. Within this scenario, there are two main sub-scenarios. The first provides a user with information and waits for the user to respond, such as an application that notifies users about changes in stock prices and then gives the user the option to buy or sell. The second waits for the user to request a session with the App and then responds to requests that the user supplies, such as a calendar application that allows a user to schedule meetings and other events while receiving reminders just prior to the meeting or event.



Figure 2. An interactive App receives and responds to requests from multiple IM clients.

1.4 Web-Based Clients
Web-based clients provide the same basic functionality as the traditional IM client through a Web interface, thus allowing the widest possible audience to use the application, as Figure 3 illustrates. It also has the side effect of eliminating the need for a user to download local software, which reduces user concerns about the download containing a potential virus. These types of clients are useful to organizations that wish to provide a Web-based front end to their internal IM system. For example, a company might wish to use a Web-based IM client to connect customers with a support group. Doing so maximizes the number of customers that can connect with the support group.



Figure 3. A Web-based client hosts multiple IM clients on a single machine by using a Web server to handle the user interface tasks

2. Real Time Communications Data Flow

2.1 RTC Client API's



It's critical that organizations planning large deployments of real-time communications applications ensure that those applications can scale to meet the desired goals. The RTC Client API is very efficient for client class applications for which each client runs on its own computer. To build a scalable RTC Client API application that services multiple clients with a single computer, you need to ensure that the application is scalable when you design it.

The Real-time Communications (RTC) Client API is a set of COM interfaces and methods designed to create PC-PC, PC-phone, phone-phone audio/video calls, or text-only Instant Messaging (IM) sessions over the Internet. Application sharing and whiteboard (An application that displays a window for two users to exchange information) can also be added to PC-PC sessions. Presence information is used to track the location of buddies (or contacts) for communication purposes. This information is available through the RTC Client API on a SIP registrar server.

The RTC Client API:

• Supports multiparty phone-phone calls
• Uses SIP-based signaling and presence communications
• Integrates with the Microsoft Office RTC proxy and registrar server
• Supports provisioning with ITSPs or third-party corporate-deployed servers
• Integrates signals over IP and PSTN networks

2.2 General Requirements
The following table shows the media types and participants allowed for each type of session. For a PC-PC session, the media type can be audio, video, or both. Application sharing and whiteboard can also be added to this session. The phone-phone session is a third-party call initiated from a third-party computer, which can be an ITSP or a corporate-deployed third-party server. For more information on the session requirements, see the Session Information and Server Requirements topics.



2.3 Session Information
A session is initiated via the SIP proxy server if the URL entered in is e-mail or a telephone number. If the IP address or machine name is entered, a direct communication link is set up and the SIP proxy is not required.



2.4 Session Initiation Protocol

SIP, the Session Initiation Protocol, is a signaling protocol for Internet conferencing, telephony, presence, events notification and instant messaging.
SIP provides the necessary protocol mechanisms so that end systems and proxy servers can provide services:

• call forwarding, including
  • the equivalent of 700-, 800- and 900- type calls
  • call-forwarding no answer
  • call-forwarding busy
  • call-forwarding unconditional
  • other address-translation services
• callee and calling "number" delivery, where numbers can be any (preferably unique) naming scheme.
• personal mobility, i.e., the ability to reach a called party under a single, location-independent address even when the user changes terminals.
• Terminal-type negotiation and selection: a caller can be given a choice how to reach the party, e.g., via Internet telephony, mobile phone, an answering service, etc. 
• terminal capability negotiation 
• caller and callee authentication
• blind and supervised call transfer 
• Invitations to multicast conferences.

Extensions of SIP to allow third-party signaling (e.g., for click-to-dial services, fully meshed conferences and connections to multipoint control units (MCUs), as well as mixed modes and the transition between those) are available.

SIP addresses users by an email-like address and re-uses some of the infrastructure of electronic mail delivery such as DNS MX records or using SMTP EXPN for address expansion. SIP addresses (URLs) can also be embedded in web pages. SIP is addressing-neutral, with addresses expressed as URLs of various types such as SIP, H.323 or telephone (E.164).

SIP can also be used for signaling Internet real-time fax delivery. This requires no major changes. Fax might be carried via RTP, TCP (e.g., the protocols discussed in the Internet fax WG) or other mechanisms.

SIP is independent of the packet layer and only requires an unreliable datagram service, as it provides its own reliability mechanism. While SIP typically is used over UDP or TCP, it could, without technical changes, be run over IPX, or carrier pigeons, frame relay, ATM AAL5 or X.25, in rough order of desirability.

2.5 Real Time Communications Server

The RTC Client API enables you to build applications that can make PC-PC, PC-phone, or phone-phone calls or create Instant Messaging (IM) sessions over the Internet. The RTC Server API allows you to create managed SIP applications that interoperate with Microsoft Live Communications Server 2003.

3. Real Time communications Server Architecture



3.1 Server Requirements

For PC-PC and IM sessions
If the SIP URL is e-mail, a SIP proxy server can be used to initiate the session. If a SIP server is not available, the client can perform a DNS lookup to find the location. If the address type is IP or machine name, a proxy server is not needed to initiate or maintain the call.

For PC-phone sessions
The presence of the TEL URL requires a SIP-PSTN gateway server. An ITSP can determine the gateway into the PSTN or the gateway information can be included in the provisioning profile.

For phone-phone sessions
Only third-party calls-where a computer initiates the call-are supported for this type of session. The ITSP or third-party corporate-deployed server connects the call between two or more PSTN devices. This type of call can be routed over the PSTN entirely or partly over the PSTN and partly over the Internet.

Presence information
All session types can take advantage of presence information on other users. A SIP registrar server is required when presence information is desired. Users can register their presence information with the server and retrieve the presence information of others with this service.

3.2 Main Advantages of RTC Server

• AD Integration
• Transport Layer Security (TLS) connections
• Audio/Video privacy using RTP/RTCP encryption
• Kerberos and NTLM for client authentication
• Familiar Windows based management tools - WMI/MMC/MOM
• Manage users, servers, and global settings
• Group Management of Clients
• SDK for Clients and Servers enable the building of compelling apps and solutions - creating a broad ecosystem
• Supporting a Store, Registrar, and a high-end Presence Engine
• Access to the SIP routing engine
• SIP provides a bridge from IM signaling to richer multimodal signaling
• SIP is transport, network and device neutral
• SIP is used in next generation carrier and mobile networks, extension to the Enterprise is natural and interoperable

3.3 Current challenges

• Encrypting data to protect trade secrets
• Integration with corporate directory
• Non-functional availability options (offline/out to lunch)
• Non-IETF services/Interoperability
• Verification of digital identity
• MSN: user@domain.tld
• YAHOO: anything@yahoo.com
• AOL:anything
• Security & manageability issues force
• Enterprises to shut down public IM connections
• Public IM Moves as clear text across the firewall
• Has been an entry point for viruses and software conflicts
• Not integrated with your namespace or authentication

4. Approach

4.1 Sample .Net Application

Consider a web application for a company which has to convey messages to all its employees who are logged into the MSN messenger. We assume that all users are on one contiguous network. Remote user has full access via VPN. The client uses HTTPS to tunnel SIP and SOAP. If there is any organizational level message to be sent across all the users then one application which has all the users subscribed to it can be used to send the message. MSN messenger should use communications service in the options provided and provide the proper SIP address.

The application internally uses RTC client API's to get logged on to the RTC server. Then any message to be sent across to the users can be sent as text message. The RTC server in turn routes these messages to the users subscribed to it. This approach can be expanded according to the needs of the organization.