Questions about the SIP Session Initiation Protocol

Previously, we handled some application problems related to the SIP Session Initiation Protocol. Many solutions are summarized. I wonder if you have mastered it. See Basic Q & A of the SIP Session Initiation Protocol. Let's add more content in this article.

Is X standard supported?

We have implemented and tested a large number of standards. We listed these standards in the Product Information Center (see references). We actually divided the standards List into two groups:

The first group is the standards that we have supported and tested. These standards may still require some operations by the application to ensure compliance, but because changes need to be made to the container or proxy server, therefore, we tested it to ensure compliance. However, this is not a complete list of standards that may be used for WebSphere Application Server ｡

There is also a table, this includes standards that can be supported by applications on WebSphere Application Server without changing the Application Server. Many of the increasingly popular IETF standards do not need to be changed on the Application Server, however, application changes are required to ensure that the runtime on the Application Server complies with the specifications ｡

Can we modify the system Header on the message of the SIP Session Initiation Protocol?

Although JSR 116 does not allow this, many people require this feature. enable can be configured on the SIP container. system. headers. modify custom attribute, which allows applications to modify headers that cannot be changed in other cases. For more information about how to configure this, see WebSphere Application Server Information Center ｡

Do you have any published performance data about the SIP Session Initiation Protocol in WebSphere Application Server?

Currently, there is no SIPServlet application server performance benchmark, which means it is extremely difficult to compare the performance of an application server based on the currently available data with other application servers. In a press release a year ago, we have published the following performance information:

"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 Equipment Building systems (NEBS ), it provides industry-leading SIP Performance Indicators for 1296 calls per second. It uses a 13-channel message SIP call model (with a holding time of 80 seconds ), this is equivalent to an attempt to call more than 4.6 million of each blade during peak hours. By using this call model in high-availability carrier-level configuration, webSphere Application Server implements 660 session replication calls per second for each blade. When these results are achieved, it also maintains extremely low end-to-end SIP Message Processing latency, the latency of 95% is less than 50 milliseconds, which fully demonstrates the ability of WebSphere Application Server to process the call volume business needs and ensure service quality ｡"

This is all done on HS21 XM Blade, which is a dual-CPU quad-core 2.33 GHz system. Currently, there is no performance data for WebSphere Application Server v7 ｡

What new SIP Session Initiation Protocol features are added to WebSphere Application Server V7?

If you contact this version for the first time, you will find that we have added support for the following RFC:

3263 -- search for the SIP Server (LocatingSIPServers)

3311--SIP Update method (TheSIPUpdate method)

3325 -- Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks)

3891--replace Header (TheSIPReplaces Header) with SIP)

3911--SIP joint Header (TheSIPJoin Header)

4475--SIP Torture Test Messages)

WebSphere Application Server V6.1 supports RFC 3263, except section 5th; Support for section 5th has been added in WebSphere Application Server V7. Unfinished RFC (SIP "distortion test" message) we will discuss more about testing, rather than functions. This test is combined with a very strict telecom operator-Level Test to help WebSphere Application Server V7 become the most stable SIP Application Server in the market ｡

Apart from other standard support, the proxy for the SIP Session Initiation Protocol located before the application server has multiple enhancements. It now supports the DMZ deployment discussed here, the proxy server cluster can be created after the firewall and the load balancing can be improved to further reduce call loss in some errors associated with the re-transmission. In the aggregation Servlet container, you will notice that digest authentication support has been more clearly integrated into WebSphere Application Server V7 than in V6.1 ｡

Can HTTP and SIP sessions be stored together?

As described in the second part of this article, in an aggregate application, HTTP and SIP sessions are bound together for failover. Therefore, whether an HTTP message or a SIP message is received after a failover, It is routed to the same computer ｡

In this case, there is a fundamental difference between HTTP sessions and SIP sessions. Because of the nature of the Protocol, the SIP Session Initiation Protocol must adopt "active" failover, HTTP failover is usually more passive. Before a new HTTP request is passed in, you do not need to access the HTTP session, and the SIP session has an associated timer, it will need to be activated immediately after failover. This means that objects in the HTTP session may not be deserialized in the new container before access, and objects in the SIP session will be deserialized as soon as possible ｡

What is the difference between Cluster Selection in HTTP and SIP Proxies?

In HTTP, the cluster is usually selected by its public application URI. However, in SIP, the URI usually does not indicate the cluster to which the server should enter. Applications are often grouped by function. For example, the application assembly that makes up the online status and registration center system may be only interested in the PUBLISH, SUBSCRIBE, and REGISTER methods, and the call control set of the application will be interested in INVITE messages ｡

As described in this information center article, the proxy's SIP Session Initiation Protocol side has the ability to route to the cluster based on various mechanisms, including the message types described in my example, the HTTP side of the proxy is mainly based on the URI exposed by the Web application ｡

Summary

WebSphere Application Server provides reliable Session Initiation Protocol (SIP) Servlet implementation, the WebSphere eXtreme Scale and WebSphere Virtual Enterprise products are further enhanced. We sincerely hope that the content in this article will answer your own FAQs about this support ｡