IBM WebSphere Developer Technical Journal: Session Initiation Protocol in WebSphere Application Server V6.1 -- Part 1

Introducing SIP

Session Initiation Protocol (SIP) has evolved to handle all sorts of rich collaboration, mobility, and media streams, and is gaining momentum as one of the most widely used standard protocols. This article introduces you to SIP, the SIP Servlet 1.0 programming model, and the SIP function that is introduced in IBM® WebSphere® Application Server V6.1.

Erik Burckart (ejburcka@us.ibm.com), WebSphere Application Server Lead Architect, IBM

Erik BurckartErik Burckart is a lead architect of the WebSphere Application Server product. He is a graduate from the University of Pittsburgh'’s School of Information Science, where he studied telecommunications, software development, and human computer interaction. Through his work with SIP servlets in WebSphere Application Server, he has joined the SIP Servlet 1.1 (JSR 289) Expert Group and has made numerous contributions in combining the state of the art Java EE platform with the latest SIP Servlet specification.



21 June 2006

Also available in Chinese

From the IBM WebSphere Developer Technical Journal.

Introduction

The Internet Engineering Task Force approved Session Initiation Protocol (SIP) as a formal Request for Comments (RFC) in 1999. Originally intended for use as a medium to negotiate video and audio media streams, SIP has become useful in many more scenarios, and has evolved to handle all sorts of rich collaboration, mobility, and media streams. SIP is gaining momentum as one of the most widely used standard protocols. This article includes an introduction to SIP, an introduction to the SIP Servlet 1.0 (Java™ Specification Request (JSR) 116) programming model, and a summary of the function that is now available in IBM WebSphere Application Server V6.1.

This article is targeted to audiences with a basic understanding of protocols over Internet Protocol (IP), particularly HTTP and SIP. Background knowledge of Java Platform, Enterprise Edition (Java EE) and HTTP servlets is helpful to understand all of the concepts discussed here.


Executive summary of SIP

Session Initiation Protocol (SIP) is an Internet Engineering Task Force (IETF) standard protocol that is defined in Request for Comments (RFC) 3261, and is quickly becoming the protocol of choice in many areas. SIP is being adopted as the control plane for the next generation of Internet Protocol (IP) telephony, instant messaging, Internet Protocol Television (IPTV), and many real-time collaboration activities. This protocol is part of the foundation of the 3rd Generation Partnership Project (3GPP) / IP Multimedia Subsystem (IMS) solutions for telecommunication carriers. SIP is also being evaluated as the control plane for many online gaming engines and other collaborative applications.

People often talk about triple or quadruple plays in the telecommunications-meets-enterprise realm. Triple play is the common term for the discussion of the voice, video, and data networks converging on Internet Protocol. Adding mobility as another factor makes it a quadruple play. SIP has become the popular protocol for convergence, as all of these networks converge onto IP. Using SIP, you can interconnect with others in new and exciting ways.

In the following sections, the high-level details of what the SIP protocol does are presented, with some illustrative sample flows. Also, a discussion of the extensions to SIP, which has helped to make the protocol more powerful, is also provided.


Introducing SIP

SIP was outlined in 1996 through a SIP charter and was formalized in RFC 2543 in 1999. When SIP was designed, the positives and negatives of the popular HTTP and Simple Mail Transfer Protocol (SMTP) were clearly considered. From those considerations, SIP was created as a text-based protocol to help negotiate interactive communication channels from one peer system or user to another. Expanding beyond connection negotiations, SIP is used to introduce new and exciting capabilities in the control plane.

Some of these new capabilities are vital to many uses of SIP today. Through the SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) IETF working group, SIP now has new capabilities to do presence and instant messaging. Presence is the function needed to publish a user's access points on the network and the capabilities of that user at each point of presence. Users and services can subscribe to the presence and capabilities of another user or group of users. These subscriptions enable the initiation of communication to the correct access point over the correct medium, based on capabilities.

For the core SIP capability, the flows around the INVITE method are the most frequently used and therefore, are perhaps the most important to the base product. The idea is that one entity wants to initiate communication to another entity, and sends an INVITE to a communication session (Figure 1).

