WebSphere most frequently asked questions about session initiation protocols

SIP FAQ

The Session Initiation Protocol (SIP) Servlet 1.0 Support (JSR 116) was added for the first time in IBM WebSphere application Server V6.1. Since then, SIP functionality and a number of issues with respect to detail have been increasing. Here are some of the most common questions I've heard about the support of SIP Servlet 1.0 and provide some good reference links to help you answer many other questions.

Which versions of WebSphere application Server have SIP Servlet functionality?

IBM WebSphere Application Server V6.1 Basic and Express editions have independent SIP Servlet support, but do not provide high availability support. The WebSphere Application Server V6.1 network deployment has high-availability features, including a stateless SIP agent, which provides session association support for application server instances. The WebSphere application Server V7 also provides SIP Servlet functionality.

Does the WebSphere Virtual Enterprise and WebSphere eXtreme Scale include SIP functionality?

Yes, both products provide SIP deployment capabilities for the application server.

WebSphere Virtual Enterprise increases the functionality of the SIP agent and application server, improving the manageability and quality of the services provided by the basic WebSphere application server. A feature of the WebSphere Virtual Enterprise to enhance the management capabilities of SIP applications is the ability to seamlessly upgrade applications and still support existing applications. Another feature is intelligent admission Control, which monitors resources and manages service policies and quality levels on backend application servers by user sessions to ensure that appropriate decisions are taken to ensure that end-to-end latency targets are met. Many of the other features of the WebSphere Virtual Enterprise apply to all applications and application servers, such as virtualization, application placement, and server health management.

WebSphere EXtreme Scale provides better quality of SIP session replication services. In addition, there are more options available on the high-availability topology design than the basic WebSphere application Server. To improve service quality, WebSphere EXtreme Scale provides asynchronous and synchronous replication, allowing replication between sessions to ensure the required service levels.

Can I bind an EJB association with a SIP association?

For stateless session beans (stateless sessions bean,slsb), there is no association or association mechanism, so SLSB requests cannot be bound to the SIP association. For stateful session beans (StateFul sessions BEAN,SFSB), the state after the first access bean is persisted. This means that SFSB is often used in situations where SFSB starts a dialog box and may want to expose the action in this dialog box.

In this case, when SFSB creates a dialog box, you can be sure to call SFSB with the same computer that owns the SIP dialog box. Our SFSB implementation in the WebSphere application Server uses the same data replication service as the SIP-Replication Service,drs. A common setting for SIP DRS is to simply configure two servers for each replication domain, essentially supporting peer-to-peer replication only. In order to implement this SIP-SFSB binding, this setting will have to be made. Then, if you set up the SFSB replication domain in the same way, the stateful Bean will always be on the same computer in the Startup dialog box. If a failover occurs, the SFSB and SIP sessions fail over to the only peer in their replicated domain.

Do you support X standard?

We have implemented and tested a large number of standards. We have listed these standards in the Product Information Center. We actually split the standard list into two groups:

The first group is the standard that we have supported and tested. These standards may still require the application to do something to ensure compliance, but because of the need to make changes to the container or proxy server, we have tested it to ensure compliance. However, this is not a complete list of criteria that may be used for WebSphere application Server.

There is also a table that contains the criteria that applications on the WebSphere application server can support without changing the application server. Many of the IETF standards that are being introduced do not require changes to the application server, but application changes are required to ensure that the specification is followed when running on the application server.

Can we modify the system Header on the SIP message?

Although the JSR 116 specification does not allow this, many people are asking for this functionality. You can configure enable.system.headers.modify custom properties on the SIP container, which allows the application to modify headers that cannot be changed in other cases. For more information on how to configure this, see WebSphere application Server Information Center.

Do you have any public information about the performance of the SIP in WebSphere application Server?

There is currently no performance benchmark for the SIP Servlet application Server, which means it is extremely difficult to compare the performance of an application server against other application servers based on currently available data. In a press release a year ago, we published the following performance information:

"The WebSphere application Server 6.1.0.11 uses Red Hat Linux and is integrated into the IBM BladeCenter HT Suite; This suite is compatible with network device Building Systems (Network equipment Buildi Ng System,nebs, which implements the industry-leading SIP performance metric of 1296 calls per second, uses the 13-way message SIP invocation model (holding time of 80 seconds), equivalent to each blade over 4.6 million peak call attempts. By using this call model in a highly available carrier-level configuration, WebSphere application Server implements 660 session replication calls per second for each blade. These results are also maintained at very low end-to-end SIP message processing latency, with a 95% delay of less than 50 milliseconds. This fully demonstrates the ability of WebSphere application Server to handle call volume business requirements and ensure quality of service. ”

This is all done on the HS21 XM Blade, which is a dual-CPU four-core 2.33 GHz system. There is currently no performance data for WebSphere application Server V7.