PM36035: SIP RE-SENDS CANCEL WHEN RECEIVING 2ND PROVISIONAL RESPONSE

Fixes are available

APAR status

Closed as program error.

Error description

Product Version:  7.0.0.13
Operating System and Additional Information:
Linux, version 2.6.18-194.17.4.el5

Example scenario:

UAC          Proxy          UAS
|             |             |
1  |-- INVITE -->|             |
2  |<-- 100 I ---|-- INVITE -->|
3  |             |<-- 180 I ---|
4  |<-- 180 I ---|             |
|             |             |
5  |-- CANCEL -->|             |
6  |<-- 200 C ---|-- CANCEL -->|
7  |             |<-- 100 I ---|
8  |             |-- CANCEL -->|
|             |             |
9  |             |<-- 200 I ---|
10  |<-- 200 I ---|             |
11  |             |<-- 200 C ---|
|             |             |
12  |             |<-- 200 I ---|
13  |<-- 200 I ---|             |

Note the problem starts at message (7) where the UAS sends a
provisional response after it received a CANCEL. This is not a
bug, it is a race condition in the network, where the downstream
CANCEL request (6) and the upstream Trying response (7) cross
each other on the wire.
However, this exposes a bug in the Session Initiation Protocol
(SIP) container, which re-sends the CANCEL in (8). The
container should not re-send the CANCEL just because it
received another provisional response.

Local fix

Problem summary

****************************************************************
* USERS AFFECTED:  Session Initiation Protocol (SIP) users     *
*                  of IBM WebSphere Application Server V7.0    *
****************************************************************
* PROBLEM DESCRIPTION: CANCEL is sent out twice                *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
The problem occurs in a call flow such as this.

   UAC          Proxy          UAS
    |             |             |
 1  |-- INVITE -->|             |
 2  |<-- 100 I ---|-- INVITE -->|
 3  |             |<-- 100 I ---|
 4  |-- CANCEL -->|             |
 5  |<-- 200 C ---|-- CANCEL -->|
 6  |             |<-- 180 I ---|

There is a "race condition" between steps 5 and 6 - sending a
CANCEL (5) and receiving a second provisional response (6).
These two steps are run in two different threads. Each thread
first checks if a CANCEL was already sent, then sends out the
CANCEL, and then updates the state machine about having sent
the CANCEL. Because of a bug, this procedure is not
"synchronized", that is, it is not guaranteed to run as one
atomic operation. As a result, specific thread timing
conditions may cause both threads to send out the CANCEL,
concurrently.

Problem conclusion

The bug is fixed in the SIP container. With this fix, the race
condition is eliminated, and the CANCEL is sent out once only,
irrespective of thread or timing.

The fix for this APAR is currently targeted for inclusion in
fix pack 7.0.0.19.  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
PM36035
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
2011-03-31
Closed date
2011-05-18
Last modified date
2011-06-18

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

PM36185

Fix information

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

Applicable component levels

R700 PSY
UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"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:
27 October 2021

Tips

PM36035: SIP RE-SENDS CANCEL WHEN RECEIVING 2ND PROVISIONAL RESPONSE

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?