LO73991: PSP COMPONENT OF BL SERVICE MANAGES INCORRECTLY USEROFFLINE EVEN T WHEN THE LAST DISCONNECTED USER'S LOGIN IS A PASSIVE LOGIN

APAR status

• Closed as program error.

Error description

• Sametime users status looks like incorrect to their buddies
  shortly after
  restarting Telephony server that is deployed in the customer
  environment. CTI
  server invokes Sametime JavaToolkit TelephonyAdapterService
  APIs.
  The traces show that SM component stops getting the user status
  change
  notifications from PSP. When watchers add the CTI user to the
  contact list, his
  status is shown correctly.
  
  The exact scenario is:
  1. CS is restarted.
  2. CTI server is restarted, CTI server connects CTI users (that
  also Sametime
  users) to the CS by performing passive logins.
  3. CTI users connect to the CS using the embedded client.
  4. CTI users log out from the CS using the embedded client.
  5. Passive logins are disconnected due to CTI server
  restarting.
  
  Working flow:
  When a passive login of a user is disconnected, OnlineDirectory
  service sends
  the appropriate UserOffline notification to PSP BL service that
  keeps the users
  status and attributes values.
  PSP verifies that the user status is changed to "offline" and
  then forwards
  UserOffline event to SM. Nothing done if the status is not
  changed ***.
  When SM gets the event, it changes the user location state from
  LOCATION_FOUND
  to LOCATION_OFFLINE and sends ALERT request to OnlineDirectory
  service to be
  notified when this user is logged in again.
  Once such a notification is received, SM changes the user
  location state to
  LOCATION_FOUND and sends SUBSCRIBE request to PSP to be notified
  on any user
  status/attribute changes.
  
  The issue:
  When the passive login got disconnected, PSP doesn't detect the
  user status
  updating, since the user status already got updated to OFFLINE
  when the
  previous login of the user (the embedded client login) was
  disconnected. The
  passive login doesn't provide any status.
  Then PSP doesn't send UserOffline event to SM. Therefore the
  flow above (see
  ***) is broken.
  When the user connects to the CS again, SM doesn't get
  notification about his
  status changes anymore since SM didn't send SUBSCRIBE request to
  PSP.
  SM still forwards FETCH request to PSP about this user since the
  old
  "LOCATION_FOUND" state is in place and the FETCH requests are
  sent to the same
  PSP as before. It explains why the watcher users get initial
  status of
  CTI-users correctly when the watchers just log to the CS.
  
  The issue is reproduced in the lab.
  

Local fix

• restart the CS Server
  

Problem summary

• A programming error was found and will be corrected in a future
   release.
  

Problem conclusion

• A programming error was found and will be corrected in a future
   release.
  

Temporary fix

Comments

• This APAR is associated with SPR# IMAN936LNV.
  A programming error was found and will be corrected in a future
   release.
  

APAR Information

• 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

  LOTUS SAMETIME

• Fixed component ID

  5724J2300

Applicable component levels

• R852 PSN

     UP