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

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 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         *
  *                  Feature Pack for Communications Enabled     *
  *                  Applications (CEA).                         *
  ****************************************************************
  * 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 executed 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 execute
  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,
  irrespectively of thread or timing.
  
  The fix for this APAR is currently targeted for inclusion in
  fix pack 1.0.0.11 for the Feature Pack for Communications
  Enabled Applications. Please refer to the Recommended Updates
  page for delivery information:
  http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg27017328
  

Temporary fix

Comments

APAR Information

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

  PM36035

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

Fix information

• Fixed component name

  CEA FEATUREPACK

• Fixed component ID

  5724J0855

Applicable component levels

• R700 PSY

     UP