![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Session Initiation Protocol (SIP) Servlet 1.0 support (JSR 116) was added into IBM WebSphere Application Server for the first time in Version 6.1. Since then, there has been an increase in SIP functionality and a lot of questions about the details. Below are some of the most common questions I hear concerning our SIP Servlet 1.0 support, along with links to some good reference material to help you answer many others.
What release of WebSphere Application Server has SIP servlet functions?
IBM WebSphere Application Server V6.1 has standalone SIP servlet support in the base and Express editions with no high availability support. WebSphere Application Server V6.1 Network Deployment has high availability including the stateless SIP proxy, which provides session affinity support for the application server instances. WebSphere Application Server V7 also has SIP servlet capabilities.
Does WebSphere Virtual Enterprise and WebSphere eXtreme Scale include SIP capabilities?
Yes, both products offer capabilities for SIP deployments of the application server.
WebSphere Virtual Enterprise adds functionality into the SIP proxy and application server, which increases the ease of management and qualities of service that the base WebSphere Application Server provides. One feature of WebSphere Virtual Enterprise that enhances the management capabilities for SIP applications is the ability to seamlessly upgrade an application while still supporting sessions on the existing application. Another feature is an intelligent admission control function that is able to monitor resources on the backend application server and manage different service policy and quality levels per user session to ensure that the proper decisions to maintain end to end latency targets are met. Many other features of WebSphere Virtual Enterprise apply to all applications and application servers, such as visualization, application placement, and server health management.
WebSphere eXtreme Scale offers a better quality of service for SIP session replication. It also gives you many more options with respect to the design of your high availability topology than base WebSphere Application Server. For better qualities of services, WebSphere eXtreme Scale offers asynchronous and synchronous replication, which enables the replication between sessions to be guaranteed if that level of service is desired.
Can you tie EJB affinity to SIP affinity?
For stateless session beans (SLSB), there is no affinity or affinity mechanism and so we cannot tie a SLSB request into SIP affinity. For stateful session beans (SFSB), the state is maintained after the first access to the bean. This means that the primary use case for this would be when the SFSB initiates a dialog and wants to, perhaps, expose actions on that dialog.
In that case, where the SFSB creates the dialog, it is possible to ensure that the SFSB is always called on the same machine that owns the SIP dialog. Our SFSB implementation in WebSphere Application Server uses Data Replication Service (DRS) as does SIP. The common setup for SIP DRS is to simply have two servers per replication domain, essentially a peer to peer replication only. This would be the required setup in order to achieve this SIP-SFSB tie. Then, if you set up the SFSB replication domains the same way, the stateful bean will always be on the same machine as the dialog it initiated. If a failover occurs, both the SFSB and SIP Session will failover to the single peer in its replication domain.
Do you support the X standard?
There are a variety of standards that we implement and for which we test. We list them all in our product Information Centers (see Resources). We actually break our list of standards into two groupings:
- The first are standards that we support and for which we test. These standards might still require some action by the application to ensure compliance, but since they required a change to our container or proxy server, we did test for them to ensure compliance. However, this is not the complete list of all that is possible with WebSphere Application Server.
- There is another table of standards that the application can support on top of WebSphere Application Server without changes to the application server. Many of the IETF standards that keep coming out do not require changes in the application server, but do require application changes to adhere to the specification when running on the application server.
Can we modify the system headers on a SIP message?
Although this is not permitted by the JSR 116 specification, we have received multiple requests for such function. A custom property called enable.system.headers.modify can be configured on an SIP container and will enable the application to modify headers that they would otherwise be unable to change. More information on how to configure this is available in the WebSphere Application Server Information Center.
Do you have any published performance numbers for SIP in WebSphere Application Server?
Currently there is not an available performance benchmark for SIP servlet application servers, which means that comparing the performance of one application server is very difficult with respect to another, based on the current data available. In a press release from a year ago we announced the following performance information:
| "WebSphere Application Server 6.1.0.11 using Red Hat Linux and integrated in the IBM BladeCenter HT chassis, which is network equipment building systems (NEBS) compliant, has achieved an industry leading SIP performance measurement of 1296 calls per second, using a 13 message SIP call model (with 80 second hold time) which translates to over 4.6 million busy hour call attempts per blade. Using this call model, in a high availability, carrier-grade configuration, WebSphere Application Server achieved 660 calls per second per blade with session replication. These results were achieved while retaining extremely low end-to-end SIP message processing latency of under 50 milliseconds ninety five percent of the time. This exhibits the ability of WebSphere Application Server to handle the call volumes businesses demands while ensuring service quality." |
This was all done on an HS21 XM Blade, which is a two CPU quad core 2.33 GHz system. At this time, performance numbers for WebSphere Application Server V7 are not available.
What new function was added into WebSphere Application Server V7 for SIP?
For starters, we added support for the following RFCs:
- 3263 - Locating SIP Servers
- 3311 - The SIP Update method
- 3325 - Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
- 3891 - The SIP Replaces Header
- 3911 - The SIP Join Header
- 4475 - SIP Torture Test Messages
WebSphere Application Server V6.1 supported RFC 3263, with the exception of section 5; support of section 5 is now complete in WebSphere Application Server V7. The outstanding RFC, SIP “torture test” messages, refers more to a testing effort than function. This testing, combined with our already rigorous telco carrier grade testing, helps WebSphere Application Server V7 be one of the most stable SIP application servers on the market.
Beyond the additional standards support, our SIP proxy that fronts the application server had several enhancements. It can now support DMZ deployments as discussed here, clustering of the proxy servers when behind the firewall, and improved load balancing to further reduce call loss in some error conditions associated with re-transmissions. In our converged servlet container, users will notice that the digest authentication support has been integrated more cleanly into WebSphere Application Server V7 than it was in Version 6.1.
Are HTTP and SIP sessions survivable together?
As described in the second part of this article, HTTP and SIP sessions are tied together and failover together in a converged application. So, regardless of whether an HTTP or SIP message comes in first after a failover occurs, they will be routed to the same machine.
That said, there is a fundamental difference between HttpSessions and SipSessions. SIP, because of the nature of the protocol, has to have an “active” failover whereas HTTP failover is commonly more passive. While the HttpSession need not be accessed until a new HTTP request comes in, the SipSession might have timers associated with it and will need to be activated immediately on failover. This means that objects in the HttpSession might not be deserialized on the new container until they are accessed, while objects in an SipSession will be deserialized as soon as possible.
How does cluster selection in the proxy differ from HTTP to SIP?
In HTTP, clusters are typically selected by the application URIs they expose. In SIP, however, the URI typically does not dictate which cluster a server should go to. The applications are often grouped instead by functionality. For example, a set of applications that make up a presence and registrar system might be interested only in PUBLISH, SUBSCRIBE, and REGISTER methods, whereas a call control set of applications would be interested in INVITE messages.
As described in this Information Center article, the SIP side of the proxy has the ability to route to a cluster based on a variety of mechanisms, including the message type explained in my example. The HTTP side of the proxy, however, will primarily route based on the URI exposed by the Web applications.
WebSphere Application Server provides a robust Session Initiation Protocol (SIP) Servlet implementation which is further enhanced by the WebSphere eXtreme Scale and WebSphere Virtual Enterprise products. Hopefully, these answers addressed some of your own frequently asked questions about this support. Check out the resources below to get more information.
-
Session
Initiation Protocol in WebSphere Application Server V6.1, Part 1: Introducing SIP
-
Session
Initiation Protocol in WebSphere Application Server V6.1, Part 2: Developing converged applications
- Redbook:
Developing
SIP and IP Multimedia Subsystem (IMS) Applications
-
Developing RESTful SIP services for a high availability environment
-
Information Center: Learn
about SIP applications
-
Information Center: SIP industry standards compliance
-
Information Center: Using
ObjectGrid for SIP session management (WebSphere eXtreme Scale)
-
Information Center: WebSphere Virtual Enterprise documentation
-
IBM
developerWorks WebSphere
Erik 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.