Figure 1. INVITE method for initiating communication
Figure 1. INVITE method for initiating communication

Through the SIP messages, the two peers initiate a communication session. Often, these sessions negotiate another protocol connection using syntax such as the Session Description Protocol (SDP), as defined by RFC 2327. SDP is not really a protocol, but rather a message syntax that can describe another protocol connection. For example, in voice connections of applications such as IP telephony, the protocol negotiated with SDP in a SIP message is often Real-Time Protocol (RTP), which is defined in RFC 3550.

The SIP messages are transferred over User Datagram Protocol (UDP), Transmission Control Protocol (TCP), or Stream Control Transmission Protocol (SCTP) transports. Depending on the nature of the protocol and the reliability and speed required, different transports are used. Typically, select application types use specific transports as their de facto standard. For example, IP telephony applications typically use a UDP transport, whereas instant messaging typically uses TCP.

Basic SIP INVITE flows

To better understand the protocol, it is helpful to understand the basic INVITE flows to see how the messages are passed back and forth throughout the infrastructure.

This basic INVITE flow (Figure 2) has user@ibm.com initiating a call with user@example.com. Each SIP request, such as INVITE, includes a SIP address (or Uniform Resource Locator (URL)), which the INVITE is sent to. That URL is the primary way that the message is routed. For this example, the SIP address passed is user@example.com. The SIP address uniquely identifies a user during the creation of a communication session. The address normally resembles an e-mail address and includes the sip:prefix. For example, the actual SIP address that is used in the INVITE message shown previously is sip:user@example.com.

Figure 2. INVITE flows
Figure 2. INVITE flows

The device that initiates this session for user@ibm.com is called a user agent client. A user agent client (UAC) is formally defined in SIP as an endpoint that can create and manage SIP sessions. User Agents (UA), either clients (UAC) or servers (User Agent Server or UAS), can be a SIP telephone or a server somewhere in the transaction, and can also independently negotiate session capabilities. The UAC initiates the session and the UAS will accept the session.

The SIP message is passed to the local SIP proxy at ibm.com. The SIP proxy at ibm.com has to locate the example.com server to forward the request onto example.com. The preferred way to do this task is described in RFC 3263, Locating SIP Servers. In this standard, a way to locate the SIP servers using Domain Name System (DNS) Naming Authority Pointer (NAPTR) records is described, which is similar to the way mail is routed with SMTP. The ibm.com server looks up the NAPTR record for example.com and forwards the INVITE message to that example.com server.

After the ibm.com proxy sends the INVITE, the proxy sends a provisional or information response. In this scenario, it is proper for the server to send a Trying response with a response code of 100. In this particular case, this Trying response indicates to the client that the ibm.com proxy has accepted the connection and will try to send the request on to the next location. The server uses these 1xx responses, called provisional responses, to communicate progress for a SIP transaction. In RFC 3262, a mechanism was developed to ensure that the responses are sent reliably and acknowledged alone so that the status of the call is not lost if the transport protocol is something like UDP.

After the INVITE message is received by the example.com proxy, the example.com server typically uses the entire Uniform Resource Identifier (URI) to look up where the user is located or to find a registrar that provides an exact IP address to initiate a connection. In this case, the user@example.com defines a specific user that is invited to this session. In cases where this user is behind a Network Address Translation (NAT) firewall, Simple Traversal of UDP through NATs (STUN), Traversal Using Relay NAT (TURN), and Interactive Connectivity Establishment (ICE) Firewall traversal mechanisms are often used to create the connection from the example.com server to the client. After the connection is made to the client, the server sends the INVITE message to the client and a provisional response (Trying) back to the client that sent the message.

If the user@example.com UAS that is contacted is trying to alert the user, the UAS often responds to the INVITE request with a provisional response code of 180, which indicates this progress. This response is often sent all the way back to the client initiating the SIP transaction and might also be used by the user@ibm.com UAC to start a local ringback.

When the user@example.com UAS accepts the call, the final response code of 200 is sent back notifying user@ibm.com that the call is accepted. This message flows through each of the network elements that the initial INVITE came over.

