PK72132: THIS APAR ADDRESSES MULTIPLE SESSION INITIATION PROTOCOL (SIP) PROXY ISSUES IN V7.0.

Fixes are available

APAR status

Closed as program error.

Error description

This APAR addresses the following SESSION INITIATION PROTOCOL
(SIP) proxy problems:
- TCP traffic not routed to UAS when proxy is present.
- SIP proxy load balancing is not evenly distributed when
there are servers down in the cluster.
- Invalid call made to WsByteBuffer
- SIP Router that's embedded in application server container on
z/OS needs to use the configured High Availability group name
for replication.
- SIP proxy UDP lockup on container facing UDP port.
- Proxy recovery detecting overload on a few servers.
- z/OS SIP servant failover not working

Local fix

Problem summary

****************************************************************
* USERS AFFECTED:  All users of WebSphere Application Server   *
*                  V7.0                                        *
****************************************************************
* PROBLEM DESCRIPTION: Various issues uncovered in SIP 7.0     *
*                      GA related to SIP.                      *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
All the issues in the error description have been resolved.

- TCP Traffic not being routed to UAS when proxy is present
issue has to do with the SIP proxy not correctly supporting
multiple inbound interfaces.  The SIP proxy was not setting
the local interface to send the outbound request to the UAS.

- SIP proxy load balancing is not evenly distributed when
there are servers down in the cluster.  When multiple
application servers are down in a cluster, there was some
situations where the SIP proxy would have an uneven
distribution of calls sent to the application servers that
were up.   Depending on the call rate, this caused the proxy
to cause overload situations on some application servers.

- Invalid call made to WsByteBuffer.  Upon startup of the SIP
proxy or SIP container, there was an intermittent exception in
the SystemErr.log file.  java.lang.RuntimeException: Invalid
call to WsByteBuffer method.  Buffer has already been released.

- SIP Router that's embedded in app server container on Z/OS nee
ds to use the configured High Availability group name for
replication.  The SIP Router on Z/OS now correctly uses the
configured High Availability group name for replication to
other servers using this group name.

- SIP proxy UDP lockup on container facing UDP port.  An
exception was being thrown and caught in the UDP Channel's
WorkerThread object and was not correctly decrementing the
number of WorkerThread's currently in use.   When the last
WorkerThread exited because of inactivity on that UDP port,
there was no code to start any other WorkerThread's and no
data was ever read again from that port.

- Proxy recovery detecting overload on a few servers.  When a
SIP proxy was brought up with SIP messages already flowing, the
SIP proxy's overload control configuration code was receiving
information about SIP containers coming up in the configured
cluster before all the configuration code had been run.  This
caused some SIP containers to be configured incorrectly and
caused a false overload condition in those SIP containers that
were incorrectly configured.

- Z SIP servant failover not working.  When an servant
terminates, the control region should leave the HA group if no
other servants are running in the app server.   The problem
occurred because the control region remained in the high
availability group and the other members of the group didn't
know to start the failover process.

Problem conclusion

The TCP issue was caused by not correctly binding to the
interface used to communicate with the SIP containers.

The load balancing issue was resolved by using a different
algorithm to use when one or more servers are not running.

The Invalid call made to WsByteBuffer was resolved by ensuring
that the UDP channel is not passing up "stale" buffers that
have already been released.

The SIP Router on Z/OS now correctly retrieves the configured
HA group name from the configuration.

The UDP channel lockup when the SIP proxy is under a large
amount of stress has been resolved.

The overload control algorithm's configuration now is
correctly initialized before any possible app servers come up.

The Z/OS servant failover now correctly detects the servant
being down and notifies other members of the high availability
group.

The fix for this APAR is currently targeted for inclusion in
fixpack 7.0.0.1.  Please refer to the Recommended Updates
page for delivery information:
http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980

Temporary fix

Comments

APAR Information

APAR number
PK72132
Reported component name
WEBS APP SERV N
Reported component ID
5724H8800
Reported release
700
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2008-09-15
Closed date
2008-10-29
Last modified date
2008-10-29

APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:

Fix information

Fixed component name
WEBS APP SERV N
Fixed component ID
5724H8800

Applicable component levels

R700 PSY
UP

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
23 October 2021

Tips

PK72132: THIS APAR ADDRESSES MULTIPLE SESSION INITIATION PROTOCOL (SIP) PROXY ISSUES IN V7.0.

Fixes are available

Subscribe

APAR status

Closed as program error.

Error description

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

APAR number

Reported component name

Reported component ID

Reported release

Status

PE

HIPER

Special Attention

Submitted date

Closed date

Last modified date

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Fix information

Fixed component name

Fixed component ID

Applicable component levels

R700 PSY

Document Information

Share your feedback

Need support?