SIP Makes Your Presence Known

The SIP proxy server also can make intelligent routing decisions. If a destination UA such as a SIP phone isn't available and sends a BUSY HERE signal (486), the proxy server can send the INVITE to a designated voicemail server, ring multiple endpoints simultaneously or follow a route determined by a unified messaging server's Find me, Follow me algorithm. It also advertises whether a UA is available to participate in a multimedia session such as a VoIP call, online chat or IM session and identifies the media types the UA can support, such as audio and video.

Once a multimedia session is established, SIP transfers the session to another endpoint (using call forwarding, for example), adds other endpoints to an existing session or modifies the parameters to include other multimedia data. When an endpoint sends a BYE message, SIP terminates the session by hanging up a phone or closing an IM application (for more on how SIP works, see It's Time To Take a Look At SIP ).

The SIP header fields include named attributes identifying the parties in a session, plus information about the message format, using the IETF's SDP (Session Description Protocol). An INVITE request, for example, includes a unique identifier for the call, the destination address (URI) and the type of session a UA wants to establish, such as an application or protocol.

With SDP, the body of a SIP message can contain details about a multimedia data-exchange session and a UA's ability to support the requested exchange. Either RTP (Real-Time Transport) or RTSP (Real-Time Streaming Protocol) will work for streaming audio and video because SIP operates independently of these protocols as well as the underlying transport.The IETF has created SIP extensions, such as UA events, that include a message stating, for example, whether a user is online and available. Even with these extensions, SIP remains simple to deploy and use. Avaya, Interactive Intelligence, Siemens and Zultys Technologies all support SIP extensions in their products.

SIP presence information describes a user's ability to communicate across endpoints (for details, see "The Skinny on SIP Presence" table below). A presence service is a client-server type of system--much like a Web application--that accepts, stores and distributes presence information. "Watchers" are users trying to find other target users to IM or speak with. Watchers must subscribe to the target user's presence information.

The presence service uses standard protocols such as XMPP (Extensible Messaging and Presence Protocol) or proprietary ones like Microsoft's Live Communication Server and AOL Messenger, which indicate a user's availability status.

Many enterprises are deploying SIP-based VoIP systems with proxy servers from suppliers such as Avaya, Interactive Intelligence, Siemens and others. SIP proxy servers already include location services with presence information such as SIP registration (a user agent's URI). SIP also can route SIP INVITE requests to any registered user on the same proxy server or to another server that can find a registered INVITE recipient. Since the registration state is a key component of user presence, SIP is an ideal protocol to set this up.

SIP extensions, on the other hand, use server-based tools that provide more specific presence information, like "in a meeting," "out to lunch," or "available but grumpy."These extensions use a PA (presence agent), a SIP-based software package like Microsoft's Live Communication Server 2005. The PA accepts and stores information about the target user. It also can send notifications to subscribers--when a user goes offline, for example. PAs are logical entities, meaning they are collocated with a SIP proxy server, and also come in standalone PSs (presence servers). (You can use the same URI as any other SIP request, such as sip:[email protected]).

PUA (presence user agent) software, such as Microsoft Communicator 2005 and Microsoft Windows Messenger manipulates presence information. Presence information changes when a user logs on or off the SIP endpoint, or when the user deploys the PUA to make these changes himself. That's akin to a user setting his or her IM client to offline mode to avoid being interrupted.

A user can have multiple devices, such as a PDA, laptop or cell phone, distributing his or her presence information. For each device, a PUA pushes presence information to PAs collocated with SIP proxy servers or included with standalone PSs.When an end user wants to determine another user's availability (his presence information), he or she requests that information. The request identifies the target user by the unique URI. Once the PA receives the request, it generates a response, such as "online, but needs coffee."

The PA then authenticates the subscription requester and authorizes the user's permission for the subscriber to receive presence information--this is what occurs when AOL Instant Messenger and other Internet IM services ask whether you want another user to know if you're online.

The PA sends the subscriber a SIP "200 OK" response if it's authorized to send the subscriber the user's presence information, or a SIP "202 Pending" response if it's not.

A PA must authenticate all SUBSCRIBE requests using digest authentication or another method outlined in RFC 3261. So when the user and subscriber are in the same domain, all subscribers will have shared secrets with the PA for authentication purposes. You get secure authentication when you combine digest authentication with TLS (Transport Layer Security).

Alternatively, in multiple domain settings where subscriptions and notifications traverse internetworks, authentication is established by trust relationships between proxy servers and PAs using TLS. (S/MIME also is used for user-to-user or peer-to-peer authentication to establish the identity of potential subscribers).SIP can be susceptible to DoS (denial of service) attacks, especially DDoS (distributed DoS) attacks. A SUBSCRIBE request can generate a healthy stream of notifications as long as there is a dynamic source of presence information available. An attacker can take advantage of this by sending SUBSCRIBE requests for large numbers of users and placing the target URI in the contact-header field, where the presence information notifications are to be sent.

Still, SIP can foil DDoS attacks by disregarding NOTIFY requests that are not acknowledged by the subscriber or and unwanted by the original subscriber. SIP's authentication and authorization schemes for potential subscribers also eliminate DDoS attacks.

DoS attacks can be mounted against PAs to disrupt presence information for multiple subscribers, too, but SIP protects itself against these SYN-attacks by using a four-way handshake with digest authentication. If a shared secret isn't available for a potential subscriber who is not on the local domain, SIP can still verify the source of the request using an "anonymous" user mechanism. SIP also enables server-side messages to clients to "back off" from sending requests using a 503 response code, which avoids a flood of SUBSCRIBE requests as long as the SIP client generating the flood adheres to the protocol standard.

SIP is not only an easy protocol for signaling and presence information, it also can protect itself from security threats. If you're ready to implement a presence-management strategy, SIP can help with applications such as IM, VoIP and videoconferencing, as well as document management and Web portals.

Sean Doherty is a senior technology editor and lawyer based at our Syracuse University Real-World Labs®. A former project manager and IT engineer at Syracuse University, he helped develop centrally supported applications and storage systems. Write to him at [email protected]. I recently felt the power of SIP-based presence in our Syracuse University Real-World Labs®, where I took Microsoft's Live Communication Server 2005 and its companion Communicator 2005 for a spin.

First, I installed LCS on a dual-processing Intel Xeon CPU (3 GHz) with 3 GB of RAM running Windows 2003 Server. In IETF parlance, LCS is a presence server that combines the activities of a PA (presence agent), a registrar server and a proxy server for SUBSCRIBE requests.

In my tests, LCS acted as a PA for two instances of Communicator 2005 running on Windows XP from an IBM Thinkpad T-41 and a Sony Vaio (PCG-R505ECP). LCS also exchanged SIP messages with a public IM provider and AOL Instant Messenger after I enabled Federation. (The Federation feature lets LCS exchange SIP messages and track the presence of users outside my skyey.nwc.com domain with AOL Instant Messenger).

To keep track of the SIP presence information and transactions, LCS must run on Microsoft SQL Server. I also used Active Directory for the users participating in the sessions. Once I prepped the forest and domain with LCS schema extensions and installed the requisite files (2 MB to 3 MB), I deployed a new tab in the Active Directory Users and Computers console (dsa.msc) that enabled Live Communications for users. I identified the SIP URI for the users "sdoherty" (sip:[email protected]) and "randerson" (sip:[email protected]) and associated them with the LCS enterprise pool I created during installation.

The enterprise pool, which is the PA, identified the SQL server instance for the presence information, and information on remote servers used to proxy SIP requests to remote servers. The PA also contained information for archiving IM sessions and tracking archive server resources via WMI (Windows Management Instrumentation) and Windows Performance Manager--so you can archive AOL IM sessions using LCS, for instance.The pool also dictates authentication for identifying users, such as NTLM (NT LAN Manager, Kerberos or both. I used NTLM and managed the pool resources as well as all aspects of LCS from a Microsoft Management Console. (See the screen.)

Once the server was up and running, I installed Communicator 2005 on the laptops. Communicator 2005 established and maintained presence for authenticated users via SIP signaling, but using Microsoft's implementation of the SIP standard.

I could view when "sdoherty" and "randerson" were online, offline or too busy for an IM session, telephone call, videoconference or sharing an application. But Communicator's SIP implementation fell short: I couldn't use Communicator to log into a Communigate Pro SIP server or an Asterisk 1.0.9 server, and I could only log into LCS using NTLM or Kerberos authentication and obtain presence information if my endpoints supported Windows APIs.

The advantage of using Microsoft Communicator as the platform for LCS is its integration with other Microsoft apps. For example, when the "sdoherty" Outlook calendar showed he had a meeting, LCS indicated over Communicator that he was unavailable while the meeting was in progress. Once the meeting was over, LCS automatically showed he was back online and available.