After the user@ibm.com UAC receives the 200 OK response, the UAC sends an acknowledgement back to the user@example.com UAS so that it knows the 200 response was received. If the proxy servers in the initial transaction flows have added themselves to the transaction through requests to record the route, the acknowledgement is sent through those servers.

Assuming the use of a protocol like SDP, the two clients have negotiated a successful session with one another to communicate over another protocol. When that protocol session is complete, the user agents close out the SIP session with one another. The UAS initiates the closing by sending a BYE message over the same route that the acknowledgement came over and the other user agent acknowledges this message by sending a 200 OK response.


Introducing the SIP Servlet 1.0 (JSR 116) and comparing it to HTTP servlets

The SIP Servlet 1.0 specification is standardized through Java Specification Request (JSR) 116. The idea behind the specification is to provide a Java application programming interface (API) similar to HTTP servlets, which provides an easy-to-use SIP programming model. Like the popular HTTP servlet programming model, some flexibility is limited to optimize ease-of-use and time-to-value.

However, the SIP Servlet API is different in many ways from HTTP servlets because the protocol is so different. While SIP is a request-response protocol, there is not necessarily only one response to every one request. This complexity and a need for a high performing solution meant that it was easier to make the SIP servlets natively asynchronous. Also, unlike HTTP servlets, the programming model for SIP servlets sought to make client requests easy to create alongside the other logic being written, because many applications act as a client or proxy to other servers or proxies.

SIP servlets

Like HTTP servlets, each SIP servlet extends a base javax.servlet.sip.SipServlet class. All messages come in through the service method, which you can extend. However, because there is not a one-to-one mapping of requests to responses in SIP, the suggested practice is to extend the doRequest or doResponse methods instead. When extending the doRequest or doResponse methods, it is important to call the extended method for the processing to complete.

Each request method, which the specification must support, has a doxxx method just like HTTP (Figure 3). In HTTP, methods such as doGet and doPost exist for GET and POST requests. In SIP, doInvite, doAck, doOptions, doBye, doCancel, doRegister, doSubscribe, doNotify, doMessage, doInfo, and doPrack methods exist for each SIP request method.

Figure 3. Comparing HttpServlet and SipServlet
Figure 3. Comparing HttpServlet and SipServlet

SIP servlets include the doProvisionalResponse, doSuccessResponse, doRedirectResponse, and doErrorResponse responses. Specifically, the provisional responses (1xx responses) are used to indicate status, the success responses (2xx responses) are used to indicate a successful completion of the transaction, the redirect responses (3xx responses) are used to redirect the client to a moved resource or entity, and the error responses (4xx, 5xx, and 6xx responses) are used to indicate a failure or a specific error condition. These types of response messages are similar to HTTP, but because the SIP Servlet programming model includes a client programming model, it is necessary to have responses handled programmatically as well.

SipServletRequest and SipServletResponse classes

The SipServletRequest and SipServletResponse classes are similar to the HttpServletRequest and HttpServletResponse classes. Each class gives you the capability to access the headers in the SIP message and manipulate them. Because of the asynchronous nature of the requests and responses, this class is also the place to create new responses for the requests. When you extend the doInvite method, only the SipServletRequest class is passed to the method. To send a response to the client, you must call the createResponse method on the Request object to create a response. For example:

protected void doInvite(SipServletRequest req) throws
 javax.servlet.ServletException, java.io.IOException {
	
	//send back a provisional Trying response
	SipServletResponse resp = req.createResponse(100);
	resp.send();

Because of their asynchronous nature, SIP servlets can seem complicated. However, something as simple as the previous code sample sends a response to a client.

Here is a more complex example of a SIP servlet. With the following method included in a SIP servlet, the servlet blocks all of the calls that do not come from the example.com domain.

protected void doInvite(SipServletRequest req) throws
 javax.servlet.ServletException, java.io.IOException {

	//check to make sure that the URI is a SIP URI
	if (req.getFrom().getURI().isSipURI()){
            SipURI uri = (SipURI)req.getFrom().getURI();
            if (!uri.getHost().equals("example.com")) {
               //send forbidden response for calls outside domain
               req.createResponse(SipServletResponse.SC_FORBIDDEN).send();
               return;
            }
         }
         //proxy all other requests on to their original destination
         req.getProxy().proxyTo(req.getRequestURI);
   }

In the previous example, the INVITE request that comes in is checked to ensure that this request is coming from the example.com domain. If it is not, an error response is returned, indicating that this request is forbidden. If the request is coming from the example.com domain, the request is proxied onto the next application or host.

Another important point to realize from the previous example is that SIP servlets have the option of proxying a request instead of responding or creating a new request. This option is important when trying to quickly get into the flows of the message without significantly altering the behavior.

SipSession and SipApplicationSession classes

Possibly the most complex portions of the SIP Servlet 1.0 specification are the SipSession and SipApplicationSession classes. Both of these classes have some useful purposes and can act as the primary place to store data in applications that are designed for distributed or highly available environments.

The SipSession class is the best representative of a specific point-to-point communication between two entities and is the closest to the HttpSession object. Because historically no proxying or forking existed for the HTTP request in HTTP servlets, the need for something higher than a single point-to-point session did not exist. However, even HTTP users can see the growing need for this type of function, since portlets began essentially forking HTTP requests. The SIP users expect the proxying and forking activities that require multiple layers of SIP session management. The SipSession class is the lowest point-to-point layer.

The SipApplicationSession class represents the higher layer of SIP session management. One SipApplicationSession class can own one or more SipSession objects. However, each SipSession class can be related to one SipSession object only. The SipApplicationSession class also supports the attachment of any number of other protocol sessions. Currently, only HTTP sessions are supported by any implementations. The SipApplicationSession class has a getSessions method,which takes the requested protocol type as an argument.

You might find it useful for many applications to combine HTTP and SIP. The authors of the SIP Servlet 1.0 specification realized the advantages of this combination. For example, you might use this approach to tie together HTTP and SIP sessions to monitor a phone call or to start a phone call through a rich HTTP graphical user interface (GUI).

More from the SIP Servlet specification

The SIP Servlet 1.0 specification has a lot of pieces, which can be useful, depending on the goal of the application developer. Some of these sections include application composition, the SipFactory API, and a lot of event listeners to handle events in the protocol handling.

Application composition is a complex portion of the SIP Servlet 1.0 specification that enables multiple applications to run on the same request message. Like the HTTP servlet model, the SIP servlets include a deployment descriptor to define the servlet to the container within which the servlet runs. However, because the application does not map to a definitive URI, multiple servlets can run on one request message. Each initial message (one the container has no prior knowledge of) gets matched against the set of rules in the deployment descriptor and invokes the applications based on those configured rules. Responses and subsequent requests follow the same path of that initial request.

Another valuable API in the SIP Servlet specification is the SipFactory API, which provides access to create more requests and sessions from within a servlet. This API is useful when writing functions such as a back-to-back user agent (B2BUA). Unlike a proxy that forwards on the requests, a B2BUA acts as both a user agent server (UAS) and a user agent client (UAC) to further participate in the SIP transaction. The UAS portion can receive and process the requests, while the UAC determines how to initiate one or more associated outbound calls.

The SipFactory API is also useful for invoking new requests out of the container when accessed through another type of service. Although one current limitation of the SipFactory API is that it is only available in the ServletContext object, you can use the SipFactory API to perform functions as a UAC, such as third-party-call setup. Because the SIP servlet container typically resides within a Java EE environment, you can write a Web service or enterprise bean that uses the SipFactory API to create application sessions and requests for other SIP entities.

Other parts of the API include:

  • ServletConfig: A mechanism used by the container to pass configuration information to the servlet on initialization.

  • ServletContext: The primary mechanism to communicate with the container and store attributes for the servlet. Also, this is currently how you access the SipFactory API.

  • SipAddress: The address from the SIP From and To header.

  • Proxy: A useful API when trying to query or change how the container proxies on a SIP request.

SIP Servlet examples

SendOnServlet class

This class is a simple SIP Servlet which would perform the basic function of being called on each invite and sending the request on from there. Function could easily be inserted here to log this invite request or reject the INVITE based on some specific criteria.

package com.example;
import java.io.IOException;
import javax.servlet.sip.*;
import java.servlet.ServletException;
public class SendOnServlet extends SipServlet {
  public void doInvite(SipServletRequest req) 
       throws ServletException, java.io.IOException {
     //send on the request
     req.getProxy().proxyTo(req.getRequestURI);
  }
}

The doInvite method could be altered to do something such as simply reject the invite for some specific criteria. In the example doInvite method below, all requests from domains outside of example.com will be rejected with a Forbidden response.

public void doInvite(SipServletRequest req)
	throws ServletException, java.io.IOException {
	if (req.getFrom().getURI().isSipURI()){
	   SipURI uri = (SipURI)req.getFrom().getURI();
	   if (!uri.getHost().equals("example.com")) {
		//send forbidden response for calls outside domain
		req.createResponse(SipServletResponse.SC_FORBIDDEN,
			"Calls outside example.com not accepted").send();
		return;
	   }
	}
	//proxy all other requests on to their original destination
	req.getProxy().proxyTo(req.getRequestURI());
   }

SendOnServlet deployment descriptor

<sip-app>
    <display-name>Send-on Servlet</display-name>
    <servlet>
        <servlet-name>SendOnServlet</servlet-name>
        <servlet-class>com.example.SendOnServlet</servlet-class>
    </servlet>

    <servlet-mapping>
        <servlet-name>SendOnServlet</servlet-name>
        <pattern>
              <equal>
                <var>request.method</var>
                <value>INVITE</value>
              </equal>
        </pattern>
    </servlet-mapping>
</sip-app>

Proxy servlet

This class is a simple SIP Servlet which would perform the basic proxy function and be included in the call path after the initial INVITE request. After the initial INVITE, this application will be called on every subsequent SIP message. For each Request and Response, this class will simply print out the action and who it is to or from.

package com.example;
import java.io.IOException;
import javax.servlet.sip.*;
import java.servlet.ServletException;
public class ProxyServlet extends SipServlet {
  public void doInvite(SipServletRequest req) 
       throws ServletException, java.io.IOException {
     //get the Proxy
     Proxy p=req.getProxy();
     //turn on supervised mode so that all events come through us
     //The default on this is true but it is set to emphasize the function.
     p.setSupervised(true);     
     //set record route so we see the ACK, BYE, and OK
     p.setRecordRoute(true);
     //proxy on the request
     p.proxyTo(req.getRequestURI());
  }
public void doRequest(SipServletRequest req)
     throws ServletException, java.io.IOException {
   System.out.println(req.getMethod()+ 
	"Request from "+req.getFrom().getDisplayName());
   super.doRequest(req);
}
public void doResponse(SipServletResponse resp)
     throws ServletException, java.io.IOException {
   System.out.println(resp.getReasonPhrase()+ 
	"Response from "+resp.getTo().getDisplayName());
   super.doResponse(resp);
}
}

Proxy deployment descriptor

<sip-app>
    <display-name>ProxyServlet</display-name>
    <servlet>
        <servlet-name>ProxyServlet</servlet-name>
        <servlet-class>com.example.ProxyServlet</servlet-class>
    </servlet>

    <servlet-mapping>
        <servlet-name>ProxyServlet</servlet-name>
        <pattern>
              <equal>
                <var>request.method</var>
                <value>INVITE</value>
              </equal>
        </pattern>
    </servlet-mapping>
</sip-app>

WebSphere Application Server V6.1 with SIP support

WebSphere Application Server V6.1 is an industry leading Java Enterprise Edition (Java EE) application server with open standards-based extensions built on Java SE 5. These extensions include portlets (JSR-168), service data objects (SDOs), JavaServer Faces (JSF), asynchronous beans, caching support, and many other APIs bringing value beyond the base Java EE environment. Also included is IBM's industry-leading Web services support for many specific specifications, such as WS-Security, WS-TX AT, WS-N, and WS-BA. WebSphere Application Server also supports IPv6 and Common Criteria.

WebSphere Application Server V6.1 integrates SIP functionality into the foundation, providing industry-leading converged application support. The SIP application support in WebSphere Application Server is achieved through an implementation of the SIP Servlet 1.0 specification, as discussed in the previous session. In WebSphere Application Server, the Web container and SIP container are converged and are able to share session management, security, and other attributes (Figure 4). In this model, an application that includes SIP servlets, HTTP servlets, and portlets can seamlessly interact, regardless of the protocol.

Figure 4. WebSphere Application Server converged container handling HTTP servlets, portlets, and SIP servlets
Figure 4. WebSphere Application Server converged container handling HTTP servlets, portlets, and SIP servlets

High availability, offered by WebSphere Application Server Network Deployment, of the converged applications is made possible because of the tight integration of HTTP and SIP in the base application server. In front of a clustered application sits the Proxy server, managing the traffic and workload of the SIP and HTTP traffic to the Container. This Proxy Server is a stateless SIP proxy and a HTTP reverse proxy together, which uses the unified clustering framework and high availability manager services of the Network Deployment package to seamlessly monitor the health of the servers and failover work, when necessary (Figure 5). The Proxy server also can act as a standalone stateless SIP proxy in front of the SIP container in the application server when no HTTP traffic is present.

Figure 5. WebSphere Application Server proxy server handles SIP and HTTP
Figure 5. WebSphere Application Server proxy server handles SIP and HTTP

With the converged proxy and converged container, session failover is done with affinity to the application, enabling the HTTP and SIP sessions to be tied together automatically. Having the SIP and HTTP sessions automatically tied together from the container to the Proxy is another way the WebSphere Application Server V6.1 solution excels in converged environments.

For the SIP function in the Proxy server, it is important to understand that it is stateless. The SIP RFC defines two types of Proxy Servers, one stateful and one stateless. Normally, a SIP Proxy is a stateful instance and stateless proxies are specified as such. A stateful proxy participates in the call flows as we had seen in the example from the SIP overview. A stateful proxy can be implemented using SIP servlets, as was shown in the a basic example in the SIP Servlet section.

The stateless SIP proxy functionality in the Proxy server enables the Proxy to handle the workload, routing, and session affinity needs of the SIP container with less complexity. Being stateless, the Proxy server can be fronted by a simple IP sprayer, such as the Load Balancer component included in WebSphere Application Server Network Deployment (Figure 6). If a Proxy Server fails, the affinity is to the container and not to the proxy itself so there is one less potential failure along the message flow.

Figure 6. Stateless SIP proxy functionality
Figure 6. Stateless SIP proxy functionality

WebSphere Application Server Development Tools

WebSphere Application Server includes an Eclipse- based Application Server Toolkit (AST) to meet all the basic development needs for Java EE applications. Support for developing SIP servlet applications is included in the AST for the Version 6.1 release. This toolkit provides graphical deployment descriptor editors and basic wizards to get you started writing SIP servlets (Figure 7).

Figure 7. SIP servlet development support in AST 6.1
Figure 7. SIP servlet development support in AST 6.1

AST also includes many other pieces that integrate well in WebSphere Application Server deployments, including the Unit Test Environment, which provides the WebSphere Application Server servlet container to run SIP servlets in the development phase of the product, plus other tools for server automation and application packaging.


Conclusion

Session Initiation Protocol (SIP) has grown a lot since it first became an IETF standard in 1999. SIP was originally intended purely for video and audio and now has grown as the control protocol for many interactive services, particularly in the peer-to-peer realm. SIP and the standards surrounding SIP provide the standards-based mechanisms to look up, negotiate, and manage connections to peers on any network over any other protocol.

WebSphere Application Server V6.1 delivers rich SIP functionality throughout its infrastructure. Using Version 6.1, you can write applications utilizing the SIP Servlet 1.0 specification, which was introduced to enable enterprise applications to use SIP and to support SIP predominant applications in the exploitation of the extensive work put into the Java EE environment.

WebSphere Application Server also provides tooling for the development environment and high performing edge components to handle distributed application environments. The SIP components in WebSphere Application Server have a tight integration with the existing HTTP servlet and portlet work, with which you can write a highly converged HTTP and SIP application with seamless failover provided by the Proxy Server.


More in this series

Resources

Learn

Get products and technologies

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=132439
ArticleTitle=IBM WebSphere Developer Technical Journal: Session Initiation Protocol in WebSphere Application Server V6.1 -- Part 1
publish-date=06212